What this analysis does
Paste two zone or change snapshots. Mailybox normalizes the mail-control records, identifies additions and removals, and prioritizes dangerous regressions such as lost MX or DMARC policy, allow-all SPF posture and selector removal. The result is a change review rather than a generic text diff.
Email DNS changes are reviewed as text in a ticket and applied to a global cache that cannot be recalled. Comparing a complete before-and-after snapshot isolates what actually changed across every mail-relevant record type, including the changes nobody intended.
Compare every record type, not just the edited one
A change described as an SPF update frequently touches more than SPF. Provider onboarding tools add DKIM selectors, verification records and occasionally a second DMARC entry alongside the record the change request mentioned. A diff across MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT and BIMI surfaces all of it.
The most consequential unintended change is a duplicate policy record. Two SPF records, or two DMARC records, are not additive: conforming evaluators treat the condition as an error, which can invalidate authentication that appeared to be working.
- Onboarding tools frequently add records beyond the one being changed.
- Duplicate SPF or DMARC records produce an error, not a merge.
- Removals matter as much as additions.
Record the baseline before touching anything
A diff needs a trustworthy before state, and that has to be captured ahead of the change. Reconstructing it afterwards from memory or from a ticket description is exactly the situation the diff was meant to avoid.
Capture from a resolver outside the network being changed. An internal resolver may serve split-horizon values that differ from what external senders and receivers observe, which makes an internal baseline misleading.
Verify after propagation, then again with a message
A change that resolves correctly at one vantage point may not have propagated everywhere. Wait at least the previous TTL of the affected records, then re-capture and diff against the intended state rather than against the pre-change baseline.
The final verification is behavioural. Send a real message and read the authentication results the receiver stamped, which confirms the change had the intended effect on the path that actually matters.
Model the change before publishing itRead the DNS change review guide
Example: an unintended second policy record
Evidence supplied
Snapshots taken before and after a sending-platform onboarding process.
How to read the result
The diff reports the expected SPF modification alongside a second DMARC record the onboarding tool added. That duplicate is flagged as an error condition, because conforming evaluators do not merge multiple policy records.
Known limits
- A diff is only as good as the baseline; a snapshot taken after the change cannot serve as one.
- Resolver caching means two vantage points can legitimately report different states.
- Structural equivalence does not confirm behavioural correctness for a specific sending path.
Common questions
How long should I wait before re-capturing?
At least the previous TTL of the changed records, and longer where intermediate resolvers are known to extend caching.
Why are duplicate records a problem?
SPF and DMARC both specify that multiple applicable records are an error condition. Evaluators do not combine them, and authentication can fail entirely.
Can I diff a competitor domain?
The analysis uses public DNS, so any domain can be snapshotted. Both snapshots must be captured by you, since historical DNS is not stored.