Almost every “DMARC is blocking our own mail” report comes down to one of eight causes. They look similar in a dashboard and have completely different fixes, so the useful first step is telling them apart rather than changing anything.
Narrow it down first
Two questions dispose of most cases before you start guessing.
Did anything pass? In the aggregate report, look at the SPF and DKIM results for the failing source. If one of them shows pass and DMARC still shows fail, it is an alignment problem, and nothing you do to the authentication itself will help. If both show fail, the sender genuinely is not authenticating.
Is the volume constant or spiky? A steady trickle from one IP is usually a forgotten service. A sudden burst is usually either a campaign someone sent or someone spoofing you — and the second is DMARC working correctly, which is worth remembering before you loosen anything.
The eight causes
1. Forwarding
A .forward rule, an alumni address, a role account that relays elsewhere. The forwarding server connects from its own IP, so SPF fails. DKIM normally survives, so DMARC still passes — if you have DKIM. Domains relying on SPF alone see all forwarded mail fail.
Fix: enable DKIM. There is no way to make SPF survive forwarding; that is inherent to how it works.
2. Mailing lists
Lists break both. SPF fails for the same reason as forwarding, and DKIM fails because the list modified the message — a [list-name] subject prefix or an unsubscribe footer invalidates the signature.
Fix: mostly the list's problem, not yours. Well-run lists rewrite the From: header to their own domain, which sidesteps DMARC entirely. ARC exists to preserve the original authentication result across the hop, but adoption is uneven.
3. SPF over a limit
The record returns permerror, so SPF cannot pass for anyone. Distinctive in reports because it affects every source at once rather than one of them.
Fix: get back under both limits — see the lookup limit. The SPF Inspector will tell you which one you breached.
4. A sender authenticating as itself
A SaaS platform sends on your behalf using its own envelope domain and its own DKIM key. Both pass — for the platform. Neither aligns with your From: domain, so DMARC fails. This is the classic alignment failure and it is extremely common with marketing, ticketing and invoicing tools.
Fix: configure the platform to sign with a DKIM key on your domain. Nearly all of them support it; it is usually a CNAME they ask you to publish. Adding them to your SPF record does not fix this on its own, because SPF authenticates the envelope domain, not the visible one.
5. Strict alignment
aspf=s or adkim=s means a subdomain passing does not count for the parent. Every sender that authenticates as mail.example.com fails DMARC for example.com.
Fix: unless you had a specific reason for strict, drop back to relaxed — it is the default for good reason.
6. DKIM key problems
The signature is present and does not verify. Causes, in rough order of frequency: the key was rotated at the provider and the DNS record was not updated; the record was published with the wrong selector; the record was truncated when pasted (long keys exceed the 255-character TXT string limit and some DNS UIs handle that badly); or t=y is set, which tells receivers to ignore failures and makes the signature decorative.
Fix: check what is actually published with the DKIM Inspector and compare it against what the provider says it should be.
7. Something nobody remembers setting up
A monitoring system, a backup appliance, a CI pipeline, a printer. It has sent mail as your domain for years from a server that was never in SPF, and nothing surfaced it because nothing was enforcing.
Fix: the reports are the inventory. The reverse DNS of the sending IP usually identifies it faster than asking around.
8. It is not legitimate
Sometimes the failing mail is exactly what DMARC is for. Before loosening anything, check whether the sending IP belongs to anyone you have a relationship with. A spike from consumer broadband or a hosting provider you do not use is a spoofing attempt, and the correct response is to finish the rollout rather than pause it.
Quick reference
| What the report shows | Most likely cause |
|---|---|
| Every source failing SPF at once | SPF over a lookup or void limit — permerror |
SPF pass, DMARC fail | Alignment — the passing domain is not yours |
DKIM pass, DMARC fail | Alignment, or strict mode |
| Both fail, low steady volume, one IP | A forgotten internal sender |
| Both fail, volume from many consumer IPs | Spoofing. This is DMARC working. |
| SPF fails, DKIM passes, recipient domains vary | Forwarding |
| Both fail, recipients are list subscribers | A mailing list modifying the message |
| One SaaS platform, consistently | It is signing as itself — needs a DKIM key on your domain |
Do not roll back on the first failure
The instinct when mail breaks is to drop the policy to p=none. That restores delivery and also restores spoofability, and it usually means starting over. If the failing volume is small, fix the sender. Drop back only when something high-volume and business-critical is affected and you need time.