550 5.7.606 banned sending IP: getting your Exchange server delisted

Fix it now

Microsoft publishes the 5.7.606 to 5.7.649 range as access denied, banned sending IP, with the source address in the message. There is nothing to tune. Find what sent the spam, stop it, and then use the delist portal – a request submitted while the source is still sending achieves nothing.

Get-Queue | Format-List Identity,NextHopDomain,MessageCount,Status
Get-Message -Queue '<server>\<queue>' -ResultSize 50 | Format-Table FromAddress,Subject,Status
Get-ReceiveConnector | Format-List Identity,Bindings,RemoteIPRanges,PermissionGroups

1. Note the exact IP address in the rejection. That is the address to investigate and eventually to delist.
2. Look for the source. A single mailbox sending far more than usual is a compromised account; a queue full of mail between two external domains is an open relay on a receive connector.
3. Stop it: reset the password and revoke sessions, or remove the accept-any-recipient right from the connector that should not have it. Then clear the offending mail out of the queues.
4. For 5.7.606, go to the delist portal at https://sender.office.com, enter the address that received the non-delivery report and the IP address from the message, confirm by email and select Delist IP.
5. For 5.7.511 the portal does not apply. Email delist@microsoft.com with the full NDR code and the IP address; Microsoft states it will contact you within 48 hours.

Microsoft says results from the delist portal vary and it might take 24 hours or longer before restrictions are removed. Plan an alternative route for urgent mail rather than resubmitting the request.

If the source is gone and the address is delisted, you are done. If a single account rather than the server is being refused, the next section covers restricted senders and 5.1.8.

Why it happens

Almost every case has one of two causes. Either a mailbox password was stolen and the account is being used to send spam through your legitimate infrastructure, or a receive connector accepts mail from anywhere for any recipient, which makes your server a relay for whoever finds it. The first shows as one account sending far more than usual. The second shows as a queue full of messages between two external domains that have nothing to do with you.

The codes in this family point at different things, and getting them the wrong way round wastes days. Microsoft publishes 5.7.606 to 5.7.649 as Access denied, banned sending IP with the source address in the message, and directs you to the self-service delist portal. It publishes 5.7.511 as Access denied, banned sender – and despite the wording, the address in brackets is an IP address and the block is on the IP you are sending from. Crucially, Microsoft states the delist portal cannot be used for 5.7.511: that one goes to delist@microsoft.com, and Microsoft responds within 48 hours.

Two more in the group are about an account rather than an address. 5.7.501 is Access denied, spam abuse detected – the sending account was banned because of detected spam activity, and the documented steps are to resolve the account’s issues, reset its credentials, and contact Microsoft Support to restore its ability to send. 5.1.8 is Access denied, bad outbound sender, and Microsoft’s published wording to the user is that they were not recognised as a valid sender because the address is suspected of sending spam. That one is cleared from the Restricted entities page in the Defender portal, without a support case.

The last, 5.7.25, is narrower than it is usually quoted. The published text is that the sending IPv6 address must have a reverse DNS record to send email over IPv6. It is not a general statement about reverse DNS on IPv4, and it will not be why your IPv4 gateway was banned – though a missing reverse record does make a sender look like exactly the kind of sender that gets banned.

Full reference

Which route delists which code

Using the delist portal

1. Go to https://sender.office.com.
2. Enter the email address that received the non-delivery report, and the IP address quoted in the error message.
3. Select Submit. A confirmation email arrives at the address you entered.
4. Select the confirmation link, which returns you to the portal.
5. Select Delist IP. Microsoft states that results vary and it might take 24 hours or longer before restrictions are removed.

Locating the source before you submit anything

What Microsoft says gets an account restricted

• Exceeding the outbound sending limits of the service.
• Exceeding the limits configured in the tenant’s outbound spam policies.
• Both of which, in Microsoft’s wording, typically result from account compromise.
• The user’s own experience of this is a bounce reading 550 5.1.8 Access denied, bad outbound sender, telling them to contact their email admin.

Do not clear transport queues by deleting the queue database, and do not remove messages without checking what they are. Legitimate mail is queued alongside the spam during an incident, and deleting indiscriminately loses customer correspondence you cannot get back.

The order of work, and why it is not negotiable

Every one of these blocks exists because traffic from your address looked like spam. Requesting removal while the source is still running produces one of two outcomes: the request is refused, or it succeeds and the block returns within days, at which point you are a repeat offender. Fix first, then request. That is also why the audit matters more than the request itself – the request takes five minutes and the audit is where the actual work is.

Preventing the next one

1. Multifactor authentication on every account that can sign in.
2. No anonymous relay from the internet; every relay connector scoped to named addresses.
3. Outbound port 25 blocked at the firewall for everything except the mail server, so a compromised workstation cannot send directly.
4. Alerting on outbound volume per sender, so you find the next incident before a receiving service does.
5. A reverse DNS record for every address you send from, IPv4 and IPv6.

Every code this article covers

Confirm the fix worked

1. Outbound queues contain only mail your organisation actually generated.
2. No receive connector grants anonymous senders the right to submit to arbitrary recipients from a wide address range.
3. No account remains on the Restricted entities page in the Defender portal.
4. A test message reaches a recipient on the service that was refusing you.
5. Sign-in and audit logs show no further activity from the source that caused the incident.

Questions people ask about this