A green checker result and a failed message can both be accurate. The checker may have inspected a current DNS policy for one name, while the receiver evaluated a different From domain, used an earlier cached answer or received a message without the intended aligned signature.
Begin by making the two observations comparable. Preserve the original results before changing configuration. Then ask exactly what each system examined and when.
Write down what the checker actually checked
Record the entered domain, the exact query name, query type, timestamp, resolver and returned record set. Save the displayed explanation as well as the result colour. Determine whether the tool examined only DNS or actually evaluated a supplied message.
For a policy published at _dmarc.example.com, a positive lookup establishes an observed policy at that name. It does not establish the SPF or DKIM identities on an application's message. It also does not prove that the tool followed the same discovery rules as the receiver.
Keep the specification assumptions visible. Current RFC 9989 §4.10 uses DNS tree-walk rules for discovery and organisational domains. A legacy implementation can use different assumptions, particularly for relaxed alignment. Do not describe a disagreement as a DNS error until the comparison supports that conclusion.
Start the receiver investigation from the message
For a delivered example, retain the original received message and identify the trusted receiving system's Authentication-Results. Record the visible From domain, evaluated SPF identity, each DKIM d and s value, authentication results, alignment and applicable policy.
Under RFC 8601 §7.1, treat an untrusted authentication assertion as message content, not a substitute for the receiving system's work. A provider name in a header also does not establish that your organisation approved the account using it.
For a rejection, there may be no delivered message to inspect. Retain the full returned SMTP text, message or transaction reference, sending account, recipient domain and timestamp. Combine those with the sending system's event record and available original submitted message.
Collect a DNS comparison with context
An investigation packet should include:
- Observation: Complete authoritative answer for the exact owner name; Why retain it: Shows the serving zone's data at collection time
- Observation: Relevant recursive answer, including status and TTL; Why retain it: Shows a resolver view and possible cached state
- Observation: Any alias or delegation path; Why retain it: Explains which authority and names were involved
- Observation: Full TXT record boundaries; Why retain it: Distinguishes one multi-string record from multiple policy candidates
- Observation: UTC collection time and recent change history; Why retain it: Relates current data to the message's evaluation time
Avoid retaining only +short output when response codes, authority information or absence matter. Use the missing-record guide to trace the name and authority.
A current authoritative answer is valuable evidence, but it cannot reconstruct a remote receiver's historical cache. State that gap rather than declaring that the receiver must have used today's answer.
Work through a synthetic mismatch
This fictional case shows why matching scope matters:
- Item: Checker at 14:10 UTC; Captured observation: A valid policy for example.com
- Item: Failed message at 14:04 UTC; Captured observation: From is alerts@notices.example.com
- Item: Sender signature; Captured observation: d=mailer.example.net verifies
- Item: Source policy evidence; Captured observation: The application uses a provider-controlled envelope domain
- Item: Subdomain configuration; Captured observation: An explicit policy exists for notices.example.com
The root-domain checker has not established the policy or alignment for that message. The passing provider signature is also unrelated to the From domain in this example. Investigate the subdomain policy and the application's supported aligned configuration.
A different case might reveal that the correct identities aligned but the required policy lookup timed out; RFC 9989 §5.3.6 does not classify that incomplete check as pass or fail. The same checker colour would then lead to a different repair.
Keep DNS response categories distinct
A successful answer containing relevant data differs from NXDOMAIN, a complete no-data response, SERVFAIL, REFUSED and a timeout. These observations do not all mean “no DMARC record”. RFC 1035 §4.1.1 defines DNS response codes; RFC 2308 §2.1 and RFC 2308 §2.2 distinguish NXDOMAIN and NODATA.
Check the queried name before interpreting absence. NXDOMAIN for _dmarc.example.com, without an alias complication, describes that queried owner name; it does not by itself establish that example.com does not exist.
Under RFC 2308 §5, negative caching can preserve an earlier absence after a record is added. Positive caching can preserve an earlier value after an edit. Retain response context and collection time so the explanation can be assessed.
Choose the repair from the matched evidence
If the tool and receiver examined different names, correct the investigation scope. If the message lacks an aligned path, correct the supported sending configuration. If answers differ among authoritative servers, investigate zone consistency. If recursive resolution fails, inspect the resolver, delegation, validation and transport path.
A policy edit is not the automatic repair for every discrepancy. Change the smallest relevant configuration and retain the reason. Use the alignment guide when raw authentication passes for a domain that does not align.
Repeat a controlled test and close the comparison
After the repair, capture fresh DNS observations and a representative message through the same application account and route. Compare the new result with the earlier packet and explain the changed evidence.
One successful retry demonstrates that attempt. Continue the defined service-level checks when the incident involved several routes or receivers.
The useful conclusion is a matched account of the disagreement: what was checked, what the receiver evaluated, which difference mattered and which repair changed the outcome.
Make the next decision explicit
For the 14:10 checker and 14:04 message fixture, first align the queried Author Domain and reconstruct the message’s identities; do not attribute the six-minute difference to caching without evidence. Required DNS errors and lack of alignment are different findings. Qualifying stale answers can extend beyond TTL expiry under RFC 8767 §4. The illustrated observations are fictional, not captured logs.