Understanding DNS TTL Values and Why They Matter for Email
DNS TTL values are one of those configuration details that most email administrators set once and never revisit — until a migration goes wrong or a DNS change takes hours longer to propagate than expected. TTL (Time to Live) controls how long your DNS records are cached by resolvers worldwide, and the value you choose has real consequences for how quickly changes take effect, how much DNS query load your authoritative servers absorb, and how smoothly email routing transitions happen.
What DNS TTL Values Actually Mean
When a resolver queries your authoritative DNS server for a record — say, your MX record — it receives both the record value and a TTL expressed in seconds. That TTL tells the resolver how long it may cache the record before querying again. A TTL of 3600 means the record is cached for one hour. A TTL of 86400 means it's cached for 24 hours.
During that cache period, the resolver serves the cached value without making a new query. This is efficient — it reduces load on your authoritative DNS servers and speeds up resolution for end users — but it also means that changes you make to your DNS records aren't immediately visible to everyone. The old cached value stays in circulation until TTLs expire across all the caches holding it.
Why DNS TTL Values Matter for Email
Email routing depends on MX records, which tell sending servers where to deliver mail for your domain. Authentication depends on TXT records — your SPF record, your DKIM public key records, and your DMARC policy. All of these are DNS records subject to TTL behavior.
When you make changes to any of these records — adding a new email provider, rotating a DKIM key, updating your SPF record to include a new sending service — the old record remains authoritative at every resolver that has it cached until their TTL expires. This creates a window of inconsistency: some senders will see your new record and some will see the old one, depending on when they last cached it.
The Right DNS TTL Strategy for Email Records
The standard approach is to use different TTLs for normal operation and planned changes:
Normal operation: Use a relatively high TTL — 3600 to 86400 seconds (1 to 24 hours) — for stable records that you don't change frequently. Higher TTLs reduce DNS query load and generally improve resolution speed for recipients looking up your domain.
Before planned changes: At least 24–48 hours before you intend to make a change, reduce the TTL on the affected record to a low value — 300 to 600 seconds (5 to 10 minutes) is typical. Wait at least one full TTL cycle at the new low value before making your change. This way, when you update the record, the old cached values expire quickly and the new value propagates within minutes rather than hours.
After changes: Once the change is confirmed working, raise the TTL back to its normal value.
Common TTL Mistakes That Break Email
The most damaging mistake is changing a DNS record without first lowering its TTL. If your MX record has a 24-hour TTL and you switch email providers, the old MX records will continue to route mail to your previous provider for up to 24 hours after the change — with some resolvers holding the old value even longer due to stale caches. Mail delivered during that window may be lost.
Other common DNS TTL mistakes include:
- Setting TTLs too low permanently: A 60-second TTL on stable records creates unnecessary DNS query load and makes your mail routing dependent on your DNS servers' uptime at every delivery attempt.
- Forgetting that some resolvers ignore TTLs: Some ISP resolvers cap maximum TTLs or enforce minimum values. Your TTL setting is a hint, not a guarantee.
- Changing multiple records simultaneously: If you're updating SPF, MX, and DKIM records as part of a migration, stagger the changes and verify each one before proceeding to the next.
Recommended TTL Values for Common Email DNS Records
- MX records: 3600 seconds (1 hour) during normal operation; 300 seconds before planned provider changes
- SPF (TXT): 3600 seconds; lower to 300 before any SPF modification
- DKIM (TXT): 3600 seconds; during key rotation, keep the old key record live at 300 seconds until confirmed clear
- DMARC (TXT): 3600 seconds; changes to DMARC policy propagate at the TTL rate like any other record
Checking Your Current TTL Values
You can check current TTL values using command-line tools:
dig MX yourdomain.com
dig TXT yourdomain.comThe output includes the TTL alongside each record value. Online DNS checkers also display TTLs and let you verify what's being served from multiple geographic locations — useful for confirming propagation after a change.
Before any email migration or provider change, check the TTL on every affected record. If it's over 3600 seconds, lower it and wait before proceeding. This single habit prevents the majority of "why isn't my mail routing to the new server?" problems.
TTL Strategy During Email Provider Migrations
Email migrations deserve a step-by-step TTL playbook:
- Check current TTLs on MX, SPF, and DKIM records
- Lower all affected records to 300 seconds, at least 48 hours before migration day
- On migration day, update the records to point to the new provider
- Verify the new records are resolving correctly from multiple locations
- Monitor mail flow for at least 2–4 hours to confirm delivery is working
- Raise TTLs back to 3600 once everything is confirmed stable
For comprehensive DNS authentication setup — SPF, DKIM, and DMARC records — the MailDog DNS security guide walks through proper configuration for each record type. If you're planning a provider migration, the MailDog team can help you sequence DNS changes to avoid downtime. The guide on MX records and how email routing works is a useful foundation before tackling TTL strategy. For those working through DKIM transitions specifically, the post on DKIM key rotation covers the exact TTL approach needed during key changes.
