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

Symptoms to confirm

• 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.

Likely causes

Every inbound message gets an X-Forefront-Antispam-Report header.

• 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.

Checklist

1. 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. 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.

3. 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).

4. 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. 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.

6. 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).

7. 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*

8. 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.

Watch out: a mail flow rule that sets SCL to -1 for a domain, or a domain in the anti-spam policy's allowed domains list, bypasses spam filtering for anyone who can forge that domain. If you inherited one, replace it with authentication fixes and Tenant Allow/Block List entries, then remove it.

Verify

• 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.