It says 'banned sender' but shows an IP address — is my email address blocked or my server?

Your server's IP. This is the part of 5.7.511 that misleads everyone: the wording says 'banned sender' but the value in the brackets is the sending IP address, and Microsoft's block is on that IP, not on your email address or domain. It doesn't matter which mailbox sent the message or how clean your domain looks — every message leaving that IP toward a Microsoft 365 recipient gets refused. That distinction changes the whole fix. You're not editing a safe-senders list or fixing one address; you're getting an IP out of Microsoft's reputation blocklist, which is a different and slower process.

Why can't I just use the delist portal like I did for 5.7.606?

Because 5.7.511 and 5.7.606-649 are two different tiers of block. The 5.7.606-649 range is Microsoft's self-service IP block: you go to sender.office.com, submit the IP, and it's usually lifted quickly because it's a lower-confidence reputation call. 5.7.511 is the stronger block — Microsoft flagged sustained abuse from that IP, and it deliberately keeps this one off the self-service portal. There is no button. You email delist@microsoft.com with the full NDR and the IP, Microsoft may investigate the traffic from that source, and it responds with next steps, typically within about 48 hours. The gate is higher on purpose.

I sent one normal email and got 5.7.511. Where did the abuse come from?

Almost always from mail you didn't knowingly send. The three usual sources: a mailbox on that IP is compromised and quietly blasting spam, an application or device is relaying mail through the server in a loop, or the server is an open or misconfigured relay that strangers are using. Microsoft doesn't ban a source IP for one clean message — it bans it for a pattern, and if your own sending was clean, the pattern came from somewhere else on the same IP. Before you appeal, find and stop the source, because Microsoft re-bans an IP that goes clean and then dirty again.

The banned IP belongs to my hosting or email provider, not me. What now?

Then you may not be able to delist it yourself, and appealing directly can even be counterproductive. On shared sending infrastructure the IP's reputation is a shared resource — one bad tenant can get the whole IP banned, and one tenant usually can't get it lifted. Open a ticket with the provider: they own the relationship with Microsoft for that IP and can either drive the delist or move you to a clean IP. If you're on a shared IP and this keeps happening, that's the real signal — you've outgrown shared sending and need a dedicated IP or a proper email service you control.

550 5.7.511 Access denied, banned sender

Problem

Mail to Microsoft 365 recipients — anyone on Outlook.com, Office 365, or a company using Exchange Online — bounces with 550 5.7.511 Access denied, banned sender [x.x.x.x]. The bracketed value is an IP address. Delivery to those recipients stops completely; mail to other providers may still go through fine.

What 550 5.7.511 Actually Means

Read it literally and it’s misleading. “Banned sender” sounds like your email address or domain is on a list somewhere. It isn’t. The value Microsoft puts in the brackets is the sending IP address, and that IP is what’s banned. Every message leaving it toward a Microsoft 365 mailbox is refused, no matter which account sent it or how well-configured your domain is.

The 550 is a permanent rejection, and here — unlike a rate limit wearing a 5xx costume — it really is a durable block until you get it lifted. Microsoft applies 5.7.511 when it has decided a source IP is sending abusively: spam, phishing, or a volume-and-pattern signature that looks like a compromised or hijacked sender. This is its high-confidence, source-level block.

So the two instincts people have are both wrong. It is not an authentication failure — bad credentials give you 535. It is not a recipient-side safe/blocked-senders entry you can ask someone to toggle. It is an IP sitting in Microsoft’s reputation blocklist, and getting it out is a process, not a setting.

The Fork That Decides What You Do Next

Before anything else, answer one question: is that IP address yours to control?

If you run your own mail server on a dedicated IP, the reputation is entirely yours — you caused it, and you can appeal it, but only after you fix what triggered it.
If you send through a shared IP — a hosting provider’s mail server, a shared SMTP relay, a platform’s pooled senders — the reputation is shared, and so is the damage. Another tenant’s spam can get the whole IP banned, and you usually can’t delist an IP you don’t own. That’s a ticket to your provider, not an email to Microsoft.

Getting this wrong wastes days. People fire off a delist request for an IP their provider controls, wait 48 hours, and get nowhere because they were never the party who could fix it.

Why This Is Not the Same as 5.7.606

If you’ve dealt with Microsoft mail blocks before, you’ve probably seen 550 5.7.606-649 Access denied, banned sending IP. Same idea — a banned source IP — but a different tier, and the difference is the whole reason 5.7.511 is worse:

5.7.606-649 is the self-service block. You go to the delist portal at sender.office.com, submit the IP, and it’s typically lifted quickly. It’s a lower-confidence reputation call, so Microsoft lets you clear it yourself.
5.7.511 is the stronger block. Microsoft deliberately keeps it off the self-service portal. You can’t clear it with a form. You email delist@microsoft.com with the full NDR and the IP, Microsoft may investigate the traffic from that source, and it replies with next steps — usually within about 48 hours.

If you land on the 5.7.606 case instead, use the 550 5.7.606 banned sending IP guide — the path there is faster.

Top 3 Causes

A compromised mailbox is sending spam you can’t see. The most common trigger for a sudden, hard IP ban is an account takeover: an attacker has valid credentials for a mailbox on that IP and is quietly blasting spam until the IP’s reputation collapses. The tell is the mismatch — your own legitimate volume is low, but Microsoft is reacting to a flood. Check for it before you assume you were sending too aggressively.
A misconfigured or open relay. A mail server that accepts and forwards mail it shouldn’t — an open relay, or an application relaying through it in a retry loop — becomes a spam conduit, and the IP pays for it. This is a server-configuration problem, not a content problem, and it will get the IP re-banned the moment it’s delisted if the relay is still open.
Abusive-looking volume from weak-reputation infrastructure. A new IP with no sending history, no PTR record, and missing or unaligned SPF/DKIM/DMARC that suddenly pushes real volume looks exactly like a spammer to Microsoft. Even legitimate mail can trip the strongest block if it arrives from a source that has none of the signals a trustworthy sender is supposed to have.

Diagnose with DechoNet

Email Check — run it on your sending domain to confirm SPF, DKIM, and DMARC are present and aligned. This is the remediation Microsoft is looking for: an appeal from a source with proper authentication and a clean setup is far more likely to succeed and stay succeeded, because it shows the traffic is accountable.
Reverse DNS Check — Microsoft weighs reverse DNS heavily. Confirm the sending IP has a PTR record and that it forward-confirms (the hostname resolves back to the same IP). A missing or mismatched PTR is one of the fastest ways to look like an abusive source, and one of the easiest to fix.
IP Check — verify exactly which IP your mail actually leaves from (it isn’t always the one you think, especially behind a relay or smart host), so you appeal for the right address and can see what else that IP is associated with.

Resolution Checklist

Read the NDR and copy the exact IP from the brackets. That is the address that’s banned — confirm it’s actually yours to fix, not your provider’s.
If it’s a shared or provider-owned IP, stop here and open a ticket with the provider. They own the delist and can move you to a clean IP.
Find and kill the root cause before appealing. Assume compromise first: reset credentials on the sending accounts, revoke sessions, and read the Sent folders. Close any open relay. Stop any runaway application or device.
Run an Email Check and fix every SPF/DKIM/DMARC gap, and a Reverse DNS Check to confirm a forward-confirmed PTR. This is your remediation evidence.
Only then email delist@microsoft.com with the full NDR and the sending IP. State plainly what the cause was and what you fixed — a bare “please unblock me” without remediation tends to go nowhere.
Wait for Microsoft’s reply (typically ~48 hours) and follow the steps it gives. Do not resume heavy sending from a freshly delisted IP; ramp back up gradually.

When to Escalate

If the IP is compromised-account driven — low personal volume, high abusive volume — treat it as a security incident, not a mail-delivery problem. Delisting the IP without securing the accounts just resets the clock until the next ban.
If you’re on shared sending infrastructure and 5.7.511 keeps recurring, the fix isn’t another appeal — it’s leaving shared IPs behind for a dedicated IP or a dedicated sending service whose reputation you control.
Related sender-side blocks worth checking when mail to Microsoft keeps failing: 550 5.7.606 banned sending IP (the self-service-delistable cousin), 550 5.7.25 (reverse DNS), and 550 5.7.26 (unauthenticated).

Check your own domain now

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