DNS propagation troubleshooting: compare authoritative and cached answers

Define the decision

The phrase propagation can hide several failures: the wrong zone was edited, a hostname was duplicated, a resolver cached an earlier answer, or delegation points elsewhere. Start with evidence from the exact queried name.

Work through the procedure

1. Confirm the domain’s delegated nameservers.
2. Query the record directly from an authoritative server.
3. Compare a recursive resolver’s answer and remaining TTL.
4. Correct publication errors immediately; for a cached old answer, record when to retest.
5. Generate a new email only after the relevant lookup returns the intended data.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Authoritative answer: new DKIM selector exists
Recursive answer: cached missing-record result
Interpretation: publication succeeded, but this resolver has not refreshed
Different case: authoritative answer is also missing → inspect zone and record name

Read the result

These cases need different actions. Repeated changes can obscure which value a receiver evaluated. Keep the query time, record type and resolver with each result.

Check before moving on

1. Query TXT, CNAME or MX as required by the actual setup.
2. Check the fully qualified name rather than a dashboard label.

Limits and next action

There is no single guaranteed wait time for every DNS change. Negative caching and prior TTLs matter; use measured answers instead of an arbitrary countdown.

Source: Cloudflare: email DNS troubleshooting