Exchange Online: Email Messages Delivered to Junk Mail Folder

When users report to IT support that Exchange Online delivers email messages to the Junk Email folder of their mailbox incorrectly, the reason is often a misconfiguration of Exchange Online Protection settings. Such a situation mainly affects Exchange Hybrid configurations that use the centralized message flow.

In our example, a recipient in the varunagroup.de domain receives a message from a sender in the setebos-ag.com domain. Those messages end up in the Junk Email folder.

As a reminder, when using the centralized message flow, incoming messages from the Internet are delivered to the on-premises Exchange organization. The on-premises Exchange organization delivers email messages for recipients with a mailbox in Exchange Online via the secured hybrid SMTP route. To do this, the Hybrid Configuration Wizard has created the necessary connectors in the on-premises organization and Exchange Online. The following simplified diagram illustrates this configuration:

But why are incoming messages now delivered to the Junk Email folder?

The why

To understand why messages are delivered "incorrectly," we need to look at the message header information. You find the email header information in the properties of the affected message. Copy the header information to the clipboard and examine the data with one of the Message Header Analyzers (MHA) available on the Internet. I prefer to use Microsoft's Analyzer for this purpose because it directly processes Forefront Antispam header data. In addition, I use the analyzer from MX Toolbox because it includes checks for DMARC, SPF, and DKIM.

The following example shows the Forefront Antispam Report headers of a setebos-ag.com message delivered to the Junk Email folder by Exchange Online:

The Forefront components of Exchange Online Protection classified the message as spam because of the assessed Spam Confidence Level (SCL) of 5.

Each Exchange Online client includes default anti-spam policies for inbound and outbound messages that cannot be disabled. However, you can customize the settings of these policies. In this case, the inbound policy classified the message as spam based on the SCL rating of 5. But the real question is, why is this message rated with a value of 5 in the first place?

Let us take a look at other header information:

Exchange Online Protection checks if the SPF record of the sender domain covers the system's IP address submitting the message. Since the message is delivered from an "internal" Varunagroup system, this IP address can never be part of the SPF configuration of the sender domain. The header data shows that the check of the SPF DNS record for the sender domain setebos-ag.com failed (spf=fail).

The following diagram illustrates the problem again graphically:

So what could be more logical than to skip checking this IP address in Exchange Online Protection? In the Microsoft 365 Defender Portal you find rules for configuring advanced filtering for inbound connectors in Exchange Online. These rules are part of the threat policies.

The Enhanced Filtering page shows all inbound connectors for on-premises servers of your organization to Microsoft 365. The page does not show connectors for partner organizations. To solve the problem of incorrect SPF checking, select the connector and choose the "Automatically detect and skip the last IP address" setting.

Likewise, we configure IP address filtering for the entire organization. After this configuration change, Exchange Online should not deliver incoming messages to the Junk Email folder.

If you are using an alternative configuration for SMTP connections to Exchange Online, you may need to use one of the other two options. Here's online documentation from Microsoft with more information about advanced filtering for incoming connectors.

The SMTP protocol, Exchange Server and Exchange Online allow various configurations between an on-premises Exchange organization and Exchange Online. Exchange is a very liberal product in this regard.

You can use any product as an SMTP gateway (on-premises or cloud). Some of those products provide direct connectivity to Exchange Online. This type of SMTP connectivity is not a hybrid SMTP connection but is also subject to the same risk of delivery failures.

The header information of an email message contains all the information related to the delivery of an email message. All the systems a message passes through more or less leave their traces in the header information. Therefore, the message header information is your starting point for analyzing email delivery issues.

If you want to analyze the anti-spam header information yourself, I recommend the Python script decode-spam-headers.py on Github.

Enjoy Exchange Online!

Links

• Message Header Analyzer (MHA)
  
  
• Anti-spam message headers in Microsoft 365
  
  
• Enhanced Filtering for Connectors in Exchange Online
  
  
• Decode Spam Headers - Python Script

Exchange Hybrid and Office 365 Monitoring and Reporting

On-premises components, such as AD FS, PTA, and Exchange Hybrid are critical for Office 365 end user experience. In addition, something as trivial as expiring Exchange or AD FS certificates can certainly lead to unexpected outages. By proactively monitoring hybrid components, ENow gives you early warnings where hybrid components are reaching a critical state, or even for an upcoming expiring certificate. Knowing immediately when a problem happens, where the fault lies, and why the issue has occurred, ensures that any outages are detected and solved as quickly as possible.

Access your free 14-day trial of ENow’s Exchange Hybrid and Office 365 Monitoring and Reporting today!