My use case was Nagios notification not delivering into our user’s inbox but rather into the Junk folder because of not having the right domain name. In other to prevent this false positive from moving emails from a specific Email ID to the JUNK folder in Outlook. Kindly refer to this related guide: How to configure WSUS Email Notification to Work With Office365.
For more articles I have written, see the following hyperlinks below; How to set up and configure Windows server update services (WSUS), important Areas to Master on WSUS (Installed and not applicable, Install 1/4, and Installed / Not applicable 100), how to configure WSUS Clients to get Updates from the WSUS server using Registry settings, how to apply Windows Updates from WSUS to the server using AWS RunCommand, how to Configure SSL between WSUS servers (Upstream and Downstream Servers).
Note: These emails were filtered out because of the following reasons,
- Because we had the safe lists enabled, only emails from specific domains are allow and delivered to inbox in Outlook. (i,e. name@iPAddress.eu-central-1.compute.internal), This does not have the right domain name and thus goes to the junk folder. To mitigate against this, i had to create a rule to deliver this this to user mailbox correctly.
- We need to add the email addresses to allow (spam filter policy) Options
- You can use a safe sender list or a mail flow rule to bypass spam filtering and prevent good email messages from getting marked as junk mail.
Steps to Fix (using Mail flow rule)
Search and get the the email header from a message sent by the sender that you want to allow as shown below.
To configure the Spam Filter Policy
Use the Exchange Admin Center (EAC) to configure spam filter policies
In the Exchange admin center (EAC), - navigate to Protection - Spam filter.
Do one of the following on the general page as shown below.
- Double-click the default policy in order to edit this company-wide policy. OR
- Click the Add Icon New icon in order to create a new custom spam-filter policy that can be applied to users, groups, and domains in your organisation.
Note: You can also edit existing custom policies by double-clicking on them. There is no need to create a transport rule for this basic task to bypass an IP.
I hope you found this blog post helpful. If you have any questions, please let me know in the comment session.