How to stop email spoofing depends on whose address is forged. Gmail’s help page says Gmail isn’t able to stop spammers spoofing your address, and for a personal address that holds. For a domain you own, DMARC at p=reject, reached in 3 steps once SPF and DKIM pass, tells receivers forged mail is not valid use of your domain.
What email spoofing is, and which of the three kinds you have
Email spoofing is sending a message with a forged sender so it appears to come from someone else. It comes in three kinds: your exact domain in the From address, your brand’s name over another address, and a lookalike domain. A DMARC policy at enforcement covers the first kind and does nothing for the other two.
Before you can stop email spoofing, you need to know which of those reached your customers, because the fix for one kind does nothing for the others. It is possible at all because, as Gmail’s help page puts it, “the sender name can be forged”, and “your address can be used as the sender address or the reply-to address”. DMARC (Domain-based Message Authentication, Reporting, and Conformance), in RFC 9989’s abstract, lets the owner of the domain in the From address state a handling preference for mail that fails validation, and request reports about the use of the name. This is one piece of the wider work on how to improve email deliverability.
The table sorts the three kinds, plus a fourth case that looks the same to a customer and is not spoofing at all. The right-hand column for rows 2 to 4 is my own wording, not a quote from any standard.
| Kind | What the recipient sees | Can your DNS stop it? | What does stop it |
|---|---|---|---|
| Exact-domain spoofing | billing@yourdomain.com in the From line: your real domain | Yes, at receivers that honor DMARC | A DMARC policy at quarantine or reject, once your real senders pass SPF or DKIM |
| Display-name spoofing | ”Your Company Billing” as the name, over an unrelated address | No | Telling customers what you never ask for by email, and their own provider’s filters |
| Lookalike-domain spoofing | A domain one letter off, or your name with another ending | No: the forger owns that domain | Registering the obvious variants, and reporting the lookalike to its registrar |
| A compromised mailbox (not spoofing) | Real mail from a real account of yours | No: the mail is real, so it passes | Resetting the password and turning on two-factor |
One received header tells you which row you are in. Open the forged message’s original headers and find the Authentication-Results line, then read header.from= on it. If that is your exact domain and the result is dmarc=fail or dmarc=none, it is the first kind: dmarc=fail means your domain publishes a DMARC record and the message had no aligned pass, and dmarc=none means no DMARC record exists for your domain yet. A dmarc=pass on your exact domain means the message carried an aligned pass for it, and I would place that in the fourth row: real mail from an account or tool of yours. If header.from= names another domain, it is one of the other two kinds, whatever result that domain earns. Reading those headers line by line belongs with SPF, DKIM and DMARC setup, and a stolen password calls for a reset plus the steps to implement two-factor authentication on that account.
Why it matters for a small SaaS: your customers trust the domain, and so do mailbox providers
Spoofing matters to a small SaaS because customers receive fake password resets and invoices that carry its domain, and the domain’s reputation is what mailbox providers judge its real mail by. Google requires bulk senders to publish DMARC but accepts p=none, which asks receivers for nothing, so meeting the rule does not stop forgery.
The first cost lands with your customers: a fake “your account is suspended” notice, an invoice with new bank details, a password reset that leads somewhere else, all with your domain in the From line. You usually hear about it from a support ticket. The second cost is slower, and it is my estimate rather than a measured effect: customers who have been fooled once start to distrust, ignore or report mail from your domain, including the real receipts and resets, which is the road to transactional emails landing in spam.
The big mailbox providers ask for DMARC but not for enforcement. Google’s email sender guidelines say that since February 1, 2024, senders of more than 5,000 messages a day to Gmail accounts must “Set up DMARC email authentication for your sending domain”, and add: “Your DMARC enforcement policy can be set to none.” Yahoo’s sender best practices ask bulk senders to “Publish a valid DMARC policy with at least p=none”, and say “Yahoo strongly urges all senders to publish a DMARC policy for each domain that sends mail.” Meeting both rules leaves forgers free, because a p=none record means, in the words of RFC 9989, “The Domain Owner offers no expression of preference.”
Public authorities have set the higher bar. CISA’s BOD 18-01, issued October 16, 2017, told US federal agencies to set “a DMARC policy of ‘reject’ for all second-level domains and mail-sending hosts” within one year, and says reject “provides the strongest protection against spoofed email”.
The side effect people often meet first is a pile of bounce messages for mail they never sent. Those come back to your domain because the forger used it, and sorting them is a job for an email bounce handling checklist.
How to stop email spoofing at the domain: from p=none to p=reject in three steps
Stopping exact-domain spoofing takes 3 steps once SPF and DKIM pass: publish DMARC at p=none with a reporting address and read the reports until every real sender passes, move to p=quarantine, then publish p=reject. At reject, the domain tells receivers that failing mail is not valid use of its name.
Knowing how to stop spoofing emails that carry your domain starts with a precondition: SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) already passing, and aligned with your domain, for the app’s email provider, the company mailbox and every other tool that sends as you. Creating those records is SPF, DKIM and DMARC setup, a separate job, and this page starts where it ends. Microsoft’s DMARC setup guide recommends the same gradual order with p=reject as the goal, and suggests starting “with a domain or subdomain with low mail volume and/or fewer potential email sources”. The record syntax below comes from RFC 9989 and the providers’ own pages as I read them on October 4, 2026; I have not run this rollout on a domain for this article.
| Rung | The record at _dmarc | What the policy asks receivers | Exit condition before the next rung |
|---|---|---|---|
| 1. Monitor | v=DMARC1; p=none; rua=mailto:... | Nothing: the owner states no preference | Reports have arrived for long enough, and every source you recognize passes aligned SPF or DKIM |
| 2. Quarantine | p=quarantine, with a t=y test first | The owner “considers such mail to be suspicious” | As long again at quarantine with no real sender failing |
| 3. Reject | p=reject, with a t=y test first | The owner “considers all such failures to be a clear indication that the use of the domain name is not valid” | None: keep rua on and keep reading the reports |
Even at reject, the receiver decides. RFC 9989 says receivers “MUST NOT reject incoming messages solely on the basis of a ‘p=reject’ policy” and weigh it with other knowledge, so a forged message may still arrive somewhere, just with your domain’s stated preference against it.
A public record shows what the first rung leaves open. On May 2, 2024, the FBI, the US State Department and the NSA published a joint advisory on North Korean spearphishing: between late 2023 and early 2024, mail went to US government officials and others with the From line showing the real domain of a legitimate think tank. The advisory’s header sample shows SPF and DKIM passing for a different domain, DMARC returning “fail” because the From domain did not match them, and the think tank’s record at p=none, which it describes as a policy “in which no email filtering action is taken on the message, despite the failed DMARC verification”, and says this “ultimately allows the spearphishing email to be delivered to the victim’s inbox”. The agencies recommend p=quarantine or p=reject, plus rua to receive aggregate reports. A p=none policy tells you about forgers and stops none of them, and reaching reject safely is what lets you stop spoofing email at the receiving server instead of in your support inbox.
Step 1: read the DMARC reports until every real sender passes
A p=none record with a rua address changes nothing for forgers. Its job is the reports: RFC 9989 says that without rua, receivers “MUST NOT generate aggregate feedback reports”, and that they “SHOULD generate and send aggregate reports with a frequency of at least once every 24 hours”. Each report, per RFC 9990, “is an XML document”, so you read them through a DMARC report service or a small script that parses the XML.
Put the reporting mailbox on the same domain as the record. If rua points at another domain, RFC 9990 has the receiver look for an authorization record at that other domain, and without it “the URI MUST be ignored”. Google’s Workspace setup page says the same in plainer words: an address on a different domain needs “a DNS record at the other domain”.
The senders people forget are mostly tools that send as the company. This list is mine, from what a small SaaS usually runs:
| Sender found in the report | Who usually owns it | What to do |
|---|---|---|
| Company mailbox (Google Workspace or Microsoft 365) | The founder or office admin | Confirm DKIM signs with your domain |
| The app’s transactional email provider | Whoever set up the app | Confirm aligned DKIM; it carries resets and receipts |
| Marketing or newsletter tool | Growth or the founder | Add its DKIM with your domain, or move it to a subdomain |
| Support desk | Support | Set up its domain authentication |
| Invoicing or payment tool | Finance | Check whether it sends as your domain or as its own |
| CRM, scheduler, form tool | Sales or ops | Authenticate it, or switch it to its own domain |
| A server sending cron or alert mail | Engineering | Route it through the transactional provider |
| A source you do not recognize | A forger | Nothing to fix; this is the reason for the next rung |
- 01 Publish p=none with a rua address on your own domain, and confirm the record with a DNS lookup.
- 02 Wait for reports to arrive, and treat zero reports as no result, not a clean one.
- 03 List every source that sends as your domain, with its pass or fail result for SPF and DKIM.
- 04 For each source of yours that fails, fix its DKIM signing per that vendor's docs, and prefer DKIM over another SPF include.
- 05 Mark the sources that are not yours as forgers, and keep reading until every source you recognize passes.
Prefer DKIM for each vendor because RFC 9989 says a domain at reject “MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages.” How long to stay here is a judgment call. RFC 9989 says that, depending on a domain’s cadence for sending mail, “it may take many months of consuming DMARC aggregate reports” before the owner is sure all its mail authenticates. For a domain whose users might post to mailing lists and that still wants reject, the standard asks for at least a month at p=none first (more on that under step 2 and step 3). For an app-only sending subdomain with few senders, I aim for about two to four weeks of reports, and at least one full monthly billing cycle, in which every source you recognize passes aligned SPF or DKIM; a sender that runs quarterly or yearly needs its run seen too.
Step 2 and step 3: quarantine, then reject, with the t=y test before each
These are the five records in order, for example.com, each keeping the reporting address. The tags: v=DMARC1 marks a DMARC record, p is the policy, t=y is RFC 9989’s test mode, and rua is where aggregate reports go.
; rung 1: monitor only
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
; rung 2: quarantine, tested first, then live
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@example.com"
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"
; rung 3: reject, tested first, then live
_dmarc.example.com. TXT "v=DMARC1; p=reject; t=y; rua=mailto:dmarc-reports@example.com"
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"Under RFC 9989, t=y means the owner “is currently testing” and expects the policy applied to failing mail to be “one level below the specified policy”: quarantine with t=y is handled as none, and reject with t=y as quarantine. That holds at receivers built to RFC 9989, which was published in May 2026. Google’s Workspace page and Microsoft’s guide, read on October 4, 2026, still cite RFC 7489, document the older pct tag, and do not mention t. RFC 7489 says “unknown tags MUST be ignored”, so I plan every t=y record as if Gmail and Microsoft 365 apply its full policy: the exit condition before p=quarantine; t=y is the one you would want before plain p=quarantine.
The pct tag is the older way to ramp. RFC 9989 dropped it because “the ‘pct’ tag was usually not accurately applied, unless the value specified was either 0 or 100 (the default)”, and its tag registry lists pct as historic, which it defines as “not expected to be in use in any current implementation”. Microsoft’s guide still shows pct steps of 10, 25, 50, 75 and 100, and Google’s page recommends pct during a rollout; both are written to RFC 7489. I leave pct out of the records above, so each record means the same thing to old and new receivers apart from t.
The other tags RFC 9989 defines that matter here: sp sets the policy for existing subdomains, np for subdomains that do not exist, and adkim and aspf choose strict or relaxed alignment for DKIM and SPF. The time between rungs is a judgment call, and I give each t=y step about a week for a small domain whose reports are clean, planned as if Gmail and Microsoft 365 apply the full policy during it, as above.
Staff mailboxes change the last rung. RFC 9989 says p=reject “can be incompatible with” indirect flows such as alumni forwarders, role addresses and mailing lists, and that “DKIM signatures will generally remain valid in these relay situations”. It goes further for domains whose people post to lists: they “SHOULD NOT publish Domain Owner Assessment Policies of ‘p=reject’”, and one that wants to anyway should first publish p=none “for at least a month, followed by publishing ‘p=quarantine’ for an equally long period of time”, then keep its users off mailing lists or tell them that list posting may be hindered. What I’d do with that in a small SaaS: put the app’s mail on DKIM first, and if staff post to mailing lists, either stop the main domain at quarantine or tell them before reject, while an app-only sending subdomain can go to reject on its own record.
To publish each rung without a terminal, open your DNS provider’s dashboard, edit the TXT record named _dmarc, and save it. Then load https://dns.google/resolve?name=_dmarc.example.com&type=TXT in a browser, with your domain in place of example.com, and read the data field. From a terminal, dig +short TXT _dmarc.example.com shows the same record. If real mail starts failing, roll back by republishing the previous record. Keep rua on at reject: a tool someone adds next year shows up in the next aggregate reports, and adding its SPF or DKIM before it sends keeps it from failing at all.
Email spoofing prevention for the domains and subdomains you never send from
Email spoofing prevention covers domains you never send from. A parked domain gets an SPF record that authorizes no sender, v=spf1 -all, a DMARC record at p=reject, and, where it has an A record but no MX record, a null MX record. On the main domain, the sp and np tags set the policy for existing and non-existent subdomains.
Forgers can pick the domain nobody watches: the old brand, the .co and .io variants, the domain bought for one campaign. To prevent email spoofing on those, the NCSC’s guidance on parked domains, written for the UK public sector, lists four measures in order: an SPF record with “no permitted senders”, a DMARC policy of reject with a reporting address, a null MX record “If you have an A record on your domain, but no MX records”, and an optional wildcard DKIM record. It also advises: “Protect your parked domains first. They are easier to deal with, and once protected, require no maintenance.” Microsoft’s guide says the same for parked domains, to “specify no email should ever come from those domains”.
parked-example.com. TXT "v=spf1 -all"
_dmarc.parked-example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
parked-example.com. MX 0 .That rua points at the main domain, so the main domain must authorize it, or receivers ignore it: publish a TXT record parked-example.com._report._dmarc.example.com containing v=DMARC1, or one wildcard record *._report._dmarc.example.com for every parked domain at once.
Subdomains need a decision too. On the main domain’s record, sp sets the policy for existing subdomains and np for non-existent ones; when np is absent, receivers fall back to sp, and when that is absent, to p. A subdomain that does send, such as the app’s mail. subdomain, needs its own SPF and DKIM. The registrar and DNS accounts hold the keys to all of this, so locking them sits next to knowing how to add HTTPS to a website and lock the registrar.
Email spoofing protection DMARC cannot give: display names and lookalike domains
Email spoofing protection from DMARC ends at the exact domain. Your brand’s display name over a free webmail address, or a domain one letter off yours, can pass every check: the checked domain is real, the webmail provider’s or the forger’s own. Registering obvious variants, telling customers what you never ask for, and reporting the lookalike reduce it.
I read RFC 9989’s definition of alignment this way: DMARC binds to the domain in the From address, so a forger who sends from a domain they control can authenticate it properly. Receivers weigh more than DMARC anyway: Microsoft’s anti-spoofing documentation says “a composite authentication failure doesn’t automatically block a message”.
| What the forger does | Why the checks pass | What reduces it |
|---|---|---|
| Puts “Your Company Support” over a free webmail address | DMARC checks the webmail provider’s domain, which is real | A help page saying which address your mail comes from and what you never ask for |
Registers yourcompany-billing.com or a one-letter typo | The forger can set up SPF, DKIM and DMARC on that domain | Registering the obvious variants and parking them with the records above |
| Uses your name and logo in the message body | SPF, DKIM and DMARC never compare the body with your brand | One sending subdomain and one From name, so a fake looks different |
| Keeps a lookalike domain live | It is a separate, valid domain | Reporting it to its registrar’s abuse contact |
I offer these as my own rules, not a standard. Inbound filtering for your own staff, which is what email-security vendors sell, is a different product and does nothing for mail sent to your customers.
If it is your personal address: how to stop spoofing emails from my email address on Gmail or Outlook
A spoofed personal Gmail or Outlook address cannot be fixed with DNS, because you do not control those domains; on October 4, 2026, both published DMARC at p=none. What is left is three actions: confirm the account itself was not broken into, turn on two-step verification, and report the message as spam or phishing.
The honest answer comes first: nobody can publish DNS records for gmail.com or outlook.com except Google and Microsoft. Gmail’s help page says it outright: Gmail “isn’t able to stop the spammers from spoofing your address”. A lookup through Google Public DNS on October 4, 2026 showed p=none; sp=quarantine on both _dmarc.gmail.com and _dmarc.outlook.com. Gmail’s sender guidelines also say Gmail “will begin using a DMARC quarantine enforcement policy”, which is Google’s move to make, not yours.
- 01 Rule out a real break-in first: follow the Gmail security checklist, or Outlook's account security page, and look for sign-ins and devices you do not recognize.
- 02 Change the password and turn on two-step verification if anything there is unfamiliar.
- 03 Report the forged message: in Gmail, mark the bounces for mail you never sent as spam; in Outlook, select Report, then Report phishing.
- 04 Do not reply and do not pay. Mail that seems to come from your own address was forged in the From line, not sent from your account.
- 05 Block the sender if the same forged address keeps coming back, knowing that a block matches only that one address.
The first step is the one Gmail’s page on spoofed addresses gives when friends say you sent them spam, and its advice for bounces of mail you never sent is “report them as spam”. To block spoofed emails in Outlook you need a second action: Outlook’s phishing help says that after Report phishing “the sender is reported but is not blocked from sending you additional messages”, and blocking needs the blocked senders list. A block on a forged address, I believe, stops only that address, so a forger who rotates addresses gets through. If the address is on your own domain, the three-step climb above is your fix.
How to check your own domain
A domain is protected against exact-domain spoofing when 4 checks pass: the DMARC record at _dmarc says p=reject or p=quarantine with no t=y, the subdomain policy is no weaker, every real sender shows aligned SPF or DKIM in a received header, and mail from a sender you have not authorized fails DMARC with your policy applied.
Each check below can fail, and each leaves a piece of evidence you can keep. Run them only against domains you own.
- 01 Look up the TXT record at _dmarc for every domain you own, sending or not. Pass: p=quarantine or p=reject with no t=y. Evidence: the record text and the date.
- 02 Read the same record for subdomain and leftover tags. Pass: sp and np are absent or no weaker than p, and no pct below 100 is left from an older record. Evidence: the same record.
- 03 Send one real message from each sender in your inventory to a mailbox you control, and read the Authentication-Results header. Pass: dmarc=pass for every sender. Evidence: the header lines.
- 04 Send through a legitimate email tool you have not yet authorized for your domain, to your own Gmail inbox and a Microsoft 365 mailbox. Pass: the message is refused, or its header shows dmarc=fail with your policy applied. Evidence: the bounce or the header.
For check 4, the plain dmarc=fail result is not enough, because a p=none record produces it too. Read the policy the receiver applied: Google’s header puts it in brackets after the result, as in the advisory’s sample dmarc=fail (p=none sp=none dis=none), and Microsoft 365 writes action=quarantine or action=oreject. If a Microsoft 365 mailbox shows dmarc=fail action=oreject and still delivers the message, Microsoft’s guide traces that to the receiving tenant: “Honor DMARC disabled, or allow list/override in place”. Your record is not at fault there.
This is how sending-domain authentication is verified in the Production Hardening Sprint, deliverable 11.1: “Inspect DNS and received message headers for the configured authentication results.” Seed tests and inbox-placement tools are part of how to test email deliverability. Repeat check 1 whenever you buy a domain, and check 3 whenever someone adds a tool that sends mail.
Where the sprint does this
Sending-domain authentication is deliverable 11.1: we verify and configure SPF, DKIM, and DMARC for the transactional sending domain, because domain-authentication problems can undermine legitimate email delivery. The result, the work completed and its verification evidence go into the production readiness report, deliverable 13.1, which accounts for all 123 IDs, keeps failures visible until resolved and explains genuine non-applicable items. Hosting, paid tools, and API usage remain in your accounts. Read deliverable 11.1 in the published scope with its verify line.
Common questions about spoofed email
What happens if I open a spoofed email?
The harm from a spoofed email comes from what you do after opening it: clicking a link, opening an attachment, replying, or paying. Outlook’s help says to “be careful about interacting with messages that don’t authenticate”, especially from a sender you don’t recognize. If you clicked or typed a password, change it and turn on two-step verification.
Does spoofing mean hacked?
No. A spoofed message is made outside your account: Gmail’s help page says these emails are “created outside of Gmail”, so your account was not used to send them. The Gmail security checklist, or Outlook’s account security page, rules out the other case, a real break-in, which looks the same to the person who received the mail.
Should I be worried if my email is spoofed?
About your own account, only if the security checklist turns up a sign-in or device you do not recognize. About what recipients think, yes when it is your business domain, because customers often cannot tell a forged invoice from a real one; that is the job of the DMARC climb above. For a personal address, reporting the messages is the useful step.
How did a scammer email me from my own email?
The scammer forged the From line; the message never left your account. If Gmail shows such a message in Spam with “Me” in place of your address, its help page says that means “someone tried to put your address in the ‘From’ field of the message.” Ignore any demand it makes, such as a demand for money.
Can email spoofing be traced?
Partly, for a domain you own: DMARC aggregate reports list the sources sending as your domain, which CISA describes as a way to be “aware of the source of an apparent forgery”. Tracing a person is rare in practice, since the sending machine is seldom the forger’s own. If money or data was taken, report it to your local police or national fraud authority.
Why should you never delete spam emails?
Deleting spam does no harm as far as I know, but reporting it is more useful, because a report tells your provider about the sender and deleting tells it nothing. For bounces of mail you never sent, Gmail’s advice is the spam report described earlier, and Outlook’s Report phishing reports the sender. After reporting, delete it if you like.
If you have a working app built with these tools and need it ready for real customers, this is what we do.
Built it with AI. Now it has to hold up for real customers.
The Production Hardening Sprint takes the app you already have and builds the production foundation underneath it. Authentication and access rules, payments that stay consistent, error handling, monitoring, backups, automated tests and a documented handover. Our engineers work inside your existing codebase for ten working days. All 123 deliverables are included, and you get the evidence for each one.
See the Production Hardening Sprint → 
$2,500 fixed price · 10 working days · One codebase