Four things get called "someone is spoofing my domain". DMARC fixes one.

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
[e-mail] — your exact domain	Domain spoofing. Anyone can write any address into a From: header.	SPF + DKIM + DMARC at p=reject
Your Company <[e-mail]>	Display-name impersonation. The address is theirs. Only the label is yours.	Nothing in your DNS. Receiver-side rules and staff training.
[e-mail], 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:[e-mail]"

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.com belongs to someone else. Your DNS says nothing about it, and p=reject on 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.