How do I tell if my domain is being spoofed or my account is hacked?

Use the evidence, not the panic. In your DMARC aggregate reports, mail from an unknown source IP that fails all checks is spoofing — strangers forging your domain from their own servers. Mail from a known, authorised source that passes aligned SPF or DKIM but that you did not send points to a compromised account or abused authorised stream — a security incident, not spoofing. And a message in your own Sent folder, an unfamiliar sign-in, or a new forwarding rule settles it: spoofed mail never appears in your mailbox, because it never touched your systems.

Can DMARC stop people spoofing my domain?

DMARC at p=reject instructs receiving servers to refuse mail that claims to be from your exact domain but fails authentication, and major receivers honour it. It cannot stop the attempts themselves, cannot touch lookalike cousin domains or display-name tricks, cannot fix a compromised mailbox (that mail authenticates legitimately), and erases nothing retroactively. At p=none DMARC only reports — compliance pages call that 'having DMARC', but for a spoofing problem, protection starts at enforcement.

Why am I getting bounces for email I never sent?

That is backscatter: a spoofer forged your address as the return path, the recipient's server rejected or bounced the message, and the bounce came home to the forged address — you. Bounces of unsent mail are evidence of spoofing activity, not evidence that your account is breached. The response is the same authentication-and-enforcement ladder; do not reply to the bounces or click anything in them.

Spoofing · Incident guide · DMARC

Someone is sending email as your domain — first, find out which problem you actually have

First published 20 October 2026 · Built on RFC 7489, Microsoft's DMARC report-interpretation guidance, Yahoo's Sender Hub and Microsoft's backscatter documentation — each claim cited to its source, and the unverifiable ones left out.

BREATHE Spoofed ≠ hacked

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.

Do not delete DNS records in a panicDo not pay a “removal” service yet

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=quarantine ramped, then p=reject — the staged method in our rollout guide. Understand the distinction panic erases: at p=none you 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).

Verification note: triage patterns, backscatter behaviour and Yahoo's spoof-counting were confirmed from the sources above on 20 October 2026. Two popular “official” abuse-reporting addresses (Yahoo and Microsoft forwarding desks) failed verification against current official pages and are intentionally omitted rather than repeated.

Did this guide work for you?

Your reaction tells us whether this guide solved the problem it promised to solve.