DNS Propagation and Email: Why Changes Take Time and What Can Go Wrong

Email Authentication

You update your SPF record, check it from your computer, confirm it's correct — and then emails still fail authentication for hours or days. The reason: DNS propagation. Every DNS change takes time to reach all DNS resolvers worldwide, and during that window, some servers see the old record while others see the new one.

For email authentication, this propagation delay creates a period of inconsistent results that can damage deliverability if you're not careful.

How DNS Propagation Works

DNS is a distributed system. When you change a record at your DNS provider:

1. Your DNS provider updates the authoritative nameserver immediately
2. DNS resolvers around the world have the old record cached
3. Each resolver keeps its cached version until the TTL (Time to Live) expires
4. Once TTL expires, the resolver fetches the new record from the authoritative server
5. Until every resolver has updated, results are inconsistent

TTL Explained

TTL is a value (in seconds) attached to every DNS record. It tells resolvers how long to cache the record before checking for updates.

If your SPF record has a TTL of 3,600, DNS resolvers will cache the old version for up to 1 hour after you make a change. Some resolvers respect TTL strictly; others cache longer than specified.

"Up to 48 Hours"

The common advice that DNS takes "up to 48 hours to propagate" is a worst case. In practice:

• Most resolvers update within 1–4 hours for standard TTLs
• Some corporate resolvers cache aggressively (ignoring TTL) and take longer
• CDN-based DNS (Cloudflare, AWS Route 53) propagates changes in minutes within their network

How Propagation Affects Email

SPF Changes

When you add or remove an SPF include, there's a window where some receiving servers see the old record:

• Adding a new sender: Emails from the new service may fail SPF at servers that still have the old record cached
• Removing an old sender: Emails may still pass SPF at servers that haven't fetched the updated record

DKIM Changes

DKIM key changes (rotation or adding a new key) have the same propagation issue:

• The new DKIM public key isn't available at all resolvers immediately
• Emails signed with the new key fail DKIM at servers that can't find the key yet

DMARC Changes

Changing your DMARC policy (e.g., from p=none to p=quarantine) propagates with the same delays. During propagation, some servers enforce the new policy while others use the old one.

How to Minimize Propagation Risk

Lower TTL Before Changes

Before making DNS changes, reduce the TTL on the affected records:

Add Before You Remove

When migrating email services:

1. Add the new service's SPF include to your record first
2. Wait for propagation (at least the TTL duration)
3. Migrate sending to the new service
4. Verify authentication passes from the new service
5. Remove the old service's include only after migration is complete

This ensures there's never a window where the active sender isn't authorized.

Keep Both DKIM Keys During Rotation

When rotating DKIM keys:

1. Add the new DKIM key to DNS
2. Wait for propagation
3. Switch your ESP to sign with the new key
4. Keep the old key in DNS for at least 48 hours (to validate emails signed before the switch that are still in transit)
5. Remove the old key after the overlap period

Don't Change Everything at Once

If you need to update SPF, DKIM, and DMARC, stagger the changes:

1. Update SPF → verify → wait 24 hours
2. Update DKIM → verify → wait 24 hours
3. Update DMARC → verify

If something breaks, you know exactly which change caused it.

Checking Propagation Status

Multiple DNS Resolver Check

Test your DNS records from multiple locations and resolvers to see if propagation is complete:

• Check from Google's resolver (8.8.8.8)
• Check from Cloudflare's resolver (1.1.1.1)
• Check from your local resolver
• Use our free checker which queries from its own resolver

If all show the same result, propagation is likely complete. If results differ, propagation is still in progress.

Test Email Verification

The most reliable test: send an email to Gmail, Yahoo, and Outlook after making changes. Check the headers:

• Authentication-Results header shows whether SPF, DKIM, and DMARC passed
• If they pass at all major providers, your changes have propagated to the servers that matter most

Common Propagation Problems

DNS Provider Caching

Some DNS providers add their own caching layer on top of TTL. Even after you change a record in their dashboard, their edge servers may serve the old version briefly.

Fix: Verify the change is live on the authoritative nameserver directly before waiting for global propagation.

Negative Caching

If a DNS record didn't exist and a resolver cached that "not found" result, adding the record doesn't immediately make it available. Negative caching can persist for the duration specified in the domain's SOA record (often 1–24 hours).

Fix: Be aware that adding new records (especially for domains or subdomains that previously had none) may take longer to propagate than updating existing records.

Corporate Resolvers

Some corporate DNS resolvers cache more aggressively than public resolvers. If B2B recipients have authentication failures after a change that's propagated everywhere else, their corporate resolver may still have the old record.

Fix: There's nothing you can do except wait. This is another reason to use the "add before remove" strategy — the overlap period covers slow resolvers.