SOLVED

SPF exception in EOP

Copper Contributor

Can I configure something like SPF exception for particular incoming SMTP domains? I mean- if I receive emails from domains with not properly configured or without SPF records I don't want to have this emails in junk or quarantine. I think allow list is not good solution because I also don't know to bypass this emails without any kind of scanning. Can I achieve this functionality in EOP? I have this option in Forti Mail for example...  

6 Replies
Mailflow rule with a rewrite of the scl score. But it is not recommended

@RobertS00 

When an email is sent from a domain with no SPF published and DKIM not enabled, the emails fails authentication and may be delivered to Junk or Quarantine. 

 

You can create a transport rule to set the SCL (spam confidence level) of emails sent from the domain to -1 but this is not recommended as all emails from the domain will not be filtered in this case. The screenshot below shows the configuration of the rule. 

  • RecepGencaslan_0-1675987497671.png

     

If the email will be coming from a specific static IP address, I will recommend you add the IP address to the allow list of the connection filter policy as only emails from the IP will be delivered and this will help should in case the domain get spoofed. 

 

If I have answered your question, please mark your post as Solved

If you like my response, please give it a Like :smile:

Appreciate your Kudos! Proud to contribute!

best response confirmed by RobertS00 (Copper Contributor)
Solution
TenantAllowBlockListSpoofItems are meant for cases when organizations sending you messages don't have their configuration in order. I prefer not using rules, as 1) over time people don't maintain these, 2) they tent to grow and nobody knows what these entries were for in few months. When submitting TABL (through submit false positives), you can also time-restrict the exception, as the sender needs to take action (and you are usually not the only recipient having to implement workarounds)
yes, thank you, it make sense
thank you, clear everything

@RobertS00 

 

Hi Robert,

 

Yes, it is possible to configure SPF exceptions for specific incoming SMTP domains in Microsoft Exchange Online Protection (EOP). To do this, you need to create a custom connection filter that bypasses SPF checks for emails coming from specific domains. Here's how to create a custom connection filter:

  1. Log in to the Microsoft 365 admin center.

  2. Go to the Security & Compliance Center.

  3. Go to Threat management > Policy > Connection filter.

  4. Click the Add button to create a new connection filter.

  5. Enter a name for the connection filter, and select the "Bypass SPF check" option.

  6. In the "Apply this connection filter to" section, select the domains for which you want to bypass the SPF check.

  7. Save the connection filter.

Once you have created the custom connection filter, EOP will bypass the SPF check for emails coming from the specified domains, and the emails will not be sent to the junk or quarantine folder.

Please note that bypassing the SPF check for specific domains can reduce the effectiveness of your spam and phishing protection, so it should only be used as a last resort if necessary. Additionally, make sure to regularly review and update your connection filters to ensure that they are effective in protecting your organization from unwanted email.

 

(external link removed by moderator)

1 best response

Accepted Solutions
best response confirmed by RobertS00 (Copper Contributor)
Solution
TenantAllowBlockListSpoofItems are meant for cases when organizations sending you messages don't have their configuration in order. I prefer not using rules, as 1) over time people don't maintain these, 2) they tent to grow and nobody knows what these entries were for in few months. When submitting TABL (through submit false positives), you can also time-restrict the exception, as the sender needs to take action (and you are usually not the only recipient having to implement workarounds)

View solution in original post