Microsoft 365 "550 5.7.750 ... unregistered domains": how to fix it

What it means

Microsoft 365 refused to send mail because it was sent From a domain your organization has not registered in Microsoft 365. The bounce usually reads:

550 5.7.750 Service unavailable. Client blocked from sending from unregistered domains.

An "unregistered" (or "unprovisioned") domain is a domain that is not in your list of accepted domains, meaning you never added and verified it in the Microsoft 365 admin center. Microsoft allows only a limited amount of mail from such domains; above that, it blocks the sender.

Why it happens

• A second brand or an old domain is used in the From address (for example shop-yourdomain.com) but only yourdomain.com was added to Microsoft 365.
• An application or on-premises server relays through a connector and sends From many different domains, for example a ticketing tool that uses each customer's domain, or a server that relays mail for several companies.
• A hybrid or relay connector configured too broadly, accepting mail from any sender and relaying it through Microsoft 365.
• An attacker created an inbound connector in your tenant to send spam From random domains. Microsoft lists this among the causes.

How to check

1. Look at the bounced message: which address is in the From line, and does that domain belong to you?
2. List the accepted domains of your tenant:

   Get-AcceptedDomain | Format-Table DomainName,DomainType,Default

   In the admin center, the same list is under Settings > Domains; each domain should show a healthy status.
3. Run a message trace on recent outbound mail and group it by sender domain. Any domain that is not in the list above is a candidate.
4. Review connectors, especially inbound ones you do not recognize:

   Get-InboundConnector | Format-List Name,ConnectorType,SenderIPAddresses,SenderDomains,TlsSenderCertificateName,WhenCreated

5. Check the domain with the Delivmail domain scanner to see its MX, SPF and DMARC. A domain whose SPF does not include spf.protection.outlook.com should not be sending through Microsoft 365 anyway.

How to fix it

Only an admin of the sending tenant can fix this.

1. Add and verify every domain you send from

This is the most common fix. In the Microsoft 365 admin center, go to Settings > Domains > Add domain, then add the TXT verification record Microsoft shows at your DNS host. For example:

Host: shop-yourdomain.com (or @)
Type: TXT
Value: MS=ms12345678

Use the exact value Microsoft gives you. Once verified, add SPF and DKIM for that domain too, as described in SPF, DKIM and DMARC for Microsoft 365, so its mail is authenticated and not only accepted. If you send from a subdomain, the same applies: see email authentication for subdomains.

2. Fix applications that use other people's domains

Microsoft 365 is not a relay for domains you do not own. Configure the application to send From one of your own domains (and put the customer's address in Reply-To if needed), or send that traffic through a transactional email service that can authenticate each domain properly.

3. Tighten your connectors

Microsoft recommends a certificate-based connector: the inbound connector identifies your on-premises server by its TLS certificate, and the certificate's domain must be an accepted and verified domain in your tenant. This ties relayed mail to a domain you own instead of to "anything from this IP".

4. Remove connectors you did not create

If you find an unknown connector, treat it as an incident: disable it, check admin accounts and sign-ins, reset credentials, and enforce MFA for admins. Large spam runs through a rogue connector can also lead to a full tenant block (5.7.705).

5. Ask Microsoft to remove the block

Microsoft says to contact Support once the cause is fixed, so the block can be removed. Include a sample bounce and the list of domains you added or connectors you corrected.

Check that it is fixed

• Send a test from the same application or server, using the newly added domain in the From address, to the unique address on the Delivmail home page. The report should show SPF and DKIM passing and aligned with that domain.
• Then resend a message that bounced. DNS changes for the verification and SPF records can take some time to propagate.
• Keep the accepted domains list in sync whenever your company adds a new brand or domain.