Email is a DNS application. The full record inventory a sending domain needs, the TTL strategy for safe changes, and the misconfigurations that quietly break delivery.
Strip email down and it is a DNS application with an SMTP delivery layer. Routing is MX records, authentication is TXT records, transport security policy is more TXT plus HTTPS, and identity verification runs through reverse DNS. When mail breaks and the MTA logs look innocent, DNS is the next suspect, and it is guilty more often than any other layer. This article is the working inventory and the failure catalog.
The full record inventory
A production sending domain accumulates more email DNS than most teams realize. Routing: MX records on every domain that receives mail, including the bounce subdomains that must accept asynchronous DSNs. Authentication: SPF TXT records per sending domain, DKIM TXT records per selector, a DMARC record per organizational domain and optionally per subdomain. Transport policy: the MTA-STS TXT record and its policy host, plus TLS-RPT. Branding: the BIMI record if you went down that road. And on the infrastructure side, forward and reverse DNS for every sending IP, matching each other, because providers check.
CNAME chains: convenience with failure modes
Vendors love CNAME delegation: point s1._domainkey.example.com at s1.dkim.esp.com and the ESP rotates keys without ever asking you for DNS changes again. The convenience is real and so is the coupling. Your authentication now resolves through infrastructure you do not operate, an extra lookup that can independently fail, and a vendor change that can break you without any modification on your side. The SubdoMailing-style takeovers of 2024 taught the sharper lesson: a CNAME pointing at an abandoned vendor hostname is a dangling delegation that an attacker can sometimes claim, inheriting whatever trust your subdomain carries.
The policy that follows: CNAME delegation to actively managed vendors is fine and normal; the audit obligation is yours. Quarterly, resolve every email-related CNAME end to end and confirm the target still belongs to a vendor you still use. Every delegation for a service you cancelled is a record to delete today. In addition, remember two protocol rules that CNAME setups trip over: no CNAME at a domain apex, and no CNAME coexisting with other record types at the same name, which is why apex SPF must be a literal TXT record.
TTLs: the change-management dial
TTL strategy for email DNS is simple and almost nobody does it. Steady state, email records want long TTLs, an hour to a day: resolution is overwhelmingly cache hits, your DNS provider's worst day matters less, and cached MTA-STS policies keep protecting you. Before a planned change, drop the affected records' TTLs to five minutes, wait out the old TTL so caches expire, make the change, verify, then raise TTLs again. The senders who skip the lowering step are the ones who discover that half the internet's resolvers hold the old DKIM key for another 23 hours while their mail fails validation.
The DKIM rotation pattern from our key rotation guide sidesteps TTL exposure entirely: publish the new selector, let it propagate at leisure, switch signing, and retire the old selector after the transition. Additive changes beat in-place edits wherever the protocol allows, because addition has no cache-coherency problem.
Failure modes from the field
Reverse DNS mismatches: the sending IP's PTR names a host whose A record points elsewhere, or worse, the PTR is the hosting provider's generic name. Many receivers score or refuse mail from generic rDNS, and forward-confirmed rDNS is table stakes for dedicated IPs. Oversized TXT responses: enough SPF includes and DKIM keys at one name and responses exceed UDP limits, forcing TCP fallback that some resolvers and firewalls handle badly; 2048-bit DKIM keys split across multiple quoted strings are the standard workaround. Truncated propagation: registrar consoles that silently strip the second string of a split TXT record, or add quotes, remain a depressingly regular DKIM outage cause.
And the quiet one: DNS provider outages during send windows. When your authoritative DNS is unreachable, receivers evaluating your mail get temperror on SPF and DKIM lookups, and mail defers or degrades globally in a way that looks like a reputation incident and is actually an availability incident. Redundant authoritative DNS across providers, or at minimum monitoring resolution from multiple external vantage points, is email infrastructure even though it never appears in the email budget.
The email DNS operations loop
- 1
Monitor resolution externally
Check MX, SPF, DKIM selectors, and DMARC records from outside your network on a schedule, alerting on changes and failures. dig from three clouds beats a dashboard that watches from inside.
- 2
Audit CNAME targets quarterly
Resolve every delegation end to end; delete anything pointing at cancelled vendors before someone else claims it.
- 3
Manage TTLs around changes
Lower before, verify after, raise when stable. Put it in the change checklist so it survives staff turnover.
- 4
Verify rDNS on every IP change
Forward-confirmed reverse DNS with a meaningful hostname on every sending IP, checked whenever infrastructure moves.
- 5
Watch temperror rates in DMARC reports
A temperror uptick in aggregate reports is external evidence of your DNS wobbling, often before your own monitoring notices.
Email DNS rewards the boring virtues: an inventory that is current, changes that follow the TTL ritual, delegations that get audited, and resolution that is watched from where the receivers stand. None of it is glamorous, and all of it is cheaper than the incident it prevents.
Frequently Asked Questions
Do I need DNSSEC for email?
How many MX records should a domain have?
Why does my DKIM record work at some receivers and fail at others?
Should email DNS live in infrastructure-as-code?
Key Takeaways
- A sending domain's email DNS spans routing, authentication, transport policy, branding, and reverse DNS; keep a living inventory
- CNAME delegation to vendors is normal and requires quarterly end-to-end audits to catch dangling targets
- Lower TTLs before planned changes and prefer additive changes like new DKIM selectors over in-place edits
- Forward-confirmed reverse DNS with meaningful hostnames is mandatory hygiene for dedicated sending IPs
- Monitor resolution from external vantage points and treat temperror spikes in DMARC reports as DNS health alerts
Related articles
Deliverability Postmortems: Learning From Incidents
The incident is over, placement recovered, and the pressure to move on is enormous. The blameless postmortem practice that converts each incident into prevention.
Backscatter: The Bounces You Never Sent
When spammers forge your domain as their envelope sender, the bounces come to you. What backscatter is, why it happens, and how to stop causing and receiving it.
DNSSEC for Email Operators: Worth It, and How Not to Break Everything
Every email trust decision resolves through DNS, and DNSSEC is what makes those answers tamper-proof. What it buys email, what DANE requires, and safe operations.