How to Interpret Authentication-Results in a Header

Start with who made the assessment

In the full message headers, look for a field named Authentication-Results. It commonly contains an identifier for the system that performed the checks, followed by one or more results. Header layout varies between mail services, so use your mail app’s option to view original message details or full headers if available.

The identifier matters. A receiving service can add a result that describes its own checks; a sender can also include text that looks like an authentication result. Do not treat every matching-looking field as equally trustworthy. Focus on the result added by the receiver handling the message, and interpret it in the context of how you obtained the headers. If you cannot identify the responsible system, treat the field as a clue rather than a verified account of the receiver’s checks.

Read the three checks as separate signals

An Authentication-Results field may report SPF, DKIM and DMARC outcomes. These are related but not interchangeable. A message can pass one check and fail another, and a receiver may report only some of them.

SPF concerns whether the sending source is permitted for the domain used in the message’s sending path. DKIM concerns a cryptographic signature associated with a signing domain; a pass indicates that the receiver’s check of that signature succeeded. DMARC checks whether SPF or DKIM passes in a way that aligns with the domain shown to the recipient in the From field, according to the domain owner’s policy. A DMARC pass therefore is not simply a repeat of either individual result.

Find the outcome beside each method

Within the field, look for labels such as spf=, dkim= and dmarc=. The word immediately after each label is the reported outcome, for example pass or fail. Details may follow in parentheses or as domain information. Read the label and its value together; do not infer that one pass means all three passed.

A result such as none may mean the receiver did not find applicable authentication information for that check. Other outcomes can indicate that a check could not be completed or did not succeed. Exact wording and detail vary. If the field gives a reason or domain, use it to understand what was assessed, but avoid treating a short status word as a full diagnosis.

Authentication-Results: mx.receiver.example;
  spf=pass (sender source accepted) smtp.mailfrom=[sender@example.com];
  dkim=pass header.d=[example.com];
  dmarc=pass header.from=[example.com]

Forwarding can change the picture

Authentication results belong to a particular receiver and message path, not to the email in every possible context. When a message is forwarded, the next receiver sees a different sending source. That can affect SPF, which evaluates the sending path. DKIM may still pass if the signed content remains verifiable, but changes to signed content can affect that check. DMARC depends on the SPF or DKIM result and alignment at the receiving system.

As a result, the original receiver and a later receiver can report different outcomes for what appears to be the same message. That difference does not, by itself, establish that either system is wrong. Compare the receiver identifiers, the reported domains and the path the message took.

A pass is not a delivery verdict

Authentication-Results describes authentication checks, not every factor involved in accepting, filtering, sorting or displaying a message. Passing SPF, DKIM or DMARC does not guarantee that a message will arrive, avoid spam filtering or appear in the inbox. A failure does not, on its own, prove malicious intent or explain the complete delivery outcome.

Use the field as one piece of evidence. If a message is missing, check the receiving account’s other folders and available delivery information, and compare headers from the relevant receiving system when you have them. Do not assume that changing an authentication setting is the right fix based on a result alone; first identify which system added the result and which domain or sending path it evaluated.

A quick way to check your reading

You have interpreted the header correctly when you can say which receiver reported each result, what each check returned, and what the field cannot establish. If you inspect another copy or receiving point, note whether the receiver and path changed before comparing outcomes.

• Locate the full Authentication-Results field and identify the receiver that added it.
• Record SPF, DKIM and DMARC values separately; mark any method not reported as not shown.
• Check which domains are named, especially the From domain used for DMARC alignment.
• If the message was forwarded, compare results at each receiving point you can inspect.
• Confirm what happened to the message in the receiving account, but do not treat an authentication pass as proof of inbox placement.