NDR 550 5.7.750 in Exchange Online: Client blocked from sending from unregistered domains

Your on-premises servers, scanners or line-of-business apps relay mail to the internet through Exchange Online, and suddenly those messages bounce with 5.7.750. The cause is almost always the same: Exchange Online is relaying mail for sender domains it doesn't know belong to you. In this post I'll show how to find the domains involved, fix them or the connector, get the block lifted and prove that relayed mail is flowing again.

Symptoms#

Senders whose mail is relayed through Microsoft 365 get a non-delivery report (NDR) with this line, as listed in Microsoft's Exchange Online NDR reference:

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

Microsoft's per-code article quotes it in the singular: 5.7.750 Client blocked from sending from unregistered domain. Either way:

• Typically, the failing messages reach Exchange Online through an inbound connector, from an on-premises Exchange server, a relay server, an application or a device.
• Message trace shows them as Failed.

Why it happens#

Exchange Online relays mail from your own servers to the internet only when it can attribute that mail to your organization. Microsoft's guidance for relaying through Microsoft 365 has two parts. An inbound connector identifies your server by its sending IP address or by its certificate. Then one of these conditions must be true:

• Sender domain: the sender's domain is registered (added and verified) in your tenant.
• Certificate-based connector: your server presents a certificate whose common name (CN) or subject alternative name (SAN) contains a domain registered in the tenant, and the inbound connector is configured with that domain.

Microsoft 365 accepts only a certain amount of mail from unregistered (unaccepted) domains. When a large volume arrives that way, Exchange Online rejects it with 5.7.750, and the block stays until Microsoft Support removes it. Microsoft names a few causes:

• Domains you never added, the most common one: a second brand, a subsidiary, or an app that sends as a domain the tenant doesn't have.
• One or more incorrectly configured connectors, which Microsoft calls a less common cause.
• Abuse: attackers who compromise an admin account sometimes create inbound connectors to send spam.

Don't confuse it with 5.7.64 TenantAttribution; Relay Access Denied. That one rejects individual relayed messages that Exchange Online can't attribute to your organization, typically after a change on-premises means the connector no longer matches your servers. 5.7.750 is a block triggered by volume from unregistered domains.

How to fix it#

1. Find the sender domains being relayed. Trace by the public IP of the relaying server and group the results by domain, then compare them with your accepted domains:
   PowerShell

   Connect-ExchangeOnline
   
   Get-MessageTraceV2 -FromIP 203.0.113.10 -StartDate (Get-Date).AddDays(-2) -EndDate (Get-Date) -ResultSize 5000 |
       Group-Object { ($_.SenderAddress -split '@')[-1] } | Sort-Object Count -Descending |
       Format-Table Count, Name
   
   Get-AcceptedDomain | Format-Table DomainName, DomainType, Default

2. Register every domain you send from. Microsoft calls this the most common fix. In the Microsoft 365 admin center, go to Settings › Domains › Add domain and complete the DNS verification. Domains you don't own can't be verified, so change any app that sends as a vendor's or partner's domain to use one of yours. If some recipients in a newly added domain live on another mail system, set the domain to Internal relay under Mail flow › Accepted domains in the Exchange admin center (see the 5.1.10 guide).
3. Switch relayed traffic to a certificate-based connector. Microsoft's per-code article calls this a "certificate-based outbound connector", seen from your server's side. In Exchange Online, the matching piece is the inbound connector from your organization's email server that identifies it by certificate. The certificate's domain must be registered in the tenant. If the certificate holds several host names, Microsoft recommends a wildcard such as *.contoso.com on the connector. Microsoft also asks hybrid customers to check connectors created by the Hybrid Configuration Wizard that name a host such as mail.contoso.com, which may not be a registered domain.
   PowerShell

   Get-InboundConnector | Format-List Name, Enabled, ConnectorType, SenderIPAddresses, TlsSenderCertificateName, RequireTls
   
   Set-InboundConnector -Identity "From on-premises" -TlsSenderCertificateName "*.contoso.com" -RequireTls $true

   On the sending side, the server must present a certificate with that domain in its CN or SAN. For Exchange Server, that's the TlsCertificateName on the send connector to Microsoft 365. This route also covers forwarded mail and on-premises NDRs, which can't meet the sender domain condition.

4. Look for connectors you didn't create. Remove or disable unknown connectors, check who created them in the audit log, and treat the admin account involved as compromised (investigation steps).
   PowerShell

   Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) `
       -Operations New-InboundConnector,Set-InboundConnector -ResultSize 100 |
       Select-Object CreationDate, UserIds, Operations

5. Ask Microsoft Support to remove the block. Microsoft lifts it only after the underlying cause is fixed. Open a request from the Microsoft 365 admin center and include the NDR, a Message ID and the changes you made.

Verify the fix#

1. Send a test message through the relay path (from the app, device or on-premises mailbox) to an external mailbox you control.
2. Trace it. Delivered means relaying works again:
   PowerShell

   Get-MessageTraceV2 -FromIP 203.0.113.10 -StartDate (Get-Date).AddHours(-1) -EndDate (Get-Date) |
       Format-Table Received, SenderAddress, RecipientAddress, Status

3. Re-run the trace with -Status Failed over the next day. Good looks like no new 5.7.750 entries, and every sender domain in the grouped output appears in Get-AcceptedDomain.
4. Test a forwarded message or an on-premises NDR too, if you depend on them. They succeed only through the certificate-based route.

Prevent it next time#

• Before a new app or brand starts sending through Microsoft 365, add and verify its domain, and publish SPF and DKIM for it (setup guide).
• Prefer certificate-based inbound connectors for on-premises relays, and when you renew the certificate, keep a registered domain in its CN or SAN.
• Review connectors regularly and alert on connector changes; they are a favorite target after an admin account is compromised.
• For hybrid connector design, see Exchange hybrid mail flow: connectors and TLS.

References#

• Fix NDR error codes 550 5.7.703, 550 5.7.705, 550 5.7.708, and 550 5.7.750 (Microsoft Learn)
• Configure a certificate-based connector to relay email messages through Microsoft 365 (Microsoft Learn)
• Email nondelivery reports and SMTP errors in Exchange Online (Microsoft Learn)