Learn
A phishing email forged your own domain? Spoofing vs a breach, and how to stop it
A suspicious email that appears to come from your own domain — usually not a server breach but a forged sender (From). How to tell a breach from a forgery by reading the email headers, why it reaches the inbox, and the phased SPF / DKIM / DMARC fix that stops spoofing.
One day a suspicious email that appears to come from your own company domain lands in your own inbox. First — breathe. In most cases this is not an intrusion; it's a forged sender. Here's how to tell, and how to stop it (no attack steps).
First, reassurance: spoofing ≠ a takeover
This is the key misconception. The "sender" on an email envelope can be written freely by whoever sends it. So one piece of mail with your domain name written on it doesn't mean your house was broken into.
That said, a genuinely compromised mailbox isn't impossible. The way to tell the two apart is to read the headers.
Use the headers to tell "breach" from "forgery"
Behind the body, every email carries a "header" — its delivery record (in Gmail: "Show original"). Five fields matter most.
| Header | What to look at | How to read it |
|---|---|---|
| Authentication-Results | the spf= / dkim= / dmarc= results | dmarc=fail means "real authentication didn't pass = likely a forgery" |
| Received (a stack) | the bottom line = the true origin | if it left from somewhere other than your own host, it's an outside forgery |
| Return-Path (envelope sender) | does it match the visible From? | a mismatch is a forgery tell |
| Reply-To (reply destination) | where a reply actually goes | From looks internal but Reply-To is an unrelated outside address → a trap to make you reply |
| X-Mailer (sending software) | a sane name? | random gibberish = the fingerprint of an automated spam tool |
Reply-To is the one people miss. The From can look exactly like a colleague, yet a reply flies off to a completely different outside address — where they'll have you send back secrets or a contact (a chat QR code, etc.) to hijack your communication channel. Not trusting From on looks alone is your strongest human-side defense (→ what is phishing).
Why it reaches your inbox at all
A forged email slips in — not even into spam — because the receiver has no basis to reject the fake.
No DMARC policy
With no DMARC policy on your domain, the receiver can detect the From forgery but can't be forced to reject it. This is the single biggest reason it reaches the inbox.
A 'soft' SPF setting
If SPF ends in ~all (softfail = "suspicious but don't reject"), the receiver lacks a decisive reason to drop it.
Forwarding breaks SPF
Forwarding a received message to another address makes SPF look like "pass" against the forwarding server, while From stays a different domain. DMARC is what finally judges that mismatch.
This is where DKIM earns its keep. SPF breaks across forwarding, but a DKIM signature survives it. So the lifeline that keeps legitimate mail from being wrongly dropped once you reach reject is DKIM — which is exactly why you set DKIM up first, as the foundation.
The fix: SPF → DKIM → DMARC, in stages
The mechanics live in what is SPF / DKIM / DMARC; here is just the safe order. The iron rule: never jump straight to reject.
One correct SPF record
Enable DKIM signing (the foundation)
Start DMARC at p=none (monitor only)
p=none plus report collection, and watch for 1–2 weeks that legitimate mail isn't dropped.Raise all the way to reject
p=quarantine → p=reject. Only when "forgeries are rejected at the receiver" is achieved does a mail like this vanish before it reaches the target's inbox.The "missing piece" is opposite per domain
Check several domains and you'll notice the gaps are often mirror images — because the sending setup differs, so does the part the service fills in for you.
Mail-service setup
- e.g. transactional mail sent via an external delivery service
- DKIM / DMARC tend to be auto-configured at onboarding
- but SPF must be added to DNS yourself → that's the gap
Hosting-default setup
- e.g. mail sent directly from a hosting server
- SPF is usually present from the start
- but DKIM is a manual toggle and DMARC is yours to publish → those two are the gap
Both are "not all three present" — the gaps are just mirror images. The first step is knowing which pattern your domain is.
This site's view: setting it isn't stopping it — it works only once you verify
On this site we treat email authentication as something that works only once you verify it, not "set and forget." You can check your own domain's current state in one shot with the SPF / DKIM / DMARC checker or the site security audit. Even a single value has pitfalls — for example, putting fo on a record with no failure-report address (ruf) makes it, by spec, a dead tag that's simply ignored. Such "harmless but pointless" settings, caught only in review, are common. And the real goal is two layers: make the receiver reject the forgery (DMARC) and make people not reply to the trap. Before detection or settings, put the design that stops it by mechanism first.
Read next
- Glossary: What is SPF / DKIM / DMARC (the mechanics)
- Glossary: What is phishing
- Tools: SPF / DKIM / DMARC checker / Site security audit
- Related: Multi-factor authentication (MFA) guide
FAQ
QAn email arrived using my own domain — does that mean my server was hacked?
Usually no. The email transport (SMTP) lets the sender write the From line freely. Like writing someone else's address on the back of an envelope, anyone can send mail 'as your domain' without ever touching your server. So receiving such a mail does not mean a breach. Whether you were actually compromised or merely spoofed is something you can tell by reading the message headers.
QWhy does a forged email reach the inbox without even being marked as spam?
Because the receiver has no basis to reject the fake. If your domain has no DMARC policy, the receiver can detect the From forgery but can't be forced to reject it. Forwarding muddies the result further. The fix is to set up SPF, DKIM, and DMARC and raise DMARC in stages up to p=reject.
QWhere do I start?
First check your domain's current state (an SPF/DKIM/DMARC checker shows it in one shot). Then, without jumping to reject, start DMARC at p=none (monitoring only), confirm from the reports that legitimate mail isn't dropped, and only then move to p=quarantine → p=reject. Enable DKIM first, because a DKIM signature is the lifeline that keeps legitimate mail passing across forwarding once you reach reject.