Post-cutover verification
The five-step routine that catches what the panel save doesn't. Saves the discovery from being the client's job.
The change is in the DNS host’s panel; the question is whether it’s visible everywhere it needs to be and the service is actually working.
Verification is the difference between I changed the record and the change works. Skipping verification means the client discovers the breakage instead of you.
The verification sequence
1. Authoritative server
dig <record-type> example.com @<authoritative-ns>The new value should appear immediately. If it doesn’t, the change didn’t save — go back to the panel and check.
2. Two public resolvers
dig <record-type> example.com @8.8.8.8 dig <record-type> example.com @1.1.1.1Two public resolvers catch cases where one resolver’s cache is briefly out of sync. After the lowered TTL window has passed, both should show the new value.
3. Online propagation check (optional)
Online tools poll multiple resolvers globally and show a propagation map. Useful when the change matters for users in regions you don’t have local visibility into.
4. End-to-end service test
DNS resolves correctly is necessary but not sufficient. Confirm the service works:
- Web (A change): load the website in a fresh private browser window. Confirm it serves from the new host.
- Mail (MX change): send a test email to a recipient at the affected domain. Confirm it arrives at the new mail provider (visible in the receiving mailbox, with delivery headers showing the route).
- Email auth (SPF/DKIM/DMARC change): send a test email from the affected domain to Gmail. Open the message, view headers, confirm
Authentication-Results:showsspf=pass dkim=pass dmarc=pass.
The destination is the only ground truth that the records work, not just exist.
5. Set the monitoring window
Watch for delayed propagation issues. The window depends on the previous TTL:
- Previous TTL 300 → watch for 1-2 hours.
- Previous TTL 3600 → watch for 4-8 hours.
- Previous TTL 86400 → watch for 24-48 hours.
If you did the TTL drop pre-flight, the window matches the lowered TTL, not the original.
Practice: the first two verification steps
You just changed an A record for a client’s website migration. Walk through the verification sequence.
What this is NOT
- “The panel saved the change, so it’s done.” Saving and propagating are different events. Verify after both.
- “Default resolver shows the truth.” Your default resolver may have a stale cache. Query the authoritative directly to confirm the change is at the source.
- “DNS resolves so the service works.” The destination may not yet be configured. End-to-end testing catches DNS correct, destination not yet deployed.
- “Set an arbitrary monitoring window.” Calibrate to the previous TTL. Watch for 24 hours is wrong if the TTL was 300.
When to escalate
- The authoritative server returns the wrong value after the change (the panel didn’t apply). Try saving again; if it fails repeatedly, the DNS host’s support is next.
- A public resolver shows the old value well past the previous TTL plus margin. May indicate cache poisoning or a misconfigured resolver; limited fix from your side.
- The end-to-end test fails despite DNS being correct. Destination-side issue; different escalation path.