DNS propagation: why DNS changes don't take effect immediately

DNS propagation is the process by which updated DNS records spread across recursive resolvers (caching DNS servers) around the world. When you update an MX record, SPF, or A record in your registrar's control panel, the change does not take effect right away. Caching servers keep returning the old version of the record until its cached lifetime expires.

The phrase "DNS propagation takes 24–48 hours" is a simplification that stuck around in hosting-provider docs. The real wait depends on the TTL of the previous record version and can range anywhere from a few minutes to several days.

How DNS caching works

DNS is hierarchical. When your computer (or mail server) requests a record, the query travels through a chain:

1. The stub resolver on your machine contacts a recursive resolver (8.8.8.8, 1.1.1.1, your ISP's resolver).
2. The recursive resolver checks its cache. If the record is there and the TTL has not expired, it returns the cached answer.
3. If nothing is cached, the resolver walks up to the root servers, then the zone servers (.com, .net, etc.), then the authoritative nameserver for your domain.
4. The answer is stored in cache for as long as the TTL field says.

While the cache is valid, the resolver never contacts your authoritative server. It has no way of knowing you changed anything. This behavior is correct: it is specified in RFC 1034 and is fundamental to DNS scalability.

TTL controls propagation speed

The actual propagation time is set by the TTL of the previous record, not the new one. This is the part people most often miss:

• Old TTL = 300 seconds (5 minutes). Within 5 minutes, any resolver that cached the record will fetch a fresh copy.
• Old TTL = 3600 seconds (1 hour). Propagation takes up to an hour.
• Old TTL = 86400 seconds (24 hours). You may wait a full day.

If your old record had TTL 86400 and you set the new TTL to 300, that does nothing for the current update. Resolvers that already cached the old value will hold it for up to 24 hours. The short TTL only helps with the next change you make after those caches expire.

Propagation and email

For email, DNS propagation creates several distinct failure modes:

• MX migration. When moving from one mail server to another, some MTAs on the internet still see the old MX record. Incoming mail splits between the old and new server. If the old server is already shut down, those messages are lost.
• Publishing SPF. After you add an SPF record, some receiving servers have not seen it yet. For them the SPF result is "none" (record not found), not "pass". Depending on the recipient's DMARC policy, this can cause rejections.
• DKIM key rotation. If you delete the old key from DNS and publish a new one simultaneously, some servers still see the old key and verify signatures successfully while others see no key at all and produce a DKIM fail. The correct sequence: publish the new key first, wait for propagation to finish, switch signing to the new key, then delete the old one.
• Tightening DMARC. Moving from p=none to p=reject. If some servers already see reject while others are still on none, behavior becomes unpredictable. A staged approach using p=quarantine with the pct parameter is safer.

How to shorten the inconsistency window

You cannot force propagation to complete faster: you do not control other resolvers' caches. But you can shrink the window during which different servers see different values:

1. Lower the TTL in advance. One to two days before your planned change, set the TTL to 300 seconds. Wait for the old TTL to expire everywhere. Then make the actual change: the new value will propagate in about 5 minutes.
2. Keep both servers running. During MX migration, do not shut down the old server until propagation is fully complete. Configure forwarding from old to new so no messages are dropped in transit.
3. Check from multiple vantage points. Use dig with explicit resolver addresses (@8.8.8.8, @1.1.1.1, @9.9.9.9) to confirm the change has reached the major public DNS resolvers.
4. Change one record at a time. If you flip the MX and update SPF simultaneously, debugging gets messy. Sequence the changes: SPF first, wait for propagation, then MX.

Negative caching

When a resolver queries for a record and gets back NXDOMAIN (domain does not exist) or NODATA (no record of that type), that negative response is cached too. The cache duration is controlled by the SOA MINIMUM field in the authoritative zone, typically 300 to 86400 seconds.

This matters when creating records for the first time. If someone queried your new domain's MX before you set up DNS, the resolver cached "no record exists." Even after you publish the MX, that resolver will not see it until the negative cache TTL expires. This often explains why DNS "isn't working" when the record is clearly there.

Propagation and email validation

Email validators query DNS on every check: MX records, A records, hostname resolution. If a domain's DNS was recently changed and propagation is not finished, the validation result can be wrong. The domain already points to a new MX server, but the validator's resolver still sees the old IP and records a timeout or connection failure.

Professional validators account for this by querying multiple independent DNS resolvers, watching TTL values, and re-checking when results are ambiguous.