KoltrixDNS TTL strategy for email authentication changes
Lower TTLs before you change SPF, DKIM or MX, and know which caches ignore you. A practical timeline for authentication changes without surprises.
On this page(8 sections)
- What a TTL really controls
- A timeline for planned changes
- Phase 1: lower the TTL in advance
- Phase 2: make the change
- Phase 3: verify from outside
- Phase 4: raise the TTL again
- Change-specific guidance
- New names need extra care
- Emergency changes
- Records with longer caches outside DNS
- A planning checklist
- Key takeaways
Changing an SPF record or a DKIM key is a one-line edit. Deciding when that edit actually takes effect for every receiver on the internet is the hard part.
DNS caching means old and new records coexist for a while, and a good change plan is mostly a plan for that overlap.
What a TTL really controls
Every DNS record has a time-to-live, in seconds. When a resolver fetches your record, it may cache the answer for up to that long before asking again. A TTL of 3600 means a resolver that fetched your SPF record at noon may keep using that answer until 1 p.m., no matter what you change at 12:05.
Three details matter for email:
- The TTL that counts is the old one. When you change a record, resolvers holding the previous answer keep it for the remainder of the TTL that was attached to it when they fetched it. Lowering the TTL at the moment of the change does not help those resolvers.
- Not every cache honors your TTL exactly. Some resolvers enforce minimum or maximum cache times. Mail servers also often run their own local caching resolvers. Plan for some stragglers.
- Negative answers are cached too. If a receiver looked up a selector before you published it, the "does not exist" answer is cached according to the negative caching TTL from your zone's SOA record. Publishing a new name and immediately using it can fail for that reason.
A timeline for planned changes
The reliable pattern has four phases.
Phase 1: lower the TTL in advance
At least one full current TTL before the change, lower the TTL on the records you will touch, for example from 3600 or 86400 down to 300. Then wait for the old TTL to pass, so that every cache now holds a copy with the short TTL.
If the current TTL is a day, this phase takes a day. Skipping it is the most common reason a "quick DNS change" takes far longer than expected to propagate.
Phase 2: make the change
Publish the new value. Within about five minutes, caches holding the short-TTL copy will refresh and see it.
Phase 3: verify from outside
Check several public resolvers and, ideally, a real receiver:
for r in 1.1.1.1 8.8.8.8 9.9.9.9; do
dig +short TXT example.com @"$r" | grep -i spf1
doneSend a test message to an external mailbox and read the Authentication-Results header to confirm receivers evaluate the new record.
Phase 4: raise the TTL again
Once you are confident the change is good, restore a longer TTL. Short TTLs mean more queries to your DNS provider and more exposure to DNS outages, since a resolver must reach your servers more often. One hour is a reasonable steady-state value for most authentication records.
Change-specific guidance
Different records need different sequencing.
| Change | Order of operations | Why |
|---|---|---|
| Add a sender to SPF | Publish SPF first, then start sending | New IPs fail SPF until receivers see the updated record |
| Remove a sender from SPF | Stop sending first, then update SPF | Mail from the old sender keeps passing during the TTL window |
| New DKIM key | Publish key, wait TTL plus margin, then switch signing | Receivers must find the key before signatures reference it |
| Retire DKIM key | Stop signing, wait days, then revoke | Delayed mail is still verified with the old key |
| Tighten DMARC policy | Change any time; effect spreads over one TTL | Policy changes take effect gradually |
| Loosen DMARC policy in an emergency | Change immediately | Short TTL beforehand makes rollback faster |
| MX migration | Lower TTL, switch, keep old host accepting mail | Some senders keep using the old MX for a while |
The general principle: authorize before you use, and stop using before you de-authorize. Additions go DNS first; removals go DNS last.
New names need extra care
A new DKIM selector or a new subdomain record is a special case because of negative caching. If anything queried the name before you created it, perhaps a monitoring tool, a receiver testing a signature you sent too early, or you yourself running dig, the nonexistence may be cached for the negative TTL.
Check your zone's negative TTL:
dig SOA example.com +noall +answerThe last number in the SOA record is the negative caching TTL in common practice. If it is long, publish new names well before you need them and avoid querying them prematurely.
Emergency changes
Sometimes you cannot wait: a vendor's IP range changed and their mail is failing, or a DMARC policy is rejecting legitimate mail. In those moments:
- Make the change immediately; waiting for a TTL reduction only delays the fix.
- Expect it to take up to the old TTL to reach every resolver.
- Communicate that window to whoever is affected, rather than repeatedly re-editing the record.
- Afterward, consider whether the records involved should live at a shorter TTL permanently. Records that change often or are critical in incidents, such as DMARC, benefit from a moderate TTL like 300 to 3600 seconds.
Records with longer caches outside DNS
A few email mechanisms cache beyond DNS TTLs:
- MTA-STS policies are cached by senders for the
max_agein the policy file, which can be weeks. The_mta-stsTXT record'sidtells senders to refetch, but the policy itself persists in caches until refreshed. Update the policy before you change MX hosts. - BIMI logos and certificates are cached by mailbox providers on their own schedules, often longer than the DNS TTL.
- Reputation does not follow TTLs at all. A new IP or domain starts cold regardless of how quickly DNS propagates.
A planning checklist
- Identify every record the change touches, including subdomains.
- Lower TTLs at least one old-TTL period before the change.
- Sequence: authorize before use, stop use before de-authorizing.
- Publish new names early to avoid negative caching surprises.
- Verify from multiple public resolvers and a real message.
- Raise TTLs afterward.
- Note any non-DNS caches, such as MTA-STS
max_age, that need their own handling.
Key takeaways
- Caches keep the old answer for the TTL attached when they fetched it, so lower TTLs before a change, not during it.
- Authorize new senders and keys in DNS before using them; stop using old ones before removing them.
- Negative caching can make brand-new names appear missing; publish them early.
- MTA-STS policies and BIMI assets have their own caches beyond DNS.
- Restore sensible TTLs once the change is verified.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
