The SCL:-1 Loophole: Why DMARC Reject Doesn’t Stop Internal Spoofing in Microsoft 365

Many admins assume that publishing p=reject in their DMARC record guarantees spoofed messages will be blocked. In reality, Microsoft 365’s Exchange Online Protection (EOP) doesn’t always honor DMARC policy out of the box.

This article explains why internal spoofing sometimes bypasses DMARC, how to detect it in headers, and what configuration changes you need to enforce it properly.

Why DMARC p=reject Doesn’t Always Work

DMARC depends on alignment of SPF or DKIM with the domain in the From: header. If neither aligns, and the DMARC policy is p=reject, the receiver should reject the message.

But in Microsoft 365:

• Spam Confidence Level (SCL) values can override filtering.
• If a message is stamped with SCL:-1 (“trusted”), it bypasses spam filtering, including DMARC.
• Misconfigured inbound connectors, allow lists, or spoof intelligence can cause SCL:-1 to be applied, allowing spoofed mail to slip past.
• On top of that, many legacy Microsoft 365 tenants (or tenants created before Microsoft started enforcing DMARC more consistently) don’t automatically honor p=reject. Unless the admin explicitly enables DMARC enforcement in Anti-phishing policies and org settings, spoofed messages can still be delivered despite the sending domain publishing a reject policy.

This is why internal spoofing — a bad actor sending as [email protected] — can succeed even with DMARC reject published.
2f9b34

Step 1: Verify and Fix RejectDirectSend

Run this in PowerShell to check the setting:

Get-OrganizationConfig | fl Identity,RejectDirectSend

If it shows RejectDirectSend : False, update it with:

Set-OrganizationConfig -RejectDirectSend $true

This forces Exchange Online to block any unauthenticated direct-to-MX traffic trying to impersonate your domain, closing one of the most common internal spoofing gaps.

Step 2: Verify If EOP Honors DMARC

Next, confirm that your EOP/Defender anti-phishing policy is set to respect the published DMARC policy of external domains. You need to check in the Microsoft 365 Security & Compliance Center:

1. Go to security.microsoft.com
2. Navigate to Email & collaboration → Policies & rules → Threat policies → Anti-phishing
3. Under Actions for authentication failures, make sure the settings are the same as the screenshot below

This ensures that your tenant is actually enforcing the sender’s DMARC policy instead of allowing spoofed mail.

To adjust the settings, follow our article here: https://easydmarc.com/blog/dmarc-and-microsoft/

Without these settings, EOP won’t enforce DMARC rejects.

Step 3: Review Allowlists, Custom Rules, and Connectors

Even if DMARC enforcement is enabled, custom mail flow rules or allowlists can silently override it. These are the most common causes of internal spoof bypass.

• Mail Flow Rules (Transport Rules)
  
  • Check under Exchange Admin Center → Mail Flow → Rules
    
  • Look for rules that:
    
    • “Bypass spam filtering”
      
    • “Set the spam confidence level (SCL) to -1”
      
    • “Always deliver to inbox”

In this screenshot, there’s no set Rules.

• Allowed Domains or Senders
  • Check under Security portal → Policies & rules → Threat policies → Anti-spam → Allowed/Blocked senders & domains
  • If your own domain is listed in “Allowed,” spoofed mail will bypass DMARC.

• Spoof Intelligence Overrides
  • Go to Security portal → Policies & rules → Threat policies → Tenant Allow/Block Lists
  • If someone clicked Allow on a spoofed sender, it effectively disables DMARC for that sender.

• Connectors and Gateways

Misconfigured inbound connectors can also cause SCL:-1. If Microsoft thinks the mail is “internal,” it won’t apply DMARC.

• Go to Exchange Admin Center → Mail flow → Connectors
• Review connectors from third-party gateways (Proofpoint, Mimecast, Barracuda, etc.).
• Set them as a Partner Organization
• Do not use “From your organization” unless the connector is truly for internal relays (e.g., hybrid Exchange servers).

Step 4: Analyze Message Headers

Headers reveal why a spoofed email was delivered or blocked.

1. Allowed Domains or Senders
   • Check under Security portal → Policies & rules → Threat policies → Anti-spam → Allowed/Blocked senders & domains
   • If your own domain is listed in “Allowed,” spoofed mail will bypass DMARC.

• X-Forefront-Antispam-Report → SCL
  Microsoft’s spam confidence levels:
  • -1 = Trusted (bypasses all filtering)
  • 0–1 = Low suspicion
  • 5–6 = Likely spam
  • 9 = High confidence spam
• If you see SCL:-1, it means DMARC was bypassed by a policy or rule.
• If you see AuthAs: Anonymous, it indicates the email came in without authentication. If paired with DMARC fail and SCL:-1, it confirms a spoof bypass.

Step 5: Deploy Fixes to Enforce DMARC Properly

To stop internal spoofing:

1. Confirm RejectDirectSend = True (Step 1).
2. Enable DMARC enforcement in Anti-Phishing policies (Step 2).
3. Clean up rules and allowlists that can stamp SCL:-1 (Step 3).
4. Test by sending spoof simulations from external systems and confirm they are rejected.
   

Key Takeaway

DMARC enforcement in Microsoft 365 is not just about publishing p=reject.

• If Direct Send is allowed, attackers can spoof your own domain.
• If Anti-Phishing doesn’t honor DMARC, spoofed emails slip through.
• If rules or allowlists trigger SCL:-1, filtering is bypassed entirely.

By checking these areas and analyzing headers, you can ensure Microsoft 365 truly respects DMARC p=reject and prevent internal spoofing from bypassing your defenses.