What is DNS propagation?

When you update a DNS record — changing an A record to a new IP, switching MX records for a mail migration, or adding a TXT record for SPF or DMARC — that change doesn't instantly appear everywhere on the internet.

The DNS system is a global network of caching resolvers. Each resolver (Google, Cloudflare, your ISP, your office router) stores a copy of DNS records and serves that cached copy to clients. The resolver only fetches a fresh copy when the cache expires. The expiry time is set by the record's TTL (Time To Live) value.

Example: Your A record has a TTL of 86400 seconds (24 hours). You change the IP address. Resolvers that cached the old value will continue serving it for up to 24 hours — even though the authoritative nameserver already has the new value.

This delay between a change being made and it being visible everywhere is called DNS propagation. It can range from minutes (with a low TTL) to 48 hours (with a high TTL).

Step 1 — Lower your TTL before making changes

This is the most important thing most people skip. If you lower the TTL on a record before changing it, resolvers will flush their cache quickly and pick up the new value much faster.

24h before

Log in to your DNS provider and reduce the TTL on the record you plan to change to 300 seconds (5 minutes). Save it and wait 24 hours for the old TTL to expire everywhere.

At change time

Update the record value. Because the TTL is now 300 seconds, resolvers will fetch the new value within 5 minutes rather than waiting hours or days.

After confirming

Once propagation is complete and you're satisfied with the change, raise the TTL back to a normal value (3600–86400 seconds) to reduce DNS query load.

If you've already made the change with a high TTL, you can't speed it up retroactively — you can only lower the TTL now to accelerate the next refresh cycle.

Step 2 — Verify the change on the authoritative nameserver

Before checking whether the change has propagated, confirm the change actually exists in DNS. The place to check is the authoritative nameserver — the server that holds the official, live record data for your domain. It has no cache: whatever it returns is the ground truth.

Open the DNS Lookup Tool, enter your domain, select the record type you changed, and set the Resolver dropdown to Authoritative Nameserver. Run the query.

If the authoritative nameserver returns the new value — your change is live. Propagation is in progress or complete. If it still returns the old value, the change hasn't been saved correctly at your DNS provider.

Step 3 — Query public resolvers and compare

Now run the same query through the major public resolvers to see what the rest of the world sees. Switch the Resolver dropdown and run the lookup for each:

Resolver	Address	Good for
Google Public DNS	`8.8.8.8`	Broad global coverage, reliable baseline
Cloudflare DNS	`1.1.1.1`	Fast, privacy-focused, often refreshes first
Quad9	`9.9.9.9`	Security-filtered, good European perspective
OpenDNS	`208.67.222.222`	Large resolver with independent cache

Step 4 — Interpret the results

Compare what each resolver returned against the authoritative nameserver value:

All resolvers return the new value

Propagation is complete. The change is visible worldwide.

Authoritative shows new, public resolvers show old

Propagation is in progress. Public resolvers are still serving their cached copy. Wait for the TTL to expire and check again.

Authoritative still shows the old value

The change hasn't been saved correctly at your DNS provider. Log back in and verify the record was actually updated and saved.

Different public resolvers return different values

Normal during active propagation. Each resolver has its own independent cache and refresh cycle. They will converge to the new value as their TTLs expire.

Common DNS propagation scenarios

Migrating a website (changing the A record)

Lower the A record TTL 24 hours before the migration. At cutover, update the A record to the new server IP. Use the DNS Lookup Tool to confirm the authoritative nameserver returns the new IP, then check Google and Cloudflare resolvers until they match. Keep the old server running until propagation is complete — visitors hitting the old IP should still get a working site.

Migrating email (changing MX records)

Lower the MX record TTL 24 hours before the cutover. Update the MX records to point to the new mail server. During propagation, some inbound email will go to the old server and some to the new one — keep both servers accepting mail until propagation is complete. Check the MX record across all four resolvers to confirm they've all updated before decommissioning the old server.

Adding SPF, DKIM, or DMARC (TXT records)

TXT records for email security (SPF, DKIM, DMARC) are additive — they don't replace existing service, they add policy. Adding them generally has no impact during propagation. Use the DNS Lookup Tool to query the TXT record type on the authoritative nameserver to confirm the record was saved correctly, then check a public resolver to confirm visibility. SPF validation by receiving mail servers will begin as soon as their resolvers pick up the new TXT record.

Check DNS propagation now

Use the DNS Lookup Tool to query any record type across Google, Cloudflare, Quad9, OpenDNS, or your authoritative nameserver — all from one place.

Open DNS Lookup Tool