MX TTL sanity

The MX TTL doesn’t change anything about mail routing. It controls how long resolvers cache the MX record before re-fetching it. That sounds boring until you’re 18 hours into a mail provider cutover and half the senders in the world are still delivering to the old host.

Cathedra runs a small sanity check on the MX TTL. The thresholds are unfussy: under 300 seconds is too low, over 86,400 seconds is too high. The default for most DNS hosts is 3,600 seconds (1 hour), and that’s the right number for steady-state operation.

What Cathedra checks

DnsHygieneCheck pulls the MX records and reads the TTL on the first one. Two conditions trigger findings.

If the TTL is under 300 seconds:

status: warning / severity: low
“MX record TTL is {ttl}s, which is very low. This causes excessive DNS lookups.”
Recommendation: “Set MX TTL to at least 300s (5 minutes). 3600s (1 hour) is typical.”

If the TTL is over 86,400 seconds (24 hours):

status: warning / severity: low
“MX record TTL is {ttl}s. Migrations will be slow to propagate.”
Recommendation: “Before any planned mail provider migration, lower the TTL to 300s.”

If the TTL is between 300 and 86,400 — including the very common 3,600 — Cathedra emits no MX TTL finding at all. No news is good news on this one.

Why the lower bound exists

A 60-second TTL means every recursive resolver in the world re-fetches the MX record at most once a minute. For a popular domain, that’s a measurable load on the authoritative nameservers and a measurable amount of UDP traffic. More importantly: each lookup adds latency to mail delivery. A sender that has to hit DNS before every connection is slower than a sender that can use a cached answer for the next hour.

In practice, you encounter sub-300-second TTLs in three scenarios:

1. Migration leftover. Someone lowered the TTL before a cutover (correctly) and never restored it. Most common cause.
2. Cloudflare proxy default. Cloudflare-proxied records often default to a 60-second TTL even though MX records aren’t proxied. The DNS host still serves it short.
3. Misunderstanding. A tech thought “lower TTL = better performance” and set it to 60 across the board.

The fix in all three cases is the same: raise the MX TTL to 3,600 seconds.

Why the upper bound exists

A TTL over 24 hours means a recursive resolver can cache the MX for a full day. When you change the MX record — most often during a mail provider migration — resolvers that have a fresh cache will keep delivering to the old host until the cache expires. For a one-day TTL, that means up to 24 hours of mixed delivery after cutover. For the multi-week TTLs you occasionally see, it means real mail being delivered to a server that no longer exists.

You’ll encounter long MX TTLs in two scenarios:

1. Set-and-forget zones. A domain provisioned years ago with the host’s default TTL, where the default happened to be a week.
2. Deliberate “don’t change anything” posture. A previous admin wanted to maximize cache hits and minimize lookups, and didn’t think about what migration would look like.

The fix: lower the TTL to 3,600 seconds for steady state. Lower it further (to 300 seconds) when a migration is coming.

The migration playbook around MX TTL

The standard pattern when you’re prepping a mail provider cutover for a client:

1. T-minus 48 hours. Lower the MX TTL to 300 seconds. The whole world re-fetches the MX at most every five minutes from now on.
2. T-minus 24 hours. Confirm with dig isidoregroup.com MX that the TTL is showing 300. If a cached resolver is still reporting the old TTL, you have a few more hours before cutover safety is guaranteed.
3. Cutover. Change the MX record. Within five minutes, every resolver in the world should be pulling the new MX.
4. T-plus 24 hours. Restore the MX TTL to 3,600 seconds.

That four-step sequence is the most common reason you’ll deliberately violate the lower bound. Cathedra will warn during the migration window. That’s expected and fine — the warning is informational. Document it on the audit report alongside “migration in progress; TTL restored after cutover” so future audits don’t surface it as a regression.

What the check ignores

Cathedra only reads the TTL of the first MX record. If a domain has multiple MX records with different TTLs (legal but unusual), the check sees only the first one. You won’t encounter this in normal operations — most DNS hosts force a single TTL across all records of the same type at the same name — but it’s worth knowing.

The check also doesn’t look at TTLs on any other record type. SPF, DMARC, and other TXT records can have whatever TTL the admin set; Cathedra has no opinion. In practice, you want the same hygiene there: 3,600 for steady state, 300 before a change.

Cheat sheet

MX TTL	Cathedra status
<300 seconds	warning / low — “excessive DNS lookups”
300–86,400 seconds	no finding emitted
>86,400 seconds	warning / low — “migrations will be slow to propagate”

Quick command reference

dig isidoregroup.com MX
;; ANSWER SECTION:
isidoregroup.com.   3600   IN   MX   0   isidoregroup-com.mail.protection.outlook.com.

The 3600 in the second column is the TTL. That’s the field Cathedra is reading.

What you should remember

• Cathedra warns when MX TTL is under 300 seconds (“excessive DNS lookups”) or over 86,400 seconds (“migrations will be slow to propagate”).
• 3,600 seconds (1 hour) is the right steady-state value. 300 seconds is the right pre-migration value. Restore to 3,600 after cutover.
• Sub-300 TTLs in the wild are usually migration residue. Raise them back to 3,600 once the migration is done.
• Multi-day TTLs make migrations painful. Lower them to 300 at least 48 hours before any planned mail cutover.
• The check reads only the first MX record’s TTL. Multi-MX domains with mixed TTLs are unusual but possible.

That closes Module 1. Module 2 starts on mail routing itself — MX priority, fallback behavior, and how Cathedra reads the path a message takes to reach a mailbox.

---

Cathedra alignment: DnsHygieneCheck — MX TTL Sanity