You fixed the mail DNS but some receivers still fail: negative caching can outlive the edit

Read the raw signal before interpreting it

RFC 2308 defines negative caching so resolvers can cache NXDOMAIN and certain no-data answers instead of repeatedly querying authoritative servers. A newly created record therefore may not be visible everywhere instantly after a prior negative answer.

A DNS fix can be correct at the authoritative server while recursive resolvers continue returning the earlier negative answer because DNS caches negative responses too. RFC 2308 defines negative caching using information from the zone’s SOA, so an earlier NXDOMAIN or no-data result can persist until the applicable negative TTL expires. This is why changing an MX or TXT record and immediately querying the same recursive resolver can make a repair look unsuccessful. The first diagnostic question is which layer answered: authoritative data, a recursive cache, or an application cache on top of DNS.

A tempting conclusion to avoid

Seeing the corrected value in your registrar panel or one public resolver does not prove every receiver has discarded an earlier cached negative response. DNS propagation is really many independent caches aging on their own schedules.

Do not keep editing the record every few minutes because one resolver still shows the old negative state. Repeated changes reset your troubleshooting baseline and can introduce a real syntax error while you are waiting on cache expiry. Likewise, “flush DNS” on your laptop proves only that one local cache was cleared; a receiving provider or cloud worker may use a different recursive resolver whose cached negative answer remains valid. Record the old negative TTL and change time before deciding the fix failed. Comparing authoritative and several recursive answers gives a timeline rather than a binary green/red result.

Test the same layer the receiver or server tested

Query the authoritative nameserver directly, then several recursive resolvers from different networks. Compare response code, answer, authority section and remaining TTL before making another change.

A good reproduction starts by querying the zone’s authoritative nameserver directly for the corrected MX/TXT name and saving the answer. Then query the same name through the recursive resolver your verifier or application uses. If authoritative data is new while recursion remains negative, inspect the SOA values and the age of the cached response where tooling exposes it. Query another independent recursive service as a comparison, but do not assume the fastest updated resolver represents every receiver. Repeat after the expected negative-cache window and verify the application itself refreshes its cached state.

Repair, then repeat the original test

If authoritative DNS is correct, wait for documented cache lifetimes while monitoring. Lower TTLs before planned migrations when possible; changing records repeatedly during recovery can make the evidence harder to interpret.

Design verification and DNS-change runbooks around this propagation model. Store `observed_at`, resolver, response code, TTL, and whether the query was authoritative. Treat a recently repaired domain that still returns a cached negative answer as pending until the known cache window passes, not as evidence to publish another DNS edit. If your own service caches verification results, set its expiration so it does not outlive the DNS evidence indefinitely. This prevents a short-lived negative lookup from becoming a weeks-long suppression after the domain has already been repaired.

A realistic low-volume case

A receiver that cached NXDOMAIN shortly before the fix can continue returning the old result while a resolver that never asked before sees the new record immediately. Both observations can be internally consistent.

Negative caching matters for verifier databases too. If your application stores “NXDOMAIN” for 30 days while DNS itself would have forgotten the negative answer in an hour, the application becomes the stale layer even after recursive resolvers recover. Align recheck policy with the strength and age of evidence, and expose the next verification time in operational tooling. After a DNS repair you control, query authoritative data first, then let external recursive caches expire naturally; do not use your privileged knowledge to mark all third-party delivery paths healthy before they can actually resolve the change. This distinction explains why a record can be correct in a DNS dashboard yet still fail at some receivers for a while. Time and resolver scope are part of the evidence, not annoying noise to ignore.

Operational telemetry to keep

Store change time, old and new values, authoritative answer, SOA/negative caching values, recursive resolver results, and first successful delivery by receiver.

The safe stopping point

Negative caching does not explain every post-change failure. Once caches should be expired, return to the exact SMTP diagnostic and verify authentication, PTR, TLS, and reputation separately.

For incident notes, write the earliest time at which each important resolver could reasonably be expected to forget the negative answer. This converts “DNS propagation” from a vague waiting period into a test schedule. Querying before that time can still be useful for comparison, but it should not trigger another configuration edit unless authoritative data itself is wrong.

Field checklist

• Capture the raw evidence for DNS negative caching after MX PTR fix email still failing before editing DNS, queue state, or mailbox metadata.
• Confirm the cited mechanism using dns-neg-rfc, gmail-faq rather than a generic deliverability score.
• Keep a known-good control case so the failing layer can be compared without changing several variables at once.
• Apply the narrow repair described for You fixed the mail DNS but some receivers still fail: negative caching can outlive the edit and preserve a rollback or retry path.
• Repeat the original failing test after the change; do not substitute a different checker as proof of recovery.
• Store timestamp, affected identity, raw result, action taken, and the post-change result in the operator log.