Read email authentication headers without trusting the wrong hop

Define the decision

Messages can contain several Authentication-Results fields after forwarding or gateway processing. The useful result is the one added by the receiving system you are diagnosing. A sender can place misleading text in an earlier header.

Work through the procedure

1. Export the original message from the receiving mailbox.
2. Identify the receiving service’s trusted result and the Received path around it.
3. Record smtp.mailfrom, header.d and header.from alongside each result.
4. Compare aligned identities separately from pass or fail, then inspect forwarding if hops disagree.

Worked example

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

Trusted receiver result: spf=pass smtp.mailfrom=bounce.vendor.example
dkim=pass header.d=example.com
dmarc=pass header.from=example.com
Reading: aligned DKIM provides the DMARC path; vendor SPF alone does not

Read the result

A passing mechanism names the identity it authenticated. It does not authenticate every address displayed in the message. Keep the raw header privately; use a redacted extract when asking another operator to review the reasoning.

Check before moving on

1. Do not treat a self-written Authentication-Results field as proof.
2. Distinguish the current received copy from an older test before DNS changes.

Limits and next action

Header evidence explains processing of that message at that receiver. It does not reveal all filtering factors or establish that the person read the message.

Source: RFC 8601: Authentication-Results header