DNS TTL Values and Their Impact on Email Authentication Changes

• March 2022
• Engineering Memo · External Release

Every email authentication DNS record — SPF, DKIM selectors, DMARC, MX — has a TTL (Time To Live) that controls how long downstream resolvers cache the record before querying for an update. TTL management is one of the most overlooked aspects of email authentication administration: operators who understand TTL behaviour can plan authentication changes with confidence, minimise propagation risk during incidents, and reduce the impact of misconfiguration by shortening the window before a correction takes effect.

This note documents the operational TTL strategy for each authentication record type, how propagation behaviour differs between planned changes and emergency fixes, and the specific TTL decisions that matter most in production email infrastructure.

How DNS TTL Works in Practice

When a DNS resolver queries a record and receives a response, it caches that response for the duration specified by the TTL value in seconds. Subsequent queries from clients using that resolver receive the cached answer — no new query to the authoritative nameserver is made until the TTL expires. A DKIM public key record with TTL=3600 can be cached by any resolver worldwide for up to one hour; after the TTL expires, the resolver will fetch the current record from the authoritative nameserver.

The implication for authentication changes: when you update a DNS record, resolvers that have cached the old value continue serving the old value until their cached copy expires. The maximum propagation delay is equal to the TTL of the old record at the moment of the change. If the DKIM selector record had TTL=86400 (24 hours) before you changed it, some resolvers may continue serving the old public key for up to 24 hours after you publish the new one.

This is why the standard advice for planned authentication changes is to lower the TTL well in advance of the change — reducing it from 86400 to 300 two or three hours before a DKIM key rotation ensures that the global cache of the old record drains quickly after the new record is published, limiting the window during which some resolvers serve the old key to 5 minutes rather than 24 hours.

TTL Recommendations by Record Type

Different authentication record types have different sensitivity to TTL misconfiguration and different operational requirements that inform the appropriate TTL values.

DKIM public key records (selector._domainkey.domain.com): The appropriate TTL for an active, stable DKIM key is 3600–43200 seconds (1–12 hours). This provides reasonable propagation speed if the key needs emergency rotation while limiting the number of resolver queries to the authoritative nameserver to a manageable rate for high-traffic domains. Lower TTLs (300–600 seconds) are appropriate during the overlap period of a key rotation — when both the old and new selectors are published simultaneously and either may be referenced by signed messages in transit. After the rotation is complete and the old selector is retired, the new selector's TTL can be raised back to 3600+.

SPF TXT records (domain.com): The SPF record changes relatively rarely compared to DKIM selectors — typically only when adding or removing sending services. A TTL of 3600 seconds (1 hour) balances propagation speed for changes against the query load on the authoritative nameserver. Lower TTLs (300–600 seconds) are appropriate in the 24 hours before and after a planned SPF change — particularly during infrastructure migrations where sending IPs change and the SPF record must accurately cover the new IPs from the moment the first message is sent from them.

DMARC records (_dmarc.domain.com): DMARC records change infrequently — primarily when escalating the policy from p=none to p=quarantine to p=reject, or when changing the RUA/RUF reporting addresses. A TTL of 3600–86400 seconds is appropriate for stable DMARC records. When planning a policy escalation, lower the TTL to 300 seconds 24 hours before the change, make the change, wait 5 minutes for propagation, and then raise the TTL back to a normal value. This limits the exposure window during which some resolvers apply the new policy to newly arriving messages while others still serve the old policy.

MX records (domain.com MX): MX records control where inbound email is delivered. Changes to MX records are among the highest-risk DNS changes because they affect the reception of all inbound email for the domain. MX TTL should be lowered to 300 seconds at least 24 hours before any planned MX change — not 1 hour before, because some resolvers that cached the old value with the original high TTL may still be serving it after 1 hour. After the MX change is stable and confirmed working, raise the TTL to 3600+ to reduce nameserver query load.

Emergency TTL Scenarios: When You Cannot Prepare

The TTL preparation protocol assumes a planned change with advance notice. Emergency scenarios — a DKIM private key is exposed and must be immediately revoked, an SPF record is misconfigured and is causing delivery failures, a sending IP is blacklisted and must be removed from the active pool immediately — do not allow 24 hours of TTL reduction before the fix. In these cases, the propagation delay is entirely determined by the TTL value that was in place before the emergency.

This is the core argument for maintaining moderate TTL values on authentication records during stable operation. An operator who sets DKIM selector TTL to 86400 seconds (24 hours) because "the record rarely changes" will face a 24-hour window of DKIM authentication failures if an emergency key rotation is required. An operator with TTL=3600 faces a maximum 1-hour window. The 10x difference in emergency response time is the cost of the "it rarely changes" optimisation.

The recommended stable-state TTL ceiling for authentication records is 14400 seconds (4 hours). This limits emergency propagation delay to 4 hours at worst, provides adequate caching to reduce nameserver query load, and is short enough that most emergency scenarios are resolved within a half-day business window. Records with TTL values above 14400 should be considered candidates for TTL reduction during the next quarterly authentication audit.

DKIM Key Rotation TTL Protocol

DKIM key rotation — replacing an existing private/public key pair with a new one — is the authentication change most sensitive to TTL management, because messages that were signed with the old key may still be in transit when the new key is published. The transition protocol must ensure that the old key's DNS record remains resolvable during the full potential transit time of signed messages.

The complete rotation protocol: (1) generate the new key pair; (2) publish the new public key at a new selector name (e.g., mail2022 if the current selector is mail2021) with TTL=3600; (3) configure the MTA to sign new messages with the new key and new selector, while ensuring the old selector's DNS record remains published; (4) wait 5–7 days — the maximum realistic transit time for deferred messages that were signed with the old key; (5) remove the old selector's DNS record.

The wait period in step 4 is critical. Removing the old selector immediately after configuring the new signing key would cause DKIM verification failures for any messages that were signed with the old key and are still in ISP delivery queues awaiting retry. These messages — typically deferred due to ISP throttling — may be retried days after the original injection and will fail DKIM verification if the old selector's DNS record has been removed. The 5–7 day overlap window accommodates even the most extended ISP retry schedules.

SPF Record Changes and TTL

SPF changes require different TTL consideration depending on the type of change. Adding a new IP address or include: mechanism to the SPF record — to authorise a new sending service before its first send — requires that the SPF record update be fully propagated before the first message is sent from the newly authorised source. If a message is sent from the new IP before the SPF record update has propagated to all resolvers, some ISPs will see SPF failure for that message because their resolver is still serving the old record.

The safe sequence for adding a new sending source to SPF: (1) update the SPF record to include the new IP or service; (2) wait for the TTL to expire — at TTL=3600, wait at least 1 hour; (3) verify propagation by querying the SPF record from multiple external resolvers (Google's 8.8.8.8, Cloudflare's 1.1.1.1, and an EU-based resolver); (4) only then send the first message from the new source.

Removing an IP from the SPF record — when decommissioning a sending source — is less time-sensitive. Messages sent before the removal are already signed and SPF-evaluated at delivery; messages sent after the removal from a decommissioned IP should not occur if the IP has been properly taken out of service. The main risk in SPF removal is inadvertently removing an IP that is still in use — which the accounting log can confirm before the DNS change is made.

DMARC Policy Escalation and TTL

Escalating DMARC from p=none to p=quarantine, or from p=quarantine to p=reject, is one of the most consequential DNS changes a domain owner can make. Messages from sources that fail DMARC alignment — which may include legitimate sending services that haven't yet been fully authenticated — will be quarantined or rejected by ISPs enforcing the DMARC policy. The propagation window during which some ISPs apply the new policy while others still serve the old policy is a period of inconsistent enforcement that can be minimised by TTL preparation.

With a TTL of 3600 on the DMARC record, the inconsistency window is at most 1 hour after the policy escalation — after which all resolvers that cached the old policy have refreshed and are serving the new one. With a TTL of 86400, the window extends to 24 hours during which some ISPs apply p=reject while others apply the old p=quarantine or p=none. For a policy escalation that is intended to immediately protect the domain from spoofing, a 24-hour inconsistency window is significant. Reducing the DMARC record TTL to 300 seconds before the escalation, then raising it after propagation is confirmed, limits this window to 5 minutes.

The TTL management for DMARC policy escalation: lower the DMARC record TTL to 300 seconds at least 24 hours before the planned escalation date. On the escalation date, update the p= value to the new policy level. Query the DMARC record from multiple external resolvers at 5-minute intervals to confirm the new policy is being served globally. Once confirmed, raise the TTL back to 3600–14400 for normal operation. This procedure takes 25 minutes of active attention on the escalation day and eliminates the extended inconsistency window that high-TTL records create.

Monitoring DNS Record Propagation

After any authentication DNS change, verify propagation before concluding the change is complete. The verification method: query the record from at least three geographically diverse DNS resolvers — one in North America, one in Europe, and one in Asia-Pacific — and confirm all three return the new record value. Tools like Google's dig command, online DNS propagation checkers, or WhatsMyDNS.net provide multi-location DNS resolution results that confirm whether a change has propagated globally.

The propagation check should also include verification that the change is functionally correct, not just propagated. For a DKIM key rotation: send a test message from the infrastructure using the new signing key, retrieve the message at a Gmail or Outlook account, and verify the Authentication-Results header shows dkim=pass with the new selector. This end-to-end test confirms that the private key is correctly configured in the MTA, the public key is correctly published in DNS, and the signing and verification process works as expected for real messages.

For SPF changes: send a test message from the newly authorised IP, retrieve it at a test inbox, and confirm the Authentication-Results header shows spf=pass. For DMARC policy escalations: send a test message that deliberately fails DMARC alignment (using a test sending source not covered by authentication) and confirm it is quarantined or rejected according to the new policy at the test ISP. These functional verification steps, performed immediately after propagation confirmation, close the loop on authentication changes before moving on to the next operational task.

Negative Caching and NXDOMAIN Propagation

DNS negative caching — the caching of "record does not exist" responses — is relevant for authentication when a DNS record is deleted rather than changed. When the old DKIM selector record is removed after a key rotation, resolvers that query for the removed record receive an NXDOMAIN response ("no such record exists"). This NXDOMAIN response is itself cached by resolvers, governed by the negative TTL (NTTL) value specified in the domain's SOA record rather than by the TTL of the removed record.

A domain with a high SOA NTTL (common values are 3600–86400 seconds) will cache NXDOMAIN responses for up to 24 hours after a record deletion. This means that messages in transit that were signed with the old DKIM key may continue to fail DKIM verification even if the key was valid at signing time — because resolvers are now caching the NXDOMAIN response for the old selector rather than fetching a fresh negative response from the authoritative nameserver.

The mitigation is the overlap period described in the DKIM rotation protocol: keeping the old selector's DNS record published for 5–7 days after the new selector is in use ensures that the removal of the old selector occurs after all realistically possible in-transit messages have been delivered and verified. By the time the old selector is removed, no messages signed with it should remain in delivery queues. The NXDOMAIN negative caching that follows the removal is then irrelevant because no new messages are signed with the old key.

TTL Management During Infrastructure Migrations

Infrastructure migrations — moving from one MTA provider to another, changing data centres, or migrating to new sending IP addresses — require coordinated authentication DNS changes across multiple record types simultaneously. The propagation complexity increases because changes to SPF (new IPs), DKIM (new key pairs from new infrastructure), and possibly PTR records must all be coordinated so that the transition period — when traffic is being moved from old to new infrastructure — is covered by correctly configured authentication records at both ends.

The migration TTL protocol: begin by auditing all authentication TTL values 2 weeks before the planned migration date. Identify any records with TTLs above 14400 seconds and lower them to 3600 during the audit week. One week before migration, lower all authentication record TTLs to 300 seconds. On migration day, make the authentication changes (new SPF IPs, new DKIM selectors for new infrastructure) in the correct sequence: SPF first (so new infrastructure IPs are authorised before first send), then DKIM new selectors (published before first send, but old selectors left in place), then PTR records for new IPs (confirmed before first send). After confirming each change is propagated and functionally verified, begin routing traffic to the new infrastructure.

The most common migration authentication mistake: routing traffic to new infrastructure before the new infrastructure's DKIM keys are published in DNS. The new MTA begins signing messages with its new key pair, but the public key is not yet in DNS, causing DKIM verification failures at receiving ISPs for all messages sent during the propagation gap. Preventing this requires that the new DKIM DNS records be published and propagation-confirmed before any traffic is routed to the new MTA — a sequencing requirement that must be explicitly included in the migration runbook.

TTL and the Quarterly Authentication Audit

TTL values should be reviewed as part of the quarterly authentication audit, not just when a change is being planned. The audit should confirm: no authentication record has a TTL above 14400 seconds (the recommended ceiling for emergency response capability); no authentication record has a TTL below 300 seconds without a specific reason (very low TTLs increase nameserver query load without corresponding operational benefit); and all TTL values are documented in the authentication inventory.

The documentation requirement: an inventory that lists each authentication record, its current value, its TTL, and the date it was last reviewed. This inventory is the foundation for planned changes — knowing the current TTL before making a change prevents the scenario where an operator makes an authentication change assuming the record has TTL=3600 but it was actually set to TTL=86400 years ago and never changed, resulting in a much longer propagation delay than expected.

TTL inventory maintenance also enables faster incident response. When an authentication problem is discovered and requires immediate DNS remediation, the incident responder who knows the current TTL of each record can immediately calculate the maximum propagation delay for the fix and communicate that timeline accurately to stakeholders — rather than needing to query DNS to discover the current TTL at the moment of the incident. The 2 minutes saved by having the inventory available does not sound significant, but under the time pressure of a P1 authentication incident affecting all delivery, having the answer immediately rather than needing to look it up reduces cognitive load at exactly the moment when cognitive load is highest.

DNS TTL management for email authentication records is a discipline of preparation: the operators who maintain moderate stable-state TTLs, follow the TTL-reduction protocol before planned changes, and document their authentication records are consistently better positioned to make changes quickly and confidently — and to recover quickly when unexpected changes become necessary. The TTL values on authentication records are configuration details that appear trivial when nothing is happening and become critical constraints when something is. Managing them proactively rather than discovering their implications under pressure is the operational standard that authentication DNS management requires.