Can Someone Spoof Your Domain? How to Check and Fix It
Domain spoofing lets anyone send email that looks like it came from you. Learn how to check whether your domain is spoofable, what the result means, and the safe path to lock it down.
Domain spoofing is when someone sends email that appears to come from your domain — your exact address in the From: line — without any access to your systems. No password, no breach, no malware. If your domain isn't protected, the only thing standing between an attacker and your customers' inboxes is whether the receiving mail server bothers to check. Most of the time, it doesn't have anything to check.
The good news: spoofing is preventable, the fix is free to start, and you can find out where you stand in about ten seconds.
How to check if your domain is spoofable
Run the Domain Spoofability Check. Enter your domain and it inspects your live DNS — your SPF record, your DMARC record and the policy it publishes, and whether you're actually receiving the reports that prove it's working. It returns one of three verdicts.
It's an outside-in test: it sees exactly what a receiving mail server sees when it decides whether to trust a message claiming to be from you. You don't need an account, and you don't need to send anything.
What the three verdicts mean
We deliberately don't reduce this to a green/red pass-fail, because "not obviously broken" and "actually protected" are different things.
Spoofable. Anyone can send mail as your domain and it will be trusted as much as your real mail. This happens when you have no DMARC record, when DMARC is published at p=none (which only watches — it tells receivers to take no action on forgeries), or when your SPF record ends in +all (which authorizes the entire internet to send as you). This is the verdict to act on.
Fragile. Your DMARC policy is at p=quarantine or p=reject, so forgeries are being sent to spam or refused outright today — but something underneath is incomplete. Usually that's a missing or broken SPF record, or DMARC reporting that was never turned on, so you're enforcing blind. It works right now, but you can't see what's flowing, and a provider change could break legitimate mail without warning. Fragile is amber, not green: protected-looking, not protected.
Protected. DMARC is enforcing and the foundation is sound — a working SPF record and DMARC reporting switched on, so forgeries are refused and you can actually see your mail stream. This is the goal.
Why domains end up spoofable
Three protocols decide whether your domain can be impersonated, and email spoofing slips through whenever one of them is missing:
- SPF lists which servers are allowed to send mail for your domain. Without it — or with a permissive
+all— receivers have no allowlist to check. - DKIM adds a cryptographic signature so receivers can confirm a message really came from an authorized sender and wasn't altered in transit.
- DMARC is the policy that ties the other two together and tells receivers what to do when a message fails both checks. This is the one that actually stops spoofing — and the one most domains are missing or leaving at
p=none.
A brand-new domain has none of these. A domain that "set up DMARC" years ago is very often still at p=none, which means it watches impersonation happen but never acts on it. Either way, the door is open.
How to fix it — the safe path
You don't flip a switch and hope. Enforcement is reached by sender readiness — you turn it on once you can see that your real mail is accounted for, not on an arbitrary timer.
-
List who sends mail as you. Your own mail server, plus every third party — your newsletter tool, invoicing app, CRM, help desk. Each one needs to be authorized in SPF (and ideally signing with DKIM) or its mail will fail authentication once you enforce. Our SPF checker and DMARC checker show what's already there.
-
Publish a DMARC record in monitoring mode (
p=none) and turn on reporting. This is the watching stage. It changes nothing about how your mail is handled, but it starts sending you aggregate reports — the evidence of who's sending as you, both legitimate and not. Publishing a DMARC record is the free first step; the reporting is what makes the rest safe. -
Read the reports until every legitimate sender passes. When your real senders are all authenticating cleanly, you're ready to move. If a sender is still failing, fix its SPF or DKIM first — that's exactly what the reports are for.
-
Advance to
p=quarantine, thenp=reject. At quarantine, mail that fails authentication is sent to spam. At reject, it's refused at the door — the receiving server never delivers it.p=rejectis full protection: a forged message claiming to be you simply doesn't arrive.
The percentage ramp (pct=) you may have read about is an optional, extra-cautious cadence for very high-volume senders — not a required step, and not what gets you to enforcement. Sender readiness is.
For a step-by-step walkthrough, see the DMARC deployment guide and the enforcement journey.
Staying protected after you fix it
Getting to p=reject once is the hard part. Staying there is the quiet part nobody warns you about. SPF records drift as providers rotate their sending IPs; a new marketing tool gets added without being authorized; an SPF record creeps past the 10-lookup limit it's allowed and silently breaks. Any of these can flip a protected domain back to fragile — or worse, start sending your own legitimate mail to spam.
That's the work Managed SPF and Managed DMARC take off your plate: keeping the records correct as your senders change, watching the reports, and advancing enforcement when your mail is ready — so "protected" stays true instead of decaying the moment you stop looking.
Start with the free spoofability check. It tells you which of the three verdicts you're at right now, and the domain health check shows the full picture across SPF, DKIM, DMARC, and more.
Frequently asked questions
Does spoofing mean my domain was hacked?
No. Spoofing requires no access to your accounts or servers — an attacker simply puts your address in the From: line of mail they send from their own infrastructure. That's exactly why DNS-level protection (SPF and DMARC) is the defense: it lets receivers reject the forgery without anyone needing to compromise you first.
Is p=none enough?
No. p=none only monitors — it asks receivers to report on forgeries but take no action, so impersonating mail is still delivered normally. It's the right first stage because it gives you visibility safely, but a domain left at p=none is still spoofable. The protection comes at p=quarantine and p=reject.
I have SPF — am I safe? Not on its own. SPF says which servers may send for you, but receivers don't reject SPF failures unless a DMARC policy tells them to — and forwarded mail routinely breaks SPF. DMARC at enforcement is what actually stops spoofing; SPF and DKIM are the foundation it stands on.
Related Articles
Your domain has no DMARC record. Learn why DMARC matters, how to create your first record, and the recommended rollout path from monitoring to enforcement.
Your DMARC policy is set to p=none, which monitors but doesn't protect. Learn the risks of staying on p=none and how to safely move to enforcement.
Step-by-step guide to deploying DMARC on your domain. Start with monitoring, identify unauthorized senders, and safely progress to full enforcement.
How to safely move DMARC from monitoring mode to full enforcement. The enforcement ladder, readiness signals, what goes wrong at each stage, and when to hold.
Your authorized senders are the foundation of SPF, DKIM, and DMARC. Learn what a sender inventory is, how to discover every service sending as your domain, and how it drives safe DMARC enforcement.
A curated reading path through email authentication. Start here if SPF, DKIM, and DMARC are new to you — or if you've been working around them and want to actually understand what's happening.