## TL;DR
Stop sending through the flagged IP, find why Exchange Online banned it, and delist it only after the cause is fixed. Check the outbound spam log for the messages that triggered the ban, confirm whether a compromised account or a bulk send is behind it, remediate that, then submit the delist request and move legitimate mail to a clean connector while you wait. Resending harder through a banned IP only extends the ban.

```text
"550 5.7.606" access denied banned sending ip in exchange online
```

## Use this when
- Outbound mail to external recipients bounces with 550 5.7.606 access denied, banned sending IP.
- Many unrelated recipients fail at once from the same tenant.
- Message trace shows the mail reached Exchange Online Protection and was refused there.

## Not for this skill when
- The bounce comes from the recipient organisation, not from your own tenant. That is their blocklist decision.
- A single mailbox is blocked for a high confidence phish verdict. That is a restricted sender case, not an IP ban.

## Steps
1. Collect two or three bounces and confirm the error, the IP named, and the time window are the same across them. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: all samples name the same banned IP and tenant source
2. Search outbound mail and sign-in logs for the trigger: a compromised account, an auto-forward storm, or a bulk campaign sent from the corporate tenant. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: a concrete triggering send or account is identified, or bulk sending is ruled out with log evidence
3. Remediate the cause first: reset credentials and revoke sessions for a compromised account, or move bulk mail to a dedicated subdomain and service. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: the triggering behaviour has stopped in the logs for a full hour
4. Submit the delist request for the IP in the Microsoft delist portal and note the request reference. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: the portal accepts the request and shows the IP as pending or delisted
5. Send a low volume test to previously failing recipients and watch message trace. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: tests deliver without 5.7.606 and no new ban appears in the next day of trace

## Why it happens
Exchange Online Protection bans a tenant outbound IP when its reputation collapses, usually because spam or phish genuinely left the tenant. The shared nature of the outbound pool means one compromised account can poison delivery for everyone. Microsoft therefore requires the cause to be gone before delisting, and a premature delist request made while bad mail is still flowing is normally refused or reversed within hours.

## Variants and edge cases
### 550 5.7.606 access denied banned sending ip delist
The delist-focused phrasing used once the admin knows it is their own tenant IP.
### exchange online outbound mail blocked banned ip compromised account
The cause-first variant when a hijacked mailbox is suspected.
### office 365 sending ip banned how long does delist take
The timing variant admins search while waiting for the pool to clear.

Compatibility: Microsoft 365 Exchange Online Protection, Defender for Office 365 message trace, Microsoft sender delist portal.

Edge cases to check:
- High volume marketing sent from the corporate domain is a recurring trigger; separating it protects transactional mail.
- A ban can return quickly if forwarding rules created by an attacker are left in place after the password reset.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_cV1-RVF2QZYGdXGpTKLp5A