Interpreting Authentication-Results: spf, dkim, dmarc, and compauth

What the header records

Your receiving server records its verdicts in Authentication-Results, naming itself first. Each method shows a result and the identity checked: smtp.mailfrom for SPF, header.d for DKIM, and header.from for DMARC. Microsoft 365 adds compauth, a composite verdict that also considers its own reputation signals.

Authentication-Results: mx.example.org;
  spf=pass smtp.mailfrom=bounce.sender.example;
  dkim=pass header.d=sender.example header.s=s1;
  dmarc=pass action=none header.from=sender.example;
  compauth=pass reason=100

Which copy to trust

Senders and relays can insert their own Authentication-Results headers. Only trust the one whose first token is your own provider’s server name, and which sits above your trusted Received boundary. Well-run receivers strip incoming copies that claim to be from them.

Lab: compare two messages

Take one legitimate message and one message from your spam folder. For each, extract the Authentication-Results header added by your provider, and fill in the table below. Compare the header.from domain with the domain shown in the client. Note which checks failed for the spam sample and whether DMARC policy was none, quarantine, or reject.

field | legitimate | spam sample
spf (smtp.mailfrom) | pass (bounce.sender.example) | softfail (random.example)
dkim (header.d) | pass (sender.example) | none
dmarc (header.from) | pass | fail (lookalike.example, p=none)
compauth | pass | fail reason=001

Results that mislead

dmarc=pass only means the From domain authenticated, not that the sender is trustworthy: an attacker who registers a lookalike domain can pass every check. Conversely, dkim=fail on a forwarded message is common and not by itself malicious. Always read results together with the domains they apply to.

• Pass on a lookalike domain is still suspicious
• Failures after forwarding can be benign
• Check the identity next to each result