Email DNS Change Validation Checklist
Validate email DNS changes with authoritative and recursive lookups, header evidence, propagation notes, and rollback documentation.
Product & Engineering · September 25, 2026 · 2 min read
An email DNS change validation checklist should prove three things: what was published, what resolvers return, and what a real message shows. Keep these evidence layers separate. A successful DNS lookup is necessary for many changes, but it does not prove receiver acceptance or inbox placement.
Capture a baseline
Before editing, record the exact owner name, record type, all values, TTL, authoritative nameserver, and lookup timestamp. Cover the relevant MX, SPF, DKIM selector, DMARC, and provider verification records. The DNS records guide explains their roles. Save the prior values and rollback owner in the change ticket.
Validate authoritative and recursive answers
Query the authoritative nameserver to confirm the zone’s source of truth. Then query more than one recursive resolver to observe caching and propagation. Note the answer, resolver, timestamp, and TTL. A recursive answer that still shows the old value is propagation evidence, not necessarily a failed authoritative change. Do not guarantee a timing window; measure it.
Send and inspect a real message
Use a controlled message from each affected stream. Inspect From, Return-Path, DKIM selector and signing domain, and Authentication-Results with header-reading guidance. Confirm provider console status and downstream events. Use authentication change management when several records or providers change together.
Close or roll back
Compare the observed result with the expected result. If authentication fails, a provider cannot verify the record, or the wrong sender remains authorized, pause the rollout and restore the documented prior value. Record the evidence, decision, and next owner. Do not mark the change successful because a single public DNS tool shows the new answer.
Related resources
The Email Infrastructure academy is the hub for DNS and change validation.
This workflow should be checked against the cited standards and current provider documentation 1.
Build a pre/post DNS evidence pack
Before a change record purpose, owner, requested value, TTL, window, rollback value, and verification plan. Capture authoritative nameserver and recursive resolver results; one cached lookup cannot establish propagation. Syntax validity is separate from receiver behavior.
| Check | Evidence | Stop rule |
|---|---|---|
| Scope | domain, name/type, purpose, owner | Stop if owner is unclear |
| Baseline | before value, TTL, authoritative answer | Stop without rollback value |
| Syntax | quoting, escaping, duplicate SPF check | Stop on malformed/duplicate policy |
| Alignment | SPF/DKIM/DMARC test | Stop when From domain is uncovered |
| Propagation | authoritative plus two resolvers | Qualify until TTL differences settle |
| Send test | controlled message, headers, result | Stop ramp on auth/TLS failure |
| Rollback | ticket, approver, observation window | Stop when owner cannot revert |
Consult RFC 7208, RFC 7489, and the Google sender guidelines. After TTL expiry save raw outputs, headers, timestamps, and tickets. Do not delete the old record first when staging is possible. Reopen after delegation, DNSSEC, selector, provider, or ownership changes.
References
Resources in this guide
Frequently asked questions
What is the difference between authoritative and recursive DNS lookups?
An authoritative lookup checks the zone’s published source; a recursive lookup shows what a resolver currently serves from cache or after refresh.
Does DNS propagation prove authentication?
No. Send a controlled message and inspect authentication results and provider evidence after the relevant record is visible.
What should be in rollback documentation?
The prior record values, owner, expected trigger, restoration method, and post-rollback verification steps.
Continue learning
Plan authentication changes safely
Continue with the closest operational guide.