Microsoft 365 "550 5.7.705 / 5.7.708 Access denied": tenant blocked

What it means

These two errors mean Microsoft 365 stopped your whole organization (your "tenant") from sending email to the outside, not just one user. Microsoft documents them as:

550 5.7.705 Access denied, tenant has exceeded threshold.
550 5.7.708 Access denied, traffic not accepted from this IP.

• 5.7.705: so much of your tenant's outgoing mail looked like spam or bulk mail that Microsoft blocked the tenant's sending.
• 5.7.708: your mail came from an IP address with a low reputation. Microsoft says this mostly affects new customers, for example on a Microsoft 365 trial.

If only one person is blocked and the bounce says 5.1.8 Access denied, bad outbound sender, that is a per-user block: see 550 5.1.8 bad outbound sender instead.

Why it happens

5.7.705

• A compromised admin account used to create connectors that relay spam through your tenant.
• A compromised on-premises server or application that routes mail through Exchange Online.
• Several compromised user accounts sending phishing at the same time.
• Legitimate but badly targeted bulk mail (old lists, many complaints) sent through Microsoft 365, which is not designed for mass mailing.
• Rarely, a renewed subscription that had expired: Microsoft notes sending can be blocked while it renews, usually for no more than a day.

5.7.708

• A trial or very new tenant sending to external recipients. New tenants are sent from IP pools with lower reputation until real licenses are assigned and the tenant has a history.

How to check

1. In the Exchange admin center, run a message trace for the last days and look at outbound volume per sender. Spikes, unknown senders or subjects you did not write are signs of abuse.
2. In the Microsoft Defender portal, check Restricted entities for blocked users, and the alerts for "suspicious email sending patterns" or "user restricted from sending email".
3. Review connectors (Mail flow > Connectors) for anything you did not create:

   Get-InboundConnector | Format-List Name,Enabled,SenderIPAddresses,WhenCreated
   Get-OutboundConnector | Format-List Name,Enabled,SmartHosts,WhenCreated

4. In the Entra sign-in logs, look for admin or user sign-ins from unusual countries or apps.
5. Check your own IPs (on-premises server, relay) on Delivmail's blacklist checker. A listing there usually means the spam really went out.

How to fix it

Only an admin can fix these errors. Microsoft's guidance is clear: fix the cause first, then contact Microsoft Support to remove the block. Support will not lift it while spam is still leaving.

Clean up (5.7.705)

1. Reset passwords and revoke sessions for any compromised admin and user accounts, remove unknown MFA methods, Inbox rules and forwarding (step-by-step for hacked accounts).
2. Delete or disable connectors you did not create, and check who has admin roles.
3. Secure any on-premises server or app that relays through Microsoft 365: patch it, require authentication, and make sure it is not an open relay.
4. Enforce MFA for everyone, starting with admins, and block legacy authentication where you can.
5. Move newsletters and mass mailings to a dedicated email marketing service with your domain authenticated.

Ask for the block to be removed

Open a support request from the Microsoft 365 admin center (Support > Help & support, or through your partner). Include a sample bounce with the full error, the date it started, and a short list of what you found and fixed. Self-service delist forms for IP blocks (used for 5.7.606 banned IP errors) do not apply to a tenant block.

5.7.708 on a trial tenant

Microsoft says to contact Support and ask for an IP exception until you assign Exchange Online licenses. In practice, buying and assigning licenses, sending from your own verified domain (not onmicrosoft.com), and keeping volume low at first are what get you out of the low-reputation pool.

Check that it is fixed

• When Support confirms the block is removed, send a test email from a normal user to the unique address on the Delivmail home page. Check SPF, DKIM and DMARC: a tenant that was abused often had weak authentication too (set them up for Microsoft 365).
• Resend one of the bounced messages to its external recipient.
• Keep watching outbound volume and alerts for a few weeks; a second incident usually leads to a longer block.