# How does DNS TTL affect an MX record change?

URL: https://iblockspam.com/blog/dns-ttl-mx-change-propagation
Last updated: 2026-10-10
Published: 2026-10-10
Topic: Switching & migration
Author: iBlockSpam Team

> What DNS TTL means, why propagation is really caching, when to lower TTL before an MX or SPF change, how negative caching works, and how to check what resolvers see.

## Short answer

TTL is the number of seconds a resolver may cache a DNS record before asking again. There's no real propagation: after an MX change, resolvers keep serving the old answer until their cached copy expires. Lower the TTL to about 300 seconds at least one old-TTL period before the change, then raise it again once the new records are confirmed.

Every MX, SPF or DMARC change you make is fast at your DNS host and slow everywhere else. The delay isn't the change "spreading" across the internet. It's thousands of resolvers holding on to the old answer for as long as you told them they could. Understanding that one number, the TTL, is most of what you need for a clean mail cutover.

## What is a DNS TTL?

Every DNS record carries a time to live. [RFC 1035](https://www.rfc-editor.org/rfc/rfc1035.html) defines it as a value "that specifies the time interval (in seconds) that the resource record may be cached before it should be discarded." [RFC 2181, section 8](https://www.rfc-editor.org/rfc/rfc2181.html) later clarified that a TTL is an unsigned number "with a minimum value of 0, and a maximum value of 2147483647."

Two other rules from the standards matter in practice:

- **TTL is a ceiling, not a promise.** RFC 2181 says "The TTL specifies a maximum time to live, not a mandatory time to live." A resolver may cap long TTLs and drop records earlier, but it shouldn't keep them longer.
- **Every record in a set shares one TTL.** RFC 2181 section 5.2 says "the TTLs of all RRs in an RRSet must be the same." Your two or three MX records for a domain form one set, so they're cached and expire together.

A TTL of 0 has a special meaning. RFC 1035 says zero values mean "the RR can only be used for the transaction in progress, and should not be cached."

## Why is "DNS propagation" really caching?

When you save a new MX record, your authoritative name servers start answering with it straight away. Nothing is pushed anywhere. The rest of the internet asks recursive resolvers, such as your ISP's, Google Public DNS, Cloudflare's 1.1.1.1, or the resolvers inside Microsoft and Google's mail systems. Each of those keeps the answer it last fetched until the TTL runs out, then asks your name servers again.

So during a change, a sending server's view depends on when its resolver last looked:

| Resolver last fetched your MX | Old TTL | What it sees after your change |
| --- | --- | --- |
| Just before the change | 3600 s | Old MX for up to 1 hour |
| 30 minutes before | 3600 s | Old MX for up to 30 more minutes |
| Never, or cache expired | Any | New MX immediately |
| Just before the change | 86400 s | Old MX for up to 1 day |
| Just before the change | 300 s | Old MX for up to 5 minutes |

That's why mail arrives through both the old and new paths for a while after an MX change. It's normal, and it's why the old destination must keep accepting mail during the overlap. Our [MX change checklist](https://iblockspam.com/blog/change-mx-records-without-losing-email) covers that side.

## How far ahead should you lower the TTL?

The TTL you lower is only read when a resolver next fetches the record. A resolver that cached your MX five minutes ago with a 24-hour TTL won't see your new 300-second TTL until tomorrow. So the rule is simple: lower the TTL **at least one full old-TTL period** before the real change.

1. **Find the current TTL.** Look it up at your DNS host, or query an authoritative name server (see the commands below).
2. **Lower it to around 300 seconds.** Amazon's [Route 53 documentation](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-values-basic.html) gives the same advice for records already in use: "specify a shorter value first, such as 300 seconds, and increase the value after you confirm that the new settings are correct."
3. **Wait out the old TTL.** If it was 3600, wait at least an hour. If it was 86400, wait a day. Add a margin.
4. **Make the real change** in a single edit.
5. **Confirm the new answer** at the authoritative servers and at a few public resolvers.
6. **Raise the TTL again**, for example to 3600, once mail is flowing through the new path. Longer TTLs mean fewer queries and less dependence on your DNS host being reachable every minute.

### Which records should you lower?

Lower the TTL on every record you're about to change, and only those:

- **MX** records for an inbound filter or mailbox move.
- **The SPF TXT record**, if outbound mail is moving to a new service. See [SPF record syntax and examples](https://iblockspam.com/blog/spf-record-syntax-examples).
- **DKIM selector records**, if you're replacing keys rather than adding new selectors alongside the old ones.
- **Autodiscover or other CNAMEs**, for a mailbox platform move.

DMARC changes are less time-critical. A stricter policy reaching receivers an hour late rarely matters, but it's worth the same care when you loosen a policy to fix a problem.

## What TTLs do common DNS hosts use?

Defaults and limits vary by host and change over time, so check your own control panel. At the time of writing (October 2026):

| DNS host | What the documentation says |
| --- | --- |
| Cloudflare | "A TTL of Auto is set to 300 seconds." DNS-only records can be set from 60 seconds (30 on Enterprise) up to 1 day. Proxied records are fixed at Auto ([Cloudflare Docs](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/)) |
| Amazon Route 53 | You choose the TTL per record. Amazon uses 172800 seconds as an example of a long TTL and suggests 300 seconds while changing records in use ([Route 53 docs](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-values-basic.html)) |
| Registrar DNS (GoDaddy, Namecheap and others) | Usually offers a preset list such as 30 minutes, 1 hour or custom. Check what your panel allows before the change day |

Mail records on Cloudflare must stay DNS only, so they use whatever TTL you set. Our guides for [Cloudflare](https://iblockspam.com/blog/add-dmarc-spf-dkim-records-cloudflare), [GoDaddy](https://iblockspam.com/blog/add-email-dns-records-godaddy) and [Namecheap](https://iblockspam.com/blog/add-email-dns-records-namecheap) show where the TTL field is in each panel.

## What is negative caching?

Resolvers also cache the answer "this doesn't exist". [RFC 2308](https://www.rfc-editor.org/rfc/rfc2308.html) defines two kinds: NXDOMAIN, where the name itself doesn't exist, and NODATA, where the name exists but has no records of the type asked for.

How long a negative answer is cached comes from your zone's SOA record. RFC 2308 says the negative TTL is "the minimum of the MINIMUM field of the SOA record and the TTL of the SOA itself". It also redefined that SOA field: its meaning is now "the TTL to be used for negative responses". For the cap a resolver puts on negative caching, the RFC notes "Values of one to three hours have been found to work well".

This catches people out when they **add** a record rather than change one:

- Someone looked up `_dmarc.example.com` before you published DMARC. Their resolver cached "no TXT record" for the negative TTL.
- You add a new DKIM selector and test it immediately. The first lookup returns nothing, and that empty answer is now cached.
- You add a new subdomain for a sending service, and its verification check fails for an hour.

The fix is patience, or creating the record well before anything needs to look it up. Lowering a record's TTL doesn't help here, because a record that didn't exist had no TTL to lower.

## How do you check what resolvers see?

Always check in this order: authoritative first, then public resolvers.

1. **Find your authoritative name servers.**

   ```bash
   dig NS example.com +short
   ```

2. **Ask one of them directly.** This shows the record you actually saved and its full TTL.

   ```bash
   dig @ns1.your-dns-host.example MX example.com
   ```

   If the authoritative answer is wrong, stop. Waiting won't fix it. You may have edited the zone at a provider that isn't authoritative, such as a registrar when the domain's name servers point elsewhere.

3. **Ask public resolvers.**

   ```bash
   dig @8.8.8.8 MX example.com
   dig @1.1.1.1 MX example.com
   ```

   The TTL in a cached answer counts down. If it shows 1200, that resolver will keep the old answer for 20 more minutes.

4. **On Windows**, use `nslookup -type=MX example.com 8.8.8.8` or `Resolve-DnsName example.com -Type MX -Server 8.8.8.8` in PowerShell.

5. **Check from outside your network** with our [MX Lookup](https://iblockspam.com/tools/mx-lookup), or the [Email Health Check](https://iblockspam.com/tools/email-health-check) for MX, SPF and DMARC together.

### Can you clear someone else's cache?

Only some of them. Google Public DNS has a [Flush Cache](https://developers.google.com/speed/public-dns/cache) page, and Cloudflare offers a similar purge page for 1.1.1.1. Each clears that one resolver's copy of a name. Every other resolver, including your ISP's and those run by the large mailbox providers, still waits for the TTL. Your own computer and mail server may also cache answers; restarting a local caching resolver clears those.

## What are the common TTL mistakes?

- **Lowering the TTL and changing the record at the same time.** The lower TTL has no effect on resolvers that already cached the old record.
- **Forgetting to raise it again.** A 60-second TTL left in place for months means more queries and less tolerance for a DNS outage.
- **Editing the wrong zone.** If the authoritative servers don't show your change, no amount of waiting will help.
- **Assuming the new record is "not working" too early.** Test against the authoritative server, not a resolver that still has the old answer.
- **Switching off the old destination at the TTL mark.** Some senders retry deferred mail for days. RFC 5321's retry guidance is covered in [what happens to email when the server is down](https://iblockspam.com/blog/what-happens-to-email-when-server-is-down).

## Next steps

1. Look up the current TTL on your MX and SPF records with the [MX Lookup](https://iblockspam.com/tools/mx-lookup) and [SPF Checker](https://iblockspam.com/tools/spf-checker), and write them down.
2. Lower the TTL on the records you plan to change at least one old-TTL period ahead, and set a reminder to raise it afterwards.
3. Follow the full [MX change checklist](https://iblockspam.com/blog/change-mx-records-without-losing-email), or, if you're moving between filters, the guide to [switching spam filter providers](https://iblockspam.com/blog/switch-spam-filter-provider).
4. Once the change is done, iBlockSpam's [domain monitoring](https://iblockspam.com/features/domain-monitoring) can alert you if MX, SPF or DMARC records change unexpectedly later.

More guides on [switching and migration](https://iblockspam.com/blog/topic/migration).

## Frequently asked questions

### How long does DNS propagation take for an MX record?

Up to the TTL that was on the old record when resolvers last cached it. If the old MX had a TTL of 3600 seconds, most resolvers will see the new MX within an hour. If it was 86400, allow a day. Lowering the TTL well before the change is what shortens this window, not anything you do on the day.

### Should I set my TTL to 0 or 60 seconds permanently?

No. RFC 1035 says a zero TTL means a record should not be cached at all, which means more queries and more dependence on your DNS host being reachable. Very short TTLs are useful during a change. Afterwards, return to a normal value such as 3600 seconds.

### Can I make Google or Cloudflare see my new MX record faster?

Partly. Google Public DNS and Cloudflare's 1.1.1.1 both offer public cache purge pages, which clear their own cached copy of a name. That only affects those two resolvers. Every other resolver, including your ISP's and the ones big mail providers run, still waits for the TTL.

### Why does my new record not show up even though the TTL has passed?

Check the authoritative name servers first. If they still return the old value, the change wasn't saved, or you edited the zone at a provider that isn't authoritative. If the record didn't exist before, a resolver may be holding a cached negative answer, which lasts as long as your SOA's negative TTL.

### Does changing the TTL itself take effect immediately?

No. A resolver that cached the record with the old TTL keeps it for that old TTL. The lower value only applies the next time it fetches the record. That's why you lower the TTL at least one full old-TTL period before the real change.

## Sources

- [RFC 1035: Domain names, implementation and specification (sections 3.2.1 and 4.1.3)](https://www.rfc-editor.org/rfc/rfc1035.html)
- [RFC 2181: Clarifications to the DNS Specification (sections 5.2 and 8)](https://www.rfc-editor.org/rfc/rfc2181.html)
- [RFC 2308: Negative Caching of DNS Queries (DNS NCACHE)](https://www.rfc-editor.org/rfc/rfc2308.html)
- [Cloudflare Docs: Time to Live (TTL)](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/)
- [Amazon Route 53 Developer Guide: Values specific for simple records (TTL)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-values-basic.html)
- [Google Public DNS: Flush Cache](https://developers.google.com/speed/public-dns/cache)

## Free tools for this guide

- [MX Lookup](https://iblockspam.com/tools/mx-lookup): See where your mail is delivered, spot unfiltered backup MX and broken hosts.
- [SPF Checker](https://iblockspam.com/tools/spf-checker): Count real DNS lookups, find PermErrors, loops and risky "all" settings.
- [Email Health Check](https://iblockspam.com/tools/email-health-check): Grade your domain's MX, SPF, DKIM, DMARC and transport security in one scan.
- [DMARC Checker](https://iblockspam.com/tools/dmarc-checker): Check your policy, reporting and the safe path from p=none to reject.

---

Source: iBlockSpam, https://iblockspam.com/blog/dns-ttl-mx-change-propagation (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt