One of the layers of processing in Exchange Online Protection is mail flow rules. You might know these from their previous name in Exchange Server, which was transport rules.
The name transport rules aligned with the naming of the Hub Transport server role, first introduced in Exchange 2007. In the latest versions of Exchange, that role no longer exists. The Mailbox server role now provides that functionality. Transport rules and mail flow rules the same thing. The capabilities of the rules have improved a lot since those early days in Exchange 2007. And calling them mail flow rules makes more sense to some people because “mail flow” is an easy concept to understand. The name “transport” is a little bit vague and wouldn’t make sense to someone who hasn’t worked with those older versions of Exchange.
Mail flow rules can provide a wide range of policy enforcement outcomes. They can also fight spam and other unwanted types of email.
Now, some of you might be asking, should we need to fight spam by creating mail flow rules in Exchange Online? Doesn’t that seem a bit old school? Especially when there are complex antispam algorithms running behind the scenes in Exchange Online Protection?
That’s a fair question. And yes, it does go back to the good old days of spam fighting where a lot of spam was blocked with very simple keyword-based rules. That was before antispam products evolved to include more intelligent detection. But even the most intelligent spam filters still miss things. And we need to use every tool at our disposal to tailor our antispam protection to suit our organization.
Sometimes that means creating mail flow rules to do things like:
- Allowing or blocking specific IP addresses, domain names, and email addresses.
- Blocking specific keywords, whether that’s to detect text in the message or even a URL that the message might contain.
- Tagging all email that is inbound from external senders that contains suspicious keywords.
Mail flow rules are also effective against fresh, new attacks and campaigns. Sometimes you need a quick solution while you wait for EOP to start detecting a new attack.
Yes, EOP should prevent most attack scenarios for you. But security is all about mitigating risks using all reasonable means at our disposal.
Here’s an example. Consider a sales contact form running on a company website. The company website is hosted on shared hosting server, provided by a web hosting company. The sales team wants to ensure that no contact form emails are filtered by Exchange Online Protection. Weakening the entire organization’s protection is not a good solution. Instead, one option to achieve this is to add the web server IP address to the IP allow list in your EOP connection filter policy. This will prevent the connection filter from blocking the email.
However, by using the IP allow list you are allowing all email from that web server’s IP address to bypass your spam filters. In effect, you’re trusting the web hosting company to prevent other customers who are also on the shared hosting server from spamming or phishing your users. It’s unlikely that the web hosting company will be able to prevent that. Furthermore, any insecurity in the web form itself could lead to abuse.
So, to enhance your protection without opening yourself up to a new risk, you can use a mail flow rule instead. The mail flow rule is configured to ensure that mail from the web server is still subject to spam filtering if it doesn’t have the specific characteristics of the sales contact form emails. To achieve this, create a mail flow rule such as the following:
Mail flow rules can also be used to combat malicious emails. A lot of phishing attacks rely on impersonation of popular services like Amazon, Dropbox, Docusign, banks, and even Office 365. These attacks can be difficult for even a human to spot, so it’s no surprise that they sometimes slip past Exchange Online Protection’s defences.
However, you can mitigate these risks by using mail flow rules with regex filters to detect likely phishing attempts. You can then either quarantine them, send them to junk folders, or modify them in some way to alert the user that the mail is suspicious. Popular Twitter personality @SwiftOnSecurity has helpfully shared a series of regex patterns and other text strings in this GitHub repository.
You should use caution when applying these patterns in your mail flow rules. I don’t recommend setting up rules to immediately delete or block the mail until you have an understanding of what is being detected. Using non-destructive actions such as prepending the subject line, or raising the SCL so the message is delivered to junk mail, are reasonable approaches. Another good approach is to configure the rules to send incident notifications, or add a BCC recipient for a shared mailbox so you can review the messages that are triggering the rule. @SwiftOnSecurity has another repository with details of mail flow rules that you can use as well.