Table of Contents
Escalating to Tenant Restrictions
In a previous post, I wrote about how Exchange Online Protection monitors the email traffic sent from mailboxes to detect potential problems like compromised accounts or bulk mailings. These mailboxes are blocked (restricted) to stop outbound messages. Administrators can lift the restrictions on the mailboxes to resume normal service, hopefully after discovering a root cause.
After blocking individual mailboxes, the next escalation occurs when Exchange Online Protection considers that a component of the tenant might be compromised, and a wider restriction is necessary. At this point, the “tenant restricted from sending unprovisioned email” alert fires. This is one of the standard alert policies installed in Office 365 tenants, defined as happening when “when most of the email traffic from your organization has been detected as suspicious and Microsoft has restricted your organization from sending email.” Figure 1 shows the settings of the alert policy as viewed through the Security and Compliance Center.
Alert Notification
When the alert fires – and every hour or so thereafter until the alert is cleared – Exchange emails the tenant administrators a notification (email is OK because it’s an internal message) to inform them about the restriction (Figure 2).
Lack of Clarity and Precision in Notification
It’s important that notifications to tenant administrators are concise and clear. When I received this notification, I was confused about its meaning. The biggest issues are:
- “Unprovisioned” and “unregistered” domains are both mentioned. Microsoft’s online documentation doesn’t define what these domains are. As it turns out, both refer to domains that are not registered as accepted domains for the tenant.
- The first line of the notification therefore means that Exchange Online Protection has detected that most of the traffic from the tenant is related to unaccepted domains. This could be perfectly normal, especially for tenants with a small number of users where most of their communication might be with external correspondents.
- The second line says that the suspicious traffic is usually related to a compromised connector. However, my tenant doesn’t have any connectors (apart from those created by Exchange Online). It’s easy to check the messaging configuration of a tenant and highlight areas to check in email, a step that would have made the notification more valuable.
- The third line says that the tenant has been restricted from sending email with unregistered domains. Going back to the point about accepted domains, surely this means that no email can be sent to any external domain. But that’s not what happened because I was able to send and receive email with domains such as Microsoft.com while the restriction was in force.
- The last line advises the administrators to check for compromised user accounts, new connectors, or open relays. It would be nice if Microsoft included a link to a checklist for administrators to consult, and even better if Microsoft tailored the checklist to take account of the tenant configuration.
The net outcome is that I knew that Exchange Online Protection was worried about some traffic from the tenant and had done something to restrict some functionality. However, the lack of clarity and precision in the text meant that I was unsure of what caused the problem and how it should be resolved.
Resolving the Block
The first step in resolving any problem with email restriction is to make sure that there’s no obvious sign of problems with accounts or connectors. Are any accounts generating more email traffic than normal and if so, why? Is the traffic external or internal? Do the account owners know about the traffic? Have any new connectors been created, and so on.
If modern authentication with MFA is used for all accounts, it’s much less likely that accounts will be compromised (this is why Microsoft is removing basic authentication for several Exchange connection protocols). If this is the case, you should use message traces to check who is generating email traffic and try to understand if a spike in traffic is causing problems. For my tenant, the problem seemed to be caused by sending email to some large distribution lists where most of the members are external mail contacts. Microsoft’s monitoring picked up the traffic as a possible indication of spam (even though the messages were perfectly valid) and imposed the block.
Tenant administrators can’t lift the block. You must contact Microsoft Support and ask them to remove the block. Before you do this, gather evidence to prove that you’ve done the due diligence to check the tenant for problems like open relays, compromised accounts, new connectors, and so on. Doing this will avoid the need for wasted time as the support professional tries to understand the full scope of the problem. I’ve criticized Microsoft Support in the past, but when contacted them about this issue, the problem was resolved quickly and without fuss.
Improving Through Experience
Blocks and restrictions are needed to ensure that no tenant can soak resources in a multi-tenant environment like Office 365. Exchange Online Protection usually does a good job of protecting Exchange mailboxes from spam and malware. Microsoft has deployed a lot of machine learning and artificial intelligence to pick up problems as they emerge. In this instance, the algorithms were a little too sensitive and the notification wasn’t nearly precise enough. Feedback has been given to Microsoft to allow them to tweak things as needed. Here’s hoping this happens soon!
Sorting out why things happen inside Office 365 tenants is our passion. Learn more by subscribing to the Office 365 for IT Pros eBook and get monthly updates about everything important that happens inside Office 365.