For email DNS records, use TTL values that balance caching efficiency with operational flexibility. Standard recommendation: MX records at 3600s (1 hour), SPF/DKIM at 3600-86400s (1-24 hours), DMARC at 86400s (24 hours). Lower TTL to 300-600s before planned changes, then restore after. Emergency failover requires pre-planned low TTLs.
DNS TTL Strategy for Email Infrastructure
Why TTL Matters for Email
TTL (Time To Live) controls how long DNS resolvers cache your records. For email infrastructure:
- Too high: Changes propagate slowly. Migrations and failovers take hours or days.
- Too low: More DNS queries, higher load, potential for lookup failures.
- Just right: Quick propagation when needed, efficient caching normally.
Email authentication especially depends on DNS lookups. Every incoming email triggers SPF and potentially DKIM/DMARC lookups. TTL strategy affects both operational flexibility and system performance. For a complete view, see our DNS configuration guide.
Recommended TTL Values
| Record Type | Normal TTL | Pre-Change TTL | Rationale |
|---|---|---|---|
| MX | 3600s (1 hour) | 300s (5 min) | Balance failover speed with caching |
| A (mail server) | 3600s | 300s | Must update quickly if IP changes |
| SPF (TXT) | 3600-86400s | 300s | Changes infrequently, cache well |
| DKIM (TXT) | 86400s (24 hours) | 300s | Rarely changes, high cache benefit |
| DMARC (TXT) | 86400s | 300s | Policy changes need time to propagate anyway |
| PTR | Controlled by IP owner | Varies | Usually 1800-3600s |
Normal Operations
For day-to-day email operations, optimize for caching:
; MX records - 1 hour
example.com. 3600 IN MX 10 mail.example.com.
example.com. 3600 IN MX 20 backup.example.com.
; Mail server A records - 1 hour
mail.example.com. 3600 IN A 192.0.2.10
backup.example.com. 3600 IN A 192.0.2.20
; SPF - 1 hour to 24 hours
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"
; DKIM - 24 hours (changes are rare)
selector._domainkey.example.com. 86400 IN TXT "v=DKIM1; k=rsa; p=..."
; DMARC - 24 hours
_dmarc.example.com. 86400 IN TXT "v=DMARC1; p=reject; rua=..."
Practitioner note: I see people set everything to 300 seconds "just in case." That's wasteful. If your DKIM key hasn't changed in two years, why make resolvers query for it every 5 minutes? Set TTL based on how often the record actually changes.
Pre-Change Preparation
Before any email infrastructure change:
24-48 Hours Before
Lower TTL on affected records:
# Lower MX TTL to 5 minutes
example.com. 300 IN MX 10 mail.example.com.
# Lower mail server A record TTL
mail.example.com. 300 IN A 192.0.2.10
Why Wait 24-48 Hours?
The old, higher TTL is cached. You need to wait for those caches to expire before the new lower TTL takes effect.
If your current TTL is 86400 (24 hours), lowering it doesn't help until 24 hours pass and caches refresh with the new, lower TTL.
Before: TTL 86400s cached at 08:00, expires at 08:00 next day
Change TTL to 300s at 10:00
Cache still holds 86400s TTL until 08:00 next day
After 08:00: Resolvers fetch new 300s TTL
Now changes propagate in ~5 minutes
Email Migration TTL Strategy
Phase 1: Preparation (T-48 hours)
# Lower all relevant TTLs
example.com. 300 MX 10 oldserver.example.com.
example.com. 300 MX 20 backup.example.com.
oldserver.example.com. 300 A 192.0.2.10
Phase 2: Migration (T-0)
Add new server at lower priority, test delivery:
example.com. 300 MX 10 oldserver.example.com.
example.com. 300 MX 15 newserver.example.com. # Added
example.com. 300 MX 20 backup.example.com.
Phase 3: Cutover (T+1 hour)
Swap priorities:
example.com. 300 MX 10 newserver.example.com. # Now primary
example.com. 300 MX 20 oldserver.example.com. # Now backup
example.com. 300 MX 30 backup.example.com.
Phase 4: Cleanup (T+24-48 hours)
After confirming new server works:
example.com. 3600 MX 10 newserver.example.com. # Restore TTL
example.com. 3600 MX 20 backup.example.com.
# Remove old server
Failover Considerations
Planned Failover
If you have maintenance windows, lower TTL beforehand:
Week before: Set MX TTL to 300s
Maintenance window: Update MX records as needed
After maintenance: Restore TTL to 3600s
Unplanned Failover
If your primary server dies unexpectedly:
- Current TTL determines how long old records are cached
- Can't speed up propagation of changes you're making now
- Backup MX records should already exist
Lesson: If fast failover matters, keep MX TTL low (300-600s) all the time. Trade increased DNS queries for faster recovery.
Practitioner note: After one client had a 4-hour outage because their MX TTL was 24 hours and they couldn't failover quickly, they dropped to 5-minute TTL permanently. DNS costs went up slightly, but they never had that problem again. Know your risk tolerance.
SPF TTL Considerations
SPF lookups happen on every incoming email. High TTL = good for caching, but:
The SPF Lookup Problem
SPF has a 10 DNS lookup limit. Each include: or redirect adds lookups. If receiving servers can't cache these, lookups may timeout.
For complex SPF with many includes:
- Higher TTL (3600-86400s) reduces lookup overhead
- Helps receiving servers cache nested records
For simple SPF:
- TTL matters less
- 3600s is reasonable default
Before Adding a New ESP
- Lower SPF TTL to 300s
- Wait 24-48 hours (based on old TTL)
- Add new ESP to SPF record
- Verify with SPF check tools
- Restore TTL to 3600-86400s
DKIM TTL Strategy
DKIM records are large (2048-bit keys are ~400 characters) and rarely change.
Recommendations:
- Use high TTL (86400-604800s / 1 day to 1 week)
- Lower before key rotation
- DKIM key rotation is infrequent (annually at most)
Key Rotation Process
- Generate new key with new selector
- Publish new DKIM record (new selector, low TTL)
- Configure ESP to sign with new key
- Keep old key published for 1-2 weeks (old signatures still in transit/queues)
- Remove old key
- Raise TTL on new key
Monitoring and Verification
Check Current TTL
dig MX example.com +ttlunits
# Shows remaining TTL in human-readable format
dig MX example.com
# Shows TTL in seconds in ANSWER section
Verify Propagation
After changes, check multiple resolvers:
# Google
dig @8.8.8.8 MX example.com +short
# Cloudflare
dig @1.1.1.1 MX example.com +short
# Quad9
dig @9.9.9.9 MX example.com +short
Different resolvers may have different cached values during propagation.
Common Mistakes
Changing records without lowering TTL first The change won't propagate quickly because old high-TTL records are cached.
Setting TTL too low permanently Unnecessary DNS query load. Use low TTL only when needed.
Forgetting to restore TTL after changes Leaving TTL at 300s when it should be 3600s wastes resources.
Not accounting for negative caching If a record didn't exist, resolvers cache that "doesn't exist" response too. Adding a new record may take time to appear.
Ignoring provider-specific minimums Some DNS providers have minimum TTL values. Cloudflare Pro allows 1 minute; free tier is higher.
If you're planning an email infrastructure migration and want to ensure zero email loss during transition, schedule a consultation.
Sources
- RFC 1035: Domain Names - Implementation and Specification
- RFC 2308: Negative Caching of DNS Queries
- Cloudflare: DNS TTL Best Practices
- AWS Route 53: Choosing a TTL
v1.0 · March 2026
Frequently Asked Questions
What TTL should MX records have?
3600 seconds (1 hour) for most organizations. This balances quick failover with reasonable caching. For high-availability setups, use 300-600 seconds. For stable environments, 3600-14400 seconds is fine.
Should SPF records have high or low TTL?
3600-86400 seconds (1-24 hours). SPF records change infrequently—typically only when adding a new ESP. Lower TTL before planned changes. High TTL reduces DNS query load and improves caching efficiency.
How do I prepare for an email migration with DNS TTL?
Lower MX record TTL to 300-600 seconds 24-48 hours before migration. This ensures most resolvers have short-cached copies. After migration and verification, restore TTL to normal (3600-86400 seconds).
What happens if TTL is too high?
Changes take longer to propagate. If your TTL is 86400s (24 hours) and you need to switch mail servers, some recipients won't see the change for up to 24 hours. During that time, mail goes to the old server.
Does low TTL hurt email deliverability?
Not directly, but very low TTL (under 60s) may cause DNS lookup delays or failures if resolvers can't cache effectively. It can also increase DNS costs and load. Use the lowest TTL necessary for your operational needs, not lower.
Want this handled for you?
Free 30-minute strategy call. Walk away with a plan either way.