Definition
Email DNS TTL (Time To Live) is the length of time, measured in seconds, that a DNS record may be cached by resolvers and receiving mail servers before they query the authoritative server again. TTL governs how quickly changes to email-related DNS records — such as SPF, DKIM, DMARC, and MX records — take effect across the internet.
How It Works
Every DNS record carries a TTL set by the domain owner. When a mail server looks up a record, it stores the result locally for the duration of the TTL. Subsequent lookups within that window are served from cache, so a change to the record is not seen by that server until the TTL expires and it re-queries.
The trade-off is straightforward:
| TTL setting | Effect |
|---|---|
| Short (e.g. 300 seconds) | Changes propagate quickly, but more DNS queries occur |
| Long (e.g. 86400 seconds) | Fewer queries and faster lookups, but changes are slow to propagate |
For email infrastructure, the TTL on authentication and routing records matters most when a change is planned, such as rotating a DKIM key, updating an SPF record, or migrating to a new mail provider.
Why It Matters
TTL directly affects how long a misconfiguration or an intended change takes to propagate. A common mistake is to change an SPF or MX record and expect immediate results, only to find delivery still affected hours later because caches have not expired.
Best practices for email DNS TTL include:
- Lower the TTL to a short value well before a planned migration or record change, so the cutover propagates quickly.
- Restore a longer TTL after the change has stabilised, to reduce query load and improve resilience.
- Remember that some resolvers and providers enforce minimum cache times, so changes may still take longer than the TTL suggests.
TTL also has security implications: an attacker who can manipulate a cached record can redirect mail until the cache expires, which is why critical records are sometimes given conservative TTL values.
Example
A company plans to migrate to a new email service provider on a Friday. On Monday, it lowers the TTL on its MX and SPF records to 300 seconds. On migration day, the new records propagate within minutes, and mail flows to the new provider almost immediately rather than being delayed by stale caches.
Was this useful?
Related Glossary Terms
BIMI
BIMI (Brand Indicators for Message Identification) is an email standard that allows brands to display their logo next to their emails in supported email clients. It requires DMARC enforcement at quarantine or reject policy.
Email Deliverability
Email deliverability is the ability to land in the recipient's inbox rather than the spam folder. It depends on sender reputation, authentication, list quality, and content practices.
DKIM Alignment
DKIM alignment is the DMARC requirement that the domain in the From header matches the domain in the DKIM signature, confirming the visible sender domain is authenticated.
DKIM (DomainKeys Identified Mail)
DKIM (DomainKeys Identified Mail) is an email authentication method that uses digital signatures to verify that an email was not tampered with during transit and comes from a authorised domain.
DMARC Aggregate Report
A DMARC aggregate report is a machine-readable XML summary that receiving mail servers send to domain owners daily to show authentication results for their email traffic.
DMARC Forensic Report
A DMARC forensic report is a detailed message-level copy of an individual email that failed DMARC authentication, sent to the domain owner to help diagnose spoofing and misconfiguration.
Frequently Asked Questions
A common default is 3600 seconds (one hour), balancing propagation speed and query load. When a change is imminent, lower the TTL to around 300 seconds in advance, then raise it again once the change is stable.
Indirectly. Stale DNS records during a migration or record change can cause authentication failures or routing problems that affect deliverability. Managing TTL correctly during changes prevents these transient failures.
Edit the existing record in your DNS provider and set a lower TTL value, then wait for that shorter value to propagate before making the actual change. This ensures caches expire quickly when the new record is published.
Yes. Extremely low TTLs increase DNS query volume, which can slow lookups and, in rare cases, cause providers to disregard the value. Use low TTLs deliberately during changes rather than permanently.