Using transport rules as a security tool (Part 1)

This is Part 1 of a series on using transport rules as a security tool. Each article will be linked in the table below as they are published:

Part 1 – Setting up the mailbox (you are here)
Part 2 – It’s all about those transport rules
Part 3 – Reducing the haystack


At a conference last May, I had an opportunity to facilitate a session focused around email security covering topics such as SPF/DKIM/DMARC/MTA-STS, spam/phishing filtering, message routing, archiving/holds, and more. During that session, I shared about the methodology I use to track current trends of spam and phishing attacks rather than relying on the native spam filtering in our email platforms (which is regularly inadequate) or paying for additional security products which are often out of budget and are also sometimes ineffective due to their focus on businesses rather than unique challenges of educational institutions. I believe creating rules based on patterns you are actually seeing can be every bit as effective, and utilizing the existing tools you have better can save a lot of money that can be invested elsewhere.

Since the think tank sessions were not recorded, I have had several people ask for more details so they could customize this method to their own liking. Hopefully this can be a reference to point back to that can be kept up to date as new ideas are shared and the process is refined. I will try to keep this focused on the methodology rather than a specific product, but since we use Office 365 (and G Suite isn’t an exact 1:1 feature match), there may be some gaps you need to figure out depending on what your platform is.

At a high level overview, this method uses rules to copy email that are likely spam or phishing but weren’t caught by the spam filters into a mailbox for review. This content is then used to create transport rules that will then allow you to not only block those messages but also refine the rules to become more effective over time. It’s also a good idea to set up a for users to forward what they believe to be phishing to. Let’s just say that even a few years in, users are still having difficulties distinguishing between phishing and spam, so do plan accordingly by having pre-canned messages for both scenarios to reply back to users with.

Setting up the mailbox

Before we begin, it’s important to note that this process requires copying email destined for your users or potentially mail driven processes (like accounts payable workflows) into a mailbox that you and/or others have access to. This means that you most likely will inadvertently intercept personal communications or even confidential information, so let that guide your decisions as you set up this mailbox and who you give permission to access it. It would be a good idea to have an approval process for every step of this to make sure it is well documented and well understood.

The first thing we need to do is create a mailbox that we can dump spam and potential phishing attacks into for review. We used a Shared mailbox in Office 365, and as a best practice, we create a security group specifically for accessing that mailbox and add the appropriate people to that security group. The documentation on creating a shared mailbox and assigning permissions can be found here: (G Suite users look here:

Once that is set up, we need to configure the spam filter to BCC messages into this mailbox and configure more stringent controls in test mode so that those messages are copied into our shared mailbox. Things like attachment types, Javascript, web bugs, etc. are good candidates for testing, and since we have so little foreign origin/language email, evaluating these and possibly increasing spam confidence levels may be a good thing to look at as well. G Suite users may be able to do similar with Content Compliance rules for Gmail, and if you have good examples, please reach out and I’ll update this post! The documentation on how to do that in Office 365 can be found here:

This is an example of how mine looks

At this point, we should have a mailbox our team can access with some data flowing in, and hopefully we can start seeing patterns that give us an idea of how we might be able to use transport rules to start catching these. If we set up a user reported phishing mailbox, we can also use that data to improve our transport rules as well. We’re going to let this fill up for a week, and in the next part of this series, we will cover how to identify campaigns (and how they are often conducted), things that make them unique, and how to create rules that are effective in catching them.

Leave a Reply

Your email address will not be published. Required fields are marked *