Skip to content
ITDWeb Security Platform
ITD
Search

Security Guides

#email authentication#phishing#DMARC#spoofing#AI-era readiness

Email spoofing your own domain: how to tell it from a breach, and how SPF, DKIM and DMARC stop it

A suspicious email from your own domain is usually a forged From, not a breach. How to tell from the headers, and the SPF, DKIM and DMARC steps that stop it.

Published 2026-06-23 Updated 2026-10-04 8 min read
On this page

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).

Got it on a personal address like Gmail?

This article is for people who run their own domain. If spam or an extortion email showing your own address as the sender landed in a personal mailbox (Gmail, Outlook, a carrier address), see spam from your own address — check three places to know if you were hacked.

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.

Outside origin (attacker's relay) — forges From to look like you
↓
Your receiving server (MX) accepts it (no basis to reject = delivered)
↓ if forwarding is set
Final inbox (Gmail, etc.) — it "arrives," looking real
A forged email originates from an OUTSIDE sender, passes through your receiving server (MX), and — if forwarding is set — reaches your final inbox. The origin is not your infrastructure.

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.

HeaderWhat to look atHow to read it
Authentication-Resultsthe spf= / dkim= / dmarc= resultsdmarc=fail means "real authentication didn't pass = likely a forgery"
Received (a stack)the bottom line = the true originif 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 goesFrom looks internal but Reply-To is an unrelated outside address → a way to get you to reply to the sender
X-Mailer (sending software)a sane name?random gibberish = a typical sign of an automated spam tool

Reply-To is the one people miss. The From can look exactly like a colleague, yet a reply goes 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.

1

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.

2

SPF is set not to reject (~all)

If SPF ends in ~all (softfail = "suspicious but don't reject"), the receiver lacks a clear reason to reject it.

3

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 makes the final decision on that mismatch.

This is where DKIM matters. SPF breaks across forwarding, but a DKIM signature stays valid. DKIM is what keeps legitimate mail from being wrongly rejected once you reach reject, which is exactly why you set DKIM up first.

The fix: SPF → DKIM → DMARC, in stages

The mechanics live in what is SPF / DKIM / DMARC; here is just the safe order. The most important point: never jump straight to reject.

1

One correct SPF record

Authorize every legitimate sending server (your own, mail services) with no gaps. Keep SPF to one record per domain, and keep DNS lookups at evaluation under 10 (over it, the whole SPF goes invalid).
2

Enable DKIM signing (do this first)

Turn on DKIM in your mail platform. A signature that stays valid across forwarding is what prevents legitimate mail from being rejected once you later move to reject.
3

Start DMARC at p=none (monitor only)

Don't reject yet. Begin with p=none plus report collection, and watch for 1–2 weeks that legitimate mail isn't rejected.
4

Raise it in stages to reject

Once the reports show no legitimate senders failing, go p=quarantine → p=reject. Only when "forgeries are rejected at the receiver" is achieved does a mail like this get rejected before it reaches the target's inbox.

What is missing differs from domain to domain

Check several domains and you'll notice the missing settings are often exact opposites, because when the sending setup differs, so does the part the service configures 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"; what is missing is simply reversed. The first step is knowing which pattern your domain is.

This site's view: setting it up isn't enough — it works only once you verify it

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 at once with the SPF / DKIM / DMARC checker or the site security audit.

Even a single value needs care. For example, putting fo on a record with no failure-report address (ruf) does nothing; by spec it is simply ignored. Such "harmless but pointless" settings, caught only in review, are common.

What matters most is two things: making the receiver reject the forgery (DMARC), and people not replying to the fake message. Before detection or settings, put a design that stops it by mechanism first.

FAQ

QAn email arrived using my own domain — does that mean my server was hacked?
A

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?
A

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 makes the result less reliable. The fix is to set up SPF, DKIM, and DMARC and raise DMARC in stages up to p=reject.

QWhere do I start?
A

First check your domain's current state (an SPF/DKIM/DMARC checker shows it all at once). Then, without jumping to reject, start DMARC at p=none (monitoring only), confirm from the reports that legitimate mail isn't rejected, and only then move to p=quarantine → p=reject. Enable DKIM first, because a DKIM signature is what keeps legitimate mail passing across forwarding once you reach reject.