I checked Spamhaus and every major blocklist — my IP is clean. So why does Microsoft still say banned?

Because 5.7.606 isn't a public blocklist. Microsoft 365 maintains its own internal blocked-senders list, separate from Spamhaus, Barracuda, SORBS, or any external DNSBL you can query. Your IP can be spotless on every public list in the world and still be on Microsoft's — the two have nothing to do with each other. This is why people burn days checking the wrong lists: a clean DNSBL result tells you nothing about your 5.7.606 status. The only place that ban lives is inside Microsoft, and the only way off it is Microsoft's delist portal at sender.office.com.

I delisted through the portal and it worked, but a week later I'm banned again. What am I doing wrong?

You treated the symptom, not the cause. Delisting removes the current ban; it does not fix whatever got you listed. If the underlying problem is still live — a compromised mailbox blasting spam, an open relay, a missing PTR record, or a shared IP whose neighbors are dirty — Microsoft's filters will re-flag the same IP and re-ban it, and repeat delist requests get less sympathetic each time. Find and fix the sending behavior first: secure any breached account, close the relay, set a valid PTR, authenticate your mail. Delist last, once the cause is gone.

How is 5.7.606 different from 5.7.511?

They route to different remedies, so the distinction matters. 5.7.606 through 5.7.614 (Microsoft documents the range up to 649) mean 'Access denied, banned sending IP' — your IP address is blocked, and you request removal at the delist portal, sender.office.com. 5.7.511, 'Access denied, banned sender,' blocks a specific sender identity rather than the IP, and it cannot be cleared through the portal; Microsoft directs those to delist@microsoft.com instead. Read the exact code off the bounce before you act — the wrong channel wastes a day.

Views: 27

550 5.7.606 Access denied, banned sending IP — Fix

550 5.7.606 means Microsoft 365 banned your sending IP. Fix it in 4 checks: delist portal, PTR, IP reputation, root cause. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Your mail to @outlook.com, @hotmail.com, or a Microsoft 365-hosted business domain bounces with 550 5.7.606 Access denied, banned sending IP [your.ip.address.here]. Nothing reached the recipient. This isn’t a content filter or a spam-folder problem — Microsoft refused the connection at the door because the IP you’re sending from is on its internal blocked-senders list.

Symptoms

Bounces read 550 5.7.606 (or 5.7.607 through 5.7.614) with the phrase “Access denied, banned sending IP” and your sending IP in brackets.
Only Microsoft destinations reject you — Outlook, Hotmail, Live, and Microsoft 365 business tenants — while Gmail, Naver, and others still accept the same mail.
Every public blocklist you check (Spamhaus, Barracuda, SORBS) shows your IP as clean, which makes the ban look inexplicable.
It started after you moved to a new IP, a new VPS, or a shared-hosting sending platform.
Or it started after a mailbox on your domain was compromised and sent a burst of spam.

What 550 5.7.606 Actually Means

Read the code in two parts. The 550 is a permanent SMTP rejection (RFC 5321): retrying the identical send won’t help. The 5.7.606 is Microsoft’s own enhanced status code, and it’s specific — “Access denied, banned sending IP.” Microsoft 365 blocks your IP address, not your message and not your domain.

The single most important fact about this error is where the ban lives. Microsoft 365 keeps its own blocked-senders list, built from its own signals — spam traps, complaint rates, authentication failures, and the reputation of the IP and its neighbors. This list is not Spamhaus. It is not any external DNSBL. So the reflex most senders reach for — check the public blocklists, find nothing, and conclude the ban is a mistake — is checking a map of the wrong city. A pristine DNSBL result and a Microsoft ban coexist perfectly, because they measure different things.

That means there is exactly one place to resolve it: Microsoft’s delist portal at sender.office.com, which anyone — even a non-Microsoft-365 customer — can use to request removal. But the portal only lifts the current ban. If the behavior that earned the ban is still happening, the same IP gets re-listed, and repeat requests wear thin. Microsoft’s own guidance notes delisting can take up to 24 hours to take effect, and a confirmation isn’t proof every recipient path has recovered.

Top 3 Causes

A compromised account or open relay spewing spam. A breached mailbox, a misconfigured relay, or a hijacked web form is sending junk from your IP, and Microsoft’s filters noticed before you did. The tell: the ban appeared suddenly with no infrastructure change on your side, and your outbound queue or mail logs show volume or recipients you don’t recognize. This is the cause that must be fixed before delisting — otherwise you re-ban within days.
A shared or freshly-allocated IP with borrowed reputation. You send from a VPS, cloud instance, or shared platform on an IP that a previous tenant abused, or from a brand-new address with no sending history. Microsoft distrusts it by inheritance. The tell: the ban was there from your very first send, or the IP is in a cloud/hosting range known for churn, and you never controlled who used it before you.
Missing or generic reverse DNS on the sending IP. The IP has no PTR record, or a default cloud-provider PTR that doesn’t match your sending hostname. Microsoft weighs reverse DNS heavily, and its absence drags reputation toward a ban — especially combined with either cause above. The tell: a reverse-DNS lookup on your sending IP returns nothing or a generic ip-x-x-x-x.provider.example name.

Diagnose with DechoNet

IP Lookup shows the sending IP’s owner, ASN, and hosting/cloud classification — so you can tell whether you’re on a shared or data-center range whose reputation you don’t control, which changes whether the fix is “delist” or “move to a dedicated IP.”
Reverse DNS Lookup checks whether your sending IP has a valid PTR that resolves back to your real sending hostname (forward-confirmed). A missing or generic PTR is a reputation drag Microsoft notices, and setting a proper one is a prerequisite before delisting is worth attempting.

Resolution Checklist

Read the exact enhanced code off the bounce. If it’s 5.7.606–5.7.614 (“banned sending IP”), use the delist portal. If it’s 5.7.511 (“banned sender”), do not use the portal — email [email protected] instead.
Before delisting, find the cause: check your mail logs and outbound queue for spam volume, secure any compromised mailbox, and close any open relay or abused form. Delisting a still-spamming IP just resets the clock.
Run IP Lookup on your sending IP. If it’s a shared/cloud IP whose reputation you don’t control, consider moving to a dedicated sending IP rather than repeatedly delisting one you’ll never keep clean.
Check Reverse DNS and set a valid, forward-confirmed PTR that matches your sending hostname if it’s missing or generic.
Confirm your mail authenticates — SPF, DKIM, and a DMARC record on the sending domain — so Microsoft has a clean identity to rebuild trust against.
Only now, submit the IP at sender.office.com, confirm via the email it sends, and allow up to 24 hours. Don’t treat the confirmation as full recovery — re-test with a real message.

When to Escalate

If you’ve fixed the cause, set a valid PTR, authenticated the mail, and delisting either fails or the ban returns, open a support request through the delist portal’s follow-up path with your logs — a persistent ban on a clean, dedicated IP is something only Microsoft can explain.
If the code is actually 5.7.511 and [email protected] doesn’t clear it, escalate through Microsoft 365 support rather than resubmitting; the banned-sender path is handled by people, not the self-service portal.