5.7.750: Blocked from sending from unregistered domains (Microsoft 365)
At a glance
- Type: permanent failure (class 5, RFC 3463 §2). The sending server does not retry; sending the same message again fails the same way until the cause is fixed.
- Basic code: varies; the enhanced code is the part that identifies the problem.
- Enhanced code 5.7.750: not in the IANA registry; the group is security or policy status (RFC 3463 §3.8).
- Who uses it: Microsoft (Exchange Online): client blocked from sending from unregistered domains.
A 5.7.750 bounce from Microsoft 365 means your tenant sent a suspicious amount of mail from domains it has not added and verified, and Microsoft has blocked it from sending from those unregistered domains.
What it means
This is Microsoft's code, not one from the IANA registry. Microsoft's Exchange Online NDR reference describes it as a client blocked from sending from unregistered domains.
Every Microsoft 365 tenant has a list of accepted domains: domains it has added and proven it owns, by publishing a DNS record Microsoft asks for. Mail sent through the tenant with a From address on some other domain is from an "unregistered" domain. A little of that can be legitimate. A lot of it looks like a tenant used to send as other people's domains, so Microsoft blocks it.
Common causes
- A device, app or connector sends through your tenant with a From address on a domain you never added (an old company name, a client's domain, a test domain).
- Your on-premises servers relay mail for several domains through Microsoft 365, but only some of those domains are in the tenant.
- A domain was removed from the tenant while systems kept sending as it.
- The tenant is being misused to send mail as unrelated domains.
How to fix it
- Read the bounce and your message trace to see which From domains are being sent through the tenant.
- For every domain you own and send from, add it in the Microsoft 365 admin center and complete verification by publishing the DNS record it gives you.
- Set up SPF and DKIM for each of those domains as well (SPF checker, DKIM checker), so the mail authenticates once it is allowed.
- Stop any system from sending as domains you do not own. If a client's domain is involved, that client should send through its own setup.
- If the block stays in place after the domains are verified, contact Microsoft support.
Similar Microsoft blocks
A tenant whose traffic mostly looks suspicious can be restricted entirely, with 5.7.708. On-premises servers that no longer match their inbound connector get 5.7.64. An IP banned by Microsoft gets 5.7.606.
What to do with the address
Keep it. This is about the domains your tenant sends from, not the recipient.
Related codes
- 5.7.708: Tenant traffic not accepted from this IP (Microsoft 365)
- 5.7.64: TenantAttribution: relay access denied (Microsoft 365)
- 5.7.606: Banned sending IP (Microsoft)
See every bounce code in the dictionary.
Many bounces from addresses that do not exist can be avoided: check an address with our free email checker, or clean a whole list before you send.
How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.