These days it can be difficult to see the difference between real and fake emails. Spammers, hackers, and phishing have gotten more and more sophisticated. Now, instead of sending casual “You got money from a Nigerian prince” emails, malicious senders are starting to research their targets and send much more believable emails. They’ll probe for real email addresses or buy lists off the dark web and start to send messages throughout organizations as if they are internal messages. By faking as if they are part of the same organization sometimes they can trick people into doing things thinking they are just doing something for a co-worker or a boss.
Most of the time spam filters will block attempts like this, especially if you are using a strong SPF record. However, most people don’t employ a hard block on SPF fail, instead they opt for a soft fail which means sometimes messages can still go through even if they do not originate from the internal mail server.
So should we always setup an SPF record to block messages that don’t originate from internal email? Perhaps. However, there are many reasons why one might use a soft fail on their SPF record. Plus, maintaining an SPF record can be tedious work that just can get overlooked in the general scheme of things.
This is where a unique mail filtering rule came in handy here at Virtual Administrator. And we wanted to share it with all of you.
[Outside Sender] Mail Rule
Mailprotector has a powerful mail filtering rule set that can allow for some creative uses. This one in particular is useful for MSPs to put in place on their end-user domains to help identify when mail that looks like it is internal is coming from an external mail server.
The rule is simple: if mail says it is from the end-user’s mail domain but didn’t originate from a known source, then add a tag to the subject line to identify it as potentially fraudulent.
Setting up the rule is easy. You can do so by simply navigating to the domain you want to protect in the Mailprotector dashboard. Then click on “Filtering” then scroll down a little bit to find the message rules link. You’ll want to create a new rule and name it something descriptive like “Identify Outside Senders” as we wrote in the graphic below.
The rule should apply to incoming mail and we won’t be using a template for this rule. Click create to begin setting up the rule.
Under the “From” section you should add all the domains your clients send email from. This includes all alias domains as well as their primary domain.
The “From” field indicates the address that the email says it is from. This can sometimes differ from the “Sender” field which could be a completely different email address. For this rule we use the “From” field because we are targeting emails that appear to be from the domain — the original sender is irrelevant since that won’t show in the email client.
Once you’ve filled out the from field, we now have to build in some exceptions. You will want to match your SPF record here. So pull up the domain SPF record (or use MX Toolbox to inspect it.) We want to add these values to our exceptions. What we will do is simply say, if these exist in the headers, then allow the message through.
Scroll down and add the SPF records like the image below:
This basically tells Mailprotector to flag any messages that say they are from your client’s domain but don’t contain anything from mail servers that the client sends mail from.
Once we have finished that then we’ll move on to the next step. Scroll back to the top of the page and click “Actions” so we can apply an action to this email.
There are several actions you can take. Here at Virtual Administrator we decided the best course of action was to simply add a tag to the subject of the message so that we are aware the message originated from servers that are not our own. This soft fail gives us the chance to review the message to see if it might still be good. There are often good reasons why an email might originate from an non-internal server so we feel like it is better to simply mark them and let the end-user decide.
However, this method still requires the end-user to understand what is going on. A quick discussion with your client to let them know what this means will give them the information they need to distrust emails that aren’t sent from an internal email server.
You could also categorize the email as spam and put it in the user quarantine. (You could also combine these two actions together for maximum impact).
This method should help to keep phishing emails at bay when people attempt to impersonate users inside your organization with malicious intent. It isn’t 100% foolproof, but most phishing scams aren’t going to take a defense like this into account. This gives you the flexibility to allow non-SPF approved email through but still treat it with caution and alert your end users that something ……phishy …. might be going on.
