This site provides a visual representation of the Microsoft 365 Roadmap.

We are announcing enforcements to move customers along to using the dedicated hybrid app.

After being asked whether licenses are needed to include shared mailboxes in Microsoft 365 retention policies, I investigated and found that licenses are not.

If you wanted to learn more about the Direct Send feature, this is the post for you!

Introduction A customer recently inquired me about a process named ai.exe, which was flagged by a user in Task Manager for consuming excessive system resources. I attempted to locate official docum…

We are happy to announce two ways of getting Exchange Online Exchange Web Services (EWS) usage reporting.  

Direct Send is a method used to send emails directly to an Exchange Online customer’s hosted mailboxes from on-premises devices, applications, or third-party cloud services using the customer’s own accepted domain. This method does not require any form of authentication because, by its nature, it mimics incoming anonymous emails from the internet, apart from the sender domain. The Direct Send method assumes that customers have properly configured SPF, DKIM, and DMARC for their tenants. It is critical that an administrator updates their SPF record by adding the source IP address where the device, application, or third-party service will send from to prevent emails from being flagged as spam. If SPF is not properly configured, any email sent using Direct Send will likely be flagged as spam. While SPF provides protection from spoofing of your domains, we recommend customers use a Soft Fail SPF configuration due to the possibility of valid routing scenarios falling foul of SPF failures. As such, no feature existed to block Direct Send traffic for the many customers who have no need to use it. To this end we have developed the Reject Direct Send setting for Exchange Online and are announcing the Public Preview for this feature today.   Reject Direct Send Feature By its definition, Direct Send covers anonymous messages sent from your own domain to your organization’s mailboxes. Enabling this setting will block any traffic that meets those conditions. The sending domain being an accepted domain in your tenant is a straightforward and easy condition to evaluate. “Anonymous” in this context means that the messages are not attributed to any mail flow connector when they are sent to Exchange Online. Direct Send traffic may include 3rd party services that you have given permission to use your domain or one of your own email applications hosted on-premises. To avoid having these messages rejected when this feature is enabled, they need to be authenticated.  This is done by creating a partner mail flow connector that matches the certificate (recommended) or IPs used to send the messages.  Learn more about partner connectors here: Configure mail flow using connectors in Exchange Online. Admins may currently not be tracking all senders who currently use Direct Send, but a good place to start would be the with your domain’s SPF record. Any senders using Direct Send without being a part of the accepted domain’s SPF record will already be having a tough time getting messages delivered successfully into recipients’ inboxes. How to enable this feature By default, the new opt-in RejectDirectSend setting is set to False.  To enable the Reject Direct Send feature, Exchange Online administrators can run the following PowerShell cmdlet: Set-OrganizationConfig -RejectDirectSend $true The change should propagate out to our entire service within 30 minutes. With the feature enabled, any received Direct Send messages will see the following message: 550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources Unless Direct Send is re-enabled again, any messages that hit this error will need a partner connector created to authenticate their source as an approved sender. Public Preview and Release Roadmap This feature is being released as a Public Preview for admins to test and provide feedback. Some customers may not have the confidence to enable it due to a lack of tracking of Direct Send senders to their organization. Feedback including feature requests and bug reports may be sent to the follow address: directsend-feedback[AT]microsoft.com. Note: Feedback submitted here will not receive a reply. If you need to engage us with questions or issues regarding the feature, please comment below or go through the regular support channels. You can also use the Exchange Online Feedback Portal to submit feature requests that other customers can then vote on. This avenue provides us with an extra layer of information to help make decisions on features. We are working on delivering features to provide optics for what Direct Send traffic is coming into your organizations. This will make it easier for admins to identify and act on any legitimate traffic and enable the feature with confidence. We will provide updates here for that work. There is no fixed date for General Availability (GA) of this feature as it will depend on the feedback received. A separate communication will be sent out to announce GA. We also plan to enable this feature in the future for new tenants by default. This is part of our effort to make your organizations more secure by default. Note that the plan includes new tenants being unable to disable this feature as we move to deter use of unauthenticated Direct Send traffic. Known Issues There is a forwarding scenario that could be affected by this feature. It is possible that someone in your organization sends a message to a 3rd party and they in turn forward it to another mailbox in your organization. If the 3rd party’s email provider does not support Sender Rewriting Scheme (SRS), the message will return with the original sender’s address. Prior to this feature being enabled, those messages will already be punished by SPF failing but could still end up in inboxes. Enabling the Reject Direct Send feature without a partner mail flow connector being set up will lead to these messages being rejected outright. Conclusion We invite Exchange admins to try out the feature and provide feedback that we can use to validate it and proceed to offering this feature for General Availability. Microsoft 365 Messaging Team

Microsoft will retire Exchange Web Services (EWS) from Exchange Online in October 2026. A new usage report helps tenants understand what apps use EWS.