550 5.7.511" access denied banned sender error on outbound mail to microsoft 365

TL;DR

Treat 550 5.7.511 as a sender level block, not a mail flow glitch: open the restricted entities list, see which verdict put the sender there, and remove the block only after the messages behind it are explained. If the mail was legitimate bulk or automated mail, move it to a proper sending service and lower the spam likeness before unblocking, or the sender will be restricted again the same day.

"550 5.7.511" access denied banned sender error on outbound mail to microsoft 365

Use this when

• A specific user, shared mailbox, or service account cannot send externally and gets 550 5.7.511.
• Internal mail from the same sender still works.
• The sender appears in the restricted entities or restricted users list.

Not for this skill when

• Every sender in the tenant is blocked. That points to an IP ban or a service issue instead.
• The sender really did send phishing content after a compromise and incident response is still open. Keep the block until IR clears it.

Steps

1. Read the bounce in full and note the sender, the recipient domain, and whether internal delivery still works. 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: the block is confirmed as sender scoped rather than tenant scoped
2. Open the restricted entities page in the Defender portal and read the reason and the sample messages listed for that sender. 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: the triggering messages are identified by subject and time
3. Decide whether the samples are compromise, legitimate bulk, or false positive, and fix that cause: secure the account, or move the volume to a dedicated 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 cause is documented and the corrective action is complete
4. Remove the sender from the restricted list and send one controlled external test. 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 test delivers and the sender does not reappear on the restricted list within the hour
5. Set an alert for restricted sender events so the next block is seen in minutes, not by user complaints. 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: a test alert or the alert policy listing shows the rule is enabled

Why it happens

Outbound spam filtering restricts an individual sender when its mail scores like spam or phish, or when recipients report it. Automated notifications, invoices sent in bulk from a user mailbox, and compromised accounts are the usual triggers. The block is protective and automatic, so simply removing it without changing the sending pattern guarantees a repeat, often with a longer restriction the second time.

Variants and edge cases

550 5.7.511 access denied banned sender remove restricted user

The portal-action phrasing admins use when they know where the list lives.

microsoft 365 user blocked sending external mail restricted entities

The symptom phrasing used before the error code is found.

service account mail restricted outbound spam false positive 365

The false positive variant for notification and invoice senders.

Compatibility: Microsoft Defender for Office 365 restricted entities, Exchange Online outbound spam policies.

Edge cases to check:

• Shared mailboxes used by applications are frequent repeat offenders; give applications a dedicated sending service instead.
• Unblocking can take a short propagation window; judge success on a fresh send after that window, not instantly.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstEpctK3npe66BA9V0B-D5Q