How to Parse Authentication-Results Headers to Find Failed Checks

An Authentication-Results header summarises checks performed by a receiving mail system, usually for SPF, DKIM and DMARC. Each method has its own result, so one can fail while another passes. For example: Authentication-Results: mx.mail.example; spf=fail smtp.mailfrom=invoice@example.com.au; dkim=fail header.d=example.com.au header.s=pay header.b=aBc123; dmarc=fail header.from=example.com.au policy.published=reject.

When Australian IT staff need to know how to parse Authentication-Results headers to determine which check actually failed, they must separate the method, result and evaluated property. spf=fail and dkim=fail describe mechanism failures; dmarc=fail describes the failure of alignment or policy evaluation. The header is evidence from the receiving path, not a complete judgement about the sender.

Reading the result fields

The compact syntax is method, result, then properties and optional reasons. In spf=softfail smtp.mailfrom=bounce@example.com.au, spf names the method, softfail gives the outcome and smtp.mailfrom identifies the evaluated envelope domain. An authserv-id can identify the service that produced the header.

Treat fail as an unsuccessful check, but avoid equating softer outcomes with spoofing. none usually means no applicable signature or DNS evidence existed; for SPF, neutral means the domain made no meaningful assertion. softfail and temperror need context. A missing method means no result was reported, not that the check passed. Compare the header with the Received chain because intermediaries can add or alter results.

Tracing SPF to the envelope sender

SPF checks the envelope sender in MAIL FROM, usually visible as Return-Path, which explains the smtp.mailfrom property. It does not directly validate the visible From address. Forwarding may rewrite MAIL FROM and cause a failure, while a result such as spf=pass smtp.mailfrom=bounces.send.example.net may describe a marketing platform rather than the company in the visible From.

For an Australian sender at shop.example.com.au, trace SPF for the domain actually reported in MAIL FROM, including include:, a, mx and redirect= branches. The usual ten-DNS-lookup limit can produce permerror. Check the reason field and gateway DNS logs before deciding whether the failure reflects unauthorised sending, broken delegation or a configuration error.

Following DKIM signatures and alignment

DKIM reports the signing domain, selector and signature through header.d, header.s and header.b. Its public key is published at selector._domainkey.signing-domain; the header.b value is the signature, not the key. A dkim=pass confirms a valid signature over the signed content, but not that the signer controls the visible From address.

DMARC alignment compares the visible From domain with the SPF or DKIM domain. Relaxed alignment allows organisational domains such as shop.example.com.au and example.com.au; strict alignment requires an exact match. Use header.d, not the optional DKIM header.i, for DMARC alignment. A changed message body can cause dkim=fail without proving impersonation, while a missing key may instead produce a permanent error.

Understanding DMARC policy outcomes

DMARC combines aligned SPF or DKIM results with the policy published for the From domain. dmarc=pass means an aligned identifier passed. dmarc=none means no aligned identifier was found, so there was no authenticated domain to align with policy. dmarc=fail means no aligned SPF or DKIM result satisfied the check; it does not, by itself, reveal whether SPF, DKIM or both failed.

Read header.from, policy.published and policy.pct together. reject requests rejection of non-aligned mail, quarantine requests isolation and none requests monitoring. pct controls the share of messages subject to enforcement, not the share of checks that passed. Actual handling can vary with gateway configuration.

Australian teams should normalise logs to UTC before comparing a result with DNS changes or policy deployment. Sydney and Melbourne shift with daylight saving, while Brisbane remains on AEST. Cached DNS and delayed header propagation can make a recent fix appear unsuccessful for a while, so timestamps and resolver behaviour belong in the diagnosis.

Connecting authentication with reputation

Authentication and reputation answer different questions. A legitimate Australian retailer using Microsoft 365 can pass SPF and DKIM yet attract bulk-mail complaints. Use sender score metrics to add context about the sending domain and infrastructure, without treating the score as proof of maliciousness or replacing the raw header evidence.

A lookalike sender may have valid SPF and DKIM for its own domain while faking another visible From domain; DMARC exposes that mismatch. Account compromise can produce clean results because the attacker uses valid credentials. A terse request such as “Can you action this payment today?” may accompany an invoice scam, so signing results should be assessed alongside mailbox activity and payment instructions. For consumer losses, ACCC Scamwatch provides Australian reporting guidance.

Building an evidence-led response

Preserve the original message as an .eml file or equivalent, retain every header and record the gateway that generated each result. The anti-spoofing incident guide provides a practical sequence for comparing these artefacts during incident response. Store copies with UTC timestamps so daylight-saving changes do not distort the sequence across Australian offices.

Follow the failure to its owner before labelling the message spoofed. If SPF fails, DKIM passes and DMARC passes, the envelope sender is broken while the visible From remains protected by aligned DKIM. If SPF does not align and DKIM passes under an unaligned domain, DMARC still fails. When both SPF and DKIM fail, investigate unsigned bulk mail, broken automation and credential misuse together. The strongest diagnosis names the failed method, affected domain and alignment gap rather than treating every fail as spoofing.