An attacker does not need to defeat SPF or DKIM to write “spf=pass” or “dkim=pass” in a header. Those strings become dangerous when a downstream tool treats supplied text as a trusted evaluation. The defence is provenance-aware interpretation, not simply a longer list of favorable keywords.
Separate extraction from evaluation
A parser can reliably show that a message contains a particular field. It cannot establish that the claimed authentication service produced it. An analyser should retain all relevant occurrences, identify where trusted receiving evidence comes from and keep untrusted reports out of the security verdict. Preserve the raw field for investigation rather than silently erasing evidence from the stored original.
RFC 8601 describes the risk of forged Authentication-Results and the need for trust-boundary handling. The authserv-id is meaningful only in that established context. Matching a configured string is not sufficient if a sender can inject a field with the same string and the gateway permits it to survive as apparently trusted. RFC 8601 section 7.
Test the same-name impersonation case
In a hypothetical controlled test, an input message contains Authentication-Results claiming authserv-id mx.receiver.example and dmarc=pass. The real receiver uses that same service identifier but determines a different result. The injected text is not trusted simply because the name matches.
RFC 8601 section 5 requires a conforming MTA to remove a discovered Authentication-Results field that claims its trust boundary but did not arrive directly from another trusted MTA; its example also describes obscuring such a claim. Check the supported ingress handling and the consumer's resulting verdict together. This guide does not claim that any gateway was configured or tested.
For the analyst, preserve the original authorized evidence copy separately. Evidence retention does not mean forwarding an unsafe field as a live trusted result. A controlled test should also cover duplicates, folded lines and legitimate reports from explicitly trusted upstream systems. First-header-wins and last-header-wins do not replace that boundary design.
Avoid misleading fallbacks
If no trusted result is available, display “not established from trusted receiving evidence” rather than synthesizing a pass from an external claim. If independent verification is performed, label it as a new evaluation with its own time, inputs and limitations. A later DNS lookup can differ from the records in effect during original receipt, so a reconstruction is not automatically the same historical result.
ARC-related fields are also not ordinary Authentication-Results substitutes that can be trusted just by spelling. An analyser needs the applicable validation and receiver trust decisions before relying on an asserted upstream history. ARC chain validation and receiver trust remain separate requirements; no ARC validation was performed for this guide. See RFC 8617.
Give the operator an actionable output
Report the selected trusted source, the ignored claims and the reason for exclusion. If boundary handling is unknown, escalate that uncertainty to the mail administrator before recommending DNS changes. Keep the analyst’s exported originals immutable; apply the required supported ingress handling to live mail and retain authorized logs that explain the decision. The goal is not to hide attacker-controlled material; it is to prevent that material from controlling the verdict.
Check the verdict selection safely
- Preserve an authorized evidence copy before analysis.
- Test only a controlled receiving path with explicit scope.
- Include a forged field using the trusted service name, not only an obvious outsider name.
- Confirm ingress removal or obscuring and downstream exclusion from the verdict.
- Report missing provenance rather than converting an external pass string into authentication.