How to Stop Someone Spoofing Your Email Domain

The direct fix for email domain spoofing

To reduce exact-domain spoofing, publish SPF, sign every real sender with DKIM, then enforce DMARC after your legitimate mail is aligned.

Spoofing happens when an attacker sends mail that appears to come from your domain. They might use your exact domain in the visible From address, or they might use a lookalike display name. You cannot stop every fake display name on the internet, but you can give participating mailbox providers a clear reason to distrust mail that claims to be from your domain and does not authenticate.

The control that matters most is DMARC. DMARC checks whether SPF or DKIM passed and whether the authenticated domain aligns with the visible From domain. Once your real senders are passing, a DMARC policy of p=quarantine or p=reject asks receivers to handle unauthenticated mail that uses your domain as suspicious or rejectable.

If you need the fastest starting point, run the free InboxRadar domain scorecard. It checks your live SPF, DKIM, DMARC, MX, and blocklist signals, then shows the record most likely to leave you exposed.

Step 1: list every legitimate sender

Do not start by copying a strict DMARC record from a blog post. Start by finding every system that sends mail with your domain in the From address.

That list usually includes Google Workspace or Microsoft 365, your website, product notifications, billing receipts, support desk, CRM, recruiting tools, newsletter software, ecommerce platform, and any cold outbound system. If one of those services is missed, strict DMARC can block real mail.

• Write down each sender, the From domain it uses, and whether it can sign DKIM with your domain.
• Check old systems too. A forgotten ticketing tool or billing platform is a common source of DMARC failures.
• Prefer vendor setups that use your own return-path or DKIM domain, because DMARC needs alignment with the visible From domain.
• Separate risky marketing or outbound streams onto subdomains when volume or complaint risk is meaningful.

Step 2: publish one correct SPF record

SPF tells receivers which servers are allowed to send for the envelope sender domain. It helps stop spoofing, but only when it is complete and aligned.

An SPF record is a DNS TXT record that starts with v=spf1. It can include IP addresses and provider includes, then it usually ends with ~all or -all. Use ~all while you are still discovering legitimate senders. Move to -all only when the sender list is complete, and do not treat SPF hard fail as a substitute for DMARC enforcement.

SPF has a hard operational limit: RFC 7208 requires SPF implementations to limit DNS-querying mechanisms and modifiers to 10 during one SPF check. Includes, redirects, a, mx, ptr, and exists count toward that limit, including nested lookups. If you exceed it, receivers must return an SPF permanent error, and DMARC may fail when DKIM is missing or not aligned.

• Publish only one SPF TXT record for each sending domain. Multiple SPF records cause failure.
• Include every authorized sender, but remove stale providers that no longer send for you.
• Never use +all. It authorizes everyone and defeats SPF.
• Keep SPF under the 10 lookup limit. Flattening can help, but stale flattened IPs create their own risk.

Step 3: turn on DKIM everywhere

DKIM signs messages with a private key controlled by your sending service. Receivers verify the signature with a public key you publish in DNS.

DKIM uses selectors, such as selector1._domainkey.example.com, so one domain can publish different keys for different providers. Each real sender should sign with a DKIM domain that aligns with your visible From domain when the provider supports it. This matters because SPF often breaks during forwarding, while a valid aligned DKIM signature can still let DMARC pass.

Use each provider's exact DNS record. Do not edit the key by hand. Google says mail to personal Gmail accounts requires a DKIM key of at least 1024 bits, and recommends 2048 bits when your DNS host supports it. Microsoft also treats DKIM as one of the core authentication records for sender identity.

• Enable DKIM in your mailbox provider, email service provider, billing system, support desk, and app mailer.
• Publish each selector record exactly as provided.
• Rotate keys deliberately, and leave the old selector in place until old signed mail is unlikely to be checked again.
• Remove selectors for vendors that no longer send for you.

Step 4: add DMARC, then enforce it

DMARC is the policy layer that tells receivers how you want mail handled when it fails aligned authentication.

A DMARC record lives at _dmarc.yourdomain.com. It starts with v=DMARC1 and has a policy: p=none, p=quarantine, or p=reject. p=none gives no special handling instruction and is used for monitoring. p=quarantine asks receivers to treat failures as suspicious, often by putting them in spam. p=reject asks receivers to reject failing mail, but final disposition is still controlled by each receiver's local policy.

Start with a reporting address, for example rua=mailto:dmarc@example.com. Aggregate DMARC reports show which sources are sending as your domain and whether SPF, DKIM, and DMARC passed. They are XML and can be noisy, but they are the cleanest way to tighten policy without breaking real mail.

• Publish p=none first unless you already know every real sender passes aligned SPF or DKIM.
• Review rua reports for at least a normal sending cycle, including invoices, password resets, support replies, and marketing sends.
• Fix each legitimate source until SPF or DKIM passes and aligns with the From domain.
• Move to p=quarantine, then p=reject when the reports are clean.
• Use the pct tag if you need to roll enforcement out gradually.

What Gmail and Outlook actually do

Mailbox providers do not promise inbox placement just because SPF, DKIM, and DMARC pass. Authentication proves identity, not message quality.

Google's sender guidelines say all senders to personal Gmail accounts must use SPF or DKIM, and bulk senders must use SPF, DKIM, and DMARC. Google also says unauthenticated mail can be marked as spam or rejected, and direct mail needs From-domain alignment with either SPF or DKIM to pass DMARC alignment.

Microsoft's Outlook.com guidance for high-volume senders says domains sending more than 5,000 messages per day to Outlook.com consumer accounts must publish SPF and DKIM records, publish DMARC, and have messages pass DMARC with at least one aligned SPF or DKIM result. Microsoft 365 also uses sender reputation, sender history, recipient history, behavioral analysis, and other signals when it evaluates inbound mail.

So the right goal is not just to publish records. The goal is to make your real mail pass authentication at the providers receiving it, then keep reputation clean enough that authenticated mail is wanted.

Do not skip MX, blocklists, and drift

SPF, DKIM, and DMARC handle domain identity, but spoofing cleanup often exposes other deliverability problems.

MX records tell the internet where inbound mail for your domain should go. Broken MX records do not normally authenticate outbound mail, but they can break replies, verification loops, abuse mailboxes, and DMARC reporting. A serious sending domain should be able to receive mail unless there is a deliberate reason it cannot.

Blocklists can also matter. A listed IP or domain does not guarantee every message goes to spam, but it can explain sudden filtering after a compromised account, a bad list, or a burst of complaints. Fix authentication first, then investigate the listing reason before asking for removal.

DNS drift is the quiet failure. A vendor rotates a DKIM selector, someone removes an SPF include, a migration creates two SPF records, or a marketing tool starts sending from a shared return-path. That is why a one-time setup is not enough. Use InboxRadar to check the domain now, and keep watching for changes that reopen the spoofing gap.

Safe setup checklist

Use this order if you want to stop spoofing without blocking your own invoices, password resets, support replies, or sales mail.

• Inventory every sender that uses your domain in the visible From address.
• Publish one SPF record, cover every sender, avoid +all, and stay under the 10 lookup limit from RFC 7208.
• Turn on DKIM for every sender and publish each selector record.
• Add DMARC with p=none and a working rua reporting address.
• Confirm each source passes either SPF or DKIM with alignment.
• Move DMARC to p=quarantine once failures are understood.
• Move to p=reject when legitimate mail is clean and reports show unknown senders are the main failures.
• Check MX records, blocklists, and domain monitoring so the setup does not drift later.

For source details, use RFC 7208 for SPF, RFC 6376 for DKIM, RFC 7489 for DMARC, the Google sender guidelines, and Microsoft Outlook sender guidance. For related basics, see the InboxRadar guides.