Why are emails being marked as junk or phishing in Outlook 365?
Updated on 11 Oct 2026: We corrected Microsoft's cloud filtering guidance and added practical steps for reporting legitimate Outlook mail as a false positive.
Emails are being marked as junk or phishing in Outlook 365 because Microsoft 365 does not decide placement only from SPF, DKIM, and DMARC. Those checks matter, but Exchange Online Protection also scores sending reputation, message content, links, bulk-mail behavior, tenant policy, spoofing risk, and whether the visible sender identity matches the authenticated domain. Outlook is the email app; these tenant policies apply to Microsoft 365 work or school mailboxes. Personal Outlook.com and Hotmail accounts have different controls, even when opened in the same app.
The practical short answer: use the message category and the recipient's policy to explain Junk placement or quarantine. Microsoft's SCL guidance says SCL alone does not determine cloud verdicts or actions. A message can also receive a phishing warning or quarantine action if it resembles credential collection or impersonation, even when basic authentication passes.
- Authentication: SPF, DKIM, DMARC, and Microsoft's composite authentication result are initial checks, not the final inbox decision.
- Reputation: Microsoft weighs the sending domain, return-path domain, IP, link domains, and complaint history.
- Content: Password reset copy, urgent account language, mismatched branding, and heavy tracking can contribute to unwanted-mail detections under aggressive tenant settings.
- Links: Microsoft checks link destinations and redirects; automated visits can consume a one-time token if opening the page completes the action.
- Bulk mail: A BCL at or above the recipient tenant's threshold can send authenticated marketing email to Junk or quarantine.
Why Outlook 365 flags mail
Separate Outlook 365 problems into authentication problems and trust problems. Authentication problems are direct. A DNS record is wrong, a third-party sender is missing, DKIM is not signing, or neither passing SPF nor passing DKIM uses a domain that matches the visible From domain under DMARC's rules. Trust problems are less tidy. The email passes the DNS checks, but Microsoft still decides the overall message resembles unwanted or suspicious mail.
Microsoft's own Outlook phishing guidance says Outlook checks whether the sender is who they claim to be and marks malicious messages as junk. It also warns users when a sender cannot be verified or when the apparent From address differs from the actual sender. That is why a message can pass SPF for one domain and still look wrong to Outlook if the user-facing identity points somewhere else.
Microsoft 365 verdicts and policy actions
Read CAT with the applied policy rather than treating SCL ranges as delivery rules.
No threat category
CAT:NONE
Check mailbox rules if the message still moves.
Spam
CAT:SPM
Default and Standard policies use Junk; Strict uses quarantine.
High confidence spam
CAT:HSPM
Default uses Junk; Standard and Strict use quarantine.
High confidence phishing
CAT:HPHSH or HPHISH
Normally quarantined; Safe Senders does not bypass this verdict.
Check these categories against Microsoft's policy recommendations and the policy that actually applied to the recipient.
The detail that catches teams off guard is that Outlook 365 can change placement without the sending platform, IP pool, or DNS records changing. Microsoft can adjust filtering models, and one recipient organization can run stricter policies than another. That explains why one customer reports quarantine while another receives the same campaign in the inbox.
Illustrative Microsoft 365 email review screen showing an Outlook junk verdict, SCL, authentication results, and URL checks.
Common Outlook junk and phishing triggers
When Outlook 365 junks or flags legitimate mail, the root cause is usually one of these signals. The fix depends on which detection or rule caused the action, so changing content blindly wastes time. Start with the headers, then test one variable at a time.
|
|
|
|
|---|---|---|---|
Spam or phishing category | CAT identifies the filtering category | Headers and applied policy | Trace the category and policy action |
Auth fail | Sender identity is not trusted | DNS and headers | Fix domain matching and signing |
DMARC domain mismatch | Neither passing SPF nor passing DKIM matches the From domain under DMARC's rules | Authentication-Results | Configure matching SPF or DKIM domains |
High BCL | Bulk complaint level met the tenant threshold | Headers and policy | Reduce complaints |
Link risk | Redirects or landing page look unsafe | URL review | Simplify links |
Blocklist (blacklist) | An IP or domain listing needs investigation; it does not prove Microsoft blocked the message | Reputation | Check the listing and address its cause |
Tenant rule | Recipient policy is stricter | Admin trace | Review the applied policy |
Mailbox setting | A rule or blocked sender entry moved the mail | Outlook settings | Remove the bad entry |
Common Outlook 365 junk and phishing triggers.
Authentication passing does not guarantee inbox placement
DMARC passes when SPF or DKIM passes with a domain that matches the visible From domain under the configured matching rules. Relaxed matching permits the same organizational domain; strict matching requires an exact domain match. Authentication does not prove the message is wanted or safe. Outlook 365 still evaluates reputation, bulk behavior, content, links, and the recipient tenant's policy.
The most common mistake is treating all Outlook 365 junk placement as one problem. A newsletter with weak engagement, a password reset email with a single-use link, and a CRM email sent through a third-party domain have different causes. They need different fixes.
How BCL affects marketing mail
Microsoft 365 assigns a Bulk Complaint Level (BCL) to messages it identifies as bulk mail. BCL is separate from SCL. A higher BCL indicates a greater likelihood of unwanted bulk-mail behavior, so an authenticated newsletter can go to Junk even when SPF, DKIM, and DMARC pass.
|
|
|---|---|
0 | The usual non-bulk value; some messages with BCL 0 are still tagged as Promotions. |
1-3 | The bulk sender generates few complaints. |
4-7 | The bulk sender generates a mixed level of complaints. |
8-9 | The bulk sender generates a high level of complaints. |
Microsoft 365 BCL ranges for bulk email.
The threshold depends on the recipient organization. Microsoft's default anti-spam policy uses BCL 7, the Standard preset uses 6, and the Strict preset uses 5. A message at or above the applicable threshold receives the tenant's bulk-mail action, commonly Junk for default or Standard policy and quarantine for Strict policy.
Bulk mail below the BCL threshold can still be delivered to the Promotions folder when the applied policy has Bulk moves enabled. Promotions placement is different from a spam or phishing verdict. Microsoft's bulk email guidance explains this behavior, including Promotions tagging for some messages with BCL 0.
Treat BCL as a sender-quality signal
Do not rely on a recipient admin raising the BCL threshold. Confirm consent, suppress inactive recipients, make unsubscribe easy, keep marketing on a separate subdomain, and reduce complaint-producing sends. These changes address the behavior behind the classification.
How to diagnose the real cause
Start by sending a controlled test message and reading the full headers. Do not rely only on the user's screenshot of the Junk folder. The headers provide evidence of authentication failures, bulk-mail filtering, phishing verdicts, and recipient rules. Pair them with the recipient organization's message trace and applied policy.
Illustrative authenticated message classified as bulk
Authentication-Results: receiver.example.net; spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com; compauth=pass reason=100 X-Forefront-Antispam-Report: CIP:203.0.113.10; SCL:5; SFV:SPM; CAT:BULK; SRV:BULK; DIR:INB X-Microsoft-Antispam: BCL:7 X-MS-Exchange-Organization-SCL: 5
Read CAT and SFV with BCL in X-Microsoft-Antispam. SFV:SPM indicates a spam-filter verdict; SFV:BLK points to Blocked Senders. CAT:HPHSH or HPHISH identifies high-confidence phishing; SRV:BULK points to bulk filtering. Microsoft's anti-spam header reference explains these fields. Composite authentication, shown as compauth, combines authentication with other sender signals; compauth=fail alone does not automatically block a message.
Then compare the result against a second test where only one variable changes. For example, send the same content from a different domain, then send different content from the same domain. If changing the domain fixes inboxing, reputation or identity warrants investigation. If changing the content fixes inboxing, wording, links, HTML, or the landing page warrants investigation. Repeat comparisons with the same recipients and similar timing; a domain change is evidence, not proof of the cause.
Domain-led problem
- Pattern: Same content improves when the From or return-path domain changes.
- Likely cause: The domain, subdomain, link domain, or sender identity has weak trust.
- Fix: Separate streams, repair authentication, warm volume, and reduce complaints.
Content-led problem
- Pattern: Same sender improves when subject, body, or links change.
- Likely cause: The message resembles credential collection, low-value automation, or risky redirects.
- Fix: Rewrite copy, simplify HTML, remove link chains, and improve the landing page.
Use Suped's email test to inspect authentication, sending IP, blocklist status, and technical headers from a real test send. It does not predict Microsoft's inbox placement or reproduce a recipient tenant's filtering verdict. For a wider domain audit, the domain health checker checks DMARC, SPF, DKIM, and related DNS health together.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
After the test, compare headers against real recipient complaints. A single seed result is useful, but a pattern across multiple Microsoft 365 tenants is stronger evidence. If only one mailbox is affected, check its Inbox rules, Blocked Senders list, and whether it only trusts safe senders. In new Outlook and Outlook on the web, use Settings > Mail > Junk email; classic Outlook has Junk Email Options, including Safe Lists Only. If only one organization is affected, ask its admin for message trace details, the applied policy, and the quarantine reason. Microsoft's junk folder guidance covers recipient actions, but sender-side diagnosis still needs headers and message trace.
How to improve Outlook inbox placement
Work through identity, reputation, bulk behavior, content, and recipient evidence in that order. If authentication is wrong, fix it first. If authentication is clean, stop changing DNS and focus on trust signals.
- Verify identity: Make sure SPF includes the sender, DKIM signs with your domain, and DMARC passes for the visible From domain.
- Split streams: Separate marketing from transactional mail using appropriate subdomains. Subdomains help manage sending streams, but shared IPs and related domains still affect reputation.
- Clean links: Use branded link domains, reduce redirect chains, and avoid link shorteners or unrelated tracking domains.
- Rewrite risky copy: Remove pressure language, unclear sender context, and login prompts that look like credential harvesting.
- Check reputation: Review IP and domain blocklist (blacklist) status, complaint patterns, and sudden spikes in unknown-user traffic. For a dedicated sending IP, verify reverse DNS (PTR) and a consistent HELO/EHLO hostname with your sending provider.
- Gather proof: Save headers, message trace, quarantine reason, sample recipients, timestamps, and the exact content version.
DMARC monitoring TXT record at _dmarc.example.com
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Publish this example at _dmarc.example.com and replace example.com and the reporting address with your domain and an active report destination. p=none requests monitoring; it does not disable Microsoft's spam or phishing filtering. Move toward quarantine or reject only after confirming every legitimate sender. Suped's DMARC monitoring workflow shows which sources pass, which sources fail, and what needs fixing before enforcement.
What to avoid
- Avoid domain hopping: Changing domains is a diagnostic clue, but repeated hopping creates fresh trust problems.
- Avoid broad bypass rules: Use false-positive submissions and scoped temporary exceptions when justified, rather than relying on a blanket sender-domain allowlist.
- Avoid guessing: Change one variable per test, or you will not know whether domain, content, or links caused the result.
If blocklist or blacklist status is part of the pattern, Suped's blocklist monitoring helps connect listings to sender behavior instead of treating a listing as an isolated event.
How to report legitimate mail as a false positive
When authentication is correct but expected mail is still filtered, the recipient organization needs to investigate the false positive. For mail delivered to Junk, the recipient can choose Report > Not junk and review Safe Senders. Confirm that the message is legitimate before releasing quarantined mail.
- Collect the original message or full headers, sender and recipient addresses, UTC timestamps, and the message ID. Ask the recipient admin to compare message trace with the delivery action, detection reason, and policy; use Explorer or Real-time detections when licensed.
- Follow Microsoft's false-positive remediation steps to submit the affected message for analysis and release verified legitimate mail from quarantine. Submitting a false positive does not automatically release other quarantined copies.
- On the Submissions page, choose "I've confirmed it's clean" only after verification. The "Allow this message" option creates scoped allow entries for the message's relevant elements. Review their scope and expiry using Microsoft's submission instructions.
- Retest and retain the submission ID. If failures persist across expected senders, the recipient admin should check Microsoft 365 service health and open a support case with the original samples, trace evidence, and submission results.
If mail first reaches the Inbox and later moves, inspect Inbox rules and zero-hour auto purge (ZAP). ZAP can act on messages delivered within the last 48 hours, so a delivered status alone does not establish their current folder.
Why Safe Senders does not fix every case
Safe Senders and ordinary spam-bypass rules do not override malware or high-confidence phishing protection. Preset policies can also take precedence over custom settings. Check the actual detection and policy rather than disabling protection. Microsoft's policy troubleshooting guidance explains these limits.
Handling link scanning and reset emails
Password reset, magic login, invoice, document, and account verification emails can be mistaken for phishing in Outlook 365. They often contain a single call to action, account language, and a link to a page that accepts a token. That is exactly the shape many phishing campaigns use.
Modern filters scan links before the user sees the message. Microsoft's Safe Links documentation describes checks before delivery and at click time. Automated visits can fetch a destination and follow redirects. If the first page visit consumes the token, the real user receives a broken link. Keep single-use tokens, but do not consume them on page load.
Risky reset flow
- Link action: The first request completes the reset or login action.
- Scanner impact: A filter visit consumes the token before the user clicks.
- User result: The message looks broken, suspicious, or already used.
Safer reset flow
- Link action: The link opens a confirmation page and no account change happens yet.
- Scanner impact: A filter visit sees static content and does not complete the action.
- User result: The user clicks a real button to confirm, then the token is consumed.
Email links should open an interstitial page, and the user should perform a deliberate action on that page. Keep HTTP GET requests read-only and complete the action through a server-validated POST request after confirmation. Use a reasonable expiration window, bind the token to the account and browser context where possible, and avoid using link open as proof of intent.
Flowchart showing a reset email link opening a static page before user confirmation consumes the token.
For more detail on a related Microsoft 365 scenario, the walkthrough on high SCL fixes explains related troubleshooting when authentication passes; assess SCL with the category and applied policy.
Where Suped fits
Suped's product helps track authentication issues across multiple sending sources. A team often has marketing mail, product mail, CRM mail, invoices, password resets, and employee mail sharing one parent domain. One bad stream can damage the trust of the others.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped's product combines DMARC monitoring with authentication issue tracking and blocklist monitoring for domain and IP reputation. The issue view turns authentication and DNS findings into specific fix steps, which reduces the need to interpret raw XML reports.
A practical operational workflow
Use Suped's DMARC monitoring to identify legitimate sources with authentication failures, assign fixes, and monitor the results after DNS changes. DMARC aggregate reports do not show a recipient's Outlook folder or full phishing verdict; obtain that evidence from recipient headers and Microsoft 365 investigation tools.
Views from the trenches
Best practices
Track Outlook results by stream, domain, content version, and tenant before changing DNS.
Design reset links so scanners can open pages without consuming tokens or changing accounts.
Use headers and message trace together, since user screenshots miss the delivery verdict.
Common pitfalls
Assuming SPF, DKIM, and DMARC pass means Microsoft must place the email in the inbox.
Rotating sender domains after every junk event instead of fixing reputation and content.
Letting one-click account actions run on page load, which scanners can trigger first.
Expert tips
Compare same content on a new domain and new content on the same domain to isolate cause.
Read CAT, SFV, and BCL with the applied policy; SCL alone does not explain cloud delivery.
Keep password reset copy plain, branded, expected, and free of unnecessary redirect chains.
Expert view
Expert from Email Geeks says link scanners now inspect destination pages, so email links should not complete account actions on first page load.
2025-01-30 - Email Geeks
Marketer view
Marketer from Email Geeks says when the same sending platform and IPs work for other clients, the issue often points to sender domain or content behavior.
2025-01-23 - Email Geeks
