Microsoft 365 emails going to spam: what to check first
Start by establishing whether Microsoft 365 is sending the message, receiving it, or both. Then connect the affected message to its trace, received headers and applicable policies. Changing SPF or disabling a filter without that context can leave the cause unresolved.
- Why can Microsoft 365 email go to spam?
- Email can authenticate correctly and still be classified as unwanted, suspicious or subject to a recipient rule. The sending service and receiving organisation also apply different controls. The useful question is which control acted on the affected message, supported by evidence from that part of the journey.
Separate the sending side from the receiving side
| Situation | Start here | Who can investigate |
|---|---|---|
| Your Microsoft 365 email reaches junk at another organisation | Identify the sending route, review the sender’s trace and request received evidence where possible. | Your administrator, with help from the recipient’s administrator. |
| External email reaches junk or quarantine in your Microsoft 365 tenant | Review the received message, filtering verdict and policy that applied. | Your receiving-tenant administrator. |
| A mailbox cannot send and returns a non-delivery report | Retain the full error and investigate the reported sending restriction or rejection. | Your sending administrator. Involve security if compromise is suspected. |
| Only a CRM or sequencer’s email is affected | Compare its actual route, authentication and message conditions with a direct-send sample. | The application owner and mail administrator together. |
1. Capture one affected message accurately
Record the sender, recipient environment, timestamp with time zone, message ID and the system reporting the problem. Distinguish junk, quarantine, rejection and no reply. If the recipient has simply not answered, placement is still unknown.
Choose a comparable message that behaved differently. Note the sending application, signature, links, attachments and any recent routing change. Keep the original observation separate from assumptions such as “Microsoft is blocking our domain”.
An authorised administrator should obtain received headers through an agreed process. A screenshot of a green score cannot replace the actual result for the affected message. Keep confidential message content and credentials out of an initial enquiry.
2. Read the trace in the correct organisation
Exchange Online message trace (opens in a new tab) helps an administrator follow the processing of a message, including delivery, rejection and deferral. Match the trace to the exact message and inspect the detail behind the status.
Your sending trace does not reveal every decision made inside an external recipient’s environment. If your tenant handed the message to another organisation, receiving-side evidence may still be needed to establish why it reached junk or quarantine.
Microsoft 365 business recipients and personal Outlook.com recipients do not share one administrator view. Establish the actual destination service before choosing an investigation or support route. For the broader distinction, see why delivered does not always mean inbox.
3. Read the filtering evidence alongside authentication
Microsoft documents these fields in its anti-spam message header reference (opens in a new tab). Interpret the header added by the relevant receiving system in the context of its route and policies.
| Field or result | What it helps explain | What it does not establish |
|---|---|---|
| Authentication-results | The reported SPF, DKIM and DMARC results. | That the message was wanted or reached the inbox. |
| CAT and DIR | The threat-policy category and message direction. | A full explanation of every signal used in the decision. |
| SFV | The documented filtering verdict or relevant bypass, blocking or rule treatment. | That the same result applies to other messages or tenants. |
| SCL | A spam confidence value. Microsoft says it does not determine the filtering decision or action in cloud organisations. Use CAT and DIR to understand filtering. | A standalone root cause or universal rule for cloud-mailbox placement. |
4. Verify authentication on the affected sending route
SPF and DKIM help authenticate sending identity. DMARC tests alignment with the visible From domain through a passing SPF or DKIM result. Passing authentication does not override every other receiving control. See Microsoft’s email authentication guidance (opens in a new tab).
Compare a message sent directly with one sent through the affected application. Check the results after the actual route has been used. The CRM may use a different sending service, and intermediaries may change how the message arrives.
Do not add a second SPF record or copy a record from another company as a trial fix. Any configuration correction should follow the requirements of the real sending services and an agreed change plan.
5. Check outbound controls when your tenant is the sender
Microsoft scans outbound messages and can restrict sending accounts. Its outbound spam protection guidance (opens in a new tab) describes both spam-related restrictions and sending-volume controls. An administrator should investigate a reported restriction and the associated alerts.
Microsoft also uses a high-risk delivery pool (opens in a new tab) for messages it identifies as outbound spam. Delivery from that pool is not guaranteed. Do not infer that a mailbox used this pool just because a recipient found one message in junk.
If unauthorised sending is suspected, the security investigation comes first. Adding mailboxes, switching domains or retrying the same campaign does not resolve a compromised account or an unsuitable sending practice.
6. Handle a false positive through the receiving administrator
When legitimate email is incorrectly filtered, the receiving administrator should inspect the detection and applicable policy before choosing a correction. Microsoft publishes a false-positive investigation workflow (opens in a new tab), including message evidence and submissions.
A broad allow rule can conceal the condition being investigated and change protection for unrelated messages. Prefer a justified, narrowly scoped correction with a named approver and a verification plan.
A correction in one customer’s tenant does not repair delivery everywhere. Record which environment was changed, what was tested afterwards and what remains outside your visibility.
Use a comparison that can answer a question
State the hypothesis
For example, the CRM route appears to behave differently from direct sending. This is a question to test, not a conclusion.
Agree a controlled sample
Use suitable test recipients and keep relevant conditions consistent. Record the message version and sending route. Avoid repeated unsolicited testing against customers.
Compare the received evidence
Review authentication, filtering and trace information together. A changed template and a changed provider in the same test make attribution harder.
Verify the scoped correction
Repeat the comparable check after an approved change. A successful sample is useful evidence, with limits, rather than a guarantee for future recipients.
When to bring in a deliverability specialist
Specialist help is useful when the issue crosses sales applications and mail administration, repeatedly returns, or leaves several teams with conflicting evidence. Prepare the symptom and platforms first, then agree the investigation boundary.
Neotiqa provides a read-only deliverability assessment with findings and a practical technical handover. Use the audit checklist to see the evidence and deliverables worth agreeing. Agencies can commission the work through our white-label service.
Questions about Microsoft 365 and junk email
SPF, DKIM and DMARC all pass. Why are messages still junked?
Authentication and filtering answer different questions. Passing authentication can coexist with a spam, impersonation or other policy decision. Review the received message and relevant control instead of treating the authentication result as a placement guarantee.
Does an SCL value tell us exactly why a message went to junk?
No. Use the documented category, direction, filtering information and applicable policy together. A single value is not a complete explanation of the receiving system’s decision.
Can we fix this by asking everyone to allow our domain?
A recipient-specific exception may affect that environment, but it does not establish or resolve the underlying cause across other recipients. The administrator should investigate the verdict and choose a proportionate action.
Can Neotiqa work with our existing Microsoft 365 provider?
Yes. Your administrator or MSP can supply evidence through guided sessions or agreed exports and retain control of production changes. The assessment and any later implementation have separate written scopes.
Still unclear where the problem sits?
Tell us whether Microsoft 365 is the sender, the recipient or both, and describe what you have observed. We can help scope the investigation.