The short answer: To prevent email spoofing of your domain, publish an SPF record, sign outgoing mail with DKIM, and publish a DMARC policy (RFC 9989) that moves from p=none to p=quarantine and finally p=reject. Lock down domains you do not send from, and monitor DMARC reports. Check your current setup with the DMARC checker.
Email spoofing means sending a message whose From address claims to be someone it is not. The core protocol, SMTP, never verified that claim, so protection has to be added at the DNS level.
This guide is for owners of a domain (a business, a nonprofit, a personal domain) who want to stop others from sending convincing mail as them. It also covers what a Gmail user can do from the receiving side.
If you want the background on how spoofing works and the different types, read what email spoofing is first. This post is the fix list.
Can You Actually Stop or Block Email Spoofing?
You can stop other people from spoofing your exact domain in a way that receivers will accept, but you cannot stop every impersonation attempt. Authentication protects the domain in the visible From address. It does not stop an attacker who registers a lookalike domain, or who changes only the display name.
Think of it as three layers:
| Layer | What it stops | What it does not stop |
|---|---|---|
SPF + DKIM + DMARC at p=reject |
Mail forged with your exact domain in the From header | Lookalike domains, display-name tricks, compromised real mailboxes |
| Receiving-side filtering and warnings | Some lookalikes, new-sender and external-sender risks | Well-crafted messages from clean infrastructure |
| People and process (verification calls, payment controls) | Fraud that gets past filters | Nothing on its own at scale, but it is the last line of defense |
The rest of this guide builds the first layer carefully, then points at the others.
Step 1: Inventory Every System That Sends Mail as Your Domain
Before you publish any policy, list everything that legitimately sends from your domain, because a strict policy will block anything you forgot.
Typical senders:
- Your mailbox provider (Google Workspace, Microsoft 365)
- Marketing platforms (newsletters, drip campaigns)
- Transactional senders (order confirmations, password resets)
- Helpdesk, CRM, billing and invoicing tools
- Scanners, printers and internal applications that relay mail
- Anything a department set up without telling IT
A fast way to find the forgotten ones is to publish a DMARC record at p=none with reporting turned on (Step 4) and read the reports. The DMARC aggregate reports guide shows how to interpret them.
Step 2: Publish SPF and Keep It Valid
SPF (Sender Policy Framework, RFC 7208) is a DNS TXT record listing the servers allowed to send mail for the domain that appears in the SMTP envelope sender (the Return-Path). A receiver checks the connecting server's IP against that list.
A simple record for a domain that sends only through Google Workspace:
example.com. IN TXT "v=spf1 include:_spf.google.com -all"
Rules that matter:
- Publish exactly one SPF record per domain. Two records cause a
permerror. - Stay under 10 DNS-querying terms. See SPF too many DNS lookups if you are close.
- Add each third-party sender through its documented include. Use the include value from that vendor's own documentation.
- End with
-allor~allonce you are confident in the list.-allis a hard fail and~alla soft fail; once DMARC is enforced, the difference matters less.
You can build and verify a record with the free SPF generator and SPF checker in our tools section.
SPF alone does not prevent spoofing. It authenticates the envelope sender, not the From address people see, and it breaks when mail is forwarded. That is why DKIM and DMARC are needed.
Step 3: Turn On DKIM for Every Sender
DKIM (DomainKeys Identified Mail, RFC 6376) adds a cryptographic signature to each message. The signing server holds a private key; you publish the matching public key in DNS under a selector, for example selector1._domainkey.example.com. A receiver fetches the public key and checks that the signature matches the message, which proves the message was authorized by whoever controls that domain's DNS and that signed headers and body were not altered.
A published DKIM key looks like this (the key is truncated placeholder text):
selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"
Each sending service gives you the exact record to publish, and many use CNAME records that point to their hosted key. Follow the vendor's instructions, then confirm the record resolves with a DKIM checker.
Platform guides: Google Workspace DKIM setup and Microsoft 365 DKIM setup. For the whole picture of how the three protocols fit together, see SPF, DKIM and DMARC explained.
Vendor interfaces change; confirm against your provider's current documentation. Last reviewed: October 2026.
Step 4: Publish DMARC at p=none With Reporting
DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 9989, which obsoleted RFC 7489 in May 2026) is the control that ties everything to the visible From address. It tells receivers what to do when a message fails authentication in alignment with that From domain, and it asks them to send you reports.
A message passes DMARC when at least one of SPF or DKIM passes and the authenticated domain aligns with the From domain. Alignment is the part that closes the spoofing gap: an attacker can pass SPF for their own domain, but not for yours.
Start with a monitoring-only record at _dmarc.example.com:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
At p=none, no mail is blocked, so you can learn who sends as you without risk. This is a starting point, not a protection. A domain left at p=none is still spoofable. You can generate a record with a DMARC record generator.
Leave this in place for several weeks so you capture monthly and quarterly senders such as billing runs.
Step 5: Fix Failing Legitimate Senders, Then Enforce
Read the reports, find legitimate sources that fail DMARC, and fix them before changing the policy. A source fails when neither SPF nor DKIM passes in alignment. Usual causes:
| Symptom in report | Likely cause | Fix |
|---|---|---|
| Vendor IP, SPF pass but not aligned | Vendor uses its own bounce domain | Configure a custom return-path or sign with DKIM for your domain |
| DKIM pass but domain is the vendor's | Default vendor signing | Enable domain authentication so the vendor signs as your domain |
| SPF fail, DKIM none | Sender missing from SPF and not signing | Add the include and enable DKIM |
| Forwarded mail fails SPF | Forwarding changes the sending IP | Rely on DKIM; it usually survives plain forwarding |
| Unknown IPs, no relation to you | Spoofing attempts | Nothing to fix; enforcement will block them |
Then step the policy up gradually. Older guides phase in enforcement with the pct tag, which applied the policy to only a share of failing mail. RFC 9989 removed pct and added a t (testing) tag: with t=y, a receiver that supports it applies handling one level below your published policy, so reject is treated as quarantine. Support for the new tag varies, so confirm against the RFC and your reports.
A common progression is quarantine, then reject, reviewing reports at each stage:
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
p=reject is the setting that tells receivers to refuse mail that fails DMARC, which is what actually prevents spoofing of the exact domain. How each policy behaves is detailed in DMARC policy: none, quarantine, reject. Receivers treat the policy as a request, and a few apply their own judgment, so it is strong protection rather than a guarantee.
If you use Google Workspace, how to set up DMARC in Google Workspace walks through it.
Step 6: Protect Domains and Subdomains You Do Not Send From
Attackers often spoof the domains and subdomains that nobody is watching. A parked domain or an unused subdomain with no records is easy to impersonate.
For a domain that never sends email, publish a null SPF record and a reject policy:
parked-example.com. IN TXT "v=spf1 -all"
_dmarc.parked-example.com. IN TXT "v=DMARC1; p=reject;"
For subdomains of your main domain, DMARC policy is inherited unless you set a subdomain policy with the sp tag. If you want to reject unauthorized subdomain mail while you keep the main domain at a softer policy, you can write p=quarantine; sp=reject. RFC 9989 also adds an np tag that sets a policy for subdomains that do not exist in DNS, which helps against attackers who invent names like billing.example.com. Be careful: if some subdomains legitimately send mail, they need their own authentication first.
Also consider:
- Registering obvious variants (common typos, a
.netor.coversion) and parking them with the records above. You cannot register every lookalike, so this is selective. - Removing dangling DNS records, such as CNAMEs pointing at decommissioned services, which attackers can claim. This is a related takeover risk rather than spoofing in the strict sense.
Step 7: Monitor Continuously and Add Receiving-Side Defenses
Authentication drifts. People add new tools, vendors change IP ranges, and records get edited. Treat DMARC as an ongoing control.
- Review aggregate reports on a schedule or use a monitoring service; our comparison of DMARC monitoring tools lists options.
- Re-check SPF, DKIM and DMARC after any DNS or vendor change.
- On the receiving side, enable external-sender warnings, impersonation protection and link scanning in your mail platform. Exact settings depend on your plan and change over time, so confirm against Google Workspace Admin Help or Microsoft Learn.
- Train staff to verify unusual payment or credential requests through a second channel. Business email compromise often involves no authentication failure at all.
How to Stop Email Spoofing in Gmail (as a Recipient)
If you are an individual Gmail user, you cannot publish DMARC for gmail.com, so you cannot stop someone from forging your address. You can reduce the damage and your own exposure:
- Report spoofed or phishing mail. In Gmail on a computer, open the message, select More next to the Reply icon, and choose Report phishing (per Google's Gmail Help). Our guide to reporting phishing email covers other clients.
- Do not trust the display name. Check the actual address and the sending domain.
- Turn on 2-Step Verification so a stolen password alone is not enough.
- Tell contacts if your address was spoofed. Spoofed mail from you does not mean your account was hacked, but check your account's recent activity and security settings to rule it out.
If bounce messages arrive for mail you never sent, a spammer probably forged your address as the sender. That is called backscatter and is not evidence of a compromise by itself.
If you own a custom domain on Google Workspace, everything above in Steps 1 to 7 applies to you. Vendor interfaces change; confirm against Gmail Help. Last reviewed: October 2026.
Common Mistakes and Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| DMARC record exists but spoofed mail still arrives | Policy is p=none |
Move to quarantine, then reject after reviewing reports |
| Legitimate newsletters landing in spam after enforcement | Vendor not signing as your domain | Enable domain authentication in the vendor and recheck alignment |
permerror in SPF results |
More than 10 lookups, or two SPF records | Trim includes; keep a single record |
| No DMARC reports arriving | Wrong rua address, or an external domain lacking authorization |
Check the address; external domains need an authorization record, as covered in the aggregate reports guide |
| Mail from a subdomain rejected unexpectedly | Inherited or sp=reject policy |
Authenticate that subdomain, or give it its own DMARC record |
| Record "not found" in checkers | TXT published at the wrong name | DMARC goes at _dmarc.yourdomain, not at the root |
| Lookalike domain sending convincing mail | Authentication cannot block other domains | Report to the registrar and host, add to filters, warn staff |
Remember that a correct, enforced DMARC record does nothing about an attacker who has the password to a real mailbox in your organization. Multi-factor authentication covers that gap.
Sources and further reading
- RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC), IETF, 2026. Obsoletes RFC 7489 and removes the
pcttag. - RFC 7208: Sender Policy Framework (SPF), IETF.
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures, IETF.
- Avoid and report phishing emails, Gmail Help.
- Google Workspace Admin Help and Microsoft Learn, for current admin settings on your plan.
Frequently Asked Questions
Can email spoofing be completely prevented?
Not completely. SPF, DKIM and DMARC at p=reject stop forged mail that uses your exact domain, but they do not stop lookalike domains, display-name impersonation or messages from compromised accounts. Combining authentication with filtering, multi-factor authentication and staff verification procedures gives the best realistic protection.
What is the best way to prevent email spoofing?
Publishing a DMARC policy of reject backed by working SPF and DKIM is the most effective domain-level control, because it tells receivers to refuse unauthenticated mail claiming to be you. Reach that policy gradually by monitoring reports, fixing legitimate senders first and increasing enforcement in stages.
Does SPF alone stop spoofing?
No. SPF checks the envelope sender, which users never see, so an attacker can pass SPF with their own domain while forging your visible From address. DMARC adds the alignment check between the authenticated domain and the From domain. SPF also breaks on forwarding, so DKIM is needed as well.
How do I know if my domain is being spoofed?
Publish a DMARC record with a rua address and read the aggregate reports. Rows from IP addresses you do not recognize, failing both SPF and DKIM, indicate someone sending as your domain. You may also hear from recipients who got suspicious mail from you or from bounces for messages you never sent.
How do I stop spoofed emails from showing up as me in Gmail?
Individual Gmail addresses cannot be protected by DMARC you control, so you cannot stop others forging them. You can report the messages as phishing, secure your account with 2-Step Verification, and warn contacts. For a custom domain on Google Workspace, publish SPF, DKIM and a DMARC policy.
How long does it take to reach a DMARC reject policy?
It depends on how many systems send as your domain. A simple domain with one mailbox provider can often move in a few weeks. A domain with many vendors may take months because each sender must be found, authenticated and verified before enforcement. Rushing causes blocked legitimate mail.
Next Step
Run the DMARC checker to see what policy your domain publishes today, or request a free email audit that reviews SPF, DKIM and DMARC together in a PDF report. If you would rather have the records built and the policy moved to enforcement for you, see the email security setup service.