550 5.7.708: Microsoft does not accept traffic from this IP
550 5.7.708 is a Microsoft code that means traffic from your sending IP is not accepted. It is often linked to mail from a Microsoft 365 tenant that Microsoft has flagged as suspicious. It needs a deeper look than a retry.
- Bounce type
- Hard bounce (permanent)
- Usually caused on
- Your sending side
- Terlido report label
- Blocked by the provider
What the standard says
RFC 5321 defines 550 as "mailbox unavailable", which includes refusals for policy reasons. Subject 7 in RFC 3463 covers security or policy. The detail numbers 705 and 708 are not defined in an RFC. They are Microsoft's own codes, so the meaning comes from the Microsoft text.
What the mailbox providers say
- Microsoft 365 / Outlook (5.7.708): “Access denied, traffic not accepted from this IP” Source
Common causes
- Most of the traffic from the sending tenant or IP was detected as suspicious by Microsoft.
- A new or abused Microsoft 365 tenant that sent a lot of mail early.
- A compromised account or an open relay that sent spam from the same infrastructure.
- A sending pattern that looks like bulk unsolicited mail to Microsoft's filters.
- A forgotten forwarding rule or an old app password that let someone else send through your account.
- Sending that started before the account had any history, which makes the first large batches look like bulk mail.
How to fix it
- Check for compromised accounts and close any open relay.
- Stop sending from the flagged tenant or IP until the cause is clear.
- Contact Microsoft support to ask about the block.
- When sending resumes, start at a low volume and raise it slowly with a warmup plan.
- Review sign-in logs and forwarding rules for the account, and reset the passwords of any account you doubt.
- Turn off sending from the flagged account until Microsoft has answered your support request.
- Keep a record of what you did before the block, such as volume and lists, so you can explain it clearly to support.
Is it a deliverability problem?
Yes, and it is a serious one. A block at this level affects every message from the flagged source, not one campaign. Remove the cause, contact the provider, and rebuild volume carefully afterwards. Block-level codes like this one change what you do first. Retrying makes no sense and more volume makes it worse. Understand what happened to the tenant, repair it, and only then rebuild reputation with slow, low volume.
How Terlido handles it
When a bounce message for this code arrives in a connected mailbox, Terlido reads the status code. An enhanced code that starts with 5 is a hard bounce. In the campaign Reports tab this one is grouped as "Blocked by the provider".
On a hard bounce Terlido adds the address to the workspace blocklist with the reason "hard bounce", so no campaign emails it again. The lead stops in that campaign as bounced, its lead score goes down by 15, and the bounce counts toward the campaign's bounce rate.
Once a campaign has at least 20 sends, it pauses itself when hard bounces divided by sends goes over the campaign's maximum bounce rate. The default is 5%. If the cause was on your side and you fixed it, you can remove the entry on the Blocklist page of your account settings and try again.
Terlido treats every 5.x.x code as a hard bounce, so it blocklists the recipient even when the real cause is your own sending setup. After you fix the sending side, remove the entry from the blocklist if you want to contact that person again.
Check the domain behind the bounce
The free domain checker runs live SPF, DKIM, DMARC, MX and blocklist lookups and explains each result in plain English.
Free tools that help
Related error codes
- 550 5.7.606: Microsoft banned the sending IP
- 421 4.7.28: Unusual rate of unsolicited mail from your domain
- 550 5.7.1: Delivery not authorized, message refused