To stop someone from spoofing your email domain, you need three DNS records working together: SPF and DKIM to prove which servers may send as you, and DMARC set to p=reject to tell receivers what to do with mail that fails both. When DMARC is enforced and aligned, a stranger can no longer put your exact domain in the visible From address and land in inboxes. The catch is doing it in the right order so you do not block your own newsletters, invoices, or helpdesk along the way.
Here is the honest version of the outcome: this locks down the domain in the From header that most people read. It does not stop attackers from registering a lookalike domain or from putting your name in the display field of a different address. We will cover those limits too, so nothing surprises you later.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
First, see what receivers see today
Before you change a single record, find out where you stand. Check your domain with the lookup above. You are looking for three things: a valid SPF record, at least one working DKIM signature, and a DMARC policy. If DMARC is missing or set to p=none, spoofers can currently forge your domain and receivers have no instruction to reject it.
Do not skip straight to a reject policy. If you enforce DMARC before your real senders are authenticated, you will bounce legitimate mail. The whole point of the ordering below is to reach enforcement without collateral damage.
Step 1: Audit every source that sends as your domain
This is the step people skip, and it is why DMARC rollouts break. You cannot authorize senders you have not written down. Make a list of every system that sends email using your domain in the From address:
- Your mailbox provider (Google Workspace, Microsoft 365)
- Marketing platforms (Mailchimp, HubSpot, Klaviyo)
- Transactional senders (SendGrid, Postmark, Amazon SES)
- Billing, CRM, ticketing, and e-commerce tools
- Any on-prem mail server or application server that sends notifications
Each of these needs to be authenticated. If a source is not on your SPF record and does not sign with DKIM, it will fail DMARC once you enforce. The audit is what turns a risky guess into a controlled change.
Step 2: Get SPF passing without breaking it
SPF (RFC 7208) publishes, in DNS, the list of servers allowed to send for your domain. A basic record looks like this:
v=spf1 include:_spf.google.com include:sendgrid.net -all
Two rules matter for anti-spoofing. First, end with -all (hard fail), not ~all or the dangerous +all, so receivers treat unauthorized servers as forgeries. Second, stay under the 10 DNS lookup limit; go over it and SPF returns a permerror that quietly voids your protection. If you have stacked many include: mechanisms, read fix SPF too many DNS lookups before you enforce anything. Full setup is covered in how to set up SPF.
One important limit: SPF checks the envelope sender (the Return-Path), not the From header your users actually see. That is exactly why SPF alone does not stop spoofing, and why DMARC exists.
Step 3: Sign your mail with DKIM
DKIM (RFC 6376) adds a cryptographic signature to each message. The receiver fetches your public key from DNS and verifies the message was authorized by the domain and not altered in transit. Because the signature travels with the message, DKIM survives some forwarding scenarios where SPF breaks.
Turn on DKIM in each sending platform, publish the selector record it gives you, and confirm it verifies. Most providers hand you a record like selector._domainkey.yourdomain.com. Walk through it in how to set up DKIM. Aim to have every source from your Step 1 audit signing correctly before moving on.
Step 4: Understand alignment, the piece that actually blocks spoofing
Here is the concept that makes DMARC work. DMARC does not just check that SPF or DKIM passed. It checks that the domain they passed for matches the domain in the visible From address. This is called alignment.
An attacker can easily make SPF pass for their own domain by sending from their own authenticated server. What they cannot do is make SPF or DKIM pass for a domain in the From header that says your domain. Alignment is the trap that catches them. If SPF passed but for attacker.com while the From says yourdomain.com, DMARC sees the mismatch and the message fails.
That is why you need SPF or DKIM to pass and be aligned to your domain. One aligned pass is enough for DMARC to pass, but you want both configured for resilience across forwarding and different receivers.
Step 5: Publish DMARC, then ratchet it to reject
Start in monitoring mode so you can watch before you block:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
p=none changes nothing about delivery. It asks receivers to send you aggregate reports about who is sending as your domain. Give it a week or two. Confirm that all your legitimate sources are passing with alignment and that the only failures are unauthorized or forged senders.
Then tighten the policy. Move to quarantine, which sends failing mail to spam:
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com
Finally, once you are confident, enforce rejection so forged mail is refused outright:
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com
At p=reject, a message that puts your exact domain in the From address and fails authentication is bounced before it reaches the inbox. That is the state that stops domain spoofing. The reasoning behind each stage is in DMARC policy: none vs quarantine vs reject, and the full walkthrough is in how to set up DMARC.
What this stops, and what it does not
Enforced DMARC is the strongest control you have, but be clear on its edges so you are not caught off guard.
What it stops
Exact-domain spoofing. Nobody can send mail with billing@yourdomain.com in the From address and reach inboxes at receivers that honor DMARC, which includes Gmail, Yahoo, and Microsoft. This kills the most common business email compromise and invoice-fraud pattern that relies on your real domain.
What it does not stop
- Lookalike domains. An attacker registering
yourdomaln.comoryourdomain-support.comsends from a domain you do not control, so your DMARC record has no say. Defenses here are domain monitoring, defensive registration, and user awareness. - Display-name spoofing. A message from
contact@random-gmail.comcan still set the display name to "Your Company." DMARC only authenticates the domain, not the friendly name. BIMI, which shows your verified logo, helps recipients spot the real thing. - Compromised accounts. If an attacker steals real credentials and sends through your own authenticated system, the mail is genuinely authenticated. That is an account-security problem, not a spoofing one.
DMARC closes the door on the easiest and most damaging attack. For more on where its protection begins and ends, see does DMARC stop phishing.
Frequently asked questions
How long does it take to stop spoofing after I set up DMARC?
DNS changes propagate within minutes to a few hours. But you should spend one to two weeks in p=none first to verify your legitimate senders pass, then move to quarantine and reject. Rushing to reject before your audit is complete risks blocking your own mail.
Can I stop spoofing with SPF alone?
No. SPF checks the envelope sender, not the From address recipients see, so an attacker can pass SPF for their own domain while forging yours in the visible header. Only DMARC alignment ties authentication back to the From domain, which is what actually blocks the spoof.
Someone is already sending email as my domain. What do I do right now?
Publish a DMARC record at p=none immediately to start collecting reports and see the scope, while you audit and authenticate your real senders. Then move to p=quarantine and p=reject as fast as your audit allows. Enforcement is what stops the forged mail from being delivered.
Does a reject policy hurt my own deliverability?
Not if you did the audit and got your real senders aligned first. Correctly configured DMARC improves deliverability because it builds domain reputation and meets bulk-sender requirements at major providers. Problems only come from enforcing before your legitimate sources authenticate.