Start with a receiver you trust, then compare the visible From domain with the SPF MAIL FROM and passing DKIM signing domains. A pass for a different domain may still leave DMARC failing.
When one message fails DMARC, its full headers can show what the receiving mail system actually checked. Look for Authentication-Results: it records results such as spf=pass, dkim=pass, and dmarc=fail, often with the identities behind them. The format comes from RFC 8601.
This is a message-level debugging tool. Aggregate reports show patterns across receivers and time; a delivered sample lets you inspect the exact sender path that produced one result. Get the original message or full headers from a mailbox you control, ideally from the workflow you are investigating.
First, choose the result you can trust
A message may contain several Authentication-Results fields. Each begins with an authentication service identifier, such as mx.recipient.example. Prefer the result added by your own receiving service or another receiver whose handling you know. An upstream sender can put a convincing-looking header in a message; a bare pass elsewhere in the header list is not proof your receiver accepted it. RFC 8601 explains this trust boundary in its security discussion.
Header viewers often wrap one field across several lines. Read those continuation lines as part of the same field. Do not treat ARC-Authentication-Results, which records an earlier hop's assessment, as the current receiver's own result.
Read the identities, not only the pass labels
Here is a simplified example using reserved placeholder domains.
From: Billing <billing@example.com>
Authentication-Results: mx.recipient.example;
spf=pass smtp.mailfrom=bounces.vendor.example;
dkim=pass header.d=vendor.example;
dmarc=fail header.from=example.comThe visible From domain is example.com. SPF passed for the envelope MAIL FROM domain bounces.vendor.example, and DKIM passed for signing domain vendor.example. Neither passing domain aligns with the visible From domain, so the receiver records a DMARC failure. The syntax of supporting properties can vary by receiver; identify the domains rather than relying on one exact header layout.
Under RFC 9989's alignment rules, one aligned, authenticated path is enough for DMARC to pass. For example, a valid header.d=mail.example.com DKIM signature can align with From: billing@example.com under relaxed DKIM alignment. Strict alignment requires an exact domain match. SPF passing for a vendor-owned return path does not become aligned merely because your root SPF record includes that vendor.
Turn the header into a concrete fix
- Confirm the visible From domain and the receiver that added the result.
- Compare smtp.mailfrom with From only when SPF passed.
- Check every passing DKIM header.d domain; one aligned valid signature can suffice.
- Check the domain's actual aspf and adkim alignment settings before declaring a mismatch.
- Repeat with fresh messages from the affected workflow, then compare aggregate report trends.
If SPF fails after forwarding but an aligned DKIM signature passes, DMARC can still pass. If both paths fail or are unaligned, fix the sender's signing domain or return path, then test a new message. Our vendor alignment guideexplains those configuration choices.
A DMARC pass confirms domain authentication for that receiving check; it does not prove who authored the message or where the mailbox placed it. Keep delivery investigation separate from authentication, and avoid sharing full real-world headers publicly because they can contain addresses and routing details.
Disclosure: AI tools were used in the process of creating this blog post.