Troubleshoot common anti-spam policy issues

Use the following information to diagnose and resolve common anti-spam policy issues:

• Policy precedence conflicts.
• Unexpected SCL overrides.
• False positives from Advanced Spam Filter (ASF) settings.

Policy precedence issues

Anti-spam policies are evaluated in a specific order. Only the first matching policy (highest priority) applies to a recipient. This order matters when multiple policies exist. Anti-spam policies are processed in the following order:

For the complete precedence model for all protection features, see Order and precedence of email protection.

Problem: Custom policy settings aren't being applied

Symptom: You configured a custom anti-spam policy with specific settings (for example, a higher BCL threshold or a different spam action), but the settings aren't taking effect for some users.

Likely cause: The affected users are also included in a preset security policy (Standard or Strict), which takes precedence over custom policies.

How to diagnose:

1. On the Preset security policies page in the Microsoft Defender portal at https://security.microsoft.com/presetSecurityPolicies, check if the Standard or Strict preset security policies are enabled and which users, groups, or domains are included.
2. Compare the recipient scope of the preset policy with your custom policy.

Resolution:

• If you need custom settings for specific users, do either of the following steps:
  • Add those users as exclusions in preset security policies.
  • Use specific user or group assignments for both preset security policies and custom policies to ensure the targeted users are assigned only to the custom policy.

In Exchange Online PowerShell, run the following command to check which anti-spam policy applies to a specific user:

Get-HostedContentFilterRule | Where-Object {$_.State -eq 'Enabled'} | Format-Table Name, Priority, SentTo, SentToMemberOf, RecipientDomainIs

Problem: Two custom policies overlap and the wrong one applies

Symptom: A user matches the recipient conditions of two custom anti-spam policies, but the wrong policy settings apply.

Likely cause: The policy you want to apply has a lower priority (higher priority number) than the other policy.

How to diagnose:

1. On the Anti-spam policies page in the Defender portal at https://security.microsoft.com/antispam, review the Priority column for Inbound anti-spam policies.
2. Check the recipient conditions (users, groups, domains) of both policies.

Resolution:

Reorder the policies so the more specific policy has a higher priority (lower priority number). For instructions, see Use the Microsoft Defender portal to set the priority of custom anti-spam policies or Use PowerShell to set the priority of spam filter rules.

Problem: Default policy has unexpected settings

Symptom: Users not covered by any other policy receive unexpected spam filtering behavior.

Likely cause: The default anti-spam policy was modified from its original settings, or you're expecting the default policy to behave like a custom policy.

Resolution:

• Review and reconfigure the default anti-spam policy settings.
• The default anti-spam policy can't be scoped to specific users. It always applies last to all recipients not covered by other policies.
• Consider creating a custom policy for the affected users instead of relying on the default.

SCL override behavior

The spam confidence level (SCL) determines how messages are classified and acted on. Certain mechanisms can override the SCL value that spam filtering assigns, which affects whether messages go to the Inbox, the Junk Email folder, or quarantine. For SCL values and their default actions, see Spam confidence level (SCL).

The following mechanisms can override the SCL value that spam filtering assigns. Their behavior and limitations affect troubleshooting:

Problem: SCL -1 mail flow rule delivers spam to Inbox

Symptom: Users receive spam or phishing messages in their Inbox instead of Junk Email or quarantine.

Likely cause: A mail flow rule sets SCL to -1 for too broad a scope. For example, all messages from a specific domain or IP range, or all messages routed through a connector.

How to diagnose:

1. On the Rules page in the Exchange admin center at https://admin.exchange.microsoft.com/#/transportrules, look for rules with the action Set the spam confidence level (SCL) to Bypass spam filtering or -1.
2. Review the conditions. Are they overly broad?

Resolution:

• Narrow the conditions: Add more conditions to the rule (for example, sender address + specific header value).
• Use Enhanced Filtering for Connectors instead: If the rule exists because mail routes through a non-Microsoft service, configure Enhanced Filtering for Connectors and remove the SCL -1 rule.
• Use the advanced delivery policy: For SecOps mailboxes or phishing simulations, use the advanced delivery policy instead of mail flow rules.

Problem: Allow list entries aren't working

Symptom: You added a sender to the allowed senders list in the anti-spam policy, but messages from that sender are still being filtered.

Likely cause: A preset security policy covers the user and overrides the custom anti-spam policy settings. Or, malware or high confidence phishing filtering is catching the message, and allow lists can't override those verdicts.

How to diagnose:

1. Check message headers for the X-Forefront-Antispam-Report header and look for the SFV (spam filtering verdict) value:
   • SFV:SKA = Message was allowed (skipped filtering due to an allow list entry).
   • SFV:SPM = Message was marked as spam (allow list wasn't applied).
2. Check if malware or phishing filtering caught the message instead of spam filtering.

Resolution:

• If the user is in a preset security policy, allowed sender/domain lists in custom policies are ignored. Use the Tenant Allow/Block List instead.
• If the message is flagged for malware or high confidence phishing, report it as a false positive via Submissions in the Microsoft Defender portal at https://security.microsoft.com/reportsubmission.

Determine which component set the SCL

When you troubleshoot unexpected spam filtering behavior, identify which component assigned the SCL value to the message. Multiple components in the Exchange Online filtering pipeline can set or override the SCL: spam filtering, mail flow rules, connection filtering, allowed/blocked sender lists, and Advanced Spam Filter (ASF) settings.

The following steps show how to use message X-headers to trace the SCL source.

Step 1: Get the message headers

To analyze how the SCL was set, you need the full internet message headers of the affected message:

• Outlook (desktop): Open the message > select File > Properties. The headers appear in the Internet headers box.
• Outlook on the web: Open the message > select ... (More actions) > View > View message details.
• Admin (Message trace): On the Message trace page in the Exchange admin center at https://admin.exchange.microsoft.com/#/messagetrace, find the message and view the header details.

Step 2: Locate the key X-headers

The following X-headers contain the information you need to trace the SCL source:

For full details on all header fields, see Anti-spam message headers in cloud organizations.

Step 3: Read the Spam Filtering Verdict

The SFV (Spam Filtering Verdict) field in the X-Forefront-Antispam-Report header is the primary indicator of which component determined the message's fate:

Step 4: Check the IPV field for connection-level decisions

The IPV (IP Verdict) field indicates whether the connection filter made a decision about the source IP:

If you see IPV:CAL with SCL:-1, the connection filter (IP Allow List) is the component that bypassed spam filtering.

Step 5: Check for ASF overrides

If an ASF setting flagged the message, a separate X-CustomSpam header is added that identifies which ASF rule triggered. For example:

X-CustomSpam: Web bug

For the complete list of ASF settings, X-CustomSpam values, and their SCL effects, see Advanced Spam Filter (ASF) settings in anti-spam policies.

Step 6: Check for mail flow rule involvement

If SFV:SKN or SFV:SKS appears in the header, a mail flow rule set the SCL before spam filtering processed the message.

To identify which mail flow rule is responsible:

1. On the Rules page in the Exchange admin center at https://admin.exchange.microsoft.com/#/transportrules, look for rules with the action Set the spam confidence level (SCL).
2. Cross-reference the rule conditions with the affected message.

Alternatively, use Message trace in the EAC. The detailed message trace output shows an AGENTINFO event that identifies which rule fired.

PowerShell: Find all SCL-setting mail flow rules

# Connect to Exchange Online PowerShell
Connect-ExchangeOnline

# List all mail flow rules that set the SCL
Get-TransportRule | Where-Object {$_.SetSCL -ne $null} |
    Format-Table Name, State, Priority, SetSCL, @{N='Conditions';E={$_.Conditions | Out-String}} -AutoSize -Wrap

Decision tree: Trace the SCL source

Use the following workflow to systematically identify which component set the SCL. Start by reading the X-Forefront-Antispam-Report header:

1. Check the SFV value:

   • SFV:SKN: Mail flow rule set SCL to -1 (bypassed filtering).
   • SFV:SKS: Mail flow rule set SCL to 5-9 (pre-marked as spam).
   • SFV:SKI: Connection filter (IP Allow List) bypassed filtering. Confirm that IPV:CAL is also present.
   • SFV:SKA: Anti-spam policy allowed sender/domain list.
   • SFV:SKB: Anti-spam policy blocked sender/domain list.
   • SFV:SFE: User's Safe Senders list.
   • SFV:BLK: User's Blocked Senders list.
   • SFV:SPM: Content filter marked as Spam. Check the CAT value for threat type and the X-CustomSpam header for ASF triggers.
   • SFV:NSPM: Content filter marked as Not Spam.

2. Check the X-CustomSpam header (if present): An ASF setting triggered. Identify which setting and disable it if the message is a false positive.

3. Check Authentication-Results (compauth):

   • compauth=fail reason=000: DMARC explicit failure (might set SCL 7+).
   • compauth=fail reason=001: Implicit authentication failure (spoof intelligence).

4. Check the SCL value:

   • SCL:-1: Filtering was bypassed (source identified in the SFV value).
   • SCL:0-1: Not spam (content filter or override).
   • SCL:5-6: Spam (content filter, ASF, or mail flow rule).
   • SCL:7-9: High confidence spam (content filter, ASF, DMARC, or analyst).

Real-world header examples

The following examples show how to interpret message headers to identify which component set the SCL.

• SCL set by spam filtering:

  X-Forefront-Antispam-Report: CIP:198.51.100.50;CTRY:US;LANG:en;
    SCL:5;SFV:SPM;IPV:NLI;SRV:;H:mail.example.com;PTR:mail.example.com;
    CAT:SPM;SFTY:;DIR:INB;
  X-MS-Exchange-Organization-SCL: 5
  

  The content filter marked the message as Spam (SFV:SPM, CAT:SPM, SCL:5). No override occurred (IPV:NLI). The spam filtering engine assigned the SCL.

• SCL set by a mail flow rule:

  X-Forefront-Antispam-Report: CIP:203.0.113.10;CTRY:GB;LANG:en;
    SCL:-1;SFV:SKN;IPV:NLI;SRV:;H:partner-mail.contoso.com;
    CAT:NONE;DIR:INB;
  X-MS-Exchange-Organization-SCL: -1
  

  A mail flow rule set SCL to -1 before spam filtering (SFV:SKN). The message bypassed spam filtering entirely. Check your transport rules for the matching condition.

• SCL set by IP Allow List:

  X-Forefront-Antispam-Report: CIP:192.0.2.25;CTRY:DE;LANG:de;
    SCL:-1;SFV:SKI;IPV:CAL;SRV:;H:smtp.partner.de;
    CAT:NONE;DIR:INB;
  X-MS-Exchange-Organization-SCL: -1
  

  The source IP (192.0.2.25) is in the IP Allow List (SFV:SKI, IPV:CAL). Connection filtering bypassed spam filtering and set SCL to -1.

• SCL set by ASF setting:

  X-Forefront-Antispam-Report: CIP:198.51.100.99;CTRY:US;LANG:en;
    SCL:9;SFV:SPM;IPV:NLI;SRV:;H:bulk.sender.com;
    CAT:HSPM;DIR:INB;
  X-CustomSpam: Web bug
  X-MS-Exchange-Organization-SCL: 9
  

  The message matched the Web bugs in HTML ASF setting (X-CustomSpam: Web bug), which set SCL to 9 (High confidence spam). The message probably contains a 1×1 tracking pixel. If the message is a legitimate newsletter, disable the MarkAsSpamWebBugsInHtml ASF setting.

• SCL set by DMARC failure:

  X-Forefront-Antispam-Report: CIP:198.51.100.77;CTRY:US;LANG:en;
    SCL:7;SFV:SPM;IPV:NLI;SRV:;CAT:SPOOF;DIR:INB;
  Authentication-Results: spf=fail (sender IP is 198.51.100.77)
    smtp.mailfrom=example.com; dkim=none;
    dmarc=fail action=quarantine header.from=example.com;
    compauth=fail reason=000
  X-MS-Exchange-Organization-SCL: 7
  

  The message failed DMARC (compauth=fail reason=000), the sender's DMARC policy specified quarantine, and the SCL was elevated to 7 (CAT:SPOOF). Anti-spoofing/DMARC enforcement set this value, not the content filter.

• SCL overridden by user Safe Senders:

  X-Forefront-Antispam-Report: CIP:203.0.113.55;CTRY:IN;LANG:en;
    SCL:-1;SFV:SFE;IPV:NLI;SRV:;CAT:NONE;DIR:INB;
  X-MS-Exchange-Organization-SCL: -1
  

  The sender is in the recipient's Safe Senders list (SFV:SFE). Spam filtering was skipped and SCL was set to -1. To verify, check the user's junk email configuration:

  Get-MailboxJunkEmailConfiguration -Identity "[email protected]" |
      Select-Object TrustedSendersAndDomains
  

SCL source identification quick reference

ASF settings that cause false positives

Advanced Spam Filter (ASF) settings mark messages as spam based on specific message properties. While these settings target characteristics commonly found in spam, they can cause false positives when legitimate messages contain the same properties.

The following tables identify ASF settings that commonly cause false positives and provide guidance on when to disable them.

Increase spam score settings

These settings increase the SCL of matching messages, giving them a higher chance of being marked as Spam (SCL 5 or 6):

Mark as spam settings

These settings set the SCL to 9 (High confidence spam), which is a more aggressive action:

The following Mark as spam settings set the SCL to 6 (Spam) instead of 9:

How to identify ASF-caused false positives

When an ASF setting flags a message, a X-CustomSpam X-header is added to the message. The header value identifies which ASF setting triggered. For the complete list of X-CustomSpam header values and their corresponding ASF settings, see Advanced Spam Filter (ASF) settings in anti-spam policies.

How to disable ASF settings

You can disable ASF settings in the Microsoft Defender portal or in Exchange Online PowerShell. For detailed steps, see Enable, disable, or test ASF settings.

Troubleshooting workflow

Use the following workflow to diagnose anti-spam policy issues:

1. Identify which component set the SCL: Use message headers to determine whether spam filtering, a mail flow rule, connection filtering, or another component assigned the SCL value. For detailed steps, see Determine which component set the SCL.

2. Check for policy precedence issues:

   • Is the user in a Strict/Standard preset? The preset wins.
   • Do multiple custom policies match? The lowest priority number wins.
   • No custom policy matches? The default policy applies.

3. Check for ASF false positives:

   • Look for an X-CustomSpam header in the message headers. The header value identifies which ASF setting triggered.
   • Disable the problematic ASF setting or use Test mode.

Diagnostic PowerShell commands

Connect to Exchange Online PowerShell and use the following commands to quickly diagnose anti-spam policy configuration issues.

# List all anti-spam policies with their priority and state
Get-HostedContentFilterRule | Sort-Object Priority | Format-Table Name, Priority, State, SentTo, SentToMemberOf, RecipientDomainIs

# Check for SCL-setting mail flow rules
Get-TransportRule | Where-Object {$_.SetSCL -ne $null} | Format-Table Name, State, SetSCL, Priority

# Check connection filter (IP Allow/Block lists)
Get-HostedConnectionFilterPolicy | Format-List IPAllowList, IPBlockList

# View the full settings of a specific policy
Get-HostedContentFilterPolicy -Identity "Default" | Format-List

# Check if any ASF settings are enabled
Get-HostedContentFilterPolicy | Format-Table Identity, MarkAsSpam*, IncreaseScoreWith* -AutoSize

# Check allowed/blocked senders in anti-spam policies
Get-HostedContentFilterPolicy | Format-Table Identity, AllowedSenders, AllowedSenderDomains, BlockedSenders, BlockedSenderDomains

Related content

• Order and precedence of email protection
• Advanced Spam Filter (ASF) settings in anti-spam policies
• Spam confidence level (SCL)
• Use mail flow rules to set the SCL
• Anti-spam message headers
• Message Header Analyzer tool
• Message trace in the EAC
• How to handle legitimate emails getting blocked (false positives)
• Report messages and files to Microsoft