Security Post & Blog #3

How to Set Up and Maintain Mimecast for Email Security on an On-Premises Mail Server

Posted on June 4, 2019 | Security Tips & How-Tos

Email remains the number one threat vector for most organisations, and if you’re still running an on-premises mail server — whether that’s Exchange 2013, 2016, or even a stubborn Exchange 2010 installation that nobody wants to touch — getting your email security right is more important than ever. Ransomware, phishing, business email compromise, CEO fraud — the bulk of it still arrives via the inbox, and a solid email security gateway is one of the most effective controls you can put in place.

Mimecast has become one of the more popular choices in this space over the past few years, and it’s easy to see why. It sits in front of your mail server as a cloud-based gateway, scrubbing inbound and outbound mail before it ever reaches your Exchange environment. It also handles continuity — so if your mail server goes down, users can still send and receive via the Mimecast portal — and it provides a cloud-based archive if you’re licenced for it. For an on-premises environment it’s a particularly good fit, since it offloads a lot of the heavy lifting to the cloud without requiring you to rip out your existing infrastructure.

In this guide we’ll walk through how to get Mimecast set up with an on-premises mail server and touch on the ongoing maintenance tasks you’ll want to keep on top of.

What You’ll Need Before You Start

Before you begin, make sure you have the following ready. You’ll need an active Mimecast account and licence — if you’re still in the evaluation phase, Mimecast’s onboarding team are generally pretty helpful and will walk you through the initial account setup. You’ll need admin access to your DNS provider, since several DNS changes are required as part of the setup. You’ll need admin access to your on-premises Exchange server or whatever mail server you’re running. And finally, you’ll want to have your current MX records documented before you change anything, just so you have a clean rollback reference if something goes wrong.

Step 1: Configure Your Domain in Mimecast

Log into the Mimecast Administration Console and navigate to Administration, then Gateway, then Domains. Add your email domain here and verify ownership — Mimecast will give you a TXT record to add to your DNS to prove you control the domain. This is a standard verification step and your DNS provider should make it straightforward.

Once verified, Mimecast will provide you with your new MX records. Don’t change these yet — get the rest of the configuration in place first and switch the MX records over at the end to minimise disruption.

Step 2: Configure Your Inbound Mail Flow

Still in the Administration Console, go to Administration, then Gateway, then Policies. This is where you’ll configure how Mimecast handles inbound mail before passing it on to your server.

The key thing to configure here is your inbound delivery route — essentially telling Mimecast where to forward clean mail once it’s been processed. This will be the hostname or IP address of your on-premises mail server. Make sure this is an externally resolvable address or hostname, as Mimecast’s cloud infrastructure needs to be able to reach it.

You’ll also want to set up your anti-spam and anti-malware policies at this point. Mimecast’s defaults are fairly sensible for most organisations, but take a look through them and adjust to suit your environment. Pay particular attention to the attachment handling policies — Mimecast’s Attachment Protection, which sandboxes suspicious attachments, is one of its stronger features and well worth enabling if your licence includes it.

Step 3: Lock Down Your Mail Server

This is a step that many guides gloss over but it’s critically important. Once Mimecast is your inbound gateway, you need to make sure your mail server only accepts inbound SMTP connections from Mimecast’s IP ranges — not from the open internet. If you skip this step, anyone who discovers your mail server’s IP address can bypass Mimecast entirely and deliver mail straight to your users unfiltered.

Log into your Exchange server and configure your receive connectors to restrict inbound SMTP to Mimecast’s published IP ranges. These are available in the Mimecast knowledge base and are grouped by region, so make sure you’re using the correct ranges for your Mimecast data centre. If you have a perimeter firewall — and you should — enforce the same restriction there as well for defence in depth.

Step 4: Configure Outbound Mail Flow

For outbound mail, you’ll want to configure your Exchange server to relay outbound messages through Mimecast rather than delivering them directly. This gives you outbound scanning, policy enforcement, and the added benefit of Mimecast handling your sending reputation.

On your Exchange server, create or modify a Send Connector to route outbound mail to Mimecast’s SMTP submission endpoint. You’ll also need to set up an outbound routing policy in the Mimecast console to tell it to accept relay from your server’s IP address. Mimecast will validate that the sending IP matches what you’ve registered, so make sure your server’s external IP is correctly configured in the console under Administration, then Gateway, then Authorized Outbound IPs.

Step 5: Update Your DNS Records

With the routing configuration in place and your mail server locked down, it’s time to cut over your MX records. Log into your DNS provider and replace your existing MX records with the Mimecast ones provided during domain setup.

At the same time, update your SPF record to include Mimecast’s sending infrastructure. Your SPF record should reference Mimecast’s include mechanism alongside any other authorised senders. If you’re not already using SPF — and in 2019 there really isn’t an excuse not to be — now is a good time to get it in place. DKIM signing through Mimecast is also worth configuring at this stage; the console will walk you through generating and publishing the required DNS records.

Be aware that DNS changes propagate at different speeds depending on your TTL settings. If you reduced your TTL to a low value in advance of the change — say 300 seconds — propagation should be fairly quick. If not, you may need to allow up to an hour or so for the change to be visible globally.

Step 6: Test Your Mail Flow

Once DNS has propagated, send test emails from an external account and confirm they’re arriving via Mimecast. You can verify this by checking the email headers — you should see Mimecast’s servers referenced in the received chain. In the Mimecast Administration Console, go to Administration, then Message Center, then Message Tracking. This gives you a real-time and historical view of all mail flowing through your gateway, which is invaluable both for testing and for ongoing troubleshooting.

Send a test outbound email and verify it’s routing via Mimecast as well. Check the headers on the received end to confirm it passed through Mimecast’s outbound infrastructure.

Step 7: Deploy the Mimecast for Outlook Plugin

If your users are on Outlook — and in an on-premises Exchange environment they almost certainly are — it’s worth deploying the Mimecast for Outlook plugin. This gives users direct access to their personal on-hold queue, allows them to manage their own permitted and blocked senders, and integrates the Mimecast archive search directly into Outlook if you’re using the archive product.

The plugin can be deployed via Group Policy or your software deployment tool of choice. Mimecast provides an MSI installer and documentation for silent deployment, which makes it straightforward to push out via SCCM or a similar tool. It’s one of those things that makes a noticeable difference to the end user experience and reduces the volume of “where’s my email gone” helpdesk tickets considerably.

Ongoing Maintenance

Getting Mimecast set up is the first part — keeping it running well is the ongoing job. Here are the key maintenance tasks to keep on top of.

Review your held message queue regularly. The Administration Console gives you visibility of messages that have been quarantined by Mimecast’s policies. Check this at least daily initially, until you’re confident your policies aren’t holding legitimate mail. False positives do happen, particularly with automated notifications from line-of-business applications, so it’s worth spending time tuning your permitted sender lists and policies in the first few weeks.

Keep your Mimecast IP ranges up to date. Mimecast occasionally updates its infrastructure IP ranges and will notify you via the console and email when this happens. Make sure whoever manages your firewall and receive connector rules is subscribed to these notifications and acts on them promptly. A missed IP range update can result in legitimate mail being rejected.

Monitor your SPF, DKIM, and DMARC alignment. If you’ve gone to the effort of setting up proper email authentication, make sure it stays correct. DNS records have a habit of drifting over time, particularly when third-party services are added that send mail on your behalf. Mimecast’s console includes some useful reporting on authentication results that can help you spot problems early.

Review your policies periodically. Threat patterns change, and a policy configuration that was sensible six months ago may need revisiting. Set a calendar reminder to review your spam thresholds, attachment policies, and URL protection settings every quarter. Mimecast releases product updates fairly regularly and new features are often worth exploring when they appear.

Check your continuity settings. Mimecast’s continuity feature is one of the things that justifies the investment for many organisations, but it only works if it’s been properly configured. Make sure your users know how to access the Mimecast portal if your primary mail server is unavailable, and consider doing a tabletop exercise once or twice a year to make sure the process is understood.

Wrapping Up

Mimecast is a solid choice for organisations running on-premises mail infrastructure who want cloud-based email security without a full migration to Office 365 or G Suite. The setup process has a reasonable number of steps but nothing that should cause experienced administrators too many headaches, and the ongoing management through the Administration Console is generally intuitive once you’ve found your way around.

The key things to take away are: lock down your mail server to only accept connections from Mimecast, get your DNS authentication records right from the start, and invest time in the early weeks tuning your policies rather than leaving the defaults and hoping for the best.

As always, if you’ve got questions or you’ve run into a specific scenario that doesn’t quite fit the standard setup, drop a comment below. Good luck with the rollout.



