Someone forwards you a message. It has your company's address on it and you did not send it. The obvious next move is to go and publish p=reject.
Wait. Four quite different attacks get reported in exactly those words, and DMARC only fixes one of them. Enforcing against the wrong one costs weeks and changes nothing.
Triage first: look at the actual From address
Not the display name your mail client shows you. The address.
| What you see | What it is | What fixes it |
|---|---|---|
billing@example.com — your exact domain |
Domain spoofing. Anyone can write any address into a From: header. |
SPF + DKIM + DMARC at p=reject
|
Your Company <randomuser@gmail.com> |
Display-name impersonation. The address is theirs. Only the label is yours. | Nothing in your DNS. Receiver-side rules and staff training. |
billing@examp1e.com, example-inc.com
|
Lookalike domain. A different domain that reads like yours. | Monitoring and takedowns. Your DMARC record has no authority over it. |
| Genuinely from your account, in your Sent folder | Compromised account. | Password, revoke sessions, and check for forwarding rules the attacker added. |
Only the first row is domain spoofing. It's also the only one where a stranger can put your domain in front of your customers, which is why it's worth fixing first and why DMARC exists.
If you can't tell which you're looking at, the raw headers will settle it — the Authentication-Results header names the domain that actually authenticated.
"I'm getting bounces for mail I never sent"
This is how most people discover the problem, and it's alarming in a misleading way.
A spammer sent to a few thousand addresses with your address forged as the sender. Some of those didn't exist. Those servers bounced the messages back to the forged sender — you.
It does not mean anything of yours was accessed. No password is required to type your address into a header. It's evidence your domain is being forged, and a good reason to get to enforcement, but it is not a breach.
One exception worth ruling out immediately: if the bounces correspond to messages that appear in your own Sent folder, that's a compromised account, not spoofing. Different problem, much more urgent.
Why fixing the real thing takes weeks
Worth understanding the mechanism, because it explains the timeline.
Nothing in the original design of email verifies the From: header. SMTP accepts whatever a sender writes. SPF, DKIM and DMARC are a layer bolted on afterwards that lets you publish a claim about who may send as you, and lets receivers act on it.
1. Get SPF or DKIM passing for every legitimate sender. Not just your mailbox provider — the CRM, the invoicing system, the ticketing tool, the booking form. And each must pass aligned with your domain. A vendor sending from its own envelope domain can pass SPF perfectly and still fail DMARC.
2. Publish DMARC at p=none with a reporting address.
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
This blocks nothing. It tells you who is sending as you — including the forger, and including the three internal systems you'd forgotten about.
3. Read the reports for four to six weeks, then enforce. Long enough that monthly and quarterly senders show up. Then p=quarantine, then p=reject.
There's no shortcut here that doesn't risk blocking your own mail.
The sp= footgun
Attackers move to subdomains once the parent is unusable, because billing.example.com is just as convincing to a recipient and is usually left unprotected.
Subdomains inherit p= unless you override it, so a bare p=reject already covers them.
The mistake is publishing sp=none alongside it — almost always copied from an example record found somewhere — which reopens precisely the door you just shut. If you don't have a specific reason for an sp= tag, don't publish one.
What DMARC will not do, whatever the vendor said
-
It does not stop lookalike domains.
examp1e.combelongs to someone else. Your DNS says nothing about it, andp=rejecton your domain has no effect on theirs. - It does not stop display-name impersonation. That message is properly authenticated for the sender's own domain. There is no authentication failure for DMARC to act on. This is now the more common attack against small organisations — precisely because DMARC adoption made the easy version harder.
- It does not stop your name being used in the message body.
- It does not apply retroactively. Mail already delivered stays delivered.
What it does is remove your domain from the attacker's toolkit. That's worth the few weeks. The rest is a filtering and training problem, not a DNS one.
I maintain notspoofed — a free, no-signup SPF/DKIM/DMARC checker. It reports whether your policy is actually enforcing and flags an sp= tag that's quietly weakening it, which is the failure above that people don't find on their own. There's also an in-browser header analyzer for the triage step; headers are parsed locally and never uploaded. Source on GitHub under MIT.
If you've had the bounce-flood experience and it turned out to be something other than plain domain spoofing, I'd be interested to hear which of the four it was.
Top comments (2)
Good triage table — the case I'd add is a fifth thing that shows up looking exactly like row one but isn't an attacker at all: your own mail, forwarded. Once you're reading those p=none reports you'll see sources failing DMARC that are legit — a plain forward breaks SPF because the return-path is now the forwarder's IP, and DKIM usually survives that so DMARC still passes on the DKIM side; but the moment a mailing list rewrites the subject or appends a footer it breaks the DKIM body hash too, and now a genuinely-yours message fails both, gets quarantined at the final hop, and lands in your rua as a "forged" source. Enforce off that without recognizing the forwarders and you blackhole your own list traffic — ARC exists precisely so a forwarder can vouch for the original auth results and let the final receiver honor them despite the break. So before p=reject the aggregate reports really need a second read: is this failing source an attacker, or me going through something that modified the message on the way?
That's a fair correction, and it's a real gap — my four rows are all "what is the attack", and you're describing the case where there is no attack and the report says otherwise. That's the one that costs people mail.
The line I'd draw is slightly different from forward vs mailing list, because it's really about whether anything touched the message:
bh=body hash no longer matches, so DKIM fails too. Both mechanisms gone, and it lands in yourrualooking exactly like forgery.What makes it nasty is that the second case is indistinguishable from an attacker in the aggregate report itself. Same shape: your domain in the From, both mechanisms failing. The only thing separating them is whether you recognise the source, which is why "read the reports for four to six weeks" matters more than it sounds — a monthly newsletter going through a list won't show up in a fortnight of data.
On ARC: agreed it's the designed answer, with the caveat that it only helps when the final receiver evaluates it. Google and Microsoft do. Plenty don't, and ARC gives them no obligation to trust the chain even when present.
Worth adding for anyone hitting this: the pragmatic mitigation on the list side is From-rewriting — Mailman and friends replacing the From with the list address so DMARC evaluates the list's domain rather than yours. It's why list mail so often shows up as "via" in Gmail. Ugly, and it works.
I'll fold the forwarded-legitimate-mail case into the guide this points at. Thanks — it belongs there.