What should I check after changing DNS?

`dig @ns1.example.net example.com A +short` queries your authoritative nameserver directly and bypasses every cache. This is the only answer that proves the record changed.

If the authoritative server still returns the old value, nothing has propagated because nothing was published — check the provider's interface rather than waiting.

Query every nameserver listed for the domain, not just one. Replication between them can lag or fail, and that produces intermittent behaviour nobody can reproduce.

`dig example.com NS +short` confirms which servers are authoritative, and that list should match what the registrar has delegated.

`dig @8.8.8.8 example.com A +short` and the same against other public resolvers show what the wider internet currently returns.

Expect disagreement for a period. Each resolver expires its cached copy on its own schedule, governed by the time to live that was in force when it cached.

The remaining TTL on a cached answer is shown by `dig` without `+short`, which tells you how long that particular copy has left.

Lowering the TTL now does not shorten this. It only affects copies cached after the change, which is why the lowering has to happen before.

Mail. Replacing a record set wholesale is the classic way to drop MX records, and the symptom is silence rather than an error.

`dig example.com MX +short` and `dig example.com TXT +short` confirm the mail routing and the SPF record survived.

DKIM lives under a selector name you have to know — `dig selector._domainkey.example.com TXT +short` — and it is the record most often lost because nobody remembers it exists.

DMARC at `_dmarc.example.com`, and any domain-verification TXT records that platforms will silently stop trusting if they disappear.

Subdomains that were pointing elsewhere: a documentation site, a status page, a mail platform's tracking host.

A record pointing at a new address proves nothing about whether that address serves the site. Request the site over both HTTP and HTTPS.

Check the certificate covers the hostname at the new destination. A migration that moves DNS before the certificate is issued produces a warning page rather than a site.

Check all four host and scheme combinations, since a new host frequently has different redirect behaviour from the old one.

Check from more than one network. A result that works from your office and fails elsewhere is either replication lag or a firewall at the new host.

Until the longest previous TTL has elapsed, a share of traffic still arrives at the old address, and nothing you do reaches those clients.

An old server that keeps serving correctly makes the transition invisible. One that is switched off immediately produces errors for exactly the period you cannot observe.

Keep it for longer than the TTL suggests: operating system and browser caches sit in front of resolvers with their own policies.

VeriFixScan reports `dns.resolution`, `dns.propagation`, `dns.nameserver_consistency` and `dns.conflicts` from a live lookup, plus `email.mx.present` and `email.spf.present` — which is the pairing that catches a web change having broken mail.