This article provides guidance on enhancing security by configuring Microsoft 365 to accept inbound emails only from Mimecast IP addresses through the creation of a receive connector. This process entails setting up a connector in the Microsoft 365 Exchange Admin Console, designating Mimecast as the partner organization, and implementing security restrictions to ensure that emails are transmitted over TLS and originate from specified IP ranges.
For information on configuring Direct Send and Reject Send, please see Administration - Configuring Direct Send in Microsoft 365.
Customers with complex mail routing environments may need to configure additional connectors to trusted partners, if mail is required to be routed around Mimecast.
Configuring Microsoft 365 Mail Lockdown
You can lock down your firewall, by using the following steps:
- Log in to the Microsoft 365 Exchange Admin Console.
- Click on the Mail flow menu item.
- Click on the Connectors tab. Your connectors are displayed.
- Click on + Add a Connector.
- Under Connection from, choose Partner Organization.
- Click the Next button.
- Change the connector's name to Mimecast to Microsoft 365.
- Click the Next button.
- Choose By verifying that the sender domain matches one of the following domains and add a * to capture all the inbound domains.
Do not add any IP ranges to the Authenticating sent email screen, specifically under By verifying that the IP address of the sending server matches one of the following IP addresses, which belong to your partner organization.
This should instead be done in the next screen Security restrictions, as per the following steps.
- Click the Next button.
- On the Security Restrictions screen:
-
- Check the check box for Reject email messages if they aren't sent over TLS.
- Check the the check box for And require that the subject name on the certificate that the partner uses to authenticate with Office 365 matches this domain name. Enter *.mimecast.com into the field below the checkbox (for ZA customers, use *.mimecast.co.za).
- Check the check box for Reject email messages if they aren't sent from within this IP address range, and provide the IP address range. See Email Security Cloud Gateway - Data Centers & URLs for IP addresses.
- Click the Next button.
- Review the settings you have configured, and click Create connector.
Monitoring
- Review the Bounced and Rejected Messages Queues in the Mimecast Administration Console to ensure any legitimate traffic like Digest Sets are not rejected by your Microsoft 365 environment.
-
Bounced Messages related to connector lock down will contain an SMTP Error like:
5.7.51 TenantInboundAttribution; Rejecting. Recipient has a partner connector with RestrictDomainsToIPAddresses or RestrictDomainsToCertificate set.
-
Bounced Messages related to connector lock down will contain an SMTP Error like:
- Validate that all Mimecast IP ranges for your grid have been added to your inbound lockdown connector in Exchange Online. See Administration - Data Centers & URLs.
- Review the Microsoft 365 Spoof Intelligence Insight Dashboard for legitimate messages spoofing your Microsoft 365 accepted domains (Requires M365 Admin Credentials).
- Check to see if emails from your Microsoft 365 accepted domains are allowed to be spoofed by the Mimecast Sending Infrastructure.
- Check to see if emails from your Microsoft 365 accepted domains are allowed to be spoofed by the Mimecast Sending Infrastructure.
- Microsoft 365 E5 and Defender P2 subscribers can review the Spoof detections report for additional information on spoofed messages delivered to the Microsoft 365 Tenant.
- Consider turning off Direct Send, if it is not needed in your organization.
Mimecast Notifications, e.g. Digest Sets and Device Enrollment emails, require a Postmaster Account to be set in the Mimecast Administration Console, under Account | Account Settings | System Notification Options | Notification Postmaster Address.
Comments
reviewed connectors do not see any that are not already locked down by specific IP address, or specific TLS certificate or combination of both.
Perhaps adding a transport rule in 365? https://office365concepts.com/stop-spoof-email-in-office-365/ “Stop Domain Name spoofing” ??
Did this and it prevented “internal” mail flow - error said undeliverable based on IPRejection or something along those lines. Anyone else have similar issues? Internal based on Mimecast definition - separate domains but all within the same Mimecast account.
This article outlines steps to create a connector to restrict email coming from the Mimecast CIDR's based on the tenant grid we're on and enforcing TLS, as well as authentication from allowed IP's. However, how do I restrict email traffic to just email from my Mimecast US-B tenant to my Microsoft O365 tenant and not allowing traffic directly from other Mimecast US-B tenants to my organizations Microsoft O365 tenant? This is something I need to determine since we don't have dedicated Mimecast IP's and we're looking to change our mail flow to go directly from Mimecast to our EOP/O365 tenant.
Hi Leesandro,
Thank you for the comment! In order to get you the best solution possible, would you please post it into our Community? Not only will it be addressed by Cybersecurity peers, but the Mimecast team as well. Once you receive a solution, it can be bookmarked for easy retrieval.
If your issue is more urgent and/or you wish to open a new Support case, please do so here.
This is not a good solution and in fact, it's not a one size fits all. Too many variables that can break. I'm speaking from my own experience after enabling this inbound connector with Mimecast's subnets. Locking it down with SPF, DKIM, and DMARC in the organization's public DNS has always worked for me and is a better solution than this in my opinion.
This document doesn't go over validation of direct send status or if it is required for Mimecast to work correctly.
I am aware that Direct Send being enabled in an environment is not a question MC can answer as that is a business decision. It might stop some devices from working correctly (printers, scanners, report sending devices, faxes)
It also doesn't state to check DMARC settings. Emails could fail DMARC but still be delivered to end users if the wrong settings are set.
hi Dustin,
Thanks for raising this feedback with us, I would recommend you take a look at https://mimecastsupport.zendesk.com/hc/en-us/articles/43158893089555-Administration-Configuring-Direct-Send-in-Microsoft-365 which covers Direct Send, and also links to articles about DMARC Settings.
Could disabling Direct Send serve as an additional method to address this issue? https://techcommunity.microsoft.com/discussions/microsoft-365/disable-direct-send-in-exchange-online-to-mitigate-ongoing-phishing-threats/4434649
Set-OrganizationConfig -RejectDirectSend $true
Disabling direct send breaks at least one function we rely on - Attachment release. Unknown what other functions break.
Hi Cameron Graham,
We have updated the above article to give more information.
Please also see the updates to linked article https://mimecastsupport.zendesk.com/hc/en-us/articles/43158893089555-Administration-Configuring-Direct-Send-in-Microsoft-365#h_01K2288MD0WY2YZAMKK1YC1J7F which will give you more information about disabling Direct Send, and lists functionalities affected when this is turned off.
There is no simple answer. The solution will depend on your environment. We manage three different O365 tenants with exchange online connectors locked down to Mimecast IPs only. We had RejectAnonymousDirectSend enabled and now RejectDirectSend enabled and not seen any negative effect on the mail flow. I would recommend reviewing the mail flow and understanding where security check are performed and make adjustments. For example, when Mimecast is used as a mail gateway, configuring just connectors to O365 is not enough. There are few more config changes needed to be done on Microsoft side, as per Mimecast implementation guides. If you have old systems that can only anonymously relay on port 25, then as a workaround you can build a linux based internal smtp server (only accept relay connections from specific internal IPs), point your internal anonymous senders to it and configure Mimecast with authorized outbound sender from your linux smpt server. This works for us.
Any idea of running a report to see what emails domains and ip's are bypassing mimecast?
Hi Danny,
Thank you for your comment! Kindly see https://techcommunity.microsoft.com/blog/exchange/direct-send-vs-sending-directly-to-an-exchange-online-tenant/4439865 for more information on this. If your issue is more urgent and/or you wish to open a new Support case, please do so here.
I hope this was helpful.
Please sign in to leave a comment.