Foundational explainer
Email DNS records explained: MX, SPF, DKIM, and DMARC
Understand how DNS routes incoming mail and publishes sender authentication without confusing MX records with SPF, DKIM, or DMARC.
- Format
- Learn · Beginner
- Published
- Published
- Updated
- Updated
- Reading time
- 2 min read
Key takeaways
- MX controls incoming routing; it does not authorize outgoing mail.
- SPF, DKIM, and DMARC use DNS to publish authentication information and policy.
Email leans on a small cast of DNS records, each with a different job — and mixing them up has consequences ranging from immediately obvious to invisible for weeks. Change the wrong one and incoming mail stops, outgoing mail fails authentication, or your spoofing protection quietly evaporates. Here’s what each record actually does.
MX routes incoming mail
Mail exchange (MX) records identify the servers that accept mail for a domain. Each record has a preference number; senders normally try lower values first.
example.com. MX 10 mx1.mail-provider.example.
example.com. MX 20 mx2.mail-provider.example.The targets must be hostnames, not IP addresses. Those hostnames resolve separately to addresses. Multiple MX records are useful only when the listed systems are configured to accept the domain’s mail.
SPF authorizes sending infrastructure
Sender Policy Framework uses a TXT record on the envelope-from domain. It lists addresses or provider domains permitted to send. SPF does not read the visible From header by itself, and forwarding can break the original path.
Publish one SPF policy per hostname. Multiple separate v=spf1 records cause a permanent error.
DKIM signs outgoing messages
DomainKeys Identified Mail adds a cryptographic signature to outgoing messages. The receiving system retrieves the public key from a selector under _domainkey and verifies that signed portions have not changed.
selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=..."The sending provider holds the private key. Multiple selectors allow key rotation and different sending systems.
DMARC evaluates alignment and sets policy
DMARC is published at _dmarc.example.com. It checks whether a passing SPF or DKIM identity aligns with the domain visible in the From header, then applies the published monitoring or enforcement policy.
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"Begin with monitoring, review reports, then tighten policy after legitimate senders align.
Other records may be involved
Mail providers can require verification TXT or CNAME records, autodiscovery names, return-path records, and provider-specific DKIM selectors. Follow the provider’s current instructions and document ownership and purpose for each record.
Safe change procedure
- Export the current zone and record TTLs.
- Inventory incoming and outgoing providers.
- Add provider-supplied records without deleting unrelated values.
- Verify authoritative DNS with
dig. - Send and receive test messages, then inspect full headers.
- Monitor bounces, authentication results, and DMARC reports.
- Remove old records only after the former provider is fully retired.
Use the authentication guide for implementation and email troubleshooting when delivery fails.
Sources and further reading
Related guides
Set up email authentication with SPF, DKIM, and DMARC
Inventory senders, publish one SPF policy, enable DKIM signing, deploy DMARC reporting, and tighten enforcement after verifying alignment.
Troubleshoot email delivery problems
Use bounce codes, message headers, DNS, authentication, logs, reputation, and content evidence to diagnose missing or spam-folder email.
What is DNS? A practical explanation
Understand how resolvers, nameservers, zones, records, and caching work together to connect a domain name to websites and email.