Internal Email Going to Junk in Microsoft 365: How to Fix It

If you are asking why is internal email going to junk in Microsoft 365, the short version is that the message failed a security check — not that it looked like spam. Exchange Online Protection (EOP) filters every message before it reaches a mailbox, including mail sent between two people on the same domain. When something in the delivery path changes the message or its source, EOP can no longer prove the sender is who they claim to be, so it treats a colleague like a stranger — moving the message to Junk, quarantining it, or flagging it as phishing.

This is almost always fixable, and the fix lives in the Microsoft 365 admin and Defender portals rather than in Outlook. This guide walks the causes in the order worth checking, with the exact settings, PowerShell, and header values Microsoft documents — verified against Microsoft Learn as of August 2026.

What "internal email going to junk" actually means#

Every mailbox in Microsoft 365 sits behind Exchange Online Protection. EOP checks each message against email authentication — SPF, DKIM, and DMARC — and against anti-spoofing intelligence before it decides where the message goes. Internal mail is not exempt from those checks.

When authentication passes and the sending domain aligns with the From address, a colleague's message lands in the inbox. When it fails, EOP has three actions available: deliver to the Junk Email folder, hold it in quarantine, or reject it with a non-delivery report (NDR). Which one happens depends on your anti-spam and anti-phishing policies and on the sending domain's DMARC policy.

The important part: EOP is usually reacting to a broken signature or an unexpected source IP, not to the words in the email. That is why a plain "lunch at noon?" from the desk next to you can land in Junk while obvious junk sails through — the junk had valid authentication, and your colleague's message, after a detour through a gateway, did not.

Why internal email gets junked: the usual causes#

Most cases trace to one of five causes. Read the message header of an affected email first — every diagnosis below comes from values there — then match your symptom to this table.

How a message loses its authentication in transit#

Most internal-junk cases come down to one thing: a hop between the sender and Microsoft 365 changed the message. A hybrid on-premises server, a third-party security gateway, or a mailing list re-sends the message from its own IP and sometimes edits the body — adding a disclaimer or a scan notice.

That single change is enough to break authentication. SPF fails because the source IP is now the gateway's, not the original server's. DKIM fails because the body hash no longer matches the signature. DMARC then fails because neither SPF nor DKIM aligns with the From domain, and EOP has nothing left to trust — so it junks a message your colleague genuinely sent.

Fix 1: Turn on Enhanced Filtering for Connectors (skip listing)#

If mail reaches Microsoft 365 through a hybrid server or a non-Microsoft filter — that is, your MX record points somewhere other than Microsoft 365 first — Enhanced Filtering for Connectors (also called skip listing) tells EOP to ignore the last hop's IP and evaluate the true source instead. This restores explicit SPF, DKIM, and DMARC checks on the original sender.

1. 1

   Open the connector's filtering settings

   In the Microsoft Defender portal at security.microsoft.com, go to Email & Collaboration > Policies & Rules > Threat policies > Rules > Enhanced filtering. The direct link is security.microsoft.com/skiplisting. Select the inbound connector that carries the affected mail.

2. 2

   Choose which IPs to skip

   Pick "Automatically detect and skip the last IP address" if only one hop sits in front of Microsoft 365, or "Skip these IP addresses that are associated with the connector" and list every public IP of your on-premises or gateway hosts. Microsoft 365 IPs and private RFC 1918 addresses are not supported and are skipped automatically.

3. 3

   Scope it to a test group first

   Under "Apply to these users", start with "Apply to a small set of users" and list the exact recipient addresses to validate, then switch to "Apply to entire organization". In hybrid setups you specify the MailUser TargetAddress, for example [email protected].

4. 4

   Or use PowerShell

   In Exchange Online PowerShell: Set-InboundConnector -Identity "From Anti-Spam Service" -EFSkipLastIP $true. Use -EFSkipIPs to name specific IPs and -EFUsers to scope recipients.

5. 5

   Remove any SCL -1 rule

   After enabling skip listing, disable any mail flow (transport) rule that sets the SCL to -1 on that connector, or it will bypass the filtering you just re-enabled. Confirm success by the X-MS-Exchange-SkipListedInternetSender header stamped on new messages.

Fix 2: Add the gateway as a trusted ARC sealer#

When the intermediary edits the message and cannot be made to preserve the source IP, a trusted ARC sealer is the answer. Authenticated Received Chain (ARC) records the original authentication results before the message is changed; once you tell EOP to trust that service's seal, EOP can use those original results and override the SPF, DKIM, or DMARC failures the change caused. This only works if the service actually adds ARC headers.

1. 1

   Find the sealer's signing domain

   Open a message header (in Outlook: File > Properties > Internet Headers, or the Message Header Analyzer at mha.azurewebsites.net) and find the ARC-Seal header. Note the d= value — that is the vendor's signing domain, not your own domain.

2. 2

   Add it in the Defender portal

   Go to security.microsoft.com/authentication (Email authentication settings), select the ARC tab, choose Add, enter that d= domain, for example fabrikam.com, and Save.

3. 3

   Or use PowerShell

   Run Set-ArcConfig -Identity Default -ArcTrustedSealers "domain1.com","domain2.com". This parameter replaces the whole list, so include any sealers you already trust. Run Get-ArcConfig first to see them.

4. 4

   Validate it worked

   Allow up to 30 minutes, then send a fresh test. In the last ARC-Authentication-Results header look for arc=pass and oda=1; in Authentication-Results look for compauth=pass reason=130, which means a trusted ARC sealer overrode the DMARC failure.

Fix 3: Repair your own domain's authentication#

If the header shows compauth=fail with reason 010 and the sending domain is your own, EOP is telling you that a message using your domain failed DMARC and looked spoofed. Microsoft's troubleshooting guidance describes reason 010 as a message that failed DMARC where the sender's policy is quarantine or reject and the sending domain is one of your organization's accepted domains. It is common when an on-premises application, a printer or scanner, or a marketing tool sends as your domain from an IP your records do not list. The fix is to authenticate the real source, not to weaken DMARC.

1. 1

   Identify the real sending source

   From the header, find the sending IP and the smtp.mailfrom domain. Message trace in the Exchange admin center confirms where the message actually originated — an app server, a relay, or a hybrid host.

2. 2

   Add the source to SPF

   Publish that source in your domain's SPF TXT record, either as an ip4: entry or a service include, for example: v=spf1 ip4:<sending-IP> include:spf.protection.outlook.com ~all. Keep one SPF record per domain and stay under 10 DNS lookups.

3. 3

   Enable DKIM for the domain

   In Exchange Online PowerShell run Set-DkimSigningConfig -Identity contoso.com -Enabled $true, after publishing the two CNAME records Microsoft generates. A DKIM signature that aligns with your domain gives DMARC the aligned pass it needs even when SPF does not align.

4. 4

   Allow a known internal sender if needed

   If a trusted internal source cannot be authenticated, review the Spoof intelligence insight in the Defender portal and allow it through the Tenant Allow/Block List (New-TenantAllowBlockListSpoofItems). Treat this as a last resort — an allow entry is a standing exception, so fix the authentication where you can.

How to tell which cause you have#

Open the message header of one affected email and read the Authentication-Results line. Every diagnosis in this guide comes from a handful of values there. Use Outlook's internet-headers view, or paste the header into the Message Header Analyzer at mha.azurewebsites.net.

Preventing it from coming back#

Once mail is flowing again, a few habits keep internal messages out of Junk for good.

• Publish SPF, DKIM, and DMARC correctly for every domain and subdomain you send from, and keep DMARC at p=none until aggregate reports look clean before moving to quarantine or reject.
• Add Enhanced Filtering or a trusted ARC sealer for every gateway or hybrid path — not just the one you fixed today.
• Avoid message modification where you can: disclaimers and body edits applied after signing are the most common cause of dkim=fail (body hash did not verify).
• Register every internal sender — apps, relays, scanners, marketing tools — in SPF and DKIM before they start sending as your domain.
• Monitor with message trace and the Threat protection status report, so a new failure surfaces before users start distrusting the mail system.

Can an email app fix this?#

No — and any tool that claims it can is pointing you at the wrong layer. Internal mail landing in Junk is an Exchange Online Protection decision, and the levers that change it live in the Microsoft 365 admin and Defender portals: connectors, ARC, SPF, DKIM, DMARC. A mail client connects to your mailbox after EOP has already ruled, so it cannot overturn that verdict. AI Emaily is a client, so on this specific problem the honest answer is that the admin fixes above are the fix.

Where a client earns its place is the mail that does arrive. Once delivery is healthy, AI Emaily handles triage and automatic filing of what lands in the inbox, separating real colleague mail from cold outreach by sender behaviour and domain rather than a single address — and every automatic action is undoable and audited. We build AI Emaily; it runs as a 7-day free trial on the paid plans, and it does not replace your EOP configuration.