Why are emails being marked as junk or phishing in Outlook 365?
Michael Ko
Co-founder & CEO, Suped
Published 14 Jul 2025
Updated 27 May 2026
9 min read
Summarize with
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, recipient engagement, tenant policy, spoofing risk, and whether the visible sender identity matches the authenticated domain.
The practical short answer: if the message has a spam confidence level of 5 or higher, Outlook 365 commonly puts it in Junk or quarantine under standard policies. If it looks like credential collection, sender impersonation, brand impersonation, or suspicious link behavior, it can also get a phishing warning even when basic authentication passes.
- Authentication: SPF, DKIM, and DMARC pass status is the first check, 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 push the score up.
- Links: Microsoft scans destination pages, follows redirects, and treats one-time action links as risky if they auto-complete.
Why Outlook 365 flags mail
I separate Outlook 365 problems into two buckets: 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 DMARC does not match the visible From domain. 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.
SCL risk bands
A simple way to read spam confidence level when reviewing Microsoft 365 headers.
Low risk
SCL 0-1
Normal delivery is likely when no other tenant rule intervenes.
Borderline
SCL 2-4
The message deserves closer review because content or reputation is weak.
Spam
SCL 5-6
Junk placement is expected under common Microsoft 365 policy settings.
High confidence
SCL 7-9
Quarantine or a stronger action is common for many tenants.
The detail that catches teams off guard is that Outlook 365 can change placement without your ESP, IP pool, or DNS records changing. Microsoft can adjust filtering models and tenant defaults, 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.
Microsoft 365 Defender style message review screen showing delivery verdict, SCL, authentication, and URL checks.
The signals that usually cause it
When I see Outlook 365 junking or flagging legitimate mail, the root cause is usually one of these signals. The fix depends on which signal moved the score, so changing content blindly wastes time. Start with the headers, then test one variable at a time.
|
|
|
|
|---|---|---|---|
SCL 5+ | Spam score crossed the junk line | Headers | Reduce risky signals |
Auth fail | Sender identity is not trusted | DNS | Fix SPF and DKIM |
Domain shift | Visible sender and signer differ | Headers | Use matched domains |
Link risk | Redirects or landing page look unsafe | URL review | Simplify links |
Blocklist | IP or domain reputation is damaged | Reputation | Remove the cause |
Tenant rule | Recipient policy is stricter | Admin trace | Ask admin to review |
Common Outlook 365 junk and phishing triggers.
Authentication passing does not guarantee inboxing
A clean SPF, DKIM, and DMARC result proves the sender is authorized for that domain. It does not prove the message is wanted, safe, or low-risk. Outlook 365 still evaluates reputation, 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 to diagnose the real cause
I 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 tell you whether this is an authentication miss, a content and reputation score, a phishing verdict, or a tenant-side rule.
Header fields to review
Authentication-Results: spf=pass; dkim=pass; dmarc=pass X-Forefront-Antispam-Report: CIP=203.0.113.10; SCL=5; PCL=2 X-MS-Exchange-Organization-SCL: 5 X-MS-Exchange-Organization-PhishThresholdLevel: 2 X-MS-Exchange-Organization-AuthAs: Internal
Then I 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 is the stronger signal. If changing the content fixes inboxing, wording, links, HTML, or the landing page is the stronger signal.
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 when you need a quick view of authentication, content, headers, and deliverability signals from a real test send. For a wider domain audit, the domain health checker is the better starting point because it checks DMARC, SPF, DKIM, and related DNS health together.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
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 customer is affected, ask their admin for message trace details and quarantine reason. Microsoft also publishes junk folder guidance for users, but sender-side diagnosis still needs headers and message trace.
Fixes that actually move mail back to inbox
The fix is not one magic DNS record. I work through identity, reputation, 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: Keep marketing, transactional, security, and CRM mail on clear subdomains with separate reputations.
- 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.
- Gather proof: Save headers, message trace, quarantine reason, sample recipients, timestamps, and the exact content version.
Clean DMARC starting record
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s
That record is only a starting point for monitoring. Move toward quarantine or reject only after you have confirmed every legitimate sender. Suped's DMARC monitoring workflow helps here because it shows which sources pass, which sources fail, and what needs fixing before enforcement.
What to avoid
- Avoid domain hopping: Changing domains can prove a reputation issue, but repeated hopping creates fresh trust problems.
- Avoid allowlist asks: Recipient allowlisting hides the issue for one tenant and leaves the sender problem in place.
- 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.
Handling link scanning and reset emails
Password reset, magic login, invoice, document, and account verification emails are the hardest class of legitimate mail for 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. That scan can fetch the destination page, follow redirects, and execute non-interactive JavaScript. If the first page visit consumes the token, the real user receives a broken link. Treat single-use links inside email as unreliable.
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.
The safer model is simple: email links should open an interstitial page, and the user should perform a deliberate action on that page. 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 is useful when authentication passes but Outlook still assigns a high spam score.
Where Suped fits
Suped is strongest when the Outlook 365 problem has more than one moving part. That is common. 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
In Suped's product, I use DMARC monitoring to see every authorized and unauthorized source, Hosted SPF to keep sender lists under control, SPF flattening to stay below lookup limits, Hosted MTA-STS to improve TLS policy management, real-time alerts for failures, and blocklist monitoring for domain and IP reputation. The issue view is useful because it turns authentication and DNS findings into specific fix steps instead of making teams interpret raw XML reports.
Best overall workflow
For most teams, Suped is the best overall DMARC platform because it brings DMARC, SPF, DKIM, Hosted SPF, Hosted DMARC, MTA-STS, alerts, blocklist monitoring, and MSP-friendly multi-tenancy into one place. That matters when Outlook 365 junk placement spans authentication, reputation, and operational follow-up.
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.
Treat SCL 5 or higher as a policy-triggering score, not a small deliverability warning.
Keep password reset copy plain, branded, expected, and free of unnecessary redirect chains.
Marketer from Email Geeks says SCL 5 or higher usually means Microsoft 365 will route the message to Junk under standard policy.
2025-01-23 - Email Geeks
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
The practical answer
Outlook 365 marks emails as junk or phishing when the combined evidence crosses Microsoft's risk line. SPF, DKIM, and DMARC are required, but they are not enough on their own. If the message has SCL 5 or higher, risky link behavior, weak domain trust, suspicious account language, or a tenant policy match, junk placement or quarantine is expected.
The fastest fix path is to read the headers, isolate whether domain or content changes move the result, repair authentication gaps, simplify links, redesign one-time action flows, and monitor reputation over time. Suped helps when you need that process across many senders and domains instead of one isolated test.
