How does spoof intelligence work in Microsoft 365?

Spoofing is when a message claims to come from a domain it didn't come from. Microsoft 365 checks every inbound message for it, and most of the time you never notice. You notice when it goes wrong: a supplier's invoices land in Junk with a question mark on the sender's photo, or your own payroll system gets flagged as a spoof of your domain. This guide explains how Microsoft decides, where to review its decisions, and how to make safe exceptions.

What is spoof intelligence?

Microsoft's anti-spoofing checks focus on the From header, the address people see. Microsoft says that when it "has high confidence the From header is forged, the message is identified as spoofed" (Microsoft Learn). This is available in every organization with cloud mailboxes, and spoof intelligence is turned on by default.

Microsoft describes three layers:

1. Composite authentication combines SPF, DKIM and DMARC into one verdict.
2. Spoof intelligence evaluates the sender's legitimacy "based on mail-flow patterns and sender-infrastructure history."
3. The anti-phishing policy decides the action for messages spoof intelligence flags as suspicious: Junk Email or quarantine.

So the flow is: if composite authentication passes, the message is delivered normally. If it fails, spoof intelligence looks at the sender. A sender it judges legitimate is delivered; a suspicious one gets the policy action. Microsoft repeats this point: "a composite authentication failure doesn't automatically block a message."

Spoofing is different from impersonation. A spoof uses your real domain, or a partner's. Impersonation uses a lookalike, like contos0.com, or a familiar display name on a free mailbox. Impersonation protection lives in Defender for Office 365; see anti-phishing policy settings and display name spoofing.

How does composite authentication decide?

Microsoft adds compauth= and a three-digit reason= to the Authentication-Results header of every inbound message. The message header reference says Microsoft 365 combines "multiple types of authentication (SPF, DKIM, and DMARC) and other parts of the message," using the From domain as the basis.

There are two kinds of failure:

• Explicit: the sender publishes DMARC with p=quarantine or p=reject, and the message fails it.
• Implicit: the sender has no records, or weak ones. Microsoft's email authentication overview says it extends normal checks with sender reputation, sender history, recipient history and behavioral analysis, so a domain with no DMARC isn't automatically trusted or blocked.

The reason codes you'll see most often when troubleshooting spoofing:

The X-Forefront-Antispam-Report header adds CAT:SPOOF and a safety level. Microsoft uses SFTY:9.11 for intra-org spoofing and SFTY:9.22 for cross-domain spoofing. Every other code is in our guide to Microsoft 365 spam headers.

If you see 905 on all your inbound mail, you probably have a gateway in front of Microsoft 365 without Enhanced Filtering for Connectors. Until you fix that, spoof checks see the gateway as the sender, not the original source.

Where is the spoof intelligence insight?

1. In the Microsoft Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Tenant Allow/Block Lists (in the Rules section).
2. Select the Spoofed senders tab. The insight sits at the top.
3. Select View spoofing activity to open the Spoof intelligence insight page (https://security.microsoft.com/spoofintelligence).

The insight covers seven days of data. If spoof intelligence is turned off, it runs in "what if" mode and shows what it would have caught. In Exchange Online PowerShell, Get-SpoofIntelligenceInsight returns 30 days.

The columns, per Microsoft Learn:

Two limits matter. The Action column refers to spoof detection only, so an "Allowed" pair can still be filtered as spam or phishing for other reasons. And the insight doesn't show messages that failed DMARC with p=quarantine or p=reject. Those follow the Honor DMARC record policy setting in your anti-phishing policy instead.

How do you allow or block a spoofed sender pair?

Exceptions are always a pair: the spoofed domain plus the infrastructure sending it. Microsoft's example is allowing gmail.com from tms.mx.com. "Other senders attempting to spoof gmail.com aren't automatically allowed," and other domains sent from tms.mx.com are still checked.

From the insight

1. On the Spoof intelligence insight page, select one or more rows.
2. Select Bulk actions, then Allow to spoof or Block from spoofing, then Apply.
3. The entry leaves the insight and appears on the Spoofed senders tab of the Tenant Allow/Block List.

Manually, before Microsoft detects it

1. On the Spoofed senders tab, select Add.
2. In Add domain pairs with wildcards, enter up to 20 pairs, one per line, as <spoofed user>, <sending infrastructure>.
3. Choose Spoof type (Internal or External) and Action (Allow or Block), then Add.

Or in PowerShell:

New-TenantAllowBlockListSpoofItems -Identity Default -Action Allow `
  -SpoofedUser billing.example -SendingInfrastructure mailer.example -SpoofType External

Domain pair rules

From the Tenant Allow/Block List documentation:

• Spoofed user can be an email address, a domain or *.
• Sending infrastructure can be the PTR domain, <source IP>/24 when there's no PTR, a verified DKIM domain, or *.
• You can use a wildcard on one side, not both. *, * isn't allowed.
• A PTR-based entry must match the PTR in Authentication-Results. Microsoft recommends the PTR's organizational domain (contoso.com, not smtp.inbound.contoso.com), and an IP/24 entry if PTR lookups fail. Our PTR Lookup shows what a sending IP resolves to.
• Up to 1,024 spoofed sender entries in total, allow and block combined.
• Spoofed sender entries never expire, and new entries should be active within five minutes.

Block entries mark matching mail as phishing, and the anti-spam policy's Phishing action decides what happens next. Submitting a message that spoof intelligence blocked as I've confirmed it's clean on the Submissions page also creates an allow entry.

What do the "?" and "via" indicators mean?

These are the unauthenticated sender indicators in Outlook, configured in the Safety tips & indicators section of each anti-phishing policy. Both are on by default, and only available while spoof intelligence is on (Microsoft Learn).

Allowing the spoofed sender pair also suppresses the via tag, even with Show "via" tag turned on. Teach staff that a question mark isn't proof of fraud, just a sign the sender didn't prove who it is. Our guide to spotting a phishing email covers what else to check.

Should you allow the pair or fix the sender?

Microsoft's own example is the most common case. A partner sends through a marketing platform. The From address is sender@fabrikam.com, but SPF and DKIM pass for the platform's domain, adatum.com. Neither aligns with the From domain, so DMARC fails and compauth fails.

Microsoft's advice splits it in two:

• Short term: allow the spoofed sender pair, From domain plus the platform's infrastructure.
• Long term: ask the partner to sign with DKIM for its own domain, add the platform to SPF, or use a subdomain such as marketing.fabrikam.com with aligned records.

The same applies to your own domain. If a payroll or ticketing system sends as you and gets reason=601 or 010, set up DKIM for that service rather than allowing yourdomain.com, *. A pair with a wildcard as the sending infrastructure lets anyone, from any server, spoof your domain to your own staff.

Mailing lists that rewrite subjects or add footers also break authentication. Microsoft suggests ARC support on the list server, asking the list owner to authenticate, or an allow entry. Our guide to DMARC and mailing lists has the detail.

How should you review spoofing regularly?

This review routine is our recommendation; Microsoft doesn't set a schedule.

1. Once a week, open the spoof intelligence insight and filter Spoof type to Internal. Every internal row is a system sending as your domain. Confirm each one is yours.
2. Check the Spoof detections report for trends.
3. Review the Spoofed senders tab quarterly and delete pairs for services you've stopped using. Entries don't expire on their own.
4. For each allowed pair, ask the sender to fix authentication, then remove the exception.
5. Check your own domain's records with the DMARC Checker, so the mail you send arrives with compauth=pass elsewhere.

Next steps

• Paste a flagged message's headers into the Email Header Analyzer and read compauth, reason and CAT.
• Make sure Honor DMARC record policy is on, and decide whether spoof detections go to Junk or quarantine. Our guide to stopping phishing in Microsoft 365 covers the policy side.
• If spoofers use your own domain, publish an enforcing DMARC policy. See how to stop email spoofing of your domain.
• If a filtering gateway sits in front of Microsoft 365, confirm Enhanced Filtering is on so spoof intelligence sees the real sender. iBlockSpam's Microsoft 365 setup includes that step.