MX Record TTL: Why Time-To-Live Matters for Email Delivery

What is TTL in DNS? The Timer That Controls DNS Caching

TTL, or Time-To-Live, is a numerical value in every DNS record that tells recursive resolvers (like your ISP's DNS or Google's 8.8.8.8) how long to cache that record before requesting a fresh copy from the authoritative nameserver.

Think of TTL as an expiration date for DNS information. When a resolver looks up your MX record, it stores the result in its cache for the duration specified by the TTL. During that time, any subsequent queries for the same record receive the cached answer instantly—no need to query the authoritative server again.

How TTL Appears in DNS Records

yourdomain.com.  3600  IN  MX  10  mail.yourdomain.com

In this example, 3600 is the TTL, specified in seconds. It means resolvers should cache this MX record for 1 hour before checking for changes.

Common TTL Ranges for MX Records

• 300 seconds (5 minutes): Very short. Used during migrations or when you need fast updates. Increases DNS query volume slightly.
• 900 seconds (15 minutes): Short. Good for dynamic environments or organizations that change email providers frequently.
• 3600 seconds (1 hour): Standard default. Balances update speed and cache efficiency. Most common for MX records.
• 86400 seconds (24 hours): Long. Used for stable configurations that rarely change. Slowest to update but fastest lookups.

Common Default TTL Values by DNS Provider

Different DNS providers set different default TTLs. Knowing your provider's default helps you plan migrations correctly.

Provider Default TTLs

• Cloudflare: Auto (typically 300-3600 seconds). Cloudflare optimizes TTL based on record type and query patterns. MX records often get 3600 seconds.
• AWS Route53: 300 seconds (5 minutes) by default. Very migration-friendly.
• Google Cloud DNS: 300 seconds (5 minutes) by default.
• GoDaddy: 3600 seconds (1 hour) by default for MX records.
• Namecheap: 1800 seconds (30 minutes) by default.
• DigitalOcean: 1800 seconds (30 minutes) by default.
• Azure DNS: 3600 seconds (1 hour) by default.

How to Check Your Current MX TTL

Use our MX Lookup Tool—it displays the TTL for each MX record returned. Or use command line:

dig yourdomain.com MX

The TTL appears as a number before the record type (e.g., `3600 IN MX`).

The TTL Migration Strategy: How to Switch Email Providers Without Losing Mail

Email provider migrations are high-risk operations. Changing MX records from old provider to new provider can cause email loss if done incorrectly. The TTL migration strategy eliminates this risk.

The 4-Step TTL Migration Process

Step 1: Reduce TTL (5+ Days Before Migration)

Weeks or days before your migration, reduce your MX record TTL to 300 seconds (5 minutes).

Before: yourdomain.com.  86400  IN  MX  10  old.provider.com
After:  yourdomain.com.  300    IN  MX  10  old.provider.com

Why? Low TTL ensures that when you make the final switch, changes propagate quickly.

Wait time: After reducing TTL, wait at least the original TTL duration (e.g., 24 hours) for all caches to expire and pick up the new TTL value. Otherwise, some resolvers still have the old 24-hour TTL cached.

Step 2: Dual Delivery (Optional but Recommended)

If your old and new email providers support it, configure both to receive email simultaneously. This requires coordination and isn't always possible with consumer providers.

Step 3: Switch MX Records (Migration Day)

Replace old MX records with new provider's MX records. Keep TTL at 300 seconds.

yourdomain.com.  300  IN  MX  10  new.provider.com
yourdomain.com.  300  IN  MX  20  backup.new.provider.com

Step 4: Verify and Monitor (48 Hours)

After switching, monitor email delivery for 48 hours. Use our MX Lookup Tool to verify propagation. Some email servers may still have old MX cached during this window.

Step 5: Increase TTL Back (After Migration)

Once you confirm all email is flowing correctly (typically 48-72 hours after switch), increase TTL back to a standard value like 3600 seconds.

What Happens If You Skip TTL Reduction?

If your MX records had a 24-hour TTL and you switch immediately, here's what happens:

• Some resolvers will deliver email to your new provider (they had expired cache or queried fresh).
• Other resolvers will deliver email to your old provider (they still have the cached old MX record for up to 24 hours).
• If you cancel your old provider immediately, email to those resolvers will bounce.
• You lose email for up to 24 hours from senders using those resolvers.

TTL's Role in Failover Speed: How Fast Can You Recover?

TTL doesn't just affect planned migrations—it also affects disaster recovery. If your primary mail server goes down, how quickly can you switch to a backup?

The Failover Scenario

Imagine your primary mail server fails at 2:00 PM. You want to switch MX records to point to a backup server. The time until email starts flowing to the backup server depends entirely on TTL.

• TTL = 300 seconds (5 minutes): Maximum 5-minute delay before all senders use backup.
• TTL = 3600 seconds (1 hour): Up to 1 hour of email loss or queuing delays.
• TTL = 86400 seconds (24 hours): Up to 24 hours before full recovery.

Balancing Failover Speed vs Query Volume

Low TTL sounds great for failover—so why not use 300 seconds for everything? Because low TTL increases DNS query volume.

Every email sender queries your MX record before delivery. With 3600 second TTL, each sender queries once per hour. With 300 second TTL, each sender queries 12 times per hour. For high-volume domains, this increases DNS infrastructure load.

Recommended TTL Strategy for Most Businesses

• Standard operation: 3600 seconds (1 hour). Good balance of failover speed and query efficiency.
• Before planned migration: Reduce to 300 seconds, wait 24 hours, then execute migration.
• High-availability critical systems: Consider 900-1800 seconds (15-30 minutes) permanently.
• Low-volume domains: 300 seconds is fine. The query volume impact is negligible.