In this post, we’re going to discuss mail flow rules in Exchange Online and the role they can play in spam prevention. Mail flow rules look for messages that match a specific criteria or conditions, and then take actions on those messages. It’s very simple and at the same time, incredibly powerful. The four components of a mail flow rule are:
- CONDITIONS–> These cover a broad range of message characteristics such as the sender details, the recipient details, message contents, attachment contents, and get into quite a lot of detail.
- EXCEPTIONS –> are used to exclude messages from the mail flow rule. So if you’ve got a rule that looks at the sender’s domain because you want to block that domain, you can set an exclusion that says just one particular email address from that domain is excluded from the rule. So in effect, it will be the only email on that domain that isn’t blocked by your mail flow rule.
- ACTIONS –> which go beyond just blocking or allowing messages, are letting you take other actions like tagging subject lines or adding special headers, redirecting messages to different recipients, adding a disclaimer, and lots more.
- PROPERTIES –> are additional controls such as whether the rule is enabled or disabled, whether it’s in test mode, whether it should automatically turn on or off at a particular time and date.
After a short introduction, let’s go ahead and create mail flow rules. Mail flow rules are managed in the mail flow section of the Exchange admin center. When we create a new rule, you can see a few rule templates here that are ready to choose from for common scenarios.
Let’s say that we have scenario where we need to add our web server’s IP address to Allow list in Connection Filtering. When we do that, all messages will be allowed and nothing will be blocked. Now at some point, users notice that they are receiving to many fake messages, someting is spamming the form with all kind of junk about fake iPhone phones. Users want that we stop that but allow everything else from the web server.
Let’s start from a blank rule. Click on a + sign and select Create a new rule
New rule window pops-up. Give it a name.
Apply this rule if… –> You will notice that there is no option here to choose IP address as a condition.
To be able to choose IP address we need to click on More Options…
This will give us the full range of mail flow conditions and actions available to us, and we can go ahead and set the condition that the sender’s IP address is the web server IP address of <IP address>
Type the IP address and click on + sign
Now we don’t want to block all mails from that IP address, just the fake iPhone spam. So let’s add another condition for messages containing that keyword in the subject or body.
Select The subject or body –> Subject or body includes any of these words
Type in the word you would like to search in email and add it. Once done click OK
Over time if different types of spam were hitting that contact form, you could just come back here, edit this rule, and add more keywords to that list.
Now we need to decide what do we want to do with those messages? This can be answered in Action pane. As you can see there are a lot of options here that we can use in different scenarios. We can forward the message to someone to approve it before it comes to the user, we can redirect it, generate a report etc. It is very important to explore and test these options so that you know what you can do.
Now for our exemple I will choose to Block the message…and to delete it. This will delete the message as soon as it finds iPhone word in the mails sent from our web server.
What are the chances, though, that a legitimate inquiry would actually include one of those spammy keywords? If you are worried about that you could instead of Block, Redirect the message to a person who’s responsible for sifting through that spam, or you could hold it for approval or you could send it to quarantine. Anything that takes the burden off the rest of the team.
I will not include any exceptions but once again, for example if you’ve got a rule that looks at the sender’s domain because you want to block that domain, you can set an exclusion that says just one particular email address from that domain is excluded from the rule. So in effect, it will be the only email on that domain that isn’t blocked by your mail flow rule.
Here is the full list and it is very important to explore and test these options.
Last but not least are the properties.
Audit this rule with severity level –> I have seen that people are disabling this option without answering why. This option controls whether this rule will appear in reports and message traces. If we uncheck this option we will not have the option to track this rule and to see it in reports. If the rule has triggered, you will see no evidence of this in reports or the message trace. I recommend that you leave this marked.
Severity Level –> By default, a new rule will have this set to NOT SPECIFIED. These levels impact how the rule will show up in reports. Rules that have an audit level set of “not specified” will show up in reports as having a “low” severity set. Regardless of the set severity, as long as the Audit check box is checked, there will be logs of the rule triggering (message trace, extended message trace, reports).
ENABLE A MODE FOR THIS RULE
Here we have options to test the rule before we implement it. This way, if you accidentally create a condition that doesn’t do exactly what you want or interacts with other rules in unexpected ways, you won’t have any unintended consequences.
Microsoft recommends that we wait ca 30 min after creating a rule before we test it.
- ENFORCE –> This is the default option. This turns on the rule and it starts processing messages immediately. All actions on the rule will be performed.
- TEST WITH POLICY TIPS –> When we select this option any Policy Tip actions ( Notify the sender with a Policy Tip) will be sent, but no actions related to message delivery will be performed. Data Loss Prevention (DLP) is required in order to use this mode.
Policy Tips are quick messages that warn end-users when they’re working with sensitive information. They can be set up to provide a link to compliance polices, require users to provide business justification, or even block information from being sent.
- TEST WIHOUT POLICY TIPS –> Only the Generate incident report action will be enforced. No actions related to message delivery are performed.
Activate/Deactivate this rule on the following date, if enabled, it specifies the date range when the rule is active.
Stop processing more rules option
If you enable this option, any additional rule that you apply to the message will not be applied. Subsequent rules will be ignored, even if they apply to the message. With this option on, when a message comes in, that meets the criteria for more than one rule, only the first rule will be applied. Without this setting, every rule that applies to the message will run.
Defer the message if rule processing doesn’t complete
You can specify how the message should be handled if the rule processing can’t be completed. By default, the rule will be ignored, but you can choose to resubmit the message for processing.
Match sender address in message
For conditions and exceptions that examine the sender’s address, you can specify where rule looks for the sender’s address.
Header: Only examine senders in the message headers (for example, the From, Sender, or Reply-To fields). This is the default value. The “From:” header field will tell you who the author of the message is.
Envelope: Only examine senders from the message envelope (the MAIL FROM value that was used in the SMTP transmission, which is typically stored in the Return-Path field). The “MAIL FROM” command specifies the address for return purposes (example: issues with mail delivery).
That’s it. I recommend that you go through these settings, create new rules and see what these can do. I hope this has been informative for you. Next post will focus on Spam Filtering.