Forwarding usually breaks SPF but preserves DKIM; spoofing fails alignment. That one distinction removes most false alarm.
The single most common DMARC question we get is: "Why is half my mail failing?" The honest answer is usually: it isn't. About 60–80% of DMARC failures on a healthy domain are forwarders, not attackers. Once you can spot the difference, the rest of the dashboard becomes much calmer.
The pattern
A forwarder looks like this in your reports:
- DKIM: pass and aligned.
- SPF: fail (or pass on the wrong domain — the forwarder's).
- Source IP: belongs to Fastmail, Proton, a corporate gateway, a mailing-list host, a personal Gmail forward, or some company's exchange server.
The classic example: alice@yourdomain.com sends a message; bob@fastmail.com has a "forward everything to my Gmail" rule. Gmail receives the forwarded copy from a Fastmail IP — which is not in your SPF. SPF fails. But the DKIM signature you applied is attached to the body of the message and survives forwarding, so DKIM aligns. DMARC passes on DKIM alignment alone. Receiver delivers the mail.
That's the system working as intended. You don't need to fix anything.
- DKIM passes and aligns with the visible From domain.
- SPF fails, or passes only for the forwarder's domain.
- The source infrastructure looks like a mailbox provider, gateway, or mailing list.
What an actual attacker looks like
- DKIM: fail.
- SPF: pass on the attacker's own domain (because they own the IP), but alignment fails — the SPF domain doesn't match the From: header.
- Source IP: a residential ISP, a cloud provider's burst range, an abuse-grade VPS host, a region with no business reason to send mail for you.
- Volume: usually small bursts, often to a single recipient or a campaign-style list.
- DKIM fails or is absent for the From domain.
- SPF alignment fails even if the sending IP has its own SPF pass.
- Source IPs come from infrastructure with no business reason to send for you.
Why this matters before going to p=reject
If you can't tell forwarders from attackers, you're going to be afraid to enforce. You'll sit at p=none indefinitely, which gives you visibility but no protection. The reason to learn to recognise the pattern is so that going to p=reject stops feeling scary.
And here's the kicker: forwarded mail is protected by p=reject too, because the DKIM signature still aligns. The forwarder is just relaying — they're not impersonating. So enforcement breaks impersonators, not forwarders.
How DMARCify surfaces this
Every source in the dashboard is classified into one of three buckets:
- Authorised — known sender, aligning.
- Forwarded — DKIM-aligned, SPF-broken, source PTR/ASN matches a known forwarder pattern. Safe to ignore.
- Unknown / unaligned — neither known nor forwarder-shaped. Investigate before tightening policy.
That third bucket is where your attention goes. Usually it shrinks to single digits within the first two weeks of monitoring, and the green path to p=reject becomes much shorter than people expect.