Overview
In June 2025, Microsoft Exchange Online introduced a tenant setting called RejectDirectSend. When enabled, Exchange Online can reject inbound email sent from systems outside Microsoft 365 using one of your accepted domains — even when the email is legitimate and properly authenticated using industry-standard methods such as SPF and DKIM.
Microsoft Blog: Introducing more control over Direct Send in Exchange Online
The following article will provide information to clarify what Direct Send is and what changes are required for you to continue to receive emails from your CIMcloud website after enabling RejectDirectSend on your tenant.
Why Microsoft reports “Direct Send” even though CIMcloud uses standard SMTP
Microsoft Exchange Online uses internal terminology that does not map cleanly to standard SMTP concepts.
When Exchange Online receives an email from an external system that is not authenticated using Microsoft’s proprietary submission methods, it classifies the delivery path internally as “Direct Send.”
This does not mean:
- CIMcloud is using Microsoft Direct Send
- CIMcloud is attempting to bypass authentication
- CIMcloud is using any Exchange-specific feature
It means Microsoft decided how to label the connection on their side.
CIMcloud sends email using standard, RFC-compliant SMTP from publicly resolvable mail servers, authenticated via:
- SPF
- (Optional) DKIM
- DMARC policy evaluation
This is how SMTP has worked for decades across the internet. Details on configuring your domain’s DNS settings for email are available at:
What “Direct Send” actually means in Microsoft’s world
In Microsoft documentation, Direct Send is a catch-all classification, not a protocol.
Exchange Online applies this label when:
- Mail is received over SMTP
- The sending system is external
- The message is not submitted via Microsoft’s authenticated SMTP submission endpoint
Microsoft now applies additional restrictions to these connections due to abuse, especially when:
- The sender domain does not have DKIM
- DMARC policy is missing or strict
- The tenant has locked down anonymous SMTP
As a result, Exchange Online may require a Receive Connector or additional tenant configuration, even when SPF is correct.
This is a Microsoft policy decision, not a protocol failure.
Why SPF alone is no longer sufficient with Microsoft
In the wider email ecosystem:
- SPF is designed to authorize third-party senders
- DKIM is optional but recommended
- DMARC ties the two together
Microsoft increasingly treats SPF-only authorization as insufficient for some tenants and workloads.
When this happens:
- Exchange Online may block or defer messages
- Microsoft documentation directs customers to create a Receive Connector
- Microsoft still labels the message path as “Direct Send”
This does not indicate a misconfiguration on CIMcloud’s side.
CIMcloud’s role and responsibility
CIMcloud:
- Sends email using industry-standard SMTP
- Publishes SPF records for authorization
- Supports DKIM signing when customers choose to enable it
- Does not integrate with or depend on Microsoft-specific email features
CIMcloud does not:
- Control Exchange Online tenant policies
- Manage Microsoft spam filtering behavior
- Create or modify customer Receive Connectors
If Exchange Online requires tenant-specific configuration to accept third-party SMTP senders, that configuration must be performed by the tenant administrator or Microsoft support.
What customers can do to resolve this
In addition to configuring DMARC and SPF as outlined in the article Configure Your Email DNS, Microsoft-hosted domains require one or more of the following:
- Create a Receive Connector for third-party/partner SMTP senders
- Enable DKIM for their sending domain
- Adjust tenant restrictions on anonymous SMTP
Microsoft’s own documentation confirms these steps may be required.
Guidance on Creating a Receive Connector
If you enable the RejectDirectSend setting and need to create a receive connector for your CIMcloud site emails, you can use the following information when creating the connector.
- Use the IP address verification of the sending server option to limit allowed email to those sent from:
- 67.23.168.0/24
- 199.15.174.0/25
- We also recommend providing the additional security restrictions:
- Reject email messages if they aren’t sent over TLS
- Require that the subject name on the certificate to match the wildcard hostname *.wsp.prod.cimcloud.com