550 5.7.708: access denied, traffic not accepted from this IP

Your own Microsoft 365 tenant refused to send the message. The recipient never saw it. The fix is a Microsoft support request, after you prove the tenant is clean; the related 5.7.750 block is fixed by registering every domain you send from.

Quick answers

What does 550 5.7.708 Access denied, traffic not accepted from this IP mean?
Exchange Online blocked outbound mail from your Microsoft 365 tenant. Microsoft's fix page says the NDR is generated when you send from an IP address with a low reputation, and that it is more likely to affect new customers such as Microsoft 365 trial subscriptions. The Exchange Online NDR reference groups 5.7.708 with 5.7.705: most traffic from the tenant was detected as suspicious, so its sending ability was banned.
Can I remove a 5.7.708 block myself?
No. Microsoft's documentation says only an email admin can fix it, by contacting Microsoft Support. On a trial subscription, the admin requests an IP address exception until Exchange Online licenses are assigned. On any tenant, the NDR reference asks you to resolve compromises and open relays first.
Is 5.7.708 a DMARC, SPF or DKIM problem?
No. The block is on your tenant's outbound traffic and happens before the message reaches the recipient's server, so the recipient's DMARC check never runs. DMARC rejections from Microsoft 365 recipients use 550 5.7.509.
What is the difference between 5.7.708 and 5.7.750?
5.7.708 is a reputation block: traffic not accepted from this IP. 5.7.750, Client blocked from sending from unregistered domains, is raised when a large volume of mail is sent from domains that are not accepted domains in the tenant. You fix 5.7.750 by adding and validating every domain you send from, then asking Microsoft Support to remove the block.
How do I open a Microsoft support request for 5.7.708?
As an admin, go to the Microsoft 365 admin center at admin.cloud.microsoft, select Help & support at the bottom right, and if the suggested results do not help, select Contact Support and choose phone or email. You need at least one subscription bought through Microsoft; if all subscriptions came through a partner, contact the partner.

The exact bounce string

The sender gets a non-delivery report from their own Microsoft 365 tenant that reads: 

Remote Server returned '550 5.7.708 Service unavailable. Access denied,
traffic not accepted from this IP.'

Some reports append For more information please go to http://go.microsoft.com/fwlink/?LinkId=526653 AS(8561), as in this Microsoft Q&A thread. Microsoft's Exchange Online NDR reference (updated August 2026) lists the code as 5.7.708 Access denied, traffic not accepted from this IP.

What Microsoft says it means

Two Microsoft pages describe the code, from two angles:

  • The fix page, NDR error codes 550 5.7.703, 550 5.7.705, 550 5.7.708, and 550 5.7.750, says the NDR "is generated if you send an email message from an IP address that has a low reputation" and that the issue "is more likely to affect new customers, such as those who have a Microsoft 365 trial subscription."
  • The NDR reference table puts 5.7.705 and 5.7.708 on one row: "Most of the traffic from this tenant is detected as suspicious. Therefore, a ban is put on the sending ability of the tenant."

Both say the block is on your tenant's outbound mail. Nothing is wrong with the recipient, and nothing the recipient's admin changes will help.

Confirm the NDR came from your tenant

Open the NDR and read Diagnostic information for administrators. Microsoft's NDR reference explains that the Generating server field names the server that created the NDR, and that when no remote server is listed beneath the recipient, the generating server is also the one that rejected the message. Check that the server that rejected the message belongs to your own Exchange Online organisation. If the rejecting server is the recipient's mail system, the rejection came from the recipient's side and this article does not apply.

How to tell it apart from other Microsoft access-denied codes

  • 550 5.1.8 Access denied, bad outbound sender: one user account exceeded sending limits and is on the Restricted entities page. An admin can unblock it after securing the account.
  • 5.7.705 Access denied, tenant has exceeded threshold: the whole tenant sent too much spam or bulk mail. Secure the tenant, then contact Microsoft Support.
  • 5.7.708 Access denied, traffic not accepted from this IP: this page.
  • 5.7.750 Client blocked from sending from unregistered domain: too much mail from domains the tenant has not added and validated. See the 5.7.750 section below.
  • 550 5.7.606-649 Access denied, banned sending IP: the opposite direction. A server outside Microsoft 365 is sending to a Microsoft 365 recipient and its IP is banned. The sender delists at sender.office.com.
  • 550 5.7.509: the recipient rejected the message on DMARC. See 550 5.7.509.

If the tenant is on a trial subscription

Microsoft's fix page is direct: "If you're an email admin, and you receive this error during a trial subscription, contact Microsoft Support to request an IP address exception until you assign Exchange Online licenses." Microsoft's documentation gives no self-service route for this code; the support request is the documented fix.

  1. Check that the mailbox that sent the message has an Exchange Online license assigned.
  2. Open a support request. In the Microsoft 365 admin center at admin.cloud.microsoft, select Help & support at the bottom right, describe the problem, and if the results do not help select Contact Support and choose phone or email (Get support, Microsoft 365 admin).
  3. Ask for an IP address exception for 5.7.708 and include the full NDR, with the Diagnostic information for administrators section.

Microsoft's support page notes that you need at least one subscription bought through Microsoft to access Microsoft support. If all your subscriptions came through a partner, the partner opens the request.

If the tenant is paid: rule out compromise first

The NDR reference's instruction for 5.7.705 and 5.7.708 is: "Make sure that any compromises or open relays were resolved, and then contact support through your regular channel." Microsoft makes this a precondition, so work through the tenant before you open the ticket.

  1. Restricted entities. In the Microsoft Defender portal, open security.microsoft.com/restrictedentities. Microsoft's Restricted entities documentation describes a restricted entity as a user account or a connector blocked from sending because of indications of compromise. Any entry is a lead. In Exchange Online PowerShell, Get-BlockedSenderAddress lists restricted senders.
  2. Compromised accounts. Follow Microsoft's Responding to a compromised email account: disable the account or reset its password, revoke its sign-in sessions, require multifactor authentication, and remove forwarding and Inbox rules the user did not create. The guide lists Get-InboxRule -Mailbox <Identity> -IncludeHidden to find hidden rules.
  3. Connectors and relays. In the Exchange admin center, open Mail flow > Connectors (Validate connectors in Exchange Online). The list includes connectors created by the Hybrid Configuration Wizard or PowerShell. Remove any connector nobody can account for, and check that each device or server relaying through a connector sends only the mail it is meant to send.

When the tenant is clean, open the support request as described in the trial section and state what you found and changed.

550 5.7.750: client blocked from sending from unregistered domains

The NDR reference lists it as Service unavailable. Client blocked from sending from unregistered domains: a suspicious number of messages from unprovisioned domains is coming from the tenant. Microsoft's fix page gives the cause: Microsoft 365 "only allows a certain amount of email messages to be sent from an unregistered (unaccepted) domain." A less common cause is incorrectly configured connectors.

One way to get there: an app, a scanner or an on-premises server relays through your tenant with a From address on a domain that was never added to Microsoft 365. List the domains the tenant knows about, in the Exchange admin center under Mail flow > Accepted domains, or in Exchange Online PowerShell (Manage accepted domains): 

Get-AcceptedDomain

Compare that list against every From domain your users, apps and connectors send with. Then follow Microsoft's fix page:

  1. Add and validate every domain you send from in the Microsoft 365 admin center. Microsoft calls this the most common solution.
  2. Use a certificate-based outbound connector. The certificate's domain must be an accepted and validated domain in Microsoft 365.
  3. Look for unusual connectors and compromised accounts.
  4. After you fix the cause, contact Microsoft Support to have the block removed.

Do not keep retrying

Resending from the blocked tenant produces more rejected attempts. Microsoft's sender policies say that after a 500-599 response the sender must not retransmit that message to that recipient. Hold application mail at the source until Microsoft confirms the block is lifted.

What DMARC reports can and cannot tell you here

A 5.7.708 or 5.7.750 block stops mail inside your tenant, before any receiver evaluates DMARC, so these messages do not appear in DMARC aggregate reports. The reports are still useful for the 5.7.750 audit. They list, for each of your domains, the source IPs that sent mail with that domain in the From header. Across a portfolio of domains, that shows which domains go out through Microsoft 365 and which through other services, and it is the list to check against Get-AcceptedDomain. The DMARCTrust DMARC reports view turns the daily XML into a per-source breakdown.

Was this page helpful? Send us feedback

Last updated: October 2026

← All guides Start now

Need expert help with email deliverability?

Hire an email deliverability consultant who has shipped billions of emails. Free assessment, hands-on engagement, written quote before any work starts.

Talk to a consultant