Planning a DNS TTL for MX and SPF changes without breaking mail flow

Every DNS record carries a TTL (time to live) that tells caching resolvers how long they may serve a stored answer before re-querying the authoritative server. For mail-critical records - MX, SPF, DKIM, DMARC - a TTL set too long is what turns a planned five-minute cutover into a multi-hour window where different senders and receivers see different, inconsistent answers for the same domain.

Why MX changes are the highest-risk case

An MX record change (moving to a new mail provider, adding a backup MX, retiring an old one) determines where inbound mail gets routed. During the propagation window, some sending servers will deliver to your old mail host and some to the new one, based entirely on which cached MX answer they happen to be holding. If the old host is decommissioned the moment you change the record, mail routed there by a resolver with a stale cache will bounce or queue and retry against a server that no longer exists.

$ dig MX example.com +short
10 mail-old.example.com.
20 mail-backup.example.com.

A safe MX migration keeps the old host answering (even just to relay forward, or at minimum to accept and queue) for the full duration of the old TTL after the record changes - not just until you personally confirm the new record resolves from your own machine.

The TTL-lowering sequence

1. Lower TTL on the record you intend to change, without changing its value yet. If the current TTL is 86400 (24 hours), drop it to something like 300 (5 minutes).
2. Wait out the old TTL's full duration - in this example, up to 24 hours - before proceeding. This is the step people skip, and it defeats the purpose: resolvers holding the old 24-hour-TTL answer will not re-query until that cache expires, no matter what you do next.
3. Make the actual change (new MX target, new SPF include, whatever the real cutover is) once the short TTL is confirmed live from multiple resolvers.
4. Keep the old infrastructure answering for at least the duration of the short TTL, ideally longer as a safety margin, so stragglers do not hard-fail.
5. Verify from multiple public resolvers that the new answer is consistent.
6. Raise the TTL back to a normal operational value (1-24 hours) once the change is confirmed stable - a permanently short TTL adds load and marginal risk with no ongoing benefit once the cutover is done.

Checking propagation state honestly

$ for r in 8.8.8.8 1.1.1.1 9.9.9.9; do
    echo "== $r =="; dig MX example.com +short @$r
  done
== 8.8.8.8 ==
10 mail-new.example.com.
== 1.1.1.1 ==
10 mail-old.example.com.
== 9.9.9.9 ==
10 mail-new.example.com.

This is the state you expect mid-propagation - do not treat the first resolver that shows the new answer as proof the change is complete.

SPF is a special case: changes take effect per-query, not per-cache

Unlike MX, an SPF TXT lookup happens fresh for each verifying receiver at send time, within the TTL constraints of their own resolver cache. The risk with SPF specifically is less about routing and more about alignment: if you add a new sending source to SPF but the receiver's resolver is still serving a cached answer without that source, mail from the new source will fail SPF at that receiver until their cache catches up - which, combined with DMARC enforcement, can mean legitimate mail gets rejected or quarantined during the propagation window.

What not to do

Do not change an MX record and decommission the old server in the same maintenance window - give it the full old TTL plus margin. Do not skip the multi-resolver check and trust a single lookup. Do not leave TTL at a long default if you are mid-migration and might need another change; shorten it for the whole migration period, not just the first change. And do not assume your own resolver's view is representative - always check from several independent public resolvers before declaring a DNS change complete.

Where MailPilot fits

MailPilot checks SPF, DKIM and DMARC on the sending domain on an ongoing basis, which catches the specific failure mode of a propagation-window SPF mismatch - a sending source newly added to SPF that some receivers have not picked up yet - rather than leaving it to surface only as unexplained authentication failures in DMARC aggregate reports days later.