Outlook 550 5.7.606 Access Denied - Banned Sending IP, How to Delist

Outlook's 550 5.7.606 Access denied, banned sending IP means Microsoft has put your IP address on its internal block list, and every Microsoft 365 / Exchange Online server will refuse your connections. The fix is to request removal at the Microsoft delist portal (https://sender.office.com, the URL is in the bounce itself), which usually clears within 24 hours, and then fix whatever got the IP banned.

The exact bounce

550 5.7.606 Access denied, banned sending IP [203.0.113.10]. To request
removal from this list please visit https://sender.office.com/ and
follow the directions. For more information please go to
http://go.microsoft.com/fwlink/?LinkID=526655 AS(1430)

This rejection happens at connection time, before Microsoft even looks at your message content. Authentication, content, and list quality are irrelevant until the IP is delisted, nothing gets through.

Why Microsoft banned the IP

The last one matters: if you just provisioned a VPS and got 5.7.606 on your first send, the previous tenant burned the IP. Check before building reputation on it, or start from pre-warmed, clean IPs instead.

Step 1: Verify it's only Microsoft

Check public blacklists to see if the problem is wider than Microsoft's internal list:

# Spamhaus ZEN check (returns 127.0.0.x if listed)
dig +short 10.113.0.203.zen.spamhaus.org

# Quick connectivity test against an M365 MX
telnet yourdomain-com.mail.protection.outlook.com 25

If Spamhaus or other DNSBLs also list you, deal with those separately. Microsoft's portal only handles Microsoft's list.

Step 2: Stop the bleeding before delisting

Submitting a delist request while spam is still flowing from the IP gets you denied, and repeated denials make manual review harder. Before touching the portal:

1. Pause all campaigns from the affected IP.
2. Check mailq / your MTA logs for traffic you didn't send, compromised webforms and stolen SMTP credentials are the top two culprits.
3. Rotate SMTP passwords and lock down submission ports.
4. Remove hard-bounced and unengaged addresses from your lists.

Step 3: The delist portal

1. Go to https://sender.office.com/ (the Office 365 Anti-Spam IP Delist Portal).
2. Enter your email address and the banned IP, complete the captcha.
3. Click the confirmation link Microsoft emails you.
4. If the IP qualifies for automatic removal, the portal confirms it; propagation takes up to 24 hours across Microsoft's datacenters.

If the portal says the IP doesn't qualify, your request escalates (or you escalate it) to Microsoft sender support, the "New support request" path linked from the same bounce's go.microsoft.com URL. In that ticket include: the full bounce text, the IP, your sending domain, volumes, and what you fixed. Generic "please unblock" tickets get template denials; specific remediation details get action.

Step 4: Enroll in SNDS and JMRP

Microsoft gives senders direct visibility that most people never use:

Register every sending IP in SNDS the day you start using it. A red verdict in SNDS is the early warning that a 5.7.606 ban is coming; JMRP complaints tell you exactly which campaign caused it.

Step 5: Re-warm after delisting

A freshly delisted IP has fragile reputation with Microsoft. Going straight back to full volume is the fastest way to a second ban, and second delist requests face more scrutiny. Restart at roughly 5-10% of normal Microsoft-bound volume and double every 2-3 days, the same curve as a standard IP warm-up schedule. For the full re-warm timeline, see how long the ramp typically takes.

Also confirm SPF, DKIM, and DMARC all pass before resuming; unauthenticated mail accelerates the next ban. Microsoft applies the same baseline requirements as Google for high-volume senders (Outlook.com enforces SPF+DKIM+DMARC for 5,000+/day senders since May 2025).

Know which Microsoft list you're actually on

Microsoft runs separate filtering stacks, and the delisting path differs. Match the bounce to the stack before filing anything:

Filing a consumer-side support request for a 5.7.606 (or vice versa) wastes days, the teams don't cross-handle. The error code in your bounce is the routing slip; use it.

If the ban keeps coming back

Recurring 5.7.606 on a clean operation usually means one of three things: a neighbor problem (you're on a shared IP with a spammer), an undetected compromise, or list quality that's worse than you think. Audit in that order. If you're on shared infrastructure, this is the point where a dedicated IP, where you alone control the reputation, stops being optional. See our notes on choosing a dedicated SMTP provider.

How BulkEmailSetup helps

We provide dedicated SMTP servers on clean, pre-warmed IPs that we monitor in SNDS from day one, so Microsoft bans are prevented rather than delisted after the fact. Authentication, warm-up, and reputation management are handled for you; see pricing.

Frequently asked questions