Email uses five DNS record types and each answers a different question. MX: which servers accept mail for this domain. A and AAAA: what IP does this hostname have. CNAME: this name is an alias for that one. TXT: arbitrary strings, which is where SPF, DKIM and DMARC live. PTR: what hostname does this IP claim, published by whoever owns the IP rather than by you.
MX records: where mail is delivered
An MX record names a hostname that accepts mail for your domain, with a priority number.
dig +short MX yourdomain.com 10 mx1.provider.net. 20 mx2.provider.net.
- Lower numbers win. A sender tries priority 10 first and only falls back to 20 if it cannot connect. People read this backwards surprisingly often.
- Equal numbers mean round-robin across the hosts at that priority — the usual way to spread load.
- MX targets must be hostnames with A or AAAA records. Never an IP address, and not a CNAME: pointing an MX at a CNAME is non-conformant and some senders refuse it.
- No MX record means senders fall back to the A record of the domain itself. This is legacy behaviour you should not rely on; publish MX records explicitly.
- A domain that only sends needs no MX for sending to work — but publish one anyway, pointing at a mailbox that accepts bounces and replies. A
Fromaddress that cannot receive mail is both a deliverability signal and a practical failure.
Typical values look like yourdomain-com.mail.protection.outlook.com for Microsoft 365, or the aspmx family for Google Workspace. Always take the exact value from your provider's own setup screen; they differ by tenant and region.
How the lookup actually happens
A sending server resolving yourdomain.com does not ask one machine. Its resolver walks the hierarchy: root nameservers, then the .com nameservers, then the nameservers your registrar has delegated your domain to, which answer authoritatively. Each answer carries a TTL in seconds, and resolvers cache it for that long.
Two consequences worth internalising:
- There is no such thing as propagation delay, only caching. Your change is live at your authoritative nameservers immediately. What you are waiting for is other resolvers' caches expiring. Lower the TTL to 300 seconds *before* a planned change, make the change, then raise it back to 3600.
- Query authoritatively when you need the truth.
dig MX yourdomain.com @ns1.yourdnshost.comskips every cache. Compare that withdig MX yourdomain.com @8.8.8.8to see what the rest of the world still believes.
A and AAAA records
An A record maps a hostname to an IPv4 address; AAAA does the same for IPv6. In an email system they do two jobs:
- Resolve your MX targets. An MX pointing at a hostname with no A record is a dead end.
- Forward-confirm your sending host. The hostname your server announces in its SMTP
EHLOmust resolve to the IP it is connecting from. Receivers check this.
If you publish AAAA records for a sending host, be aware that IPv6 senders are held to a stricter standard by large receivers — several require valid reverse DNS and passing authentication on IPv6 before they will accept mail at all. Publishing AAAA for a mail host you have not fully configured for IPv6 is a common self-inflicted wound.
A record vs CNAME
A CNAME says "this name is an alias; go look up that other name instead". Use each one deliberately:
| Use an A record | Use a CNAME |
|---|---|
| MX targets | autodiscover, autoconfig and similar service aliases |
| The hostname in your SMTP banner | Vendor-delegated DKIM selectors |
| Any name that needs a matching PTR | SPF or Return-Path delegation to a sending platform |
| The zone apex | Tracking-link subdomains |
Hard rules: a CNAME cannot coexist with any other record type at the same name, and it cannot be placed at the zone apex — which is why apex MX and TXT records always sit alongside an A record, never a CNAME. Some DNS hosts offer ALIAS or flattened-CNAME types to work around the apex restriction; those are vendor features, not DNS ones.
CNAMEs also cost an extra lookup. That is irrelevant for a web host and relevant inside an SPF record, where every DNS-querying mechanism counts against a hard limit of 10.
TXT records: authentication lives here
Three strings, three different names:
dig +short TXT yourdomain.com # v=spf1 ... — one record only dig +short TXT selector._domainkey.yourdomain.com # v=DKIM1; k=rsa; p=... dig +short TXT _dmarc.yourdomain.com # v=DMARC1; p=...
Only one v=spf1 record may exist per name — two is a specification violation that makes receivers return PermError and ignore SPF entirely. DKIM, by contrast, can have as many selectors as you have platforms, each at its own _domainkey name. And only one DMARC record may exist at _dmarc.
Underscore-prefixed names are the records DNS migrations lose. If authentication broke after a nameserver change, check _domainkey and _dmarc first.
PTR records: the one in someone else's zone
A PTR maps an IP back to a hostname, and it lives in the in-addr.arpa hierarchy delegated to whoever owns the address block. You request it from your hosting provider; records you create in your own zone for in-addr.arpa names are not authoritative and nobody will see them.
dig -x 203.0.113.9 +short
What receivers want is forward-confirmed reverse DNS — the IP resolves to a hostname and that hostname resolves back to the same IP — and they compare it with your SMTP banner. Generic PTRs containing dynamic, dsl or pool, or cloud-default names, are treated as consumer space and filtered accordingly. If you send through a hosted platform, the PTR belongs to the platform's IPs and is not yours to manage.
A verification pass that takes two minutes
dig +short MX yourdomain.com dig +short A mail.yourdomain.com dig +short TXT yourdomain.com dig +short TXT _dmarc.yourdomain.com dig -x 203.0.113.9 +short dig MX yourdomain.com @ns1.yourdnshost.com
What not to do
- Do not put an IP address in an MX record, or point an MX at a CNAME.
- Do not keep a cheap "backup MX" on a server with no recipient list. It accepts mail for addresses that do not exist and generates backscatter.
- Do not leave the previous provider's MX records in place after a migration. A share of your mail will be delivered somewhere nobody looks.
- Do not chase propagation with repeated edits. Query authoritatively and wait out the TTL.
- Do not proxy authentication records through a CDN. They must be DNS-only or the delegation returns the wrong answer.
MailPilot checks the SPF, DKIM and DMARC records behind every connected mailbox and measures per-provider inbox placement with a seed-inbox network, so a DNS mistake shows up as a failing check and a measurable placement drop rather than as mail that quietly stops arriving.
Ready to reach the inbox every time?
Automated email warmup across real peer mailboxes. Live inbox placement monitoring. Free 7-day trial - no credit card required.
Start free trial