550 5.7.708: Microsoft 365 will not accept traffic from your sending IP

Fix it now

Microsoft publishes 5.7.708 as access denied, traffic not accepted from this IP, and names the cause as sending from an address with low reputation – which particularly affects new customers on trial subscriptions. It is a decision about where the mail came from, not about the message.

Get-AcceptedDomain | Format-List DomainName,DomainType
Get-Mailbox sender@contoso.com | Format-List PrimarySmtpAddress,RecipientTypeDetails
Get-InboundConnector | Format-List Name,SenderIPAddresses,SenderDomains,Enabled

1. Establish which address is being refused. It is the public address your mail leaves from – the tenant’s outbound infrastructure if you send through Microsoft 365, or your own gateway if you relay through a connector.
2. Check the subscription. In the Microsoft 365 admin centre, under Billing and Your products, confirm whether the tenant is on a trial or a paid subscription and whether that subscription is active.
3. Check the domains under Settings and Domains. Every domain you send from must be listed and verified in the tenant.
4. Open the Microsoft Defender portal and look at Restricted entities. An account restricted after a suspected compromise produces refusals that look like an infrastructure problem.
5. Assign Exchange Online licences to the mailboxes that send, then contact Microsoft Support to request an IP exception. That is the documented route for 5.7.708.

5.7.703 does not belong in this group. Microsoft publishes it as a block your own organisation configured in the Tenant Allow/Block List, and an email admin can lift it without contacting anyone.

If mail leaves after the licences and the exception, you are done. If a single account is refused while the rest of the tenant sends normally, the next section covers restricted senders.

Why it happens

Outbound mail from a large service is a shared reputation. Every tenant sending through it affects the addresses everyone else’s mail leaves from, so the service applies restrictions long before a message is examined for content. Microsoft’s published cause for 5.7.708 is that the mail was sent from an IP address with low reputation, and it names new customers with trial subscriptions as the group this particularly affects. Its published fix is equally specific: assign Exchange Online licences, then contact Microsoft Support to request an exception for the address.

5.7.705 sits alongside it, and Microsoft pairs the two in its own reference: most of the traffic from this tenant is detected as suspicious, so a ban is placed on the tenant’s ability to send. The published remedy is to make sure any compromises or open relays are resolved, and then to contact support through your normal channel. The support conversation is not optional in either case; it is the documented step.

5.7.750 is a different judgement. The published text is that the client is blocked from sending from unregistered domains, and the published cause is a suspicious number of messages coming from unprovisioned domains, or misconfigured connectors. The fix is to add and validate every domain you send from, use certificate-based connectors with accepted domains, and audit for suspicious connectors or compromised accounts before asking support to remove the block.

5.7.703 is the odd one out and is worth separating clearly. Microsoft publishes it as Your message can't be delivered because messages to <recipients> are blocked by your organization using Tenant Allow Block List – somebody in your organisation sent mail to an address or domain your own tenant has blocked, and the whole message is blocked for every recipient even if only one of them matched a block entry. Nothing about reputation, thresholds or subscriptions is involved, and only an email admin can change it.

Full reference

The four codes, and who can lift each block

Where the refusal is coming from

Restricted senders, and what the user sees

When an account is restricted from sending, the message it gets back is 5.1.8, and Microsoft publishes the wording: the sender was not recognised as a valid sender, most commonly because the address is suspected of sending spam and is no longer allowed to send. The account is cleared from the Restricted entities page at the Defender portal, under Email & collaboration, Review, Restricted entities, with the Unblock action. Microsoft’s stated timing is that restrictions should be removed within an hour under most circumstances, and within 24 hours at most.

1. Reset the password and revoke sessions first. Unblocking a still-compromised account simply restarts the incident.
2. Remove any inbox rules or forwarding the attacker created.
3. Unblock the mailbox from Restricted entities, enabling multifactor authentication and resetting the password from the flyout if you have not already.
4. Watch outbound volume for that account over the next day.

What Microsoft says users are restricted for

• Exceeding the outbound sending limits of the service.
• Exceeding the limits in the tenant’s outbound spam policies.
• Both of which, in Microsoft’s own words, typically result from account compromise rather than from unusual but legitimate use.

Moving the same traffic to a different sending address does not solve a reputation problem; it spreads it. Relaying business mail through an unrelated third party to get around a block also creates authentication and compliance problems of its own, and the original block stays where it is.

Before you contact support

1. Have the exact NDR text, including the code and the sending IP address.
2. Confirm the subscription is paid and active, and that the sending mailboxes have Exchange Online licences.
3. Confirm every sending domain is added and verified in the tenant.
4. Confirm no account remains on the Restricted entities page and no compromise is still active.
5. Then open the case. Microsoft’s documented fixes for 5.7.705, 5.7.708 and 5.7.750 all end with contacting support, and the case moves faster when the preceding steps are already done.

Every code this article covers

Confirm the fix worked

1. A test message from a licensed mailbox on a verified domain reaches an external recipient.
2. The admin centre shows an active paid subscription and every sending domain verified.
3. No account remains on the Restricted entities page in the Defender portal.
4. The Tenant Allow/Block List contains no stale entry for the recipients that were being refused.
5. Automated senders have been checked individually, since they usually run as the accounts nobody thinks to license.

Questions people ask about this