Microsoft 365 550 5.7.708 'Traffic Not Accepted From This IP' (and 5.7.705, 5.7.750): What to Do

550 5.7.708 Access denied, traffic not accepted from this IP means your own Microsoft 365 tenant cannot send. It is not about the recipient. Microsoft says the error is generated when you send from an IP with a low reputation, and that it "is more likely to affect new customers, such as those who have a Microsoft 365 trial subscription." Its sibling 5.7.705 means the whole tenant was blocked for sending spam, and 5.7.750 means too much mail went out from a domain the tenant has not registered. All three need a tenant admin and, in most cases, Microsoft support. The public delist portal does not apply.

The three codes

From Microsoft's fix guide for 5.7.703, 5.7.705, 5.7.708 and 5.7.750 (ms.date 2 October 2026, read 2 November 2026):

Code	Full text	Microsoft's explanation	Fix
5.7.708	Access denied, traffic not accepted from this IP	You sent from an IP with a low reputation. More likely for new customers, such as trials	On a trial, contact support for an IP exception until you assign Exchange Online licences
5.7.705	Access denied, tenant has exceeded threshold	Your organisation sent too much spam or bulk mail; often a compromised on-premises server or admin account	Fix the cause, then contact support to remove the block
5.7.750	Client blocked from sending from unregistered domain	Large volume sent from a domain that is not an accepted domain; less often, a misconfigured connector	Add and validate every sending domain, check connectors, then contact support
5.7.703	Messages to these recipients are blocked by your organisation using Tenant Allow Block List	Your own admin blocked the recipient	Only your admin can change the list

Microsoft's Exchange Online NDR reference (ms.date 24 August 2026) puts 5.7.705 and 5.7.708 in 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."

Is it one of these, or a different Microsoft block?

Microsoft uses many similar-looking codes. The fix depends on whether the problem is your tenant, your user, your IP or the recipient.

Code	Who is blocked	Where to fix it
5.7.705 / 5.7.708 / 5.7.750	Your whole tenant's outbound mail	Admin, then Microsoft support
5.1.8 "bad outbound sender"	One user on your tenant	Defender portal, Restricted entities. See Microsoft 365 restricted sender
5.7.606-649 "banned sending IP"	An IP sending into Microsoft 365	sender.office.com. See 550 5.7.606
5.7.509	Your domain failed DMARC	Authentication. See 550 5.7.509
5.4.1	The recipient does not exist	Suppress. See 550 5.4.1
451 4.7.650	Your IP, throttled by Outlook.com	Slow down. See 451 4.7.650

If you are not sure which one you have, paste the whole bounce into Bounce Doctor.

Why new tenants hit 5.7.708

Microsoft 365 sends outbound mail from shared pools, and it protects those pools. A tenant with no history and no paid licences is the kind of sender most likely to be abused, so Microsoft's systems are cautious with it. For cold senders, this is a common pattern:

• Buy a new domain, start a Microsoft 365 trial or a cheap plan, create several inboxes.
• Connect them to a cold email platform the same day.
• Send to a full list at normal volume within the first week.

That is close to what spam operations look like from Microsoft's side. A new tenant should send small, steady volumes, from licensed users, while its reputation builds. Microsoft 365 also applies separate outbound sending limits to new tenants, which come back with different codes, so read the full bounce before you open a ticket.

Fixing 5.7.708

1. Confirm you are the admin or reach whoever is. End users cannot fix tenant blocks.
2. Assign Exchange Online licences to the users who send. Microsoft's fix is written for trial tenants that have not yet done this.
3. Open a support request through the Microsoft 365 admin center and ask for an IP address exception, quoting the full NDR, timestamps and sample message IDs.
4. Stop bulk sending until the exception is in place. Every refused message is more evidence the tenant is risky.
5. When mail flows again, ramp slowly: a few dozen messages a day per user at first, steady through the day.

Fixing 5.7.705

5.7.705 means Microsoft saw spam or bulk mail leaving your tenant. Assume compromise until you have ruled it out.

• Check for compromised accounts. Look for sign-ins from unexpected places and inbox rules that forward or delete. Microsoft points to its guide on responding to a compromised email account.
• Check connectors. Attackers sometimes add connectors to relay mail through a tenant.
• Turn on multifactor authentication for every account.
• Review your own sending. If the "spam" was your cold campaign, the volume, list quality and complaints are the cause.
• Then contact support to have the block removed. Microsoft also notes a rarer case: a tenant renewing an expired subscription can be blocked for up to about a day.

Fixing 5.7.750

Add and validate every domain you send from in the Microsoft 365 admin center. If you send cold email from secondary domains, each one must be an accepted domain in the tenant before users send as it. Then check connectors for anything you did not create, and contact support to lift the block.

For cold senders: avoid the next one

Habit	Why it helps
Licensed users only, no trial tenants for outreach	Removes the most common 5.7.708 trigger
Small, steady volume for the first weeks	New tenants are judged on early behaviour
Verify every lead before sending	Invalid addresses are a classic spam signal
Accepted, authenticated domains	Avoids 5.7.750 and DMARC failures
MFA and no shared passwords	Stops compromises that cause 5.7.705
Watch bounces per inbox	A bad list on one inbox can affect the tenant

Check the domain's setup with the Microsoft sender requirements checker, and SMTP authentication for your sending tool with the Microsoft 365 SMTP AUTH checker.

What to tell Microsoft support

A support request moves faster when it answers the obvious questions up front:

• The full NDR, including the code, the text and the server reference at the end.
• When it started, with timestamps from two or three bounced messages.
• Your tenant status: trial or paid, how many licensed users, and when the domain was added.
• What the tenant sends: normal business mail, outreach, notifications, and rough daily volume.
• What you checked: no compromised accounts, MFA on, no unknown connectors, domains validated.

Be straightforward about outreach volume. Support can only grant an exception if the traffic looks like something Microsoft wants to carry.

Where SimpleVerifier fits

Verification cannot lift a tenant block. It removes one of the things that causes one. SimpleVerifier runs a live mailbox check on each address and returns safe to send, send with care, check again later or do not send, with the reason. Microsoft 365 business domains are probed normally, and catch-alls stay risky, never guessed valid, so a new tenant's first sends go to addresses a server confirmed.

The first 100 checks are free with a Google sign-in on the verify page. Pro is $39 a month with the first 100,000 checks a month at full speed, then slower, never cut off. See pricing.