550 5.7.606 access denied, banned sending IP: what to do
550 5.7.606 to 5.7.649 means Microsoft has banned the IP address you are sending from. Fix the cause, then request removal at Microsoft's delist portal.
On this page(8 sections)
The bounce reads "550 5.7.606 Access denied, banned sending IP [203.0.113.25]", and every message to Microsoft 365 and Outlook.com recipients fails with it. The problem is the sending IP address, not the message or the recipient. Microsoft has put that IP on its blocked list, and until it comes off, mail from it will not be accepted.
Here is how to read the code, work out why the IP was banned, and get it removed without being banned again a week later.
What does 550 5.7.606 mean?
550 5.7.606 means the IP address that connected to Microsoft's servers is on Microsoft's blocked senders list. Microsoft's NDR reference documents the whole range 5.7.606 to 5.7.649 as "Access denied, banned sending IP" with the IP in brackets. The number inside the range is not something you need to decode. Treat all of them the same way.
An IP address is the numeric address your mail server connects from. Microsoft judges mail by it long before it looks at your content, which is why the block hits every message at once.
How is it different from 5.7.511 and 5.7.705?
Microsoft uses several similar-looking codes, and the right fix depends on which one you have.
| Code | Microsoft's description | Who fixes it |
|---|---|---|
| 5.7.606 to 5.7.649 | Banned sending IP | You, then the self-service delist portal |
| 5.7.511 | Banned sender (the IP was banned) | Email [email protected] with the full NDR and the IP |
| 5.7.705 | Tenant has exceeded threshold | A tenant admin, via Microsoft Support |
| 5.7.708 | Low-reputation sending IP | See our 5.7.705 versus 5.7.708 guide |
The 5.7.511 row matters because the two codes get mixed up. Microsoft's table sends 5.7.511 to an email address, while the 606 to 649 range is the one with a self-service portal. Read the exact code in your bounce before you pick a route.
Why was your IP banned?
Microsoft's own wording is to follow email deliverability best practices and to make sure the IP's reputation is not degraded "because of compromise or malicious traffic." In practice, the causes fall into a few groups:
- A compromised account or application. Stolen credentials, an exposed API key or a hijacked web form sending spam from your server. See what to do about compromised-account outbound spam.
- A shared IP with a bad neighbor. On a shared pool, someone else's behavior can list the address you share. See shared versus dedicated IPs.
- A bulk send to a stale list. High bounce and complaint rates on a purchased or old list are the classic trigger.
- A new or reassigned IP. A fresh address with no sending history, or one previously used by someone else, starts with nothing in its favor.
- Missing basics. No reverse DNS, a HELO name that does not match, or no SPF and DKIM.
Check the message trace or your server's outbound log for the day the bounces started. A sudden spike in volume to one provider or to unfamiliar recipients is usually the first thing you find.
What should you check before asking for removal?
Fix the cause first. Delisting an IP that is still sending the problem traffic only invites the same ban. Work through this list:
- Confirm the IP in the bounce is really yours (or your provider's). Mail relayed through another service shows the relay's IP, not your server's.
- Look for compromised accounts: unexpected logins, forwarding rules, large outbound batches you did not send.
- Rotate any SMTP password or API key that could be exposed.
- Stop any send that targets an old or unverified list.
- Make sure the IP has matching reverse DNS and HELO.
- Confirm SPF, DKIM and DMARC pass for the domain you send as.
- Check other major blocklists too. Our blocklist delisting playbook covers the order to work in.
How do you request removal from the Microsoft block?
For the 5.7.606 to 5.7.649 range, use Microsoft's self-service delist portal at sender.office.com, which Microsoft points to in its NDR reference. The usual steps:
- Open the portal and enter the sending IP from the bounce and an email address Microsoft can reach you at.
- Submit the request and wait. Microsoft's guidance is to allow up to 24 hours, sometimes longer, rather than expecting an instant result.
- Send a test message to a Microsoft recipient and read the new bounce, if any.
The portal does not reliably send a confirmation, so the test message is how you find out. If you still get 5.7.606 after a few days, the request may have been refused because Microsoft still sees problem traffic from the IP. Go back to the checklist above instead of submitting the same request again.
If you have a 5.7.511 instead, the route is different: email [email protected] with the full NDR text and the IP address, per the same Microsoft table.
What if the IP is not yours to fix?
If you send through an email service and the banned IP belongs to it, you cannot delist it yourself. The provider owns the address and has to act. Tell them the full bounce text, the time and the recipient domain, and ask whether the IP is known to be listed. If the answer is slow, moving the traffic to a different sending path is a reasonable stopgap while they work on it.
Whichever route you use, keep the exact bounce text, since the provider and Microsoft both need it. Our docs cover sending and bounce handling for Koltrix.
How do you avoid a repeat?
- Send only to addresses that opted in, and remove hard bounces immediately.
- Ramp volume gradually on any new IP instead of switching a full load over at once.
- Watch complaint and bounce rates; Microsoft enrolls senders in SNDS and JMRP so you can see what it sees.
- Use unique, rotated credentials for every application that sends.
- Alert on unusual outbound volume so a compromise is caught in minutes, not days.
Bottom line
550 5.7.606 means Microsoft has banned the sending IP, and the fix is a sequence: find the cause, close it, then use sender.office.com to ask for removal. For 5.7.511, email [email protected] instead. Delisting without fixing the cause is the most common reason an IP gets banned again.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
