Users in a new or recently changed Microsoft 365 tenant send mail to outside recipients, and every message bounces with 5.7.708. Nothing in the Exchange admin center explains why. This is a sending block applied by Microsoft's service, not a setting you can switch off. In this post I'll explain what Microsoft documents about the code, the checks to run before you open a support request, and how to confirm that mail is flowing again.
Errors this guide fixes
5.7.708 Access denied, traffic not accepted from this IPNDR550 5.7.708 Service unavailable. Access denied, traffic not accepted from this IPNDR (diagnostic information)5.7.705 Access denied, tenant has exceeded thresholdNDR
Symptoms#
Messages to external recipients bounce, and the non-delivery report (NDR) quotes this text, which is the wording Microsoft documents:
5.7.708 Access denied, traffic not accepted from this IPIn the Diagnostic information for administrators section, admins usually report the full line in this form, with a Microsoft 365 server (*.prod.outlook.com) as the generating server:
Remote Server returned '550 5.7.708 Service unavailable. Access denied, traffic not accepted from this IP.'- It usually affects many or all senders in the tenant, not just one mailbox.
- Message trace shows the affected messages as Failed, with the 5.7.708 response in the details.
- A close relative, documented alongside it, reads
5.7.705 Access denied, tenant has exceeded threshold.
Why it happens#
Microsoft's per-code article says 5.7.708 is generated when mail is sent from an IP address with a low reputation, and that new customers, such as tenants on a Microsoft 365 trial, are the most likely to see it. The main Exchange Online NDR table groups 5.7.705 and 5.7.708 together: most of the tenant's traffic was judged suspicious, so the tenant's ability to send was restricted. Microsoft doesn't publish the reputation data or the thresholds, so there is nothing to tune on your side. Only Microsoft lifts the block.
For 5.7.705, Microsoft names the usual sources of the spam or bulk mail: an on-premises server that relays through Exchange Online and has been compromised, or a compromised admin account used to create connectors. That's why Microsoft asks you to resolve compromises and open relays before you contact support. The codes look alike but are fixed differently:
| Code | What is blocked | How it's lifted |
|---|---|---|
5.7.708 | Tenant sending from a low-reputation IP | Microsoft Support (an IP exception for trial tenants) |
5.7.705 | Tenant over the spam or bulk threshold | Fix the cause, then Microsoft Support |
5.7.750 | Mail from domains not added to the tenant | Add and verify the domains (guide) |
5.1.8 | One user restricted for sending spam | Restricted entities page (guide) |
5.7.606-649 | Your server's IP when it sends into Microsoft 365 | Self-service delist portal |
How to fix it#
- Confirm the scope with message trace. Check which senders fail and whether the failure detail quotes 5.7.708. If only one user is affected, you are probably looking at a restricted user instead.
PowerShell
Connect-ExchangeOnline # Senders with failed messages in the last two days Get-MessageTraceV2 -StartDate (Get-Date).AddDays(-2) -EndDate (Get-Date) -Status Failed -ResultSize 5000 | Group-Object SenderAddress | Sort-Object Count -Descending | Select-Object -First 20 Count, Name # Failure detail for one message Get-MessageTraceV2 -SenderAddress adele@contoso.com -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -Status Failed | Select-Object -First 1 | Get-MessageTraceDetailV2 | Format-List Date, Event, Detail - Rule out compromised accounts. Look for unusual outbound volume (run the first query without
-Status), check the Restricted entities page and the User restricted from sending email alerts in the Microsoft Defender portal, and review the top senders' sign-ins, Inbox rules and forwarding. The compromised mailbox guide has the full sequence. - Rule out rogue connectors and open relays. Microsoft notes that attackers sometimes create inbound connectors to send spam. List every connector, question anything you don't recognize, and check who created or changed one recently. If an on-premises server or application relays through Exchange Online, make sure it doesn't accept anonymous relay from anywhere (safe relay setup).
PowerShell
Get-InboundConnector | Format-Table Name, Enabled, ConnectorType, SenderIPAddresses, TlsSenderCertificateName, WhenCreated Get-OutboundConnector | Format-Table Name, Enabled, ConnectorType, SmartHosts, WhenCreated Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) ` -Operations New-InboundConnector,Set-InboundConnector -ResultSize 100 | Select-Object CreationDate, UserIds, Operations - Put the tenant on a normal footing. Add and verify your custom domain, send from it rather than the
onmicrosoft.comdomain, and assign Exchange Online licenses if you are still on a trial. Microsoft's guidance for trial tenants is an IP address exception that lasts until licenses are assigned. - Open a support request from the Microsoft 365 admin center. Only an admin can do this. Include the full NDR text, a Message ID from message trace, the time range and what you checked in steps 2 and 3. For 5.7.705, state what caused the spam and how you fixed it, because Microsoft removes that block only after the underlying cause is addressed.
Note: Microsoft documents the self-service delist portal for IPs banned when they send into Microsoft 365 (codes such as 5.7.511 and 5.7.606-649). For 5.7.708 and 5.7.705, the documented route is a support request.
Verify the fix#
When support confirms the change, send a test message to an external mailbox you control and trace it:
Get-MessageTraceV2 -SenderAddress adele@contoso.com -RecipientAddress tester@fabrikam.com `
-StartDate (Get-Date).AddHours(-1) -EndDate (Get-Date) |
Format-Table Received, RecipientAddress, Subject, Status- Delivered: the block is gone. Re-run the failed-senders query over the next day; it should show no new 5.7.708 failures.
- Failed with 5.7.708 again: reply on the same support case with the new Message ID.
- Failed with another code: follow that code instead, for example 5.1.8 for a single restricted user.
For more on reading trace results, see using message trace in Exchange Online.
Prevent it next time#
- Finish tenant setup before production mail starts: custom domain verified, MX pointing at Microsoft 365 and licenses assigned.
- Publish SPF, DKIM and DMARC for every sending domain (setup guide).
- Don't send newsletters or other bulk mail from user mailboxes. Use a dedicated bulk email service and ramp up new sending gradually.
- Require MFA, alert on restricted users and review connectors after any admin account incident, so a compromise is caught before it drags down the tenant's reputation.
