What Is DNS TTL and How Does It Affect Email Changes?

DNS TTL (time to live) is a number of seconds attached to every DNS record that tells resolvers how long they may keep a cached copy before asking your nameservers again. A TTL of 3600 means one hour. For email, TTL decides how quickly the world notices a new MX or SPF record, and therefore how long a migration overlaps between old and new mail hosts.

Quick summary

• 300 (5 minutes): common default at Cloudflare and good for records you are about to change.
• 3600 (1 hour): the most common default and a sensible resting value for MX and TXT records.
• 14400 (4 hours): the cPanel and many shared host default. Slow to change but reduces DNS traffic.
• 86400 (24 hours): safe for records that never change, such as NS records at the registry.
• Auto: Cloudflare language for a managed value, usually 300 for non-proxied records.

How TTL works in practice

When a sending server delivers to you, it usually asks its local resolver (Google Public DNS, its ISP, or its own cache) for your MX records (the settings that tell the internet where to deliver email for your domain). That resolver fetches the answer from your authoritative nameservers and remembers it for the TTL. Any query in that window gets the cached copy. Only after the TTL expires does the resolver fetch the fresh record. So a change is not visible everywhere until every cache that held the old value has expired.

TTL values you will see

• 300 (5 minutes): common default at Cloudflare and good for records you are about to change.
• 3600 (1 hour): the most common default and a sensible resting value for MX and TXT records.
• 14400 (4 hours): the cPanel and many shared host default. Slow to change but reduces DNS traffic.
• 86400 (24 hours): safe for records that never change, such as NS records at the registry.
• Auto: Cloudflare language for a managed value, usually 300 for non-proxied records.

Example: how TTL shapes a mail migration

Day 0, 09:00  Lower MX TTL from 14400 to 300 (keep the old value)
Day 0, 13:00  Old 14400 caches have expired; everyone now caches for 300s
Day 0, 13:05  Change MX to mail.oqumail.com priority 10
Day 0, 13:10  Nearly all senders deliver to OquMail
Day 1         Raise TTL back to 3600

How to check the TTL of a record

1. Run dig MX (Mail Exchanger — where incoming email is delivered) yourdomain.com (macOS, Linux). The number after the name in the ANSWER section is the remaining TTL as seen by your resolver.
2. Run dig MX (Mail Exchanger — where incoming email is delivered) yourdomain.com @ns1.your-nameserver.com to ask the authoritative server directly and see the full configured TTL.
3. On Windows, nslookup -debug -type=MX (Mail Exchanger — where incoming email is delivered) yourdomain.com prints the ttl line.
4. Your DNS panel shows the configured TTL next to each record; that is the value new caches will use.

Common TTL mistakes

• Changing the MX and the TTL at the same time. The old cache still holds the old record for the old TTL; lowering must happen first.
• Setting TTL to 60 permanently. It works but causes far more DNS traffic and offers no benefit once the record is stable.
• Assuming DNS is broken because a checker still shows the old value. It is simply serving from cache.
• Forgetting that your own computer and router also cache. Flush with ipconfig /flushdns on Windows or sudo dscacheutil -flushcache on macOS before retesting.

TTL and OquMail verification

OquMail queries your authoritative nameservers when you press Check DNS, so a fresh record is usually detected within minutes regardless of the TTL you set. Senders elsewhere, however, follow their own caches. If you are moving from another host, keep the old mailboxes reachable for at least the length of the old TTL after the switch, then create your mailboxes on OquMail and confirm mail is arriving in webmail.

Common questions

What TTL should I use for MX, SPF and DKIM?

3600 is a good resting value. Drop to 300 the day before any planned change, and restore afterwards.

Does TTL affect how fast my email is delivered?

No. It only affects how long a cached answer is reused. A lookup takes milliseconds either way.

Why did my change appear instantly for me but not for a customer?

Your resolver had no cached copy, or you flushed it. Their resolver still held the old record and will refresh when its TTL runs out.