DNS Propagation and TTL Explained: Why DNS Changes Take Time

You changed a DNS record… but some people still see the old site. Or your SSL certificate fails only in certain regions. This is usually “DNS propagation,” but the real mechanism is caching—and the most important setting is TTL (Time To Live).

What “DNS propagation” really means

DNS is distributed. Your authoritative DNS provider publishes records, but user devices usually ask a recursive resolver (often your ISP, Google DNS, Cloudflare, or your company). Resolvers cache answers so they don’t have to ask the authoritative servers every time.

What is TTL?

TTL (Time To Live) is the cache lifetime (in seconds) for a DNS answer. If a record has TTL 3600, a resolver can reuse the cached answer for up to an hour before checking again.

TTL example

• You change an A record at 12:00
• A resolver cached the old record at 11:30 with TTL 3600
• That resolver may keep serving the old record until 12:30

Why DNS changes look inconsistent

• Different resolvers have different cache states.
• Device caches (OS/browser) may store results briefly.
• CDNs may have their own logic depending on record type.
• Negative caching can cache “does not exist” (NXDOMAIN).

How to reduce downtime during DNS changes

1. Lower TTL before a planned migration (e.g., 300 seconds).
2. Wait at least one old TTL period after lowering it.
3. Make the change (A/AAAA/CNAME), then monitor.
4. After stable, raise TTL again if you prefer.

How to confirm you’re seeing the new record

Use DNS queries from multiple networks/resolvers. On this site, start with DNS Lookup and check the exact record type you changed (A, AAAA, CNAME, TXT, MX).

Understanding different DNS record types

• A record — maps a domain/subdomain to an IPv4 address. Most common record changed during migrations.
• AAAA record — same as A, but for IPv6. Don't forget to update this too when moving hosts!
• CNAME record — alias that points to another domain name. Cannot be used on the root domain in most DNS systems.
• MX record — mail server routing. Changes here affect email delivery — mistakes can cause bounced emails.
• TXT record — used for SPF, DKIM, DMARC (email authentication), domain ownership verification, and other metadata.
• NS record — specifies which DNS servers are authoritative for your domain. Slowest to propagate (can take 24–48 hours).
• SOA record — Start of Authority — contains administrative information including the serial number and refresh intervals.

How to check DNS accurately using command line

• Windows: nslookup example.com 1.1.1.1 — queries Cloudflare DNS, bypassing your local OS cache
• Mac/Linux: dig example.com @8.8.8.8 — queries Google DNS directly
• Query authoritative servers: first dig NS example.com, then dig A example.com @ns1.example.com
• Flush OS DNS cache: Windows: ipconfig /flushdns | Mac: sudo dscacheutil -flushcache

Common DNS change mistakes

• Forgetting the AAAA record — updated A record but not AAAA; IPv6 users still reach the old server
• Changing NS records with high TTL — NS record changes can take up to 48 hours; plan well ahead
• Removing old MX records before email migration completes — causes immediate email delivery failures
• Not testing from a clean resolver — your browser and OS may still have the old answer cached
• Deleting the old server too soon — users with the old cached IP need the old server to remain live for one full old TTL period

DNS and email authentication (SPF, DKIM, DMARC)

Email authentication records are TXT records with their own TTL. If you're migrating email providers, lower the TTL of your TXT records in advance, wait for the old TTL to expire, then make the change. This prevents a window where incoming mail is rejected because a recipient's server is using a stale SPF record. To check whether email headers show your authentication records are working, use our Email Header Analyzer.

The DNS hierarchy in detail

DNS is organized as a tree, starting from the root (.) at the top, then top-level domains (TLDs like .com, .net, .org), then second-level domains (example.com), and so on. Each level is managed by different organizations.

• Root zone: managed by IANA (part of ICANN). There are 13 root server clusters worldwide (operated by organizations like Verisign, NASA, RIPE NCC). Despite being 13 "named" servers, each has hundreds of physical machines via anycast routing.
• TLD nameservers: managed by registries (Verisign for .com, Public Interest Registry for .org, etc.)
• Authoritative nameservers: operated by your DNS hosting provider (Cloudflare, AWS Route 53, GoDaddy, Namecheap, etc.)
• Recursive resolvers: operated by ISPs, companies, and public services (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9)

When you change a DNS record, only the authoritative nameserver tier is updated immediately. The recursive resolvers update lazily — only when their cached copy expires.

DNSSEC: signed DNS for authenticity

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records, allowing resolvers to verify that responses haven't been tampered with in transit. This prevents "DNS cache poisoning" attacks where a malicious actor could trick a resolver into caching a fake DNS response (e.g., pointing your domain to a phishing site).

DNSSEC does not encrypt DNS queries — it only authenticates them. For encrypted queries, see DNS-over-HTTPS and DNS-over-TLS below.

Key DNSSEC record types you may encounter:

• DNSKEY — contains the public key used to verify zone signatures
• RRSIG — the actual cryptographic signature for a set of DNS records
• DS (Delegation Signer) — hash of the child zone's DNSKEY, stored in the parent zone to create the chain of trust
• NSEC / NSEC3 — authenticated denial of existence (proves a record does NOT exist)

DNS privacy: DNS-over-HTTPS and DNS-over-TLS

Traditional DNS queries are sent in plaintext. Your ISP, network administrator, or anyone on your local network can see every domain you query — even if the websites you visit use HTTPS. This is a significant privacy leak.

• DNS-over-TLS (DoT): wraps DNS queries in TLS encryption on port 853. The queries are encrypted but still look like DNS traffic (the port is recognizable).
• DNS-over-HTTPS (DoH): sends DNS queries inside HTTPS requests (port 443). This makes DNS traffic indistinguishable from regular web traffic, harder for ISPs or firewalls to block or observe.

Modern browsers (Chrome, Firefox, Edge) support DoH natively. You can enable it in browser settings or use a VPN that encrypts all DNS. However, DoH/DoT don't prevent DNS leaks if your VPN is misconfigured — some traffic may bypass the encrypted tunnel. Learn more about DNS leaks in our guide: DNS/WebRTC/IPv6 Leaks.

Real-world DNS propagation timelines

While "up to 48 hours" is the traditional guideline, here's what typically happens in practice for each record type:

• A/AAAA records (TTL 300): most users see the change within 5–15 minutes after one old TTL expires
• A/AAAA records (TTL 3600): expect 1–2 hours for most users; some ISPs with aggressive caching may take longer
• MX records: typically 30 minutes to 4 hours depending on TTL
• NS records: 24–48 hours — the parent zone (registrar) must update the delegation, which has its own cache
• Domain registration (new domains): can take up to 48 hours for registrar-to-registry propagation, though often faster
• TXT records (SPF, DKIM): same as other records — TTL-dependent. Typically 15 minutes to a few hours.

Frequently asked questions about DNS propagation

Why can I see my updated DNS record but someone else can't?

You're using different recursive resolvers. Your device might be using Cloudflare (1.1.1.1) which has already fetched the new record, while the other person uses their ISP's resolver which is still serving a cached copy. Wait until the TTL expires on their resolver.

Does flushing my DNS cache help?

It helps on your own device — it forces your OS to re-query the resolver. But if the resolver itself has a stale cache, you'll still get the old record from the resolver until its cache expires. To verify, query a specific resolver like nslookup example.com 8.8.8.8 to check what Google DNS currently returns.

How do I check if DNS is causing a website to be "down"?

First check the DNS record points to the right IP. Use our DNS Lookup to see the current record. Then verify the server at that IP is responding — if the IP is correct but the site is down, it's a server issue, not DNS. If the IP is wrong or pointing to an old server, it's a DNS/propagation issue.

What happens if my TTL is set to 0?

Theoretically resolvers would not cache the record at all and always fetch fresh from the authoritative server. In practice, many resolvers enforce a minimum TTL of 30–60 seconds regardless of what you set. Ultra-low TTL also increases load on your authoritative DNS server significantly.