DNS Propagation Troubleshooter

Your DNS change isn't taking effect. This page walks through the seven things that are actually wrong, in the order they're worth checking.

1. Are the right nameservers active?

Most "DNS not updating" problems are actually "the registrar is still pointing at the wrong nameservers." Check the delegation directly from the TLD:

# Ask the root/TLD which nameservers handle your domain
dig +trace example.com NS

# Or query the registrar-published nameservers
dig example.com NS @whois-published-ns.example.net

If the nameservers listed at the registrar don't match where you're editing records, nothing you change will ever be visible to the internet.

2. Is the record correct on the authoritative server?

Query the authoritative nameserver directly. This bypasses every cache between you and the source of truth.

# Find the authoritative nameservers
dig example.com NS +short

# Then query one of them directly
dig @ns1.your-dns-provider.com example.com A
dig @ns1.your-dns-provider.com www.example.com A

If the authoritative server returns the wrong answer, the record is wrong in your DNS dashboard. Fix it there. If it returns the right answer, the problem is downstream caching, not propagation.

3. Has the TTL expired?

The TTL on the old record determines how long recursive resolvers keep caching it. If you set TTL to 3600 (1 hour) and changed the record 10 minutes ago, resolvers will return the old value for another 50 minutes.

# Look at the TTL on the live answer
dig example.com A

# The number before "IN A" is seconds remaining in cache
# Wait that many seconds and re-test

Habit worth keeping: lower the TTL to 300 (5 minutes) before a planned change, then raise it back to 3600 after the new record stabilizes.

4. Is your local cache lying to you?

Your operating system and browser cache DNS too. The record may be live everywhere except on your laptop.

# Test against a public resolver instead of your default
dig @1.1.1.1 example.com
dig @8.8.8.8 example.com

# Flush local DNS cache
# macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
# Windows
ipconfig /flushdns
# Linux (systemd-resolved)
sudo resolvectl flush-caches
# Linux (nscd)
sudo systemctl restart nscd

Also check the browser. Chrome caches independently — open chrome://net-internals/#dns and clear the host cache.

5. CNAME, A, and AAAA traps

• CNAME at the apex. Most DNS providers don't allow example.com CNAME ... at the root. Use A/AAAA records or a provider-specific flatten/ALIAS feature.
• CNAME chains. A CNAME pointing to another CNAME pointing to another CNAME works but multiplies cache expiry time. Keep chains short.
• AAAA exists but A doesn't. IPv6-only resolvers will reach you; IPv4-only clients won't. Always set both or neither.
• Wildcards. *.example.com only matches one label. foo.bar.example.com won't match unless you also wildcard at that depth.

6. DNSSEC and validation failures

If you enabled DNSSEC at the DNS provider but didn't publish the DS record at the registrar — or vice versa — validating resolvers will return SERVFAIL and your domain looks broken to a chunk of the internet.

# Check for DNSSEC issues
dig example.com +dnssec
dig example.com +cd        # bypass validation; if it works now, DNSSEC is broken

If +cd resolves but the default doesn't, your DS record is wrong or missing. Either publish a matching DS at the registrar or disable DNSSEC until you can.

7. MX, SPF, DKIM, and DMARC

Email DNS is its own category of pain. The four checks worth running:

# Mail servers
dig example.com MX

# SPF (TXT record at apex)
dig example.com TXT | grep spf

# DKIM (TXT record at selector._domainkey.example.com)
dig selector._domainkey.example.com TXT

# DMARC (TXT record at _dmarc.example.com)
dig _dmarc.example.com TXT

Common mistake: editing the SPF record without using the proper TXT format, or publishing two SPF records (only one is allowed per domain).

FAQ