Spoofing · Incident guide · DMARC
Someone is sending email as your domain — first, find out which problem you actually have
Forging a From address takes no access to your systems at all — it is a lie told to other people's servers. Most “my email is hacked” panics are this lie, and it is fixable from your chair. But two other problems wear the same costume, and they need different responses. Ten minutes of evidence first.
The triage — three tests, in order
| Test | Spoofing looks like | Compromise looks like | Your own tool looks like |
|---|---|---|---|
| 1. DMARC report source (aggregate reports; Microsoft's interpretation pattern) | Unknown IP, everything fails — Microsoft's own table calls this pattern a potential spoofing campaign | A known source, passing aligned — on mail you didn't send | A known vendor, passing but misaligned |
| 2. A customer's sample (ask them to forward the message as an attachment, or use Show original) | Authentication results fail; DKIM domain (d=) is absent or a stranger's | Results pass with your domain on a message you never wrote | Results name the vendor's domain; content is genuinely yours |
| 3. “Is it in my house?” | Not in Sent; no new sign-ins; no new rules | In Sent, or strange sign-ins/forwarding rules exist | The tool's own logs show the sends |
Only bounces arriving, no other sign? That's backscatter: the spoofer used your address as the return path, and rejections came home to you. Microsoft documents the phenomenon; treat it as evidence of spoofing (Fork A), not of a breach.
Fork A — It is spoofing: the response ladder
- Preserve evidence: save the DMARC reports and one full sample message (with headers) before changing anything.
- Complete authentication for every real sender — you cannot enforce against fakes until your genuine mail is unmistakably identified. If any legitimate tool is unauthenticated, fix it now (that is Fork C's job, below).
- Climb DMARC to enforcement:
p=quarantineramped, thenp=reject— the staged method in our rollout guide. Understand the distinction panic erases: atp=noneyou are compliant (Google and Yahoo accept the record's existence) but not protected — p=none asks receivers to do nothing about fakes. Yahoo's own remedy language for a spoofing problem is an enforcement policy, regardless of the compliance minimum. - Lock the parked siblings — attackers forge the spare domains too, and those have no legitimate mail to protect: three records each, per our lockdown guide.
- Report through channels that exist: in-client “Report phishing” in Gmail/Outlook for samples; the FTC's reportfraud.ftc.gov accepts fraud reports; if real money moved by deception, the FBI's IC3 (ic3.gov) is the official intake. (Folklore addresses circulating on blogs for Yahoo/Microsoft abuse desks could not be verified against official pages during this guide's research, so they are deliberately not printed.)
- Tell affected customers, factually — after the fork is established, not before: “Messages appearing to come from us on [dates] were not sent by us. Our domain's protections are now set to reject such mail. We never ask for [the thing the fake asked for] by email.” Say only what the evidence supports.
- Watch it settle: reports keep arriving — attempts continue (DMARC stops delivery, not attempts), dispositions shift to reject. That pattern is the system working.
Fork B — It authenticates, and you didn't send it: this is a security incident
- Change the affected mailbox password and revoke sessions; check for attacker-added forwarding rules and filters (the classic persistence trick), unfamiliar sign-ins, and new app passwords.
- Turn on two-step verification everywhere if it isn't, and audit who else has admin access to the mail platform and the DNS — the DNS is in scope because a hijacked registrar account rewrites authentication itself.
- DMARC cannot help this fork: the mail is legitimately authenticated. If money was requested or moved, report promptly (IC3) and involve your bank — speed matters more than any DNS record here.
Fork C — It's your own tool, unauthenticated
The least frightening fork and the most common: a website form, shop, or invoicing platform sending as you without alignment. It fails DMARC, alarms customers, and — at enforcement — your own policy will reject it. Authenticate it through the vendor's domain-authentication flow (or its SPF include + its DKIM on your domain), exactly as in the sender-specific fixes across this site. Until it is done, do not climb DMARC past it.
What DMARC cannot do — the honesty ceiling
- Stop attempts. Forgers keep trying; receivers refuse the delivery. Your reports will show attempts forever. That is success, not failure.
- Touch lookalikes. DMARC covers your exact domain. Cousin domains (yourbrand-support.com) and display-name tricks are outside its scope by design (RFC 7489 is explicit). Defensive registration has sharply diminishing returns; customer education and enforcement on the real domain are the durable spend.
- Erase booked damage. If receivers already degraded your domain's reputation from the spoofed traffic (Yahoo counts spoofed volume toward the claimed domain's review), recovery is the ordinary sender-rehabilitation path — enforcement plus clean sending over time. No reset button exists, at any provider, at any price.
- Serve as legal proof. Reports are operational telemetry, not courtroom exhibits; if real fraud losses are involved, that is a matter for law enforcement and counsel, not a DNS guide.
The scams that hunt people in your exact situation
| Pitch | Reality |
|---|---|
| “Pay us to remove/block the spammer” | There is no central blocklist authority to pay. Enforcement is your DMARC policy, set by you, free. |
| Incident-themed “verify your account” emails arriving mid-crisis | Attackers time credential phishing to publicised incidents. Navigate to your provider directly; never via the email that “warned” you. |
| “Buy these 40 defensive domains” | Attackers mint infinite variants. Register the handful of obvious typos if you wish; do not fund a portfolio. |
| “Abandon the domain, it's burned” | Almost never true, and it hands the attacker your brand's home. Enforcement + time rehabilitates. |
FAQ
Will p=reject stop the bounces (backscatter) too?
Mostly, over time: receivers rejecting at the policy level generate fewer misdirected bounces than accept-then-bounce handling, and senders' lists decay as delivery fails. It trends down; it does not switch off on day one.
My DMARC reports show sources I don't recognise but the mail passes. Panic?
No — read the pattern, per Microsoft's table: a passing, aligned source you don't recognise usually means a forgotten legitimate service (an old website, a scanner, a second shop). Inventory it; if it is genuinely yours, document it; the all-fail rows are the hostile ones.
How long until customers stop seeing fakes?
At the major receivers, from the moment your enforcement policy propagates and every legitimate sender is aligned — the ladder's gates exist so that day arrives without your own mail becoming the casualty.
Sources
RFC 7489 — DMARC (report contents §7.2; scope limits §§2.4/12.4) · Microsoft Learn — DMARC aggregate-report interpretation (pattern table), backscatter documentation, DMARC configuration · Yahoo Sender Hub — sender requirements & FAQ (spoofed mail counts toward the claimed domain's enforcement review) · Google — sender guidelines and in-client phishing reporting · FBI IC3 and FTC ReportFraud (official intakes).
Did this guide work for you?
Your reaction tells us whether this guide solved the problem it promised to solve.