Fix Slow DNS Propagation After a Record Change

What's happening

DNS propagation is misnamed — there is no global rollout. Each recursive resolver caches records until their TTL expires, then re-fetches from authoritative nameservers. "Slow propagation" is a side effect of long TTLs being respected by many resolvers, plus negative caching of NXDOMAIN responses for the SOA-defined negative TTL.

When you publish a new SPF record, MX, or A record, resolvers that already have the old (or NXDOMAIN) cached will continue serving it for the full TTL. If your TTL was 86400 (one day), users in some regions may see the old record for 24 hours, while users whose resolver had no cached entry see the new record immediately.

Operationally this matters most during migrations: switching mail providers, moving DNS hosts, deploying new web infrastructure. A bad TTL plan extends the migration window from minutes to days, with intermittent failures users find hard to describe.

Why it matters

User-visible inconsistency. Customers in one country reach the new mail provider; customers in another bounce because their resolver still caches the old MX. Support gets reports that are impossible to reproduce.

Mail authentication TempError on a percentage of messages. Receivers querying the SPF or DKIM TXT during the propagation window may get the old record (TempError or NXDOMAIN cached), producing intermittent dmarc=fail.

Negative caching is the worst case. If a record was missing and then published, resolvers that received NXDOMAIN cache that response per the SOA negative TTL — typically 3600. Even after publishing, those resolvers report NXDOMAIN until the negative cache expires.

Common causes

• Original TTL set high (86400 = 1 day) with no pre-migration lowering.
• Negative caching from a prior NXDOMAIN response on a name that did not previously exist.
• Anycast DNS providers' regional caches not invalidated uniformly.
• Authoritative server returning stale data due to a replication lag between primary and secondaries.
• Local resolver (corporate DNS, ISP cache) overriding TTL with longer minimums.

Detect this on your site

Run a quick scan with the DNS Checker. The tool surfaces this exact issue with the records and context needed to apply the fix below.

How to fix it

1. 1

   Always lower TTL before a planned change

   At least 24 hours before a planned DNS change, lower the TTL on the records you will modify to 300 seconds. Wait for the original TTL to expire across resolvers. Now any subsequent change will propagate within 5 minutes for most users.

2. 2

   Make the actual change

   Update records as planned. Because TTL is 300, resolvers will pick up the new value within 5 minutes of their previous cache expiry. Monitor your DNS provider's dashboard for record-publish confirmation.

3. 3

   Verify from multiple regions

   Use dnschecker.org or whatsmydns.net to query the record from many global resolvers simultaneously. The map shows green checkmarks for resolvers serving the new value and red x marks for those still cached on the old. Within 10 minutes most should be green.

4. 4

   Diagnose stragglers

   If some resolvers still serve the old value 30 minutes after the change, they may have a forced-minimum TTL or be hardcoded to ignore short TTLs. Corporate DNS resolvers sometimes do this. Run dig @ +noall +answer +ttl example.com to see the remaining TTL on the cached value.

5. 5

   Address negative caching

   If the symptom is NXDOMAIN persisting after publication, check the SOA negative TTL: dig +short SOA example.com — last field is the negative TTL. To prevent next time, lower SOA negative TTL to 300 before any change that creates new names.

6. 6

   Raise TTL after stability

   Once all resolvers are serving the new value, raise TTL back to a stable value (1800 to 3600 typically). Higher TTL reduces nameserver load and improves resilience to brief outages.

Example

# Pre-migration: lower TTL to 300 (24h before change)
# At provider: edit each record's TTL field

# Verify TTL is in effect
dig +short example.com
dig example.com | grep -E '^example.com.\s+[0-9]+'

# Multi-resolver check after publish
for ns in 1.1.1.1 8.8.8.8 9.9.9.9 4.2.2.1 208.67.222.222; do
  echo "=== $ns ==="
  dig @$ns +short example.com
done

Pre-migration TTL lowering and post-publish multi-resolver verification.

Related fixes