The three checks in one table
| Check | What it asks | Where it looks |
|---|---|---|
| SPF | Is the server that delivered this message on the domain's list of allowed senders? | A DNS record of the domain used in the hidden envelope sender (Return-Path). |
| DKIM | Does the cryptographic signature on the message match the sender domain's public key, and is the message unaltered? | A DKIM-Signature header and a public key in DNS. |
| DMARC | Did SPF or DKIM pass and match (align with) the domain you see in the From line? What should happen if not? | A DMARC policy in DNS for the From domain: none, quarantine or reject. |
The key idea is alignment. SPF and DKIM on their own can pass for any domain an attacker controls. DMARC ties them to the visible From address. Google describes it this way: to pass DMARC, a message must pass at least one of SPF with SPF alignment or DKIM with DKIM alignment.
Where you see the result
The results sit in the Authentication-Results header. Open the full headers and look for lines like these:
spf=fail [email protected]
dkim=none
dmarc=fail (p=REJECT) header.from=examplebank.com- pass: the check succeeded.
- fail: the check ran and failed. For SPF this is a hard failure; you may also see softfail (the domain says "probably not allowed") or neutral.
- none: there was nothing to check, for example the domain publishes no DKIM signature or no DMARC record. That is missing protection, not a failure.
- temperror / permerror: a DNS problem or a broken record. It says more about the sender's setup than about the message.
Why forwarded mail often fails
Legitimate mail fails these checks more often than people expect, and forwarding is the classic cause.
- SPF breaks when a message is forwarded. SPF checks the IP address of the server that handed over the message. After forwarding, that server is the forwarder, not the original sender, so it is not on the original domain's list.
- DKIM survives forwarding, unless the message is changed. Mailing lists that add a footer or change the subject, and some security gateways that rewrite links, invalidate the signature.
- DMARC therefore fails only when both break, or when the passing one does not align with the From domain.
- Other legitimate causes: a marketing or billing service sending for a company without being set up in its SPF and DKIM, a forgotten DNS record after a provider change, or a typo in the record.
When a fail signals spoofing
A fail becomes a red flag when it combines with other signs. Treat it seriously when:
- The From domain belongs to a bank, a courier, a government office or a company that clearly runs a strict DMARC policy, and the message fails DMARC.
- SPF passes, but for an unrelated domain in the Return-Path (the message is authenticated, just not as the brand it claims).
- The message asks for a password, a payment, a code or a login, or pushes you to hurry.
- Reply-To or the links point to a different domain than the sender.
- The sender domain is a lookalike, such as
examp1ebank.cominstead ofexamplebank.com. Lookalikes often pass authentication, because the attacker owns the domain.
What to do with a fail
- Do not click links or open attachments in the message while you decide.
- Check whether the message makes sense in context: did you expect it, is the request normal for that sender?
- If you are unsure, contact the sender through a channel you already trust, such as the official app or a phone number from their website, not through the message.
- Run the full message through a checker that weighs authentication together with links, wording and attachments.
- If it is phishing, report it.
If the fail is on your own domain's mail, the fix is on the DNS side: add the sending service to your SPF record, enable DKIM signing for it, and then publish a DMARC policy, moving gradually from monitoring to enforcement.