Why are my emails landing in Office 365 spam folders?
Updated on 18 Oct 2026: We updated our Office 365 troubleshooting advice with current Microsoft header guidance and practical steps for resolving legitimate mail sent to junk.
Your emails are landing in Office 365 spam folders because Microsoft 365 has a negative or uncertain signal about the message, the sender, the domain, the IP, the recipient relationship, or the receiving tenant's policy. A simple subject line rarely fixes it. Microsoft is usually reacting to reputation, authentication, list quality, engagement, content, or a local rule inside the recipient organization.
Start by proving whether this is truly an Office 365-wide problem, then inspect the headers and check authentication, sender reputation, complaint signals, and the exact sending stream. A few test inboxes are useful, but they are not enough evidence on their own.
Fast answer
If Microsoft 365 alone sends your mail to Junk Email, investigate Microsoft-specific filtering and recipient-tenant policy. Check authentication, message headers, bounces, complaints, sending volume, domain age, IP reputation, and whether the affected recipients are in one tenant or many tenants.
What Office 365 is reacting to
Office 365, now part of Microsoft 365, filters mail through multiple layers. Some signals come from your DNS and headers. Some come from historical recipient behavior. Some come from Microsoft tenant policies that you do not control. That is why the same message can hit the inbox at Gmail, iCloud Mail, and one Outlook tenant, then land in Junk Email at another Microsoft tenant.
- Authentication: Configure SPF and DKIM for each sending source. DMARC passes when either SPF or DKIM passes with the required domain match to the visible From domain.
- Reputation: Microsoft judges the sender domain, sending IP, sending pattern, complaint history, and past recipient interaction.
- List quality: Bad addresses, stale opt-ins, low engagement, and complaint-heavy segments can push commercial mail toward spam.
- Content: Links, redirects, attachments, URL reputation, misleading branding, and repeated templates can influence placement.
- Tenant rules: A recipient's Microsoft 365 admin can apply anti-spam, anti-phishing, quarantine, safe sender, or mail flow rules that change delivery.
|
|
|
|---|---|---|
SPF | Whether the sending IP is authorized for the envelope sender domain | DNS and headers |
DKIM | Whether the signature verifies for the signing domain | Headers |
DMARC | Whether SPF or DKIM passes with the required From domain match | Headers and aggregate reports |
CAT and DIR | Filtering category and message direction | Microsoft headers |
SCL | Spam confidence level, supporting context rather than a cloud delivery verdict | Headers |
BCL | Bulk complaint level, an estimate of complaint likelihood | Headers and the applied anti-spam policy |
Policy | Tenant-specific filtering | Recipient admin |
Use this as a first-pass map before changing DNS or campaign copy.
Prove the problem before changing anything
The first mistake is assuming that one Microsoft test inbox tells the whole story. A single inbox has its own history, user choices, mailbox rules, tenant settings, and previous interaction with your domain. Determine whether the issue appears across several independent Microsoft 365 tenants or only inside one organization. Personal Outlook.com and Hotmail mailboxes use Microsoft's consumer mail service; assess those results separately from Microsoft 365 business tenants.
If only your own Microsoft tenant junked the message, the fix can be local. If multiple unrelated Office 365 tenants junk it, the sender-side problem is more likely. If delivery problems also appear at Gmail, Yahoo, or iCloud Mail, broaden the investigation beyond Microsoft.
Microsoft Defender portal message trace showing a message delivered to Junk Email.
- Scope: Send the same message to unrelated Microsoft 365 tenants, personal Outlook mailboxes, and non-Microsoft mailboxes.
- Headers: Save the full original headers from each result, not screenshots of the inbox folder.
- Stream: Compare transactional mail, sales mail, newsletter mail, and any third-party sender separately.
- Rates: Check bounce rate, complaint rate, unsubscribe rate, opens, clicks, and replies around the date placement changed. Treat open and click rates cautiously because privacy protections and automated scanning can distort them; compare replies and conversions too.
- Recipients: Separate active opt-in recipients from cold prospects, purchased contacts, and old publisher-sourced lists.
Do not trust one seed inbox
Just because a message lands in your own junk folder, it does not mean it lands in everyone's junk folder. The reverse is also true. Office 365 placement needs several independent samples before you change sending infrastructure or policy.
Read the Microsoft headers
Headers turn a vague spam complaint into evidence. Office 365 adds fields that show authentication results, spam confidence, bulk mail signals, connecting IP, and filtering actions. Read these before touching DNS because headers show what Microsoft actually evaluated for that delivered message. Capture the original message source in Outlook or ask the recipient's admin for the full headers.
Header fields to capturetext
Authentication-Results: spf=pass smtp.mailfrom=bounce.example.com; dkim=pass header.d=example.com; dmarc=pass action=none header.from=example.com; compauth=pass reason=100 X-Forefront-Antispam-Report: CIP:203.0.113.25; SCL:5; SFV:SPM; IPV:NLI; CAT:SPM; DIR:INB; PTR:mail.example.com X-Microsoft-Antispam: BCL:6 X-MS-Exchange-Organization-SCL: 5 Received-SPF: Pass
A passing SPF result does not prove the mail is safe. A passing DKIM result does not prove the visible From domain is the one being authenticated. A DMARC pass confirms that SPF or DKIM passed with the required domain match, but Microsoft still applies composite authentication, content, reputation, bulk, and tenant policy checks.
What a header can prove
- Authentication: Whether SPF and DKIM passed and whether DMARC found the required domain match.
- Routing: Which IP and hostname handed mail to Microsoft.
- Verdict: Whether the message received spam, phishing, bulk, or policy treatment.
What a header cannot prove
- Global scope: One recipient's result does not prove the same result everywhere.
- Root cause: A spam verdict still needs reputation, content, and list evidence.
- Future delivery: Filtering changes as recipient behavior and sender history change.
Interpret Microsoft filtering verdicts
Start with CAT (filtering category) and DIR (message direction), then read the spam filtering verdict (SFV) for an override or filtering decision. SCL alone does not determine a cloud message's verdict or delivery action. Check BCL for bulk mail and compauth for authentication failures, then confirm the applied policy and delivery event in message trace.
|
|
|
|---|---|---|
CAT:SPM | Spam category, usually delivered to Junk Email under default policy | Confirm the applied anti-spam action and inspect X-CustomSpam if present |
CAT:HSPM | High confidence spam category, quarantined by default | Review the quarantine reason and applied policy |
SFV:BLK | The sender matches the recipient's Blocked Senders list | Ask the recipient or admin to remove an incorrect blocked entry |
SFV:SKB | The sender matches a blocked sender or domain in an anti-spam policy | Ask the admin to review the matching policy entry |
SFV:SPM | Spam filtering marked the message as spam | Read CAT to identify the category before choosing a fix |
SRV:BULK and BCL | Bulk mail classification met the configured BCL threshold | Compare the applied threshold with BCL and review consent and engagement |
compauth=fail reason=000 | Explicit authentication failed under an enforcing DMARC policy | Fix the SPF or DKIM domain match and retest |
Confirm the filtering category and applied policy with message trace; the same SCL can appear with different cloud verdicts.
BCL estimates complaint likelihood for bulk mail; it is not your measured complaint rate. The default anti-spam policy uses a threshold of 7, Standard preset uses 6, and Strict preset uses 5. Custom thresholds differ, so a BCL below 7 can still trigger bulk filtering.
Use Outlook's Report > Not junk action for a legitimate message. This provides a report through the organization's configured reporting workflow. Moving a message to the Inbox alone does not repair authentication or sender reputation.
Use allow entries narrowly
A Safe Senders entry is a mailbox-level override, and threat checks still apply. It does not guarantee inbox placement or a particular SCL value. Use a narrow temporary exception only while the tenant admin investigates the original verdict. Broad or permanent allowlists can admit spoofed mail.
Fix authentication first
Authentication is not the whole answer, but it is the cleanest place to start. If Microsoft cannot verify that your sender is authorized to send for your visible From domain, every other signal starts from a weaker position. Check the domain with a domain health check and then review real DMARC reports rather than only checking the DNS record.
Configure both SPF and DKIM, then verify that at least one passes with the domain match DMARC requires. If a third-party sender signs with its own DKIM domain and uses its own bounce domain for SPF, both checks can pass while DMARC fails for your visible From domain. Default relaxed matching accepts domains with the same organizational domain; strict matching requires an exact domain match. If Microsoft 365 sends your outbound mail, publish the two DKIM CNAME records provided for the custom domain and enable DKIM signing before retesting. The generic DKIM TXT example below is for senders that publish public keys directly.
Illustrative DNS records, replace the documentation IP and public keydns
example.com. TXT "v=spf1 ip4:203.0.113.25 -all" selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=REPLACE_WITH_PUBLIC_KEY" _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
Use p=none for an initial reporting stage, verify every legitimate sender, then move to enforcement. Keep an established quarantine or reject policy when authorized sources are already verified. Replace the example reporting address with a mailbox that processes aggregate reports.
Enforcement can expose hidden senders
Moving DMARC to quarantine or reject can reveal old CRMs, invoicing tools, publisher systems, or shared mail relays that were never configured correctly. Use DMARC monitoring to identify every source before enforcing rejection.
Looks configured
- SPF: A record exists, but it has too many includes or misses a sender.
- DKIM: A selector exists, but the sender does not sign every stream.
- DMARC: A record exists, but reporting is not being reviewed.
Actually healthy
- SPF: Every sender is authorized and SPF uses no more than 10 DNS-querying terms, including nested includes.
- DKIM: Every major stream signs with your domain or a domain DMARC accepts.
- DMARC: Reports show the real senders, failure reasons, and policy impact.
If failures appear only after forwarding, compare the original and forwarded headers. Forwarding can break SPF, and message changes can break DKIM. Ask the recipient admin to review trusted Authenticated Received Chain (ARC) sealers for a legitimate intermediary.
Check reputation and list quality
If authentication passes and headers do not identify a local override, investigate reputation and list quality. Microsoft does not need a broken SPF or DKIM record to junk mail. High complaint rates, poor engagement, sudden volume increases, stale recipients, and commercial content can all create a spam pattern. On shared sending infrastructure, clean DNS does not erase reputation carried by traffic that uses the same IP pool.
Blocklist checks matter here, but they are only one part of reputation. A domain or IP can be absent from every public blocklist (blacklist) and still perform badly at Microsoft because Microsoft has its own data. Use blocklist monitoring because a blacklist listing gives you a concrete remediation path and often explains sudden placement changes.
Reputation signals to triage
These bands are practical investigation priorities, not universal mailbox provider thresholds.
Clean
Monitor
Stable opt-in list, low bounces, low complaints, steady volume.
Warning
Pause segment
Reply or conversion rate drops, bounces rise, or one segment starts complaining.
Critical
Stop and fix
Multiple tenants junk the same stream, blocklist hits appear, or complaints spike.
- Complaints: People marking mail as junk is one of the strongest negative signals for commercial campaigns.
- Bounces: Hard bounces show poor address quality and can hurt a sending stream quickly.
- Engagement: Compare replies and conversions with bounce and complaint trends. Open and click rates alone do not establish inbox placement.
- Volume: New sending patterns need a controlled ramp, especially on new domains or new IPs.
- Consent: Publisher opt-ins need clear proof, source tracking, and suppression if recipients do not recognize your brand.
If Microsoft is quarantining rather than junking the message, the investigation changes. Quarantine often points to stronger policy or threat verdicts. The related O365 quarantine fixes path is worth following when messages never reach the user's Junk Email folder.
Fix the message and sending pattern
Content checks are still real, but they are rarely just about one word in the subject. Microsoft looks at the whole message: links, domains, redirects, branding, plain text quality, HTML structure, unsubscribe handling, attachments, and how recipients react to similar mail.
|
|
|
|---|---|---|
Link domain | URL reputation differs from sender reputation | Use trusted branded links |
Redirects | Tracking chains look risky | Reduce hops |
Attachments | Files trigger extra scanning | Use expected file types and remove unnecessary attachments |
HTML | Broken markup reduces trust | Simplify the template |
Unsubscribe | Difficult exits increase complaints | Provide a clear one-click option |
Common message-level causes of Office 365 junk placement.
For a fast message-level check, send a real campaign sample through the Suped email tester before sending it to a Microsoft seed set. Use it to investigate authentication and message configuration, then verify Microsoft folder placement with recipient evidence.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
The sending pattern matters as much as the template. If you send a new commercial campaign to old contacts, add a new sending domain, increase volume sharply, and switch link tracking at the same time, you cannot isolate which change affected delivery. Keep high-volume marketing and transactional traffic on separate authenticated subdomains and sending streams. Do not rotate domains to escape a damaged reputation. Change one thing at a time and measure folder placement after each change.
Use Suped to verify sender authentication
Suped is the DMARC and email authentication platform behind this site. It collects DMARC aggregate reports, maps sending sources, monitors SPF and DKIM status, and alerts on authentication failures or blocklist (blacklist) changes. DMARC aggregate reports show receiver-reported authentication and policy results, rather than final Inbox or Junk Email placement. This workflow addresses the sender-side evidence in an Office 365 investigation. It does not replace Microsoft tenant message trace or policy review.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Add the domain, let reports collect, verify each sending source, fix any SPF or DKIM mismatch, then use alerts to catch new failures before Office 365 placement drops. MSPs and agencies can manage multiple client domains in one dashboard, which matters when Microsoft spam issues appear across several brands at once.
Best use of Suped in this issue
- Source discovery: Find every system sending mail for your domain before enforcing policy.
- Issue fixes: Use automated detection and steps to fix failed authentication.
- Hosted records: Manage SPF and DMARC changes without repeated manual DNS edits.
- Alerts: Get notified when a new sender, policy failure, or blocklist hit appears.
A practical fix sequence
Use this order to avoid random changes. The point is to isolate the cause, fix the smallest confirmed issue, then retest with the same seed set and the same type of message.
Flowchart showing the Office 365 spam troubleshooting order.
- Confirm scope: Test unrelated Microsoft 365 tenants and non-Microsoft mailboxes; assess personal Outlook.com results separately.
- Save evidence: Collect full headers, delivery location, message trace data, and recent campaign metrics.
- Fix DNS: Correct SPF, DKIM, DMARC, return-path, and tracking domain problems first.
- Segment risk: Pause cold, old, low-engagement, or complaint-heavy segments while testing.
- Reduce triggers: Remove risky links, redirect chains, attachments, and unclear unsubscribe paths.
- Retest: Send the same sample again and compare Microsoft headers before changing another variable.
When to escalate
Escalate to the recipient's Microsoft 365 admin when only one tenant is affected, headers show a tenant policy action, or the message is quarantined by that organization. Ask the admin to check CAT, DIR, SFV, the applied policy, and the recipient's Blocked Senders list. Include the message ID, timestamp with time zone, sender, recipient, full headers, and why the recipient expected the email.
Ask the recipient admin to resolve false positives
If legitimate mail still goes to Junk Email after sender checks, the recipient's admin needs to investigate the applied policy. Microsoft's false-positive troubleshooting guidance separates spam cases from phishing or malware detections.
- Trace the message: In the Exchange admin center, open Mail flow > Message trace and inspect the delivery events. A status of Delivered also covers messages sent to Junk Email or quarantine; it does not prove inbox placement.
- Find the policy source: Check the Tenant Allow/Block List, the user's Blocked Senders list, connection filtering, and mail flow rules. Standard and Strict preset policies take precedence over custom anti-spam policies, so confirm which policy actually covers the recipient.
- Submit a false positive: In Microsoft Defender, open Actions & submissions > Submissions > Emails and select Submit to Microsoft for analysis. Provide the network message ID or original .eml/.msg file and an affected recipient. Select the clean-message option that matches your investigation.
- Apply a narrow fix: Remove an incorrect block or correct the matching rule. If needed, create a temporary allow entry during submission and review its scope and expiry. Keep phishing and malware investigations with the security admin.
- Validate and retain evidence: Allow 15-30 minutes for anti-spam policy changes and up to one hour for mail flow rules, then resend a comparable sample. Confirm the folder and new headers, review the submission verdict, and retain the submission ID for support.
If a message reaches the Inbox and moves later, ask the admin to check mailbox rules and zero-hour auto purge (ZAP). ZAP can move delivered messages after a later spam or threat verdict, so the initial delivery event does not tell the whole story.
Views from the trenches
Best practices
Confirm folder placement across unrelated Microsoft tenants before changing infrastructure.
Review bounces, complaints, opens, and replies before blaming one mailbox provider.
Keep full headers for every test message so filtering evidence stays measurable.
Common pitfalls
Assuming one seed inbox proves all Office 365 recipients see the same placement.
Changing subject lines first while DNS, source reputation, and list quality stay unknown.
Treating active opt-in as enough when recipients do not recognize the sender brand.
Expert tips
Separate transactional, marketing, sales, and publisher traffic before comparing results.
Pause weak segments while testing because complaints can hide the effect of DNS fixes.
Retest one variable at a time so each Microsoft header change has a clear cause.
Marketer view
Marketer from Email Geeks says Office 365 spam placement should first be checked against bounce, complaint, open, and reply trends before assuming a filter problem.
2020-02-27 - Email Geeks
Marketer view
Marketer from Email Geeks says a sender should not assume Microsoft is the only provider affected until there is data across multiple mailbox providers.
2020-02-27 - Email Geeks
