DNS TTL Values and Email Delivery: How to Set Them and When to Change Them
TTL — Time to Live — is a number attached to every DNS record that tells resolvers how long to cache the record before checking for updates. It is a simple concept with significant practical consequences for email. Get TTL values wrong and you will find yourself waiting unexpectedly long for DNS changes to take effect — or making a change that you thought would propagate in minutes but instead takes 24 hours to reach everywhere.
How TTL Works
When a DNS resolver looks up a record for the first time, it caches the response for the duration specified by the TTL. If another query comes in for the same record before the TTL expires, the resolver serves the cached answer without querying the authoritative nameserver again. TTL is measured in seconds: 3600 means one hour, 86400 means 24 hours, 300 means five minutes.
When you change a DNS record, the old version persists in caches around the world until their cached copies expire. The maximum time you will wait for a change to be universally visible equals the TTL that was set on the record before you changed it — not the TTL you set on the new record.
TTL Values for Email-Related DNS Records
MX Records — 3600 to 14400 seconds
MX records point to your mail servers. They do not change often, but when they do — during a migration or failover — you need them to propagate reasonably quickly. A TTL between one and four hours balances stability with responsiveness. Avoid TTLs above 24 hours for MX records; you do not want to wait a full day for records to update during an urgent migration.
SPF TXT Records — 3600 seconds
SPF records change when you add or remove sending services. A one-hour TTL is appropriate — it gives resolvers good caching efficiency while not creating a long wait when you need to add a new service.
DKIM TXT Records — 3600 to 86400 seconds
DKIM public keys change during key rotation but are otherwise stable. You can use longer TTLs here — up to 24 hours — since the keys change infrequently. During key rotation, lower the TTL on the old key record first so removal propagates quickly after the cutover.
DMARC TXT Records — 3600 seconds
DMARC policies evolve as you move from monitoring to enforcement. A one-hour TTL lets policy changes propagate without long delays when you advance from none to quarantine or reject.
A Records for Mail Server Hostnames — 3600 seconds
The A records for your MX hostnames should allow for failover without excessive delay. One hour is a practical default.
How to Prepare for DNS Changes
The standard approach when a significant DNS change is planned:
- Lower the TTL well in advance. Before making the actual change, reduce the TTL on the record to 300 seconds. Do this at least as far in advance as the current TTL value. If the current TTL is 86400 (24 hours), lower it 24 hours before the change for the shortened TTL to be universally cached.
- Make the actual change. Update the record. With the short TTL in place, new values propagate within minutes.
- Monitor and verify. Confirm the change has taken effect using
digqueries or an online DNS checker. - Restore the longer TTL. Once the change is stable, set the TTL back to your standard value.
The TTL Trap: Planning Too Late
The most common mistake is deciding to change a DNS record without checking the current TTL first. If a record has a TTL of 86400 and you need the change to take effect in two hours, you are stuck. The cached copies will not expire for up to 24 hours regardless of what you set on the new record.
This is particularly painful during email migrations. When moving to a new mail provider, lowering your MX record TTL days in advance is the difference between a smooth cutover and a full day where some messages go to the old server and some to the new one. Always check the current TTL before scheduling a migration window.
TTL and Negative Caching
Negative caching is what happens when a query returns no result. The negative response is also cached, for a duration specified in the SOA record's negative TTL field. If a record is temporarily removed or contains a typo, resolvers will cache the "not found" response. This is another reason to double-check records before removing old entries — a cached negative response can cause delivery failures that outlast the original error.
Putting It Into Practice
A good default TTL policy for a business email setup is one hour (3600 seconds) for MX records, SPF, DMARC, DKIM, and A records for mail server hostnames. Before any planned change, lower to 300 seconds at least one full current-TTL duration in advance.
TTL management is part of the same careful DNS discipline that avoids common configuration errors that break email delivery. For teams managing DNS alongside email hosting, the MailDog DNS security tools provide a view of your current configuration. The documentation covers recommended DNS settings for all MailDog-hosted domains. For help planning a migration or DNS change, reach out to the team. More DNS guides are on the MailDog blog.
