The migration seemed straightforward. Move DNS to a new provider, update the nameservers, done. Except someone forgot to recreate the SPF record. For three days, every email from the company failed authentication. Deliverability tanked. Customer complaints piled up. All because of a missing TXT record.
Email and DNS are deeply intertwined. MX records tell the world where to deliver your mail. TXT records handle authentication. CNAME records enable tracking and custom domains. Miss any of them, and email breaks in ways that aren't always obvious.
This checklist covers every DNS record that affects email, from the essential to the optional-but-recommended.
Essential records
MX records. Mail Exchanger records tell sending servers where to deliver email for your domain. Without MX records, you can't receive email. Most setups have multiple MX records with different priorities for redundancy.
example.com. MX 10 mail1.example.com.
example.com. MX 20 mail2.example.com.
The number is priority—lower numbers are tried first. If mail1 is unavailable, senders try mail2.
SPF record (TXT). Sender Policy Framework declares which servers can send email as your domain. It's a TXT record that lists authorized IP addresses and includes for third-party services.
example.com. TXT "v=spf1 include:_spf.google.com include:amazonses.com -all"
The -all at the end means "reject anything not listed." Use ~all (soft fail) only during initial setup.
DKIM records (TXT or CNAME). DomainKeys Identified Mail uses public key cryptography to sign emails. The public key is published in DNS so receivers can verify signatures. The record name includes a selector that identifies which key to use.
selector._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."
Some providers use CNAME records that point to their hosted keys instead of publishing the key directly.
DMARC record (TXT). Domain-based Message Authentication, Reporting, and Conformance ties SPF and DKIM together and tells receivers what to do with failures.
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
The p= value is your policy: none (monitor only), quarantine (send to spam), or reject (block entirely).
Recommended records
Reverse DNS (PTR). PTR records map IP addresses back to hostnames. Many receiving servers check that your sending IP has a PTR record and that it resolves back to the IP. Without proper reverse DNS, your emails may be rejected or flagged as spam.
PTR records are set by whoever controls the IP address—usually your hosting provider or ISP, not in your domain's DNS.
MTA-STS records. Mail Transfer Agent Strict Transport Security tells sending servers to require TLS when delivering to your domain. It prevents downgrade attacks where attackers force unencrypted delivery.
_mta-sts.example.com. TXT "v=STSv1; id=20240115"
You also need to host a policy file at https://mta-sts.example.com/.well-known/mta-sts.txt.
TLS-RPT record (TXT). TLS Reporting tells senders where to send reports about TLS connection failures. It helps you identify delivery problems caused by TLS issues.
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:[email protected]"
BIMI record (TXT). Brand Indicators for Message Identification displays your logo in supporting email clients. It requires DMARC enforcement and, for full support, a Verified Mark Certificate.
default._bimi.example.com. TXT "v=BIMI1; l=https://example.com/logo.svg"
Service-specific records
Email provider verification. Most email providers require you to add TXT or CNAME records to verify domain ownership. Google Workspace, Microsoft 365, and others each have their own verification records.
Tracking domain CNAMEs. Email services that track opens and clicks often use CNAME records to enable custom tracking domains. Instead of links pointing to track.emailprovider.com, they point to click.yourdomain.com.
click.example.com. CNAME track.emailprovider.com.
Custom return path. Some providers use CNAME records for custom return-path domains, which helps with SPF alignment and deliverability.
Security records
DANE records (TLSA). DNS-based Authentication of Named Entities provides certificate pinning for email. It's more complex than MTA-STS but provides stronger security guarantees. Requires DNSSEC.
_25._tcp.mail.example.com. TLSA 3 1 1 abc123...
CAA records. Certificate Authority Authorization specifies which CAs can issue certificates for your domain. While not email-specific, it protects the certificates your mail servers use.
example.com. CAA 0 issue "letsencrypt.org"
Verification checklist
After setting up or modifying DNS records, verify everything works:
MX records resolve. Use dig MX example.com or MXToolbox to verify MX records exist and point to valid, reachable servers.
SPF is valid. Use an SPF checker to verify syntax, lookup count, and that all your senders are included. Send a test email and check the Authentication-Results header.
DKIM keys are published. Use a DKIM checker with your selector to verify the public key is accessible. Send a test email and verify the DKIM signature validates.
DMARC is published. Use a DMARC checker to verify the record exists and is syntactically valid. Verify you're receiving aggregate reports at the specified address.
Reverse DNS is configured. Use dig -x [your-ip] to check PTR records. Verify the returned hostname resolves back to your IP.
TLS is working. Use CheckTLS or similar to verify your mail server accepts TLS connections and has a valid certificate.
Common mistakes
TTL too high during changes. If you're making DNS changes, lower TTL first (to 300 seconds or less), wait for the old TTL to expire, make changes, then raise TTL again. High TTL during changes means long propagation delays.
Forgetting trailing dots. In zone files, hostnames should end with a dot (e.g., mail.example.com.). Without the dot, the zone name gets appended, creating invalid records.
Conflicting records. You can only have one SPF record per domain. Multiple SPF records cause failures. If you need to authorize multiple services, combine them into one record.
Stale records after migrations. When changing email providers, old records (MX, SPF includes, DKIM keys) need to be removed. Stale records cause authentication failures or route email to decommissioned servers.
Frequently asked questions
How long do DNS changes take to propagate?
It depends on TTL (Time To Live). Records are cached for their TTL duration. If TTL is 3600 (1 hour), changes may take up to an hour to propagate globally. Lower TTL before making changes to speed propagation.
Do I need all these records?
MX, SPF, DKIM, and DMARC are essential for modern email. MTA-STS and BIMI are recommended but not required. DANE is optional and requires DNSSEC. Service-specific records depend on what services you use.
What happens if I mess up a DNS record?
It depends on the record. Wrong MX records mean you can't receive email. Wrong SPF/DKIM means authentication failures and potential spam filtering. Always test changes in a staging environment or with low TTL so you can quickly revert.
Should I use my registrar's DNS or a dedicated DNS provider?
Dedicated DNS providers (Cloudflare, Route 53, etc.) typically offer better performance, more features, and better management interfaces. For critical email infrastructure, the reliability and features of dedicated DNS are worth the complexity.