How to stop others sending email as your domain

Anyone can type your domain into the From line of an email. Whether that forgery reaches an inbox depends on what your DNS tells receivers to do with it. This guide is the practical path: authenticate your real senders, move DMARC to enforcement, close the gaps on subdomains and spare domains, and know which attacks need other controls.

Can someone send email as your domain?

Yes, unless you publish records that let receivers detect it. Email was designed without sender verification, so the From address is just text. Three standards fix that:

• SPF lists the servers allowed to send for a domain in the envelope (bounce) address.
• DKIM adds a cryptographic signature that names the signing domain.
• DMARC ties them to the From address people see, and tells receivers what to do when neither SPF nor DKIM passes for that domain.

A message passes DMARC "if one or both of the described SPF or DKIM checks pass", and fails only if both fail (Microsoft Learn). Without a DMARC policy at quarantine or reject, receivers fall back on their own judgment.

CISA's joint phishing guidance tells organizations to "ensure DMARC is set to 'reject' for sent emails", which it says "provides robust protection against other users receiving emails that impersonate a domain" (CISA, NSA, FBI, MS-ISAC, 2023). In our scan of the Tranco top 1,000 domains in October 2026, 38.3% didn't enforce DMARC. Check yours in seconds with the DMARC Checker.

How do you stop email spoofing, step by step?

1. Find every legitimate sender

List each service that sends with your domain in the From address: Microsoft 365 or Google Workspace, your marketing platform, CRM, help desk, invoicing, website forms, copiers. You can't enforce DMARC safely until each one authenticates.

2. Set up SPF

Publish one SPF record that includes every sending service, within the 10-DNS-lookup limit. Use the SPF Checker to count lookups, and our SPF syntax examples for the format.

3. Turn on DKIM with your own domain

DKIM is what keeps DMARC passing when SPF can't, for example after forwarding. Each service must sign with your domain, not its own. See DKIM setup for Microsoft 365 and Google Workspace and verify each selector with the DKIM Checker.

4. Publish DMARC at p=none with reports

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Google recommends starting with the policy set to none, then over time changing it to quarantine or reject (Google Workspace Admin Help). Build the record with the DMARC Record Generator.

5. Read the reports and fix failures

Aggregate reports list every IP that sent mail as your domain and whether it passed. RFC 9989 says legitimate streams that fail DMARC must be addressed before you enforce, and that this "may take many months" for complex domains (RFC 9989, sections 5.1.6 and 5.1.7). The DMARC Report Analyzer reads the XML in your browser, and how to read DMARC reports explains the fields.

6. Move to quarantine, then reject

When every legitimate source passes, raise the policy. Microsoft recommends a gradual approach with the goal of "a p=reject DMARC policy for all of your custom domains and subdomains" (Microsoft Learn). Our staged rollout from p=none to p=reject has a timeline and rollback plan.

One change to know about: RFC 9989, published in 2026, removed the pct tag. In its place, t=y flags that you're testing: receivers shouldn't apply your policy as published, and you can expect failing mail to be treated one level lower. Microsoft's documentation still shows pct examples, and some receivers may still read it, but don't rely on percentages for a gradual rollout.

7. Keep monitoring

Every new tool someone signs up for is a new sender. Keep the rua address and review reports regularly, especially after any change to your mail setup.

Should SPF end in -all or ~all?

SPF's last term says what to do with servers you haven't listed. RFC 7208 defines -all (fail) as "an explicit statement that the client is not authorized", and ~all (softfail) as "a weak statement" that the host is probably not authorized.

DMARC treats both -all and ~all as an SPF failure. But Microsoft says your DMARC policy is "effectively ignored for SPF ~all failures if the messages don't also contain DKIM signatures", so make sure every sender signs with DKIM. Microsoft recommends -all for Microsoft 365 domains that also use DKIM and DMARC, and v=spf1 -all for parked domains (Microsoft Learn). With DKIM on every sender, the real protection comes from the DMARC policy, not the SPF ending. Our guide to SPF softfail vs hardfail covers why Microsoft, Google and M3AAWG advise differently.

How do you protect subdomains and unused domains?

Attackers don't need your main domain. billing.example.com or an old domain you bought for a rebrand works just as well if nobody protected it.

Subdomains

Microsoft notes that, unlike SPF and DKIM, a domain's DMARC record "automatically covers all subdomains (including nonexistent subdomains)" that don't have their own record. RFC 9989 adds two tags:

• sp= sets the policy for subdomains that exist.
• np= sets the policy for subdomains that don't exist, a common choice for attackers.

If you leave them out, np= falls back to sp= (or p= when there's no sp=), and sp= falls back to p=. If your main domain is at p=reject, made-up subdomains are covered too. See DMARC subdomain policy for examples.

Parked and unused domains

A domain that never sends mail should say so. Microsoft's recommended DMARC record for parked domains is v=DMARC1; p=reject;, and its SPF guidance gives v=spf1 -all for the same domains. A full setup looks like this:

example.net.          MX   0 .
example.net.          TXT  "v=spf1 -all"
_dmarc.example.net.   TXT  "v=DMARC1; p=reject;"

The Null MX line says the domain accepts no mail. Protecting parked domains covers wildcards and bulk management. The UK NCSC's advice is simple: "You should protect all of your organisation's domains" (NCSC).

Is BIMI worth adding?

BIMI shows your logo next to authenticated mail in supporting inboxes. It doesn't block anything by itself, but it requires DMARC at quarantine or reject, so it can be a reward at the end of the rollout. It's optional. See BIMI explained for costs and requirements.

What can't DMARC stop?

DMARC protects one thing: the exact domain in the From address. RFC 9989 is explicit that "it does not address the use of visually similar domain names or abuse of the RFC5322.From human-readable display name" (RFC 9989, section 2.2).

Two more points trip people up.

Your DMARC protects other people's inboxes. It tells receivers how to treat mail claiming to be from you. What arrives in your own users' inboxes depends on your inbound filter. If forged mail "from" your domain still reaches your staff, check that your filter checks DMARC and blocks inbound mail claiming to be from your own domain unless it comes from your own servers.

Not every receiver honors your policy. Microsoft 365, for example, has an "Honor DMARC record policy" setting in anti-phishing policies that controls what it does with mail failing your policy. Enforcement is widely respected, but it's a signal, not a guarantee.

For the wider picture of spoofing types, see what email spoofing is.

How do you know if your domain is being spoofed?

• DMARC aggregate reports show IPs you don't recognize sending as your domain. At p=reject, those rows should show the mail rejected.
• Bounces you didn't cause. A flood of non-delivery reports for mail you never sent usually means someone forged your address. See backscatter spam.
• Customers or suppliers forwarding odd mail. Ask for the original with full headers, and run them through the Email Header Analyzer to see whether the message passed DMARC and where it came from.

Next steps

1. Check your domain's SPF, DKIM and DMARC in one scan with the free Email Health Check.
2. Publish DMARC at p=none with a reporting address today, if you haven't already.
3. List your sending services, fix each one that fails in the reports, then plan your move to p=reject.
4. Add p=reject records to every domain you own that doesn't send mail.
5. For attacks DMARC can't stop, put inbound filtering with impersonation checks in front of your mailboxes. iBlockSpam filters at the MX with spoofing protection and allow and block lists that can require sender verification.

Related: someone is sending email from my address covers what to do when it's already happening. If you use iBlockSpam, DMARC monitoring shows likely spoofing of your domain in your reports, and Lookalike Domain Watch alerts you when a similar-looking domain is registered.

Browse our other SPF, DKIM and DMARC guides.