What the receiver is telling you

Microsoft's filter has decided the IP range you are sending from is a spam source. On Microsoft 365 or Workspace as a sender this is rare because the ranges are the providers' own; it appears mainly for senders on VPS, shared hosting or small relay providers whose neighbours got the range listed. If you are on a provider's shared IPs and see it, the range is temporarily poisoned by someone else and Microsoft usually clears it within a day.

Why a policy block must not be treated as a bad address

Sending tools file every 5xx under "bounced", and the natural reflex is to scrub the address. For a policy block that is exactly wrong. The recipient exists and would have received the mail; the receiver refused it because of your domain, IP, authentication or content. Scrubbing throws away a lead and leaves the cause in place, so the next send produces the same block against the next thousand addresses. The right response is to stop sending from the affected domain, find what the receiver named, fix it, and resume at low volume.

What to do

1. Identify the sending IP from the bounce and check it on the blacklist checker.
2. If it is your own server or VPS, request delisting at sender.office.com with the IP and a description of your sending.
3. If it is a relay provider's IP, tell them; they need to delist their range.
4. Meanwhile route mail to Microsoft-hosted domains through a different path if you have one.

don't Do not keep hammering Microsoft-hosted recipients from the blocked range. Each attempt extends the block.

Decode the whole bounce

Paste the complete failure notice — every code and the receiver's wording — and get each part explained together.

Common questions