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
Greylisting, Tarpitting, and Other Receiver Defenses Senders Should Understand
Receiving servers defend themselves with deliberate delays, temporary rejections, and traps for impatient senders. How each defense works and how a good MTA passes them.
Building a Deliverability Monitoring Stack
Postmaster Tools, SNDS, FBLs, DMARC reports, TLS-RPT, bounce logs, engagement data: the full observability stack, what each layer catches, and the alerts worth paging on.
Duplicate Sends: Idempotency in Email Pipelines
Everyone has received the same email twice. The retry loops, queue semantics, and race conditions that cause duplicates, and the idempotency patterns that stop them.