DELIVTERMS: TTL

Today on DELIVTERMS, the series here on Spam Resource where we help decode email and deliverability terminology, we're digging into something that's absolutely everywhere in DNS but rarely explained in plain language: TTL. It stands for "Time To Live." And in DNS, it determines how long a piece of information should be considered valid and kept around in cache.

TTL Defined

TTL ("Time to Live") is a setting attached to DNS records, like the ones you use for SPF, DKIM, DMARC, and MX. It tells other servers how long they're allowed to hang onto that record before they need to come back and ask for it again.

Think of it as an expiration date for DNS info. If your SPF record has a TTL of 3600 seconds (1 hour), then anyone looking it up will cache that answer for up to an hour. After that, they'll go back and check again to see if anything has changed.

Short TTLs mean frequent rechecks. Long TTLs mean less traffic, fewer DNS lookups, and less load on your DNS servers.

It is pronounced "time to live," as in "how long a DNS record has to live," meaning with a short "i" sound in live. 

Caching 101

Caching just means saving the result of a DNS lookup temporarily so you don't have to ask again every single time. TTL is what defines how long that saved result is considered fresh. Caching improves speed. In the context of email authentication, without caching, every email sent would trigger multiple DNS lookups per domain (SPF, DKIM, DMARC, MX) and that traffic would add up fast. Caching helps to keep, among other things, email authentication checks speedy and efficient.

But caching data for longer, while making things speedier, means that it can take longer for DNS changes to show up to the world. If Google is caching your SPF record for a day (thanks to a TTL setting of 86400), that means that they'll hold on to an already captured version of that email authentication record for up to 24 hours, even if you've made changes halfway through the day. Meaning your changes won't be visible at Gmail until that caching expires.

Services that utilize DNS, and who want to do so dynamically, allowing for quick "on the fly" updates to DNS-related settings (like, for example, in the realm of email authentication) by their nature will have very short (low) TTL settings.

How do I look up the TTL for a domain?

Here's an easy way to look up the TTL setting for a given domain or subdomain. Head over to dns.google, type in a domain and select the record type (TXT, MX, etc.). The result will include the TTL value, labeled right there for you in the output. (This is very similar to using the unix command "dig.")

How do I set TTL for a domain?

TTL settings are managed in your DNS host or provider. Log in to wherever you manage DNS (Cloudflare, GoDaddy, AWS Route 53, etc.), find the DNS record you want to adjust, and you'll usually see a TTL field next to it. Some providers give you a dropdown menu with common values like 300 (5 minutes), 3600 (1 hour), 86400 (24 hours). Others let you type in the TTL directly. 

How do TTLs impact email deliverability?

They must, somehow, sometimes, or why would I be talking about it here?

If your SPF record has a TTL of 60 seconds, then mailbox providers need to fetch that record again every minute. Multiply that by a high email volume, and now a mailbox provider's DNS servers are handling a lot of traffic, with a lot of external callouts to various authoritative servers. If those servers can't keep up, or if the servers hosting the necessary DNS information being queried have trouble keeping up, then lookups might fail. And if they do, email authentication checks could fail, even when your SPF or DKIM setup seems to be implemented correctly.

This could cause deliverability problems, including potential message rejections. If you're worried that you might be running into this, Steve Atkins has some suggestions for you on how best to handle it.

What about negative caching?

One thing people often overlook: TTLs on existing records don't control how long a DNS resolver will remember that a record doesn't exist. That's known as negative caching.

Negative caching is governed by the SOA (Start of Authority) record for your domain. It has a field that tells resolvers how long to cache a "no such record" result. So if you just published a new DKIM key and it's not showing up right away, it might not be your TTL, but instead it could be negative caching holding onto an earlier NXDOMAIN result for a few hours.

Something to keep in mind when making DNS changes and wondering why they're not visible immediately.

Learn more about DNS and Deliverability

If you'd like a chance to experiment with DNS settings (including TTLs), be sure to check out "Mess with DNS" from Julia Evans, where she lets you create DNS records to experiment with.

And who wouldn't want to see more than forty additional email technology and deliverability definitions like this? Check out the full DELIVTERMS series here on Spam Resource and thank you for reading!