Learn · Reading your report

Why SPF and DKIM are showing fail

A row in your report with two red badges looks like the worst thing on the page. Often it isn't. Failing both checks has three quite different causes, and they call for three quite different responses — from “do nothing, this is normal” to “this is exactly why you're here.” Telling them apart takes about a minute.

What the two badges actually mean

DMARC doesn't ask whether SPF and DKIM passed. It asks whether either one passed and aligned — that is, whether the domain it authenticated matches the domain in the visible From: header. Your report shows the aligned result, which is why a source can pass SPF at its own provider and still show fail here.

DMARC passes if either check aligns. So both badges red is the only combination that fails the domain, and it's the only one worth reading closely.

Cause 1: the message was forwarded

Forwarding breaks SPF by design. When a message is relayed onward — by a mailing list, a university alias, an info@ that redirects, or the recipient's own mail security gateway — it arrives from a server that was never in your SPF record, and SPF fails. DKIM usually survives, because the signature travels inside the message; but a gateway that rewrites the subject line, appends a disclaimer or strips an attachment invalidates the signature too. Then both fail.

This is your own mail, being handled by machinery on the recipient's side. There is nothing to publish and nothing to fix. ARC exists to carry the original verdict across those hops, though it only helps when the receiver honours it.

How to recognise it: the PTR belongs to a security vendor or a mail host rather than to a sender you'd recognise — .pphosted.com (Proofpoint), .mimecast.com, .iphmx.com (Cisco), .barracudanetworks.com, .cloud-sec-av.com (Check Point Harmony). Volumes are low and steady. Canny Pigeons labels these rows for you where it can identify the vendor.

Cause 2: a legitimate sender nobody aligned

Someone in your organisation signed up for a newsletter tool, a CRM, an invoicing product or a help desk, put your domain in the From field, and never completed the DNS step. The vendor sends the mail perfectly well — it just authenticates as the vendor's domain, not yours, so nothing aligns.

This is the most common finding on a first report, and the most valuable: it's mail your customers are receiving that would be lost the moment you move to p=reject. The fix is the vendor's custom-domain authentication setup — a CNAME or two, usually. See ESPs and DMARC for why passing SPF and DKIM at the vendor still isn't enough.

How to recognise it: the PTR or network owner names a recognisable product (SendGrid, Mailchimp, Zendesk, HubSpot, Klaviyo). The volume is consistent and the header-from is your domain on purpose. Nobody is hiding.

Cause 3: someone is sending as you

The remaining case is the one DMARC was built for: mail carrying your domain in From: that you had nothing to do with. It fails both checks because the sender has neither a listed IP nor your private key — and cannot get either.

How to recognise it: no PTR at all, or a generic one from a hosting provider; a network owner that's a bulk VPS or residential ISP rather than a mail platform; volume that spikes and vanishes; often a geography with no relationship to your business. Source IPs: geo, ASN and threat flags walks through the evidence in detail.

The response is enforcement, not DNS surgery. Once you're confident your real senders align, advance your policy to quarantine and then reject, and receivers will stop delivering it.

The one-minute triage