---
title: "Troubleshoot email landing in Microsoft 365 Junk"
description: "Diagnose legitimate email landing in Microsoft 365 Junk, collect message headers, and work with the recipient administrator on a review."
canonical: "https://bird.com/docs/knowledge-base/deliverability/microsoft-365-junk"
---

# Troubleshoot email landing in Microsoft 365 Junk

Use this guide when email you send through Bird reaches an Exchange Online mailbox but appears in **Junk Email**. A password reset can pass authentication and still receive a spam or phishing verdict.

An Outlook.com or Hotmail inbox test does not establish how a business mailbox handles your messages. [Personal Outlook.com accounts and organizational Microsoft 365 accounts are different services](https://support.microsoft.com/en-us/outlook/how-to-sign-in-to-outlook-on-the-web). The recipient organization's protection policies can affect placement.

## Collect fresh examples

Collect two or three fresh affected examples and an inbox example when available. You need your Bird email log, the recipients' original messages, and help from their Microsoft 365 administrator. For each example:

1. Send a fresh test through the same application and sending domain that produce the affected mail. Record the recipient, subject, and send time with its time zone.
2. Find the message in the [email log](/docs/guides/email/email-log). Save its Bird message ID and per-recipient timeline. **Delivered** means the receiving mail server accepted the message; it does not confirm inbox placement. If the message bounced or was rejected, follow the failure shown in the log instead.
3. Ask the recipient to export the original message as an `.eml` or `.msg` file, or provide its full headers. A screenshot of the Junk folder does not contain the evidence needed to investigate.

Keep the original file for the administrator's submission. Share message evidence through an agreed secure support channel, since it can contain recipient details and password-reset links.

## Check authentication and Microsoft's verdict

Use the [Email header analyzer](/tools/email-analyzer) to read SPF, DKIM, and DMARC results and relay hops from the received headers. If authentication fails, check your [sending domain setup](/docs/guides/email/sending-domains) before repeating the test.

Ask the recipient administrator to inspect the threat category (`CAT`), message direction (`DIR`), and spam-filtering result (`SFV`) where present. Microsoft's [anti-spam header reference](https://learn.microsoft.com/en-us/defender-office-365/message-headers-eop-mdo) explains these fields. Keep the complete headers rather than copying isolated values.

Compare verdicts and connecting IPs across the examples to check whether the issue follows a particular IP or affects several. Microsoft's `CIP` field records the connecting IP; with an intermediary, it can differ from the original sending IP. Use the relay hops to check the path.

Passing SPF, DKIM, and DMARC does not guarantee inbox placement. Microsoft [also evaluates reputation and other signals](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-about#inbound-email-authentication-for-mail-sent-to-microsoft-365).

## Ask the recipient administrator to review the message

If the administrator confirms that the email is legitimate, ask them to follow Microsoft's [Report good email to Microsoft procedure](https://learn.microsoft.com/en-us/defender-office-365/submissions-admin#report-good-email-to-microsoft). They can submit the original email file or network message ID and specify the affected recipient. That recipient context helps Microsoft check the applicable organization and user policies.

The administrator should review the submission result and the policy that detected the message. A submission does not automatically override impersonation protection. Any policy exception needs their assessment; avoid blanket allowlisting or disabling protection to make a test pass.

## Retest and escalate if needed

After the administrator completes the review or makes a targeted correction, send another fresh message through the original sending path. Confirm its folder with the affected recipient and compare the new headers.

If it still lands in Junk, share the original and retest examples, Bird message IDs, timestamps, affected recipient domains, and the administrator's findings with support. Include whether the problem affects one organization or several.

Changing to a dedicated IP does not guarantee a fix. Low or irregular sending volume can make a new IP's reputation harder to establish. Review [dedicated IPs and pools](/docs/guides/email/dedicated-ips-and-pools) before changing infrastructure.

## Next steps

- [Avoiding the spam folder](/docs/knowledge-base/deliverability/spam-folder): review content, consent, and sender reputation.
- [Email log](/docs/guides/email/email-log): inspect delivery outcomes for individual messages.
- [Sending domains](/docs/guides/email/sending-domains): verify your sender authentication setup.

## Related resources

- [What happens between send and the inbox](/learn/email/what-happens-between-send-and-the-inbox) (video)
- [What are bounced emails?](/explained/deliverability/what-are-bounced-emails) (answer)
- [Email deliverability](/email-api/features/deliverability) (product)
- [Operate messaging reliably](/learn/paths/reliability) (course)

[Get an implementation brief](/learn/workspace?topic=email-delivery)