DNS Change Management
Plan TTL reductions, rollout windows, validation, and rollback.
Production note: DNS and authentication changes should be staged, validated with independent resolvers, and rolled out with a documented rollback path.
Operational model
Email authentication works only when DNS, message construction, SMTP identity, signing, and bounce processing agree. Treat the entire chain as one controlled system.
Design decisions
- Define the visible From domain and organizational domain.
- Define the return-path and bounce-processing domain.
- Assign DKIM selectors and rotation ownership.
- Document DNS provider, TTL, and rollback authority.
- Separate production, staging, customers, and message streams.
Implementation workflow
- Inventory current DNS and message identities.
- Publish low-risk records before enforcement changes.
- Validate through at least two public resolvers.
- Send controlled messages to several mailbox providers.
- Review Authentication-Results and reports.
- Increase enforcement only after exceptions are understood.
dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short -x 192.0.2.10Validation evidence
Capture raw headers, DNS answers, timestamps, resolver locations, DKIM signature fields, SPF identity, DMARC disposition, and the exact message path. A single web checker is not enough evidence.
Common failure modes
- SPF authenticates the wrong identity.
- DKIM signs with an unpublished or stale selector.
- DMARC alignment fails despite individual SPF or DKIM pass.
- PTR and HELO do not match the intended source identity.
- DNS changes are cached longer than expected.
- Third-party senders are omitted from inventory.
Rollback and ownership
Keep the previous record values, TTL plan, change owner, and validation evidence. Roll back only the affected layer, then retest the full path.