I have several large distribution groups that were migrated to Exchange Online but are still synchronized from on-premises Active Directory. They currently allow messages from outside the organization. I want to prevent general external senders while still allowing an application server in Azure to send to specific groups.
The application routes outbound mail through Mimecast before it reaches Microsoft 365, so Exchange sees the Mimecast IP addresses rather than the app server's actual address. Because of that, an Exchange rule based on the source IP would either fail or require allowing all Mimecast ranges. I also cannot easily select the distribution group directly in some transport-rule conditions, and rebuilding the larger groups immediately is not practical.
What are the safest options for allowing this application while blocking other external senders? I would also like a solution that works with synchronized groups and does not require maintaining a running on-premises Exchange server.
3 Answers
For synchronized groups, you can use the Exchange Management Tools from a domain-joined machine and set the group to require authenticated senders with RequireSenderAuthenticationEnabled. The underlying Active Directory attribute is msExchRequireAuthToSendTo, which Entra Connect can synchronize to Microsoft 365. You do not necessarily need a running on-premises Exchange server, although editing the attribute directly should be treated as a last resort and tested carefully.
For the application, a separately scoped Exchange Online connector or authenticated submission path is safer than trying to identify the app by Mimecast’s shared outbound IP addresses.
You probably do not need to rebuild the groups just to change the delivery restriction. A setting such as AcceptMessagesOnlyFrom can allow messages from a specific approved sender, though it may not fit if the application needs to send using multiple addresses or impersonate different users. Test it against a small group first, especially because synchronized objects may reject changes made directly in Exchange Online.
If the application sends as different addresses, use a controlled authenticated service account or a dedicated connector and limit its permitted sender and recipient scope. Avoid allowing all Mimecast addresses as an exception, since that would effectively bypass the restriction for any mail entering through Mimecast.
Since the message is already passing through Mimecast, you can apply a Mimecast policy specifically to those distribution-group addresses and block external senders there. That avoids the fact that Exchange only sees Mimecast as the connecting source.
Longer term, avoid relying only on an IP-based safe-sender exception. Give the application an authenticated identity or a narrowly scoped relay configuration, and restrict which recipients it can use. That provides better control than allowing anonymous or broadly trusted relay from an application server.
I tested a temporary approach using a blocked-sender policy for the specific distribution-group address while leaving the group’s external-sender setting unchanged. The app is currently trusted through a Mimecast IP-based safe-sender configuration, but I agree that an authenticated and more narrowly scoped setup would be preferable. I’m also rebuilding the smaller groups in Exchange Online with PowerShell and plan to clean up the larger ones over time.