550 permanent failure for one or more recipients: what it means

"550 permanent failure for one or more recipients" is a summary line that Microsoft Exchange and Outlook.com non-delivery reports use to introduce a hard bounce. It is not itself an enhanced status code — it is wrapper text, and the real cause sits in the enhanced code and remote-server text printed underneath it. Treat this line as a signal to go read the rest of the bounce, not as a diagnosis on its own.

Why this message looks different from a normal bounce

Most receiving servers reply with a three-digit code and an enhanced status code on the same line, for example 550 5.1.1 User unknown. Exchange's non-delivery report format instead prints a generic header — "Your message wasn't delivered because the recipient's email provider rejected it" or "550 permanent failure for one or more recipients (domain.com)" — and puts the actual SMTP exchange, including the real code, in a "Diagnostic information for administrators" block further down. If you only read the subject line of the bounce, you will miss the part that tells you what actually went wrong.

Find the real code first

Open the full bounce message (in Outlook: double-click the NDR, then look for "Diagnostic information for administrators;" in Gmail and other clients forwarding an Exchange bounce, check the message source). You are looking for a line that looks like one of these:

Remote Server returned '550 5.1.1 RESOLVER.ADR.RecipNotFound; not found'
Remote Server returned '550 5.7.1 Message rejected by content filtering'
Remote Server returned '550 5.4.1 Recipient address rejected: Access denied'
Remote Server returned '550 5.2.1 Mailbox unavailable'

Each of those enhanced codes is a different fault, and the wrapper text "550 permanent failure for one or more recipients" is identical across all of them. Do not try to fix all four causes — identify which one you actually received.

Who is at fault, by sub-code

• 5.1.1 (address does not exist) — sender fault: the address or domain is wrong, or the mailbox was deleted. Suppress it.
• 5.7.1 (content/policy rejection) — sender fault: the message tripped a transport rule, malware/spam filter, or DLP policy on the recipient's tenant.
• 5.4.1 (access denied / relay) — could be either: often the recipient's organisation restricts external senders to that mailbox, or your IP/domain has no reputation with them yet.
• 5.2.1/5.2.2 (mailbox unavailable/full) — recipient fault: their mailbox is disabled, over quota, or on hold.

How the three big providers present the same underlying faults

Diagnostic commands

# Confirm the domain accepts mail and see its MX
dig MX recipient-domain.com +short

# Hand-test the exact RCPT TO that bounced
swaks --to user@recipient-domain.com --from you@yourdomain.com \
  --server mx.recipient-domain.com --quit-after RCPT

Sample swaks output that confirms a 5.1.1 cause:

<-  220 mx.recipient-domain.com Microsoft ESMTP MAIL Service ready
 -> EHLO yourdomain.com
<-  250-mx.recipient-domain.com Hello
 -> MAIL FROM:<you@yourdomain.com>
<-  250 2.1.0 Sender OK
 -> RCPT TO:<user@recipient-domain.com>
<-  550 5.1.1 RESOLVER.ADR.RecipNotFound; not found

Ordered fix

1. Open the full NDR and extract the real enhanced status code — never act on the wrapper line alone.
2. If it's 5.1.1, verify the address with the contact through another channel and remove it from future sends; do not retry.
3. If it's 5.7.1, check your content for flagged terms, oversized attachments, or links to domains with poor reputation, and confirm your own SPF/DKIM/DMARC align.
4. If it's 5.4.1, ask the recipient whether their tenant restricts external mail and request an allow entry, or warm up the sending identity so reputation improves.
5. If it's 5.2.x, wait and retry later for a full mailbox; if the account is disabled, treat it as a hard bounce and suppress it.

What not to do

Do not resend the same message hoping a "permanent failure" clears itself — 5xx is final for that transaction by definition, and retrying wastes send reputation without changing the outcome. Do not lump every "550 permanent failure" NDR into one spreadsheet row labelled "bounced" — a 5.1.1 and a 5.7.1 need opposite responses, and conflating them hides whether your real problem is a dirty list or a content/reputation issue. Do not disable your malware or DLP rules to work around a 5.7.1 you triggered by mistake; fix the content instead.

MailPilot's per-mailbox reputation tracking flags the difference between hard-bounce spikes (list hygiene problem) and policy-rejection spikes (content or authentication problem) so you are not reading raw NDR text to tell them apart.