Legitimate email landing in Junk: how EOP decides and the right way to fix it

A supplier's invoices keep landing in Junk Email, the CEO's newsletter from the marketing platform does the same, and the first instinct is to add the domain to an allow list somewhere. That instinct is what gets tenants phished. In this post I'll show you how Exchange Online Protection (EOP) actually reaches a junk verdict, how to read the headers that explain it, and the fixes Microsoft documents, from submissions and the Tenant Allow/Block List to fixing the sender's authentication, so the mail stays in the Inbox without punching a hole in your filtering.

Symptoms#

• Messages from a known external sender arrive in the recipients' Junk Email folder, sometimes with a safety tip banner, while other mail from the same sender is fine.
• Messages appear briefly in the Inbox and are then moved to Junk, which is zero-hour auto purge (ZAP) acting on a later verdict.
• Adding the sender to Outlook's Safe Senders helps for one user but not for a shared mailbox or for everyone else.
• Messages aren't in Junk at all but in Focused Inbox's Other tab, which is an Outlook sorting feature, not a spam verdict; check that first.

Why it happens#

Every inbound message gets an X-Forefront-Antispam-Report header. Two fields tell you what happened: CAT, the verdict category, and SFV, how the filter arrived at it. The spam confidence level (SCL) is still stamped, but Microsoft now says it doesn't decide the outcome in cloud mailboxes; read CAT and DIR instead. The action is then taken from the anti-spam policy that applies to the recipient: in the default policy, spam, high confidence spam, bulk and phishing all go to the Junk Email folder, and only high confidence phishing is quarantined (the Standard and Strict presets quarantine more).

The other half of the story is the Authentication-Results header. compauth=fail reason=001 means the message failed implicit authentication: the sending domain has weak or missing SPF, DKIM and DMARC, so EOP had to guess. reason=000 is an explicit DMARC failure with a reject or quarantine policy, 010 is one of your own domains being spoofed, 1xx and 7xx are passes, and 905 means DMARC wasn't enforced because of complex routing. The recurring "good mail in Junk" cases are therefore a sender with broken authentication, a marketing platform sending without alignment, a bulk sender with a high BCL, or mail that passed through a gateway or on-premises server before EOP, so the connecting IP wasn't the real sender's.

How to fix it#

1. Read the headers properly. Get the message as .eml or .msg from the recipient, or copy the headers from Outlook's message properties, and paste them into Microsoft's Message Header Analyzer (linked from the anti-spam headers page on Microsoft Learn). Note CAT, SFV, BCL, CIP (connecting IP) and the spf, dkim, dmarc and compauth results; they tell you which fix below applies.
2. Submit it to Microsoft. In the Microsoft Defender portal go to Actions & submissions › Submissions › Emails › Submit to Microsoft for analysis, paste the network message ID or upload the file, pick the recipient, and choose It appears clean or I've confirmed it's clean. The result explains the cause (policy hit, user override, authentication failure) within minutes for configuration issues, or up to a day when graders are involved. Users can do the same with the built-in Report button in Outlook; their reports land on the User reported tab.
3. Create the allow through the submission, not by hand. On the second page of the submission select Allow this message. EOP then creates Tenant Allow/Block List entries only for the elements that actually caused the block (sender address or domain, URL, file, or a spoofed sender pair). Entries default to 45 days after last used and are removed automatically once the filter agrees the sender is clean; spoofed sender allows don't expire. They also only override the verdict they were created for; malware and high confidence phishing checks still run. If the message wasn't blocked by filtering, no entry is created, which is a hint that the "junking" was a user setting or a rule.
4. If it's an impersonation verdict, fix the anti-phishing policy. CAT:DIMP, UIMP or GIMP false positives don't go in the Tenant Allow/Block List; the submission adds the sender to Trusted senders and domains in the anti-phishing policy that caught it, and you can maintain that list yourself.
5. When the sender's domain is the problem, say so. If the headers show spf=fail or softfail, dkim=none and compauth=fail reason=001, the lasting fix is on the sender's side: publish SPF that includes their sending platform, sign with DKIM, and move DMARC towards enforcement. Microsoft's recommended-settings guidance is blunt about it: fix authentication first, then tune policies. An allow entry buys time; it doesn't repair reputation.
6. Mail routed through another system first. If your MX points to a third-party filter or an on-premises Exchange server, enable Enhanced Filtering for Connectors on the inbound connector so EOP evaluates the original sending IP instead of the gateway's (Set-InboundConnector -EFSkipLastIP $true for a single hop, or list the gateway IPs in EFSkipIPs). Without it, SPF and DMARC fail for everything and your compauth results are meaningless.
7. Per-user settings when it really is one person. Safe Senders are honoured for Move to Junk Email folder verdicts (both addresses and domains); for quarantine verdicts only addresses count, and never for malware or high confidence phishing. Admins can manage the lists:
   PowerShell

   Set-MailboxJunkEmailConfiguration -Identity adele@contoso.com -TrustedSendersAndDomains @{Add="billing@fabrikam.com"}
   Get-MailboxJunkEmailConfiguration -Identity adele@contoso.com | Format-List Trusted*, Blocked*, Contacts*

   Keep Outlook's own Junk Email Filter at No automatic filtering; Microsoft recommends it so the client doesn't second-guess the service.
8. Review the policy itself with the configuration analyzer. Under Email & collaboration › Policies & rules › Threat policies › Configuration analyzer compare your anti-spam, anti-phishing and anti-malware policies with the Standard and Strict baselines, and use the drift tab to see who changed what. A bulk threshold set too low, or an entry in Allowed sender domains (which Microsoft calls a bad idea because attackers can spoof the domain), both show up here.

Verify the fix#

• Ask the sender for a fresh message and check its headers: SFV:NSPM (or the allow being honoured), compauth=pass, and no SRV:BULK.
• Check the submission's Result column and the new entries under Tenant Allow/Block Lists; entries become active within about five minutes.
• Run Get-MessageTraceV2 for the sender and confirm the delivery status and folder for the recent messages.

Prevent it next time#

• Turn on the Standard preset security policy instead of hand-tuning anti-spam policies, and let the configuration analyzer flag drift.
• Make the user Report button the official way to flag false positives so every case reaches the Submissions page with headers attached.
• Review Tenant Allow/Block List entries monthly; the service removes allows it no longer needs and raises an alert when it does.
• Give vendors a short note about SPF, DKIM and DMARC alignment; most "please allow us" requests disappear once their authentication is right.

References#

• Anti-spam message headers in cloud organizations (Microsoft Learn)
• Submit messages, URLs and attachments for analysis (Microsoft Learn)
• Manage allows and blocks in the Tenant Allow/Block List (Microsoft Learn)