Microsoft 365 550 5.7.750: sending from an unregistered domain
550 5.7.750 means Exchange Online blocked a large volume of mail from a domain that is not an accepted domain. Add and validate the domain, then ask Support.
On this page(8 sections)
550 5.7.750 Client blocked from sending from unregistered domain is an Exchange Online rejection. It appears when your Microsoft 365 tenant sends a large amount of mail with a domain that the tenant has not registered as an accepted domain. The usual fix is to add that domain to Microsoft 365 and validate it.
An accepted domain is a domain your Microsoft 365 organization is set up to send and receive mail for. It is a tenant setting, so no DNS record at your registrar will clear this error on its own. This guide covers what Microsoft documents, how to find the domain that triggered the block, and where the evidence stops and guessing starts.
What does 550 5.7.750 mean?
It means Exchange Online refused outgoing mail because the sending domain is not an accepted domain in your tenant. Microsoft's page for NDR error codes 550 5.7.703, 5.7.705, 5.7.708, and 5.7.750 says the NDR is typically generated "if a large volume of email messages are sent from a domain that isn't an accepted domain," and that Microsoft 365 only allows a certain amount of mail from an unregistered domain.
Two details matter:
- It is volume-based. Microsoft does not publish the threshold, so you cannot compute how close you are. A few messages may pass for a while, then a burst trips the block.
- It is generated on the sending side. The bounce comes from your own tenant, not from the recipient's server. That is why the fix is in the Microsoft 365 admin center and not in the recipient's postmaster process.
Only an email admin in your organization can fix it.
Which domain is the unregistered one?
Start with the bounce and a message trace, because the domain in the error is not always the one you think you send from. Collect these facts for one failed message:
| What to read | Where | Why it matters |
|---|---|---|
| Full NDR text | The bounce message | Confirms the exact code and which sender it was for |
| Sender (From) address domain | Message trace in the Exchange admin center | The visible domain people see |
| Domain of the sending system or connector | Message trace details and your app or relay settings | Mail can leave under a different domain than the visible From address |
| Accepted domains list | Exchange admin center, Mail flow | Shows whether each domain is registered |
Then compare each domain you found against the accepted domains list. Microsoft does not say which address field its check reads, so do not assume it is only the From header. Check every domain that appears in the message path.
Common places an unregistered domain hides:
- A product or app that sends "from" a company domain you never added to Microsoft 365, relaying through a connector.
- A newly bought or secondary domain used for marketing, tracking or a side project.
- A domain used by a copier, CRM or ticketing system that someone pointed at your tenant.
- A leftover domain from an acquisition or rebrand.
How do you fix it?
Microsoft lists three recommendations, in this order of how common they are. Work top to bottom.
- Add and validate every domain you send from. Microsoft calls this adding a domain in Microsoft 365 "the most common solution." Validation means proving you own the domain by adding the DNS record Microsoft gives you, usually a TXT record.
- Use a certificate-based outbound connector if you relay mail through one. The certificate's domain must itself be an accepted and validated domain in Microsoft 365. Microsoft's page on configuring mail flow with connectors has the details.
- Look for connectors you did not create and for compromised accounts. Microsoft notes that attackers sometimes create new inbound connectors to send spam. See validating connectors in Exchange Online and responding to a compromised email account.
Microsoft also lists "one or more incorrectly configured connectors" as a less common cause. If step 1 shows every domain is already accepted and the error remains, the connector review is where to look next.
After you address the cause, Microsoft says to contact Microsoft Support to have the block removed. Do the fix first. Asking for removal while the unregistered domain is still sending invites a repeat.
Checklist before you contact Support
- I have the full NDR and the time of the first failure.
- I ran a message trace and listed every domain involved in a failed message.
- Each of those domains is in the accepted domains list and shows as validated.
- I reviewed outbound and inbound connectors and recognize every one of them.
- I checked sign-in activity and forwarding rules for compromised accounts.
- I can explain in one sentence what was sending and why it now sends from a registered domain.
What if the domain is already added?
This case is reported often and documented poorly, so be careful. In a Microsoft Q&A thread, a hybrid tenant with the domain added and set as default saw 5.7.750 only on automatic replies to external recipients. The domain was accepted but set to Internal Relay, because mailboxes also lived on an on-premises server.
One responder suggested the accepted domain should be Authoritative if every mailbox for the domain is in Microsoft 365, and a connector to the on-premises server if Internal Relay is needed. Another suspected a missing SPF record. The thread was locked with no confirmed fix, so treat both as hypotheses to test, not as Microsoft's documented answer. If you run a hybrid setup, send the full NDR and message trace to Support rather than changing the accepted domain type blind, because that setting also controls how mail for the domain is routed.
Related: automatic replies are a common source of outbound surprises. If one of yours is looping or answering bots, see an auto-reply that never loops.
How is it different from 5.7.705 and 5.7.708?
The same Microsoft page documents all three. We compare them in 550 5.7.705 vs 5.7.708.
| Code | Blocked because | First check |
|---|---|---|
| 5.7.705 | Tenant sent too much spam or bulk mail | Compromised accounts, connectors, on-premises relays |
| 5.7.708 | Sending IP has a low reputation | Trial status, source IP |
| 5.7.750 | Volume of mail from a domain that is not accepted | Accepted domains list |
If the rejection is a DMARC failure rather than a block on your tenant, you want 550 5.7.509 vs 5.7.515 instead.
How do you stop it recurring?
- Register a domain before anything sends with it. Make "added and validated in Microsoft 365" a step in launching any new domain, the same way you would add its SPF, DKIM and DMARC records. Our guide to domain verification flows shows why a clear verified or not verified state saves support time.
- Keep a short list of what sends mail. Apps, devices and relays that use your tenant should each be named, with the domain they send as.
- Use a separate sending domain for high-volume mail. A sending subdomain strategy keeps bulk and transactional mail away from the domain your people use in Microsoft 365.
- Review connectors on a schedule, and alert on unusual outbound volume from any one account.
If your application mail does not need to go through your Microsoft tenant at all, a transactional service on its own verified domain removes the dependency. Koltrix's API and SMTP relay (see docs.koltrix.com) send from custom domains you verify with SPF, DKIM and DMARC records. That is a design choice, not a fix for a block already in place.
Bottom line
550 5.7.750 means Exchange Online blocked a large volume of mail from a domain your tenant has not registered as an accepted domain. Find every domain in a failed message's path with a message trace, add and validate each one in Microsoft 365, check for connectors and accounts you do not recognize, and only then ask Microsoft Support to remove the block. If the domain is already accepted, suspect a connector or, in a hybrid setup, the accepted domain type, and send Support the full NDR and trace.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
