# How does spoof intelligence work in Microsoft 365?

URL: https://iblockspam.com/blog/microsoft-365-spoof-intelligence
Last updated: 2026-10-10
Published: 2026-10-10
Topic: Setup guides
Author: iBlockSpam Team

> Use the Microsoft 365 spoof intelligence insight, allow or block spoofed sender pairs, read compauth reason codes and explain the ? and via tags in Outlook.

## Short answer

Spoof intelligence is Microsoft 365's check for mail whose From domain fails SPF, DKIM or DMARC. Microsoft combines those results into a composite verdict (compauth), then judges whether the sending infrastructure is legitimate. You review detections in the spoof intelligence insight and allow or block a specific pair of spoofed domain and sending infrastructure in the Tenant Allow/Block List.

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](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-protection-spoofing-about)). 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](https://iblockspam.com/blog/microsoft-365-anti-phishing-policy-settings) and [display name spoofing](https://iblockspam.com/blog/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](https://learn.microsoft.com/en-us/defender-office-365/message-headers-eop-mdo) 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](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-about) 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:

| compauth | Reason | What Microsoft says it means |
|---|---|---|
| fail | `000` | Explicit failure: DMARC failed and the policy is quarantine or reject |
| fail | `001` | Implicit failure: no records, or weak ones (`~all`, `?all`, `p=none`) |
| fail | `002` | Your organization explicitly blocked this sender/domain pair from spoofing |
| fail | `010` | DMARC failed with quarantine or reject, and the domain is one of your accepted domains |
| fail | `601` | The sending domain is one of your accepted domains (self-to-self spoofing) |
| pass | `1xx` | Passed explicit or implicit authentication, for example `100` for aligned SPF or DKIM |
| pass | `701`–`704` | DMARC not enforced because of a history of legitimate mail from that infrastructure |
| none | `905` | DMARC not enforced because of complex routing, such as a non-Microsoft service first |

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](https://iblockspam.com/blog/microsoft-365-spam-headers-explained).

If you see `905` on all your inbound mail, you probably have a gateway in front of Microsoft 365 without [Enhanced Filtering for Connectors](https://iblockspam.com/blog/microsoft-365-third-party-spam-filter-enhanced-filtering). 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](https://learn.microsoft.com/en-us/defender-office-365/anti-spoofing-spoof-intelligence):

| Column | What it shows |
|---|---|
| **Spoofed user** | The domain in the From address |
| **Sending infrastructure** | The PTR domain of the source IP; or the source IP as a /24 if there's no PTR; or a verified DKIM domain |
| **Message count** | Messages from that domain and infrastructure combination in the last seven days |
| **Last seen** | The last date a message arrived from that pair |
| **Spoof type** | **Internal** (one of your accepted domains) or **External** |
| **Action** | **Allowed** (failed explicit checks but passed implicit ones) or **Blocked** |

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:

```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](https://learn.microsoft.com/en-us/defender-office-365/tenant-allow-block-list-email-spoof-configure):

- **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](https://iblockspam.com/tools/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](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-policies-about)).

| Indicator | When Outlook shows it | How to make it go away |
|---|---|---|
| **?** on the sender's photo | The message doesn't pass SPF or DKIM **and** doesn't pass DMARC or composite authentication | The sender fixes SPF or DKIM, which Microsoft calls "the most important" here |
| **via** tag (`chris@contoso.com via fabrikam.com`) | The From domain differs from the DKIM signing domain or the MAIL FROM domain | The sender signs with DKIM for its own domain, or uses a MAIL FROM in the same domain |

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](https://iblockspam.com/blog/how-to-spot-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](https://iblockspam.com/blog/dkim-setup-microsoft-365-google-workspace) 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](https://iblockspam.com/blog/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](https://iblockspam.com/tools/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](https://iblockspam.com/tools/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](https://iblockspam.com/blog/stop-phishing-emails-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](https://iblockspam.com/blog/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](https://iblockspam.com/platforms/microsoft-365) includes that step.

## Frequently asked questions

### What is the difference between spoof intelligence and impersonation protection?

Spoof intelligence deals with forged From addresses that use the real domain, such as a message claiming to be from contoso.com that fails authentication. Impersonation protection looks for lookalikes, such as a similar domain or a familiar display name on a different address. Spoof intelligence is in every cloud tenant; impersonation protection needs Defender for Office 365.

### Do allowed spoofed sender entries expire in Microsoft 365?

No. Microsoft states that allow and block entries for spoofed senders in the Tenant Allow/Block List never expire. That's unlike domain and address allow entries, which expire. Because spoofed sender entries stay forever, review the Spoofed senders tab regularly and delete pairs for services you no longer use.

### Why doesn't a message that failed the sender's DMARC policy show in the spoof intelligence insight?

Microsoft excludes it. Messages from domains that fail DMARC with p=quarantine or p=reject don't appear in the insight. They're handled by the Honor DMARC record policy setting in your anti-phishing policy instead. The insight only lists spoofed senders that spoof intelligence itself detected.

### How do I remove the question mark from a sender's photo in Outlook?

The question mark means the message failed SPF or DKIM and also failed DMARC or composite authentication. The lasting fix is for the sender to authenticate properly; Microsoft says SPF or DKIM matter most. As an admin, you can also allow the spoofed sender pair in the Tenant Allow/Block List, or turn the indicator off in the anti-phishing policy.

### What does compauth=fail reason=601 mean?

Reason 601 means the sending domain is one of your own accepted domains, so Microsoft treats it as self-to-self or intra-org spoofing. It's common when a third-party service sends as your domain without SPF or DKIM for it. Fix the service's authentication, or allow that specific domain pair as an Internal spoofed sender.

## Sources

- [Microsoft Learn: Review and manage spoof intelligence insight](https://learn.microsoft.com/en-us/defender-office-365/anti-spoofing-spoof-intelligence)
- [Microsoft Learn: Anti-spoofing protection](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-protection-spoofing-about)
- [Microsoft Learn: Allow or block email using the Tenant Allow/Block List](https://learn.microsoft.com/en-us/defender-office-365/tenant-allow-block-list-email-spoof-configure)
- [Microsoft Learn: How email authentication works in Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-about)
- [Microsoft Learn: Anti-spam message headers](https://learn.microsoft.com/en-us/defender-office-365/message-headers-eop-mdo)
- [Microsoft Learn: Anti-phishing policies in Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-policies-about)

## Free tools for this guide

- [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer): Trace hops and authentication results — runs entirely in your browser.
- [DMARC Checker](https://iblockspam.com/tools/dmarc-checker): Check your policy, reporting and the safe path from p=none to reject.
- [SPF Checker](https://iblockspam.com/tools/spf-checker): Count real DNS lookups, find PermErrors, loops and risky "all" settings.
- [DKIM Checker](https://iblockspam.com/tools/dkim-checker): Validate DKIM keys by selector, including key type and strength.

---

Source: iBlockSpam, https://iblockspam.com/blog/microsoft-365-spoof-intelligence (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt