7 Ways to Prevent Email Spoofing and Protect Your Brand

To prevent email spoofing, give every service that sends as your domain working SPF and DKIM, move DMARC to quarantine or reject, and lock down domains you never send from. Then cover what authentication can't: lookalike domains, hijacked mailboxes and fake payment requests, with monitoring, phishing-resistant sign-in and phone call-backs.

Key takeaways

• SPF, DKIM and DMARC at p=quarantine or p=reject tell receiving mail systems to junk or reject mail that forges your exact domain in the From address.
• Domains you don't use for email need an SPF record of v=spf1 -all, a DMARC record with p=reject and, if they never receive mail, a null MX record.
• Authentication can't stop lookalike domains or a criminal signed in to a real mailbox. Those need monitoring, phishing-resistant MFA and out-of-band payment checks.
• BIMI shows your logo only after DMARC enforcement, and MTA-STS protects mail in transit. Neither one blocks spoofing on its own.

What is email spoofing, and which defenses stop it?

Microsoft defines spoofing as an attacker forging the sender's address or domain in the From address so a message looks like it came from a trusted source. Impersonation is its close cousin: the attacker uses a domain or name that only looks like yours, such as ćóntoso.com instead of contoso.com. The difference matters, because the fixes are different.

Two 2026 cases show why. In its Q2 2026 email threat report, Microsoft described an automated business email compromise (BEC) campaign that reached more than 67,000 users at more than 42,000 organizations in under three hours. Its messages were sent from a DKIM-configured domain, so they passed SPF and achieved DKIM alignment. And on September 16, 2026, Georgia's Attorney General announced a sentence in a case where an agricultural business wired $158,000 in 2021 after payment requests arrived from an email address nearly identical to its strawberry-seed supplier's. Neither attack forged the exact domain it was imitating, so DMARC on that domain couldn't have stopped it.

What are the 7 ways to prevent email spoofing?

1. Authenticate every sender with SPF and DKIM

SPF lists the servers allowed to send for your domain. DKIM adds a cryptographic signature that receivers check against a public key in your DNS. Microsoft's guidance boils down to a few rules: publish one SPF record per domain or subdomain, keep it within 10 DNS lookups, and set up DKIM signing with your own domain on every service so it can align with your From address. Where your provider offers a choice, pick a 2048-bit DKIM key. Start with a complete list of senders, including marketing, invoicing, CRM and help-desk tools.

2. Move DMARC to enforcement

DMARC ties SPF and DKIM to the From address people see and tells receivers what to do when a message fails. Only p=quarantine and p=reject ask receivers to act on forged mail; p=none is for monitoring. The safe route is to start at p=none with a reporting address, fix every legitimate sender the reports reveal, then step up. Our DMARC setup guide walks through each step, including the May 2026 update to the standard (RFC 9989), which retired the pct tag.

3. Lock down domains that never send email

Every domain you own can be spoofed, including parked domains. For a domain that sends no mail, publish these records (shown for example.org, a domain reserved for documentation; substitute your parked domain):

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

The SPF record says no server may send for the domain, and Microsoft recommends both the SPF and DMARC records above for parked domains. Because a DMARC record also covers subdomains without their own record, it protects made-up subdomains too. The last line is a "null MX" record, defined in RFC 7505: a single MX record with preference 0 and a lone dot, which declares that the domain accepts no email, so delivery attempts fail immediately. Only add null MX to a domain that truly never receives mail.

In Microsoft 365, also protect the *.onmicrosoft.com domain if you don't send from it. Microsoft manages that domain's SPF record, so you add only the DMARC record, in the Microsoft 365 admin center.

4. Add BIMI once you're at enforcement

BIMI (Brand Indicators for Message Identification) lets supporting mailbox providers show your logo next to authenticated mail. It rewards enforcement; it doesn't block anything itself. Google's requirements for Gmail are specific:

• Your DMARC policy must be p=quarantine or p=reject and apply to 100% of mail. p=none isn't supported.
• Your logo must be backed by a mark certificate: a Verified Mark Certificate (VMC), which requires a registered trademark, or a Common Mark Certificate (CMC), which Google describes as the option for logos that aren't trademarked.

Each mailbox provider sets its own rules, so check the current requirements for the ones your customers use. Our BIMI guide covers the logo file and DNS record.

5. Watch for lookalike domains and register the obvious ones

A lookalike domain is a different, real domain, so it can pass SPF, DKIM and DMARC with its own records. Microsoft says exactly that about impersonation. Three habits help:

• Monitor for newly registered domains that resemble your name, and your key suppliers' names if you pay them regularly.
• Filter. Some email security tools flag lookalikes. Microsoft Defender for Office 365, for example, includes user and domain impersonation protection that looks for similar domains, such as a different top-level domain or a slightly altered spelling.
• Register defensively the most obvious typos and extensions of your name, then lock them down as in step 3. You can't register every variation, so this supports monitoring rather than replacing it.

6. Verify payment changes out of band, and make reporting easy

Business email compromise typically ends with a request to move money. Microsoft's BEC guidance is to pause and use a phone call to verify financial requests, to contact people directly rather than using contact details from the suspicious message, and to set clear policies for how accounting, payroll and HR handle changes to bank or payment details. A written rule makes "I need to call you back" routine instead of awkward:

1. New or changed bank details are confirmed by phone, using a number you already had on file, before any payment.
2. Urgent or confidential payment requests from executives get the same call-back, with no exceptions.
3. A second person approves the first payment to any new account.

Train staff to spot a display name that doesn't match the actual address. Microsoft listed that mismatch as a red flag in its September 2026 analysis of an executive-impersonation invoice scam. Give staff a one-click way to report: in Outlook, the built-in Report button can send suspected phishing to a reporting mailbox, to Microsoft, or both. If money has already gone, Microsoft's advice is to contact your bank immediately to try to halt or reverse the payment.

7. Stop mailbox takeover with phishing-resistant MFA

When criminals sign in to a real account, their emails come from your own systems and pass SPF, DKIM and DMARC. Microsoft notes that attackers often use a compromised mailbox to send mail inside and outside the organization. It also warns that traditional MFA, such as SMS codes, email one-time codes and authenticator apps, is prone to phishing, and recommends phishing-resistant methods instead: passkeys and FIDO2 security keys, Windows Hello for Business, and certificate-based authentication. A passkey only works with the site it was registered for, so a fake login page can't use it.

Microsoft is pushing the same way: Microsoft Entra ID began making passkeys the default sign-in experience on September 1, 2026, and Microsoft plans to retire its built-in SMS and voice MFA for most users on February 1, 2027. Start with admins, executives and anyone who can approve payments.

Do MTA-STS and TLS-RPT stop spoofing?

No, and it's a common mix-up. MTA-STS lets your domain require mail servers that support it to use TLS encryption, and to check that your server has a valid certificate, when they deliver mail to you. According to Microsoft, that protects against man-in-the-middle and downgrade attacks on mail in transit. TLS-RPT sends you reports about problems with those encrypted connections. Both are worth setting up, but neither checks who wrote a message or stops someone forging your domain.

Do Google, Yahoo and Microsoft require any of this?

Yes, for bulk senders, although the minimum is well below real protection. Google's sender rules, in force since February 2024, require anyone sending more than 5,000 messages a day to Gmail accounts to set up SPF, DKIM and DMARC, and p=none is accepted. Yahoo requires bulk senders to use SPF and DKIM and publish a DMARC policy of at least p=none. Microsoft requires domains sending more than 5,000 messages a day to Outlook.com to have SPF, DKIM, and DMARC of at least p=none aligned with SPF or DKIM. Its announcement said non-compliant mail would go to Junk from May 5, 2025; bounce messages that senders have since posted on Microsoft's Q&A forum show some of that mail being rejected outright, with error code 550 5.7.515. Our post on Microsoft's bulk sender requirements has more detail.

Meeting those rules keeps your mail flowing. Stopping spoofing takes enforcement.

What should you do this week?

1. Scan your domain with our free domain scanner to see your SPF, DKIM and DMARC status.
2. List every sender and turn on DKIM with your domain for each one.
3. Publish or tighten DMARC. If you have no record, start at p=none with a reporting address. If you've sat at p=none for months, plan the move to p=quarantine.
4. Lock down parked domains with the three records above.
5. Write the call-back rule for bank-detail changes and share it with everyone who approves payments.
6. Roll out phishing-resistant MFA, starting with admins, executives and finance staff.
7. Turn on the Report button and tell staff who reviews the reports.

If you'd like help with any of these steps, call us at (818) 574-8240.

Frequently asked questions

Can someone spoof my email address if I have an SPF record?

Yes. SPF checks the hidden envelope (bounce) address, not the From address people see, so a message can forge your From address while passing SPF for a different domain. DMARC closes that gap by requiring an SPF or DKIM pass that aligns with your From domain, and it asks receivers to act on failures only at p=quarantine or p=reject.

Does DMARC stop lookalike domains?

No. A lookalike, such as a misspelled version of your name, is a separate domain, and it can pass SPF, DKIM and DMARC with its own records. Microsoft makes the same point about impersonation. To reduce the risk, monitor for lookalikes, register the most obvious ones, use impersonation filtering where you have it, and verify payment requests by phone.

Does BIMI prevent spoofing?

Not by itself. BIMI displays your logo in supporting inboxes, and Gmail only shows it when your DMARC policy is p=quarantine or p=reject and your logo is backed by a Verified Mark Certificate or Common Mark Certificate. The spoofing protection comes from DMARC enforcement; BIMI adds a visual cue for recipients who know to look for it.

Is MTA-STS an anti-spoofing control?

No. MTA-STS tells sending servers that support it to use TLS encryption and check your mail server's certificate when they deliver mail to your domain, which protects messages in transit from interception and downgrade attacks. It doesn't verify who sent a message. Use SPF, DKIM and DMARC against spoofing, and MTA-STS with TLS-RPT for transport security.

What should we do if we already paid a fake invoice?

Call your bank immediately and ask it to halt or reverse the transfer; Microsoft's guidance stresses acting fast. Then change the password of any mailbox that may be compromised, look for new mail-forwarding rules, which attackers often use, report the fraud to law enforcement, and warn the real supplier so they can alert their other customers.

Sources

1. Microsoft Learn — Anti-phishing policies in cloud organizations (reference documentation, undated)
2. Microsoft Learn — Impersonation insight in Defender for Office 365 (reference documentation, undated)
3. Microsoft Learn — Set up SPF to identify valid email sources for your custom cloud domains (reference documentation, undated)
4. Microsoft Learn — Set up DMARC to validate the From address domain for cloud senders (reference documentation, undated)
5. Microsoft Learn — Email authentication in cloud organizations (reference documentation, undated)
6. RFC Editor — RFC 7505: A "Null MX" No Service Resource Record for Domains That Accept No Mail (June 2015)
7. RFC Editor — RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (May 2026)
8. Google Workspace Admin Help — Set up BIMI (help article, undated)
9. BIMI Group — Verified Mark Certificates (VMC) and BIMI (undated)
10. Google — Email sender guidelines (Gmail Help) (help article, undated)
11. Yahoo Sender Hub — Best practices (help article, undated)
12. Microsoft Tech Community — Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders (2025)
13. Microsoft Q&A — Why are emails I send to some Outlook email addresses being sent back undeliverable (forum thread, 2026)
14. Microsoft Security Insider — Shifting tactics fuel surge in business email compromise (May 19, 2023)
15. Microsoft Security — What is business email compromise (BEC)? (undated)
16. Microsoft Security Blog — Protecting organizations from AI-assisted executive impersonation and invoice fraud (September 10, 2026)
17. Microsoft Learn — Report phishing and suspicious emails in Outlook for admins (reference documentation, undated)
18. Microsoft Learn — Respond to a compromised cloud email account (reference documentation, undated)
19. Microsoft Learn — Microsoft Entra authentication overview (reference documentation, undated)
20. Microsoft Learn — Authentication methods in Microsoft Entra ID: passkeys (FIDO2) (reference documentation, undated)
21. Microsoft Learn — Passkeys by default and retirement of Microsoft-provided SMS and voice authentication (reference documentation, undated)
22. Microsoft Learn — Enhance mail flow with MTA-STS (reference documentation, undated)
23. Microsoft Learn — How SMTP DNS-based Authentication of Named Entities (DANE) works (reference documentation, undated)
24. Microsoft Security Blog — Email threat landscape: Q2 2026 trends and insights (July 23, 2026)
25. Georgia Office of the Attorney General — Carr: Decatur Woman Sentenced for Involvement in $158k Business Email Compromise Scam (September 16, 2026)
26. CBS News Atlanta — Decatur woman sentenced for role in $158,000 email scam targeting agriculture business, AG says (September 2026)
27. AgDaily — Georgia woman sentenced in $158K ag email scam (September 2026)
28. Microsoft Learn — Tune anti-phishing protection (reference documentation, undated)
29. Cloudflare Docs — Set up Google Workspace (reference documentation, undated)

Editor's note: This article was researched and written with AI assistance. Every factual claim was checked against the sources listed above; see our fact-check process for details.