DNS Propagation & TTL: Why Your Domain Changes Take Time

What Is DNS Propagation & TTL?

Chances are, you just updated a DNS record—like switching your email provider or pointing your website to a new host. You click save, expecting mail to flow instantly to the new inbox. Instead, some messages still land at the old provider for hours. This gap is DNS propagation: the time it takes for your change to be picked up by every server that helps route internet traffic to your domain.

DNS, or the Domain Name System, acts like a global phonebook. When someone types your domain or sends you an email, their computer looks up your DNS records to find your server. But this phonebook isn’t one book printed daily—it’s millions of copies scattered across thousands of servers (called DNS resolvers), each keeping notes to speed things up. The Time to Live (TTL) setting tells those servers how many seconds they can hold onto a copy before asking for the latest version. Propagation is simply the period while old copies still exist and haven’t expired yet.

Real-World Analogy

Think of DNS like a chain of coffee shops that each keep a printed menu. When you change your pastry supplier (a new MX record), each location doesn’t call central immediately—they only check for updates when their copy expires. Until then, baristas still point customers to the old supplier. That lag is propagation, and the menu’s ‘freshness timer’ is TTL.

How DNS Propagation Works

In plain English, here’s what happens step by step:

1. You update a DNS record at your domain’s registrar or DNS hosting provider (for example, Google Domains or Cloudflare). You’re telling the authoritative servers—the official source—about the change.

2. Down the line, when someone tries to visit your website or send you an email, their device asks a local DNS resolver (often provided by their internet provider or company network). This resolver doesn’t go straight to the authoritative server every time—it keeps a cache of previous lookups, like a scrapbook.

3. The resolver checks the TTL of the record it has cached. If the TTL hasn’t expired, it happily uses that old answer, and your change goes unseen. If the TTL has passed, the resolver says “stale” and queries the authoritative server again, getting the fresh record.

4. As different resolvers around the world reach their different expiration times, your new record gradually becomes visible. This is why the change might show up on your phone but not your colleague’s laptop in another office.

This is propagation: the staggered updating of cached copies based on TTL. The lower the TTL, the faster this process—but also the more load on your DNS provider.

Technical Details

▸TTL values are set in seconds. Common defaults: 3600 (1 hour), 14400 (4 hours), or 86400 (24 hours). Before a planned change, lowering to 300 (5 minutes) speeds propagation.

▸DNS hierarchy: Authoritative nameservers hold the master copy; recursive resolvers (e.g., 8.8.8.8, 1.1.1.1, your ISP) cache results. Propagation is the cache expiration across all intermediate resolvers.

▸Negative caching: If a record doesn’t exist, servers may cache that ‘no answer’ for a period defined by the SOA minimum TTL. This can delay newly added records.

▸Record types: MX (mail exchanger) records point to email servers; A/AAAA records point to website IPs. SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) are TXT records used for email authentication, and they also follow TTL rules. Slow propagation of SPF can cause temporary email authentication failures.

▸Digging deeper: Use to see the current record and its TTL from a specific resolver. The TTL shown is what remains in the cache at that moment.

Why It Matters for Your Business

When you move email to a new platform and the MX record still points to the old server, customers who send order confirmations or support requests might get a bounce or silence. Similarly, if a marketing team launches a campaign with updated SPF records that haven’t propagated, emails may land in spam or get rejected. Even a short period of misrouting can damage your reputation with customers who expect reliability.

A sales team might miss lead notifications, support tickets get buried, and your website can display error pages instead of your new branding. This isn’t just an IT headache—it directly affects revenue, customer trust, and team productivity. The marketing director who can’t reach inboxes, the CEO who sees the wrong website: they all feel the sting of flaky DNS.

Proper propagation management isn’t a nice-to-have; it’s a core part of maintaining a professional online presence. A little planning with TTL can mean the difference between a seamless cutover and a day of chaos.

Common Issues and Warning Signs

Propagation delays often look like glitches, not configuration mistakes. Here are patterns to watch for.

Common Issues

New emails still arriving in the old inbox hours after you switched email providers. This is a classic sign that MX records with a long TTL are still cached.

Your website shows a parked page or an error despite updating A records. The old IP address is still in your visitor’s resolver cache.

Email deliverability tests flip-flop between pass and fail. If SPF or DKIM records haven’t fully propagated, some incoming servers see old policies while others see new ones.

You lowered TTL right before a change, but delays persist. That’s because the previous high TTL was already cached, and you have to wait for that cache to expire. Lowering TTL ahead of time is key.

A TechSpy scan reveals a high TTL on critical records like MX or SPF. High TTLs mean future changes will take longer to take effect.

How to Fix or Improve DNS Propagation & TTL

While you can’t magically purge every cached DNS record worldwide, you can set yourself up for smoother transitions. Here’s how to handle propagation before and after a change.

Once propagation settles, run a TechSpy scan to double-check that all your records are correct and that TTL values are appropriate for future changes.

1Before making an important DNS change, lower the TTL on the record you plan to modify. Set it to 300 seconds (5 minutes) at least 24 hours in advance. This ensures that any caches that already have the record will expire quickly once you make the change.

2After updating, verify that the authoritative nameservers are serving the correct record. You can use a command-line tool like or an online DNS checker. TechSpy’s scan also confirms the current state of your DNS settings from its perspective.

3Check global propagation progress with a tool like whatsmydns.net, choosing the record type (e.g., MX or A). This shows where the new record is already live.

4If you don’t manage DNS yourself, forward these instructions to whoever does (your IT team, web agency, or hosting provider). Provide them with the specific new values you need updated.

5For an immediate, local fix while you wait for the world to catch up, you can temporarily override DNS on your own computer by editing the hosts file. But this won’t affect anyone else—so only helpful for testing.