Why Microsoft 365 Email Filtering Still Misses Spoofed Invoices

Your Microsoft 365 spam filter is running. Your SPF record is correct. Your DKIM signature verifies. And someone still sends a spoofed invoice to your finance team from your own domain name. Microsoft 365 delivered it.

This is not a configuration error on your end. It is a gap in how Microsoft 365 built-in filtering works, and you cannot close it from inside the Microsoft 365 admin center.

What Microsoft 365 Built-in Filtering Actually Checks

Microsoft 365 anti-spam filters evaluate two authentication signals: SPF and DKIM.

SPF verifies that the sending mail server IP is allowed to send for the envelope-from domain (the address used in the SMTP transaction, also called Return-Path).

DKIM verifies a cryptographic signature on the message header. The signature covers specific headers and is tied to the selector domain chosen by the sending organization.

Both checks happen against the envelope domain, not the address your employees see in their email client.

Why SPF and DKIM Passing Does Not Mean the Email Is Legitimate

Here is the part that trips up most IT admins.

When an attacker sends a spoofed invoice, they control the sending server. They have valid SPF for their own server. They have a valid DKIM key for their own domain. Microsoft 365 sees SPF pass, DKIM pass, and treats the message as authenticated.

The From header -- the address recipients see, the one that says who the email is from -- is never verified to match the Return-Path domain during standard Microsoft 365 delivery.

Microsoft 365 anti-phishing does include models that analyze sender behavior, link reputation, and other signals, and it applies From-header checks for internal messages within the same organization. For external senders, however, the built-in filter relies primarily on SPF and DKIM passing against the envelope domain.

How a Spoofed Invoice Bypasses Microsoft 365 Filters

The attack works like this:

The attacker obtains a list of target domains -- often scraped from your website, LinkedIn, or a vendor database.
The attacker configures a mail server they control. SPF passes for their server. DKIM is signed with their key.
The attacker sets the From header to match your domain: invoices@yourcompany.com.
The Return-Path header is set to the attacker's own domain -- this is what SPF validates against.
Microsoft 365 receives the message, checks SPF against the attacker's server (pass), checks DKIM against the attacker's domain (pass).
Microsoft 365 delivers the message to your finance team's inbox because both authentication checks passed.

Your employees see an email from invoices@yourcompany.com. Microsoft 365 sees a validly authenticated message from an external server. There is no conflict from Microsoft's perspective.

What Microsoft 365 Anti-Phishing Does and Does Not Catch

Microsoft Defender for Office 365 adds behavioral and reputation-based analysis on top of SPF and DKIM. These models are effective against high-volume phishing campaigns, credential harvesting pages, and known malicious senders.

They are less reliable against targeted spoofing of your specific domain, especially when the attacker uses a freshly registered domain with clean reputation. The machine learning models need patterns to learn from. A low-volume, targeted campaign using a clean domain does not trigger those patterns.

The gap is structural. Microsoft 365 cannot tell the difference between a legitimate email from a third-party service that sends from its own infrastructure and a targeted spoofing attempt using the same setup. Both look like authenticated external mail.

How DMARC Closes the Gap Microsoft 365 Leaves Open

DMARC adds one check that SPF and DKIM do not perform: it verifies that the domain in the From header aligns with the domain verified by SPF or DKIM.

DMARC alignment means either:

The domain in the From header matches the domain the SPF check was performed against (SPF alignment), or
The domain in the From header matches the domain in the DKIM signature (DKIM alignment).

When neither alignment holds, DMARC fails -- regardless of whether SPF and DKIM individually passed.

This is what catches spoofed invoices. The attacker's SPF and DKIM pass for their own domain. But when the From header claims to be from yourcompany.com, and neither SPF nor DKIM validated that domain, DMARC alignment fails.

With a p=quarantine policy, the receiving server routes suspicious messages to junk. With p=reject, it refuses delivery outright. Neither policy relies on Microsoft 365's built-in anti-spoofing -- it is enforced at the protocol level.

FAQ

Does Microsoft 365 check the From header for spoofing? For internal messages (same domain sender and recipient), Microsoft 365 applies From-header checks. For external senders, the built-in filter relies primarily on SPF and DKIM against the envelope domain. Microsoft Defender adds behavioral analysis on top, but this is less reliable for targeted low-volume spoofing campaigns.

My SPF and DKIM pass but I still get spoofed emails. Why? SPF and DKIM passing means the sending server is authorized for its own domain and the DKIM signature is valid for the selector domain. Neither check compares the From header to the authenticated domain. If the From header claims a different domain than the one validated by SPF or DKIM, both can pass while the message is still a spoof.

What is the difference between Return-Path and From in email authentication? Return-Path (also called Envelope-From) is the address used during SMTP delivery. It is what SPF validates against and where bounce messages are sent. From is the header address recipients see in their email client. DMARC alignment is the mechanism that links these two: it checks whether the From domain matches the domain validated by SPF or DKIM.

Can Microsoft Defender catch spoofed invoices without DMARC? Microsoft Defender anti-phishing adds behavioral and reputation-based analysis. For targeted, low-volume spoofing using freshly registered domains, these models are less reliable. DMARC is the only standard mechanism that directly answers: is the From header domain authorized by the domain that actually sent this message?

Will implementing DMARC affect my legitimate email deliverability? If you publish p=none, there is no effect -- you are only receiving reports. When you move to p=quarantine or p=reject, legitimate mail that fails DMARC alignment (such as messages forwarded without proper configuration, or emails from certain third-party senders using your From domain without proper DKIM) may be affected. This is why moving to enforcement gradually and reviewing aggregate reports before each step is the recommended approach. Most organizations with properly configured email infrastructure see no disruption when moving to p=reject.

How does DMARC p=quarantine compare to p=reject for stopping spoofing? p=quarantine routes failing messages to the recipient's spam folder. p=reject refuses delivery at the MTA level -- the message does not reach the recipient's mailbox at all. p=reject is more effective against spoofing but requires that you have resolved all legitimate mail issues first (forwarding, mailing lists, third-party senders using your From domain). p=quarantine is a safer intermediate step that still blocks most spoofing attempts while giving you room to fix false positives.

What Microsoft 365 Admins Can Do Right Now

Step 1: Check whether you have a DMARC record. Query your domain in any DNS lookup tool:

dig TXT _dmarc.yourdomain.com TXT

If nothing returns, you do not have a DMARC record. That is the gap.

Step 2: Publish a monitoring record. Start with p=none to collect aggregate reports:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

This tells receiving servers to send you XML reports about messages claiming to be from your domain. You will see both legitimate mail and spoofing attempts.

Step 3: Review your aggregate reports. Aggregate DMARC reports are verbose XML. Parsing them manually to find alignment failures is time-consuming and error-prone, especially across multiple domains. DMARCFlow parses these reports automatically, surfaces alignment failures in a readable dashboard, and alerts you when your domain is being spoofed -- so you do not have to manually decode XML to know something is wrong.

Step 4: Move to p=quarantine once you understand your legitimate mail patterns. This tells receiving servers to junk messages that fail DMARC alignment. Legitimate mailing lists and forwarding services may break -- those are the sources to identify and resolve before moving further.

Step 5: Move to p=reject once forwarding and ESP issues are resolved. This is the full enforcement level. Any message failing DMARC alignment is refused at delivery.