Group failures in your aggregate report by sending source, then check whether SPF or DKIM failed, and whether it failed to pass or to align. Send a test through that source and read the authentication results header. Most cases are a third party sender, a forwarder, or a From domain that does not match the signing domain.
Pass, fail and align are different
DMARC does not ask whether SPF or DKIM passed. It asks whether at least one passed and aligned with the visible From domain. The specification, RFC 9989, defines alignment between the author domain and the identifier that SPF or DKIM validated. A message can pass SPF for the vendor's bounce domain and still fail DMARC because that domain is not yours.
So each failing row has two questions: did the check pass, and did the domain match? Compare the ideas in what SPF, DKIM and DMARC each prove.
Triage flow
- Open the aggregate reports for the past week and list sources by volume and result. See reading aggregate reports.
- Name each source. Look up the sending address ranges. Match them to a vendor or one of your own servers. Unknown sources are either unregistered senders or spoofing.
- Sort failures into groups using the table below.
- Reproduce. Send a test from the failing system to a mailbox you control. Open the full headers and read the results, as in reading headers.
- Fix the cause at the sender or in DNS.
- Confirm in the next set of reports.
Common causes
| Pattern in the report | Likely cause | Fix |
|---|---|---|
| SPF pass, not aligned | Vendor uses its own bounce domain | Custom return path, or rely on DKIM |
| DKIM pass, not aligned | Vendor signs with its own domain | Configure signing with your domain |
| DKIM fail | Message altered after signing, or wrong key published | Check the selector record and any gateway that edits mail |
| SPF fail from a known vendor | Vendor missing from your SPF record, or lookup limit exceeded | Add the include to the right subdomain, check the count |
| SPF fail on a subset of mail | Forwarding | Rely on DKIM, see forwarding and ARC |
| Unknown source, all fail | Spoofing or unregistered sender | Identify, then reject if hostile |
| Intermittent DKIM failure | Mixed key rotation, or two systems sharing a selector name | Use distinct selectors |
Things that quietly break authentication
- Footers added by a gateway change the body after signing, which invalidates the signature unless the gateway signs again.
- Mailing lists that rewrite subjects and add footers can break DKIM. Forwarded mail often breaks SPF.
- A vendor changing its sending addresses while your flattened SPF record stays the same. See flattening trade offs.
- A DKIM record published at the wrong name, or truncated by a DNS interface.
- A new subdomain with no records at all.
What to do before enforcement
Do not move to quarantine or reject while a legitimate stream is still failing. Fix it, or isolate it on a subdomain with its own policy, then continue the rollout plan. The specification starts with a monitoring policy precisely so that you can find streams you overlooked.
When failures are the point
Some failing sources are attackers. A reject policy exists to stop those. Do not whitelist an unknown source to make a report look clean.
Safeguard's compliance and evidence automation can help you document the review for audits. For code and dependencies, the free scan is at gold.safeguard.sh/scan.
Quick check
Can DMARC pass with SPF failing?
Yes. DMARC needs one aligned pass, either SPF or DKIM. A valid, aligned DKIM signature is enough.
Why does forwarded mail fail?
The forwarding server is not in your SPF record and the bounce address often stays the same, so SPF fails. DKIM usually survives, if the message body is unchanged.
Sources
Last reviewed: 19 October 2026.
