A saved DNS change and a failing message can both be real. The record may have reached authoritative DNS while a resolver still has an older answer. Or the change may be visible everywhere but unrelated to the identity the sending application uses.
Start by identifying exactly what changed and what you expected that change to accomplish. A policy edit, an SPF authorization and a DKIM public key solve different problems. Treating them as interchangeable leads to repeated changes without a causal explanation.
Write down the expected effect
Keep the prior value, new value, exact owner name, record type, timestamp and responsible operator. State a testable hypothesis: for example, a new DKIM key should let the receiver verify a signature with a particular d domain and s selector. If the service is not signing with those values, the DNS publication alone cannot produce that result.
Changing p=reject to p=none changes the requested handling context; it does not turn an unaligned identity into an aligned one. Under RFC 7208 §2.4 and RFC 7208 §4.4, publishing an SPF include at example.com does not repair SPF for an unrelated envelope domain used by the vendor. The alignment guide explains how to compare these identities.
Determine whether the intended DNS is actually serving
Query the authoritative nameservers for the exact name and type, preserving full responses. Compare the expected record with every relevant authoritative answer. If the authoritative service still returns the old value, investigate the editor, zone selection, delegation and provider-side deployment before waiting on recursive caches.
When authoritative answers agree on the new value, query the resolver used by your test environment and another relevant recursive resolver. Record status and TTL as well as content. A cached absence is different from a cached old value: negative caching can preserve an earlier NXDOMAIN or NODATA response for its remaining lifetime. RFC 2308 §3, RFC 2308 §4 and RFC 2308 §5.
Lowering a record’s TTL now does not retrospectively shorten a copy already cached under its previous lifetime. Avoid a universal promise that all DNS changes become visible in a fixed number of minutes. Qualifying serve-stale behavior can also retain and use older data beyond TTL expiry under RFC 8767 §4. Use observed answers and cache evidence to decide when retesting is meaningful.
Test a new message, not yesterday’s header
Authentication results are recorded for a particular delivery. A new DNS configuration does not rewrite a message already received. Generate a fresh controlled message through the affected application and preserve its timestamp and receiver-generated results. RFC 8601 §1.2 and RFC 8601 §4.
Compare the visible From domain, SPF-evaluated identity and result, and each relevant DKIM signing domain, selector and verification result. Then examine alignment under the applicable DMARC policy. Do not stop at a vendor dashboard saying authentication is enabled; determine what the actual message carries.
If the signing selector differs from the one you published, investigate the service’s activation or configuration. If the signature verifies for an unrelated domain, investigate its supported customer-aligned identity settings. If a signature fails only after a gateway, compare the route before and after that intermediary. Covered-content changes can affect verification under RFC 6376 §3.7, but failure alone does not identify the cause or prove which hop modified the message. These are different diagnoses and should lead to different changes.
Use a compact decision record
This synthetic example shows why the layers matter:
- Observation: Authoritative DKIM key is new; recursive lookup is old; What it supports: DNS observations differ; Next investigation: Cache lifetime and resolver path
- Observation: Both DNS views are new; message uses a different selector; What it supports: Published key does not match this signature; Next investigation: Sender’s active signing configuration
- Observation: Matching signature passes; d domain is unrelated to From; What it supports: Signature works but does not supply alignment; Next investigation: Supported aligned sending identity
- Observation: New direct message passes; forwarded copy fails; What it supports: The route affects surviving authentication; Next investigation: Forwarding and message modification
None of these observations alone proves an attack or an outage across all recipients. Keep the conclusion proportional to the evidence.
Avoid changing policy to hide the symptom
A business-critical delivery problem may need a documented temporary mitigation. Choose its scope, owner, expiry and verification criteria separately from the technical fix. An organization-wide policy reduction can affect unrelated traffic and should not be the reflex response to a single unverified application failure.
Preserve a rollback plan for the actual change. Restoring a DNS value may itself take time to become visible through caches, and restoring an old key is not appropriate if that key is suspected compromised. Identify those constraints before treating rollback as instant recovery.
Close with a causal explanation
Record which layer was wrong, what changed and which new evidence confirms the correction. Keep a before-and-after received-message comparison and the relevant DNS observations together. Use aggregate reports to look for the same pattern over subsequent reported traffic without treating them as a real-time or complete delivery log; RFC 9990 §3.1 describes aggregated reporting.
The issue is resolved when the intended workflow has a trusted passing aligned result and any delivery problem is explained. Inbox placement remains a separate receiver decision. A successful DNS update is a milestone, not the end of that investigation.
Make the next decision explicit
Use the changed-selector fixture to decide whether to fix active signing configuration rather than republish the same unused key. Before closing, record one fresh test through the affected workflow, its trusted receiver result, exact d/s values and remaining coverage limits. If that evidence is unavailable, keep the relevant claim pending. No DNS publication, key activation or delivery test was performed here.