What the receiver is telling you
The address is a Microsoft 365 group or distribution list, and it is configured to accept mail only from people inside the organisation. Your message was rejected because you are external, which is the default for new Microsoft 365 groups. The address is real and works fine for internal mail; it will never accept yours. In lead lists these show up as team@, sales@ and project@ addresses that were scraped from a website.
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
- Remove the address. It is a group that does not take external mail.
- Find an individual at the company instead — groups are rarely useful for outreach anyway.
- If you have a real relationship with the company, ask them to allow external senders on the group; only their admin can.
don't Do not retry. The restriction is a setting, not a state.
Decode the whole bounce
Paste the complete failure notice — every code and the receiver's wording — and get each part explained together.
Common questions
Is 5.7.133 my fault?
No. It is a setting on the recipient's group. Nothing about your sending would change the result.
Why do role addresses often return this?
Because team@ and department@ addresses at Microsoft 365 companies are usually groups, and groups default to internal-only.
Often seen alongside
Related reading
If this is the thing going wrong
The pages explain it. If you would rather it was simply fixed, that is the work I do.