5.7.750 appears when high-volume mail flows through a Microsoft 365 tenant from a domain that is not registered as an accepted domain of that tenant. Microsoft treats it as a sign of misconfiguration or abuse and blocks it.
Most common causes
- The From or sending domain is not configured as an accepted domain
- A connector is using an unexpected or unregistered identity
- Bulk traffic is being sent from a domain outside the tenant’s intended configuration
What to verify next
- Confirm the domain used in the failing message
- Verify accepted-domain configuration
- Review connector and outbound identity settings
- Retest after the sending identity is correctly registered
Accepted domains define who the tenant may send as
Every domain a tenant sends from should be added and verified as an accepted domain. Mail using a domain outside that list — through a connector, a relay, or an application using a tenant mailbox with a different From address — is allowed at low volume but blocked once it becomes significant.
The NDR names the domain. Often it is a subdomain nobody registered, an acquired brand, or an application-generated address that was never added to the tenant.
Common configurations that trigger it
Multifunction devices and line-of-business applications relaying through the tenant with a hard-coded From address on an unregistered domain. Hybrid or on-premises relays forwarding mail for domains that exist on-premises but were never added in the cloud. Connectors configured with an identity that does not match any accepted domain.
Each case has the same shape: legitimate mail using an identity the tenant does not claim to own.
- Check the From and envelope domain named in the NDR.
- Subdomains need to be accepted separately unless the parent is added with subdomain routing.
- Connector and relay identities must match accepted domains.
Fix and verify
Add and verify the domain as an accepted domain in the Microsoft 365 admin center, or change the sending identity to a domain that is already accepted. If the domain is not yours to verify, the sender configuration is wrong and must be corrected at the source.
After the change, resend and confirm. Then review the domain’s own authentication: an accepted domain still needs SPF and DKIM configured for the tenant so downstream receivers accept it.
Best diagnostic path
Mail Failure Doctor
Classify the complete rejection and preserve provider-specific diagnostic context.
Open analysis → Live analysisEmail Infrastructure Digital Twin
Map the domain’s public mail infrastructure and provider relationships before remediation.
Open analysis →Known limits
- The volume threshold is Microsoft’s and applies across the tenant.
- Adding an accepted domain requires proving ownership; it cannot be used to send as a third party’s domain.
Common questions
We only send a little from that domain. Why blocked?
The block applies once volume becomes significant across the tenant. Small early traffic passes, then stops as usage grows.
Is a subdomain covered by the parent domain?
Only if the parent was added with subdomain routing enabled. Otherwise register the subdomain separately.
Can I send as a partner’s domain?
Not through your tenant without them delegating. Verification requires proof of ownership.
Why the exact message matters
The same status family can be triggered by different conditions, and providers frequently add diagnostic text that narrows the issue. Use the complete rejection text rather than treating the numeric code as a complete diagnosis.
Provider reference
For the provider-defined meaning and current requirements, review Microsoft Exchange Online NDR reference.