A mailbox such as info@yourcompany.com instead of yourcompany@gmail.com is a basic sign of a serious business. To set it up you need the correct DNS records on the domain.
Minimum set of DNS records for mail
| Record | Purpose | Example |
|---|---|---|
| MX | Address of the mail server | mail.example.com (priority 10) |
| A | IP address of the mail server | mail IN A 192.168.1.1 |
| TXT (SPF) | Authorised senders | v=spf1 mx ~all |
| TXT (DKIM) | Digital signature of messages | Generated by the mail server |
| TXT (DMARC) | Handling policy | v=DMARC1; p=quarantine |
Setup for Google Workspace
# Google Workspace MX records
@ IN MX 1 aspmx.l.google.com.
@ IN MX 5 alt1.aspmx.l.google.com.
@ IN MX 5 alt2.aspmx.l.google.com.
@ IN MX 10 alt3.aspmx.l.google.com.
@ IN MX 10 alt4.aspmx.l.google.com.
# SPF for Google Workspace
@ IN TXT "v=spf1 include:_spf.google.com ~all"Setup for Zoho Mail (free plan)
# Zoho Mail MX records
@ IN MX 10 mx.zoho.eu.
@ IN MX 20 mx2.zoho.eu.
@ IN MX 50 mx3.zoho.eu.
# SPF for Zoho Mail
@ IN TXT "v=spf1 include:zoho.eu ~all"Setup for your own server (cPanel/Exim)
# MX record
@ IN MX 10 mail.example.com.
# A record of the mail server
mail IN A YOUR.SERVER.IP
# SPF (allow your own IP and the MX)
@ IN TXT "v=spf1 ip4:YOUR.SERVER.IP mx ~all"nslookup -type=MX example.comCommon Mail Delivery Errors
| Message or symptom | Cause | Fix |
|---|---|---|
| 550 5.7.1 SPF check failed | The sending server's IP is not listed in the domain's SPF record, or the SPF record has a typo in an include mechanism | Add the IP or the include for the relevant service to SPF, and check the syntax with an online SPF validator |
| 550 5.7.26 The message could not be authenticated over IPv6 without DKIM | Google requires DKIM for sending over IPv6; SPF alone is not enough | Enable and publish a DKIM record on the sending server |
| The message is delivered but marked as Spam with dmarc=fail | The DMARC policy is set to p=reject or p=quarantine, and SPF/DKIM fail alignment (the From domain does not match the signing domain) | Check that the domain in the From header matches the DKIM d= domain and the SPF-checked domain |
| Temporary failure in name resolution while sending | The MX record points to a name that does not resolve itself (no A record) or resolves with delay | Make sure the name in the MX record has a valid A record and is not a CNAME (the RFC forbids a CNAME as an MX target) |
| SPF Permerror: too many DNS lookups | The 10-DNS-lookup limit for SPF resolution (RFC 7208) is exceeded — usually because of a chain of nested includes | Reduce the number of includes, replace some mechanisms with direct ip4/ip6 entries |
DKIM: How to Check the Signature
DKIM adds a cryptographic signature to the message header. The public key is published in a TXT record shaped like selector._domainkey.example.com, where selector is an arbitrary name chosen by the mail server (for example, google or default).
# Check the public DKIM key for the "google" selector
dig TXT google._domainkey.example.com +short
# Check the Authentication-Results header on a received message
# (shows the SPF, DKIM and DMARC result on the recipient's side)If the selector is unknown, it can be found in the headers of any message sent from the domain: the DKIM-Signature: ... s=selector1 line carries the value you need.
DMARC: Reading the Policy
| p= value | Recipient action | When to use it |
|---|---|---|
| none | Reports only, messages are delivered as usual | The first rollout stage — collecting data without risking lost mail |
| quarantine | Messages that fail the check are placed in spam | After a week or two of clean none reports with no false positives |
| reject | Messages that fail the check are rejected outright | The final stage, once every legitimate sending source is covered by SPF/DKIM |
Jumping straight to p=reject without the intermediate none stage is a common cause of lost legitimate mail: any forgotten mailing service or CRM sending on the domain's behalf will start being rejected without warning.
When You Need a Separate Subdomain for Bulk Mail
- Transactional and marketing messages go through an external service (SendGrid, Mailgun) — the sending reputation of bulk mail should not affect the main domain's reputation
- Mail volume exceeds a few thousand messages a day — a sudden volume spike from the main domain can look like an anomaly to spam filters
- Different senders (support, billing, marketing) use different DKIM selectors and DMARC policies for independent reputation monitoring
- You need to test a new bulk mail provider without risking deliverability for the main domain
If mail still lands in spam after configuring SPF and DKIM, check the server's reverse DNS — see setting up a PTR record.
Frequently asked questions
What happens to existing mail if the MX records are changed without any preparation beforehand?
Changing MX records switches where new incoming mail gets delivered, but messages already sitting in mailboxes on the old service do not move anywhere automatically. Before switching, it helps to export the existing mail or set up parallel delivery on both servers during a transition window, otherwise messages sent while the records are changing can end up lost.
Does the old SPF record need to be removed when switching from one mail provider to another?
Yes, the old SPF record should be replaced or merged with the new include into a single record, rather than leaving two separate SPF TXT records — mail servers that see multiple SPF records for one domain treat that as invalid and may reject the mail. The correct approach is one TXT record listing every allowed sender through include.
How long does it take for DNS record changes for mail to take effect after saving them?
How long it takes depends on the TTL value of that record and on caching by access providers and mail servers along the way — changes are usually visible within a few hours, but full propagation across the internet can take longer. Before an important switch it helps to lower the record's TTL early, shortening the wait for the change.
Can several bulk mail services be used at the same time under one SPF record without exceeding the lookup limit?
Running several bulk mail services under the same domain works, but every include added to the SPF record increases the number of DNS lookups during a check, and going over the limit triggers a Permerror that can make mail from the domain fail validation. To stay within the limit, point services directly to an IP address instead of nesting includes.