Email Security Hardening (Part 4): Mail Flow Rules

Welcome to the final part in our 4 part series where we have looked at Email Security Hardening by setting up SPF, DMARC, DKIM and creating Mail Flow rules. In this final part, we will be focusing on Mail Flow rules.

Mail Flow rules describes precisely what it sounds like, it is a series of rules which governs the actions to be taken on mail flowing in your environment. The control which can be sent can be very granular (individual users/groups, specific domains, etc) or wide sweeping (entire organisation) depending on your requirements.

For the following rules, we suggest these apply company-wide and could require a shift in how the organisation regards email security depending on the implementation of the rules. Mail Flow rules can be set in the Exchange Admin Centre -> Mail Flow -> Rules -> + Create New Rule.

The first rule is to allow users to easily identify when emails are received from inside or outside the organisation with inside the organisation being defined within your SPF record as domains which are considered as part of the organisation. Within a new rule, set the following options:

This rule will take any mail sent from outside your organisation and prepend the subject with “[EXTERNAL] – “, this will only be applied 1 time, however (will not see multiple [EXTERNAL] in an email chain). Some may find this to be overly intrusive into everyday mail as a good deal of mail will contain the “[EXTERNAL]” tag, for cases where this is not desirable but you do wish to bring the external nature of the email to the attention of users then replace the “Do the following” portion of the above with the below:

The “Except if” would also require an amendment to contain the message (to prevent duplication on every email) or removed if you wish it to be added to every email received.

This change will make it so that rather than receiving a notification in the subject line, a line will be added to the start or end of an email to advise users that this is an external message. While this is a fine practice of giving notice to users, it is possible that it will be ignored. Particularly at the end of emails where various other disclaimers/notices may be found from the senders’ signature. Therefore, it may be more advisable to utilize the more obtrusive (but more recognizable) subject tag.

The second rule is to alert users of emails received from sources not listed as a recognized sender within senders’ SPF record, note that this rule can only fire if an SPF entry exists in the DNS record of the domain and ignored if none is listed. Within a new rule, set the following options:

This rule inspects the contents of a message header for variants of methods of indicating that the email failed an SPF check and prepend the subject with “[CAUTION] – “, this will only be applied 1 time, however (will not see multiple [CAUTION] in an email chain). As before some may find this obtrusive, in which case it can be altered as previously shown to a disclaimer message to the top or bottom of the email. However, as this rule is highlighting message failed an SPF check it could point to a potential spoofing email it may be preferable to highlight these more prominently than with a potentially ignored disclaimer. This would require further verification as it could also be the senders’ domain has not listed all authorized senders within their own SPF entry, as we detailed at the beginning.

The final Mail Flow rule we will look at is to monitor attempts to send spoofing attacks to your users where the attacker is posing as your domain. Within a new rule, set the following options:

This rule will identify any emails sent into your organization but are not recognized as part of the organisation, as defined by your SPF entry, and also checks if the sender domain claims to be your domain. If the message matches these checks then it can be said with reasonable certainty that the message is an attempted spoofing of your domain. This rule will then add the tag “[SPOOFING] – ” and also prepend the message with a disclaimer warning the user that this is a spoofed email and to beware of its contents.

Due to the more serious nature of this type of message the use of both notification types will allow users to see an initial warning in the subject with an additional warning an explanation should users proceed in opening the message.

There are many other potential Mail Flow rules to warn/protect against a wide range of scenarios. However, with these three rules, the addition of SPF/DKIM/DMARC entries and appropriate user training to understand the implemented changes your organisation you can begin to protect against a range of the most common attacks which are prevalent in the modern threatscape.

If you have missed any of our 4 Part Series focusing on Email Security Hardening, you can find all entries below:

Part 1 – The Sender Policy Framework (SPF)
Part 2 – DomainKeys Identified Mail (DKIM)
Part 3 – Domain Based Message Authetication, Reporting & Conformance (DMARC)

 

Meet the Author

Darren Fotheringham
CSIRT Lead, Quorum Cyber

“Since starting in cyber security, I have had a keen interest in all aspects of blue team and working with new technologies to investigate potential threats on behalf of our customers. With such a diverse field of study, there is always something new to learn or defend against, and this challenge of continual progression makes every day feel new and exciting.”