550 permanent failure for one or more recipients: how to fix it

“550 permanent failure for one or more recipients” means an SMTP server rejected the current request with a permanent-failure reply. Do not resend the same message repeatedly. Preserve the complete diagnostic, enhanced status code, rejected recipient, receiving domain, and SMTP stage; those details determine whether to fix an address, sender authorization, authentication, reputation, content, relay, or recipient policy.

What SMTP 550 means

SMTP uses three-digit replies. A 5xx reply says the requested action was not completed and the sender should not repeat it unchanged. RFC 5321 describes 550 as requested action not taken, historically illustrated by an unavailable mailbox. Modern receivers use 550 with enhanced codes and diagnostic text for many permanent address, authorization, security, content, and policy failures.

550 5.7.1 Message rejected due to sender policy [receiver reference]
│   │     └─ receiver-specific diagnostic: preserve it verbatim
│   └─────── enhanced status: class.subject.detail
└─────────── SMTP reply: permanent failure for this request

2.x.x success
4.x.x persistent transient failure: retry with bounded backoff
5.x.x permanent failure: do not retry unchanged

Enhanced status codes add structure. The first digit is the result class. The second identifies a broad subject: X.1 address, X.2 mailbox, X.3 mail system, X.4 routing, X.5 protocol, X.6 content/media, and X.7 security/policy. The third digit narrows the condition. Receiver prose remains important because providers extend and contextualize these codes differently.

Why the SMTP stage matters

CONNECT / EHLO   IP, TLS, hostname, rate, network policy
MAIL FROM        envelope sender, relay authorization, SPF-domain policy
RCPT TO          individual address, mailbox, group, recipient restrictions
DATA / end-data  content, authentication, message format, size, reputation
LATER DSN        remote system accepted first, then reported final failure

One RCPT TO can fail while other recipients are accepted.
A DATA-stage rejection can affect every recipient in that transaction.

If a message has several recipients, SMTP can accept some RCPT TO commands and reject others. A client or provider should report recipient-level results instead of describing the entire submission as one boolean. Never resend to accepted recipients merely because another address failed; that can create duplicates.

Common 550 enhanced codes and first actions

Fix recipient and address failures

When the rejection names one recipient and carries an address-oriented code, confirm the address from the authoritative source. Check spelling, domain, alias changes, account closure, group membership, and whether a form or import introduced it. Do not ‘repair’ addresses automatically by changing domains or guessing mailbox names.

• For customer-entered addresses, let the customer correct the value through an authenticated product flow.
• For an internal directory or CRM, update the source record rather than only the email provider's suppression list.
• Suppress an address after a supported permanent recipient failure so other automations cannot keep retrying it.
• Track unknown-user failures by signup form, import, partner, tenant, and list age to find the acquisition defect.
• Do not suppress a valid recipient when the diagnostic identifies sender authentication, reputation, content, or infrastructure.

Fix 550 5.7.1 policy and authorization failures

5.7.1 is deliberately broad. Microsoft documents it for delivery restrictions, groups that require authorized senders, transport rules, blocked source IPs, domain enrollment, MX issues, and relay problems. Gmail uses 550 5.7.1 diagnostics for policy restrictions, invalid relay credentials, messages considered unsolicited, and some IPv6 sender-guideline failures. The words following the code are essential.

ONLY ONE RECIPIENT OR GROUP?
  -> check membership, external-sender restrictions, allow/block rules

RELAY OR SUBMISSION SERVER?
  -> check SMTP AUTH, connector/IP authorization, MAIL FROM, HELO, TLS

ONE RECEIVER, MANY RECIPIENTS?
  -> inspect that receiver's exact code, volume, reputation, policy portal

ALL RECEIVERS OR A WHOLE STREAM?
  -> verify credentials, SPF, DKIM, DMARC alignment, PTR, TLS, message syntax

ONE TEMPLATE OR URL SET?
  -> inspect content, attachment, redirects, compromised destinations

Verify authentication and infrastructure

• Inspect a real received message from the same production route for SPF, DKIM, and DMARC alignment.
• Confirm the visible From domain, DKIM d= domain, selector, Return-Path, sending IP, PTR, and EHLO identity.
• Ensure the connecting IP has matching forward and reverse DNS where the receiver requires it.
• Check that TLS is negotiated and the message meets current sender and format requirements.
• Confirm every service using the From domain is authorized; one forgotten integration can lower pass rates or trigger policy.
• Separate transactional and promotional traffic enough to identify and contain the source of harmful sending.

Investigate reputation and unwanted-mail evidence

A message can authenticate correctly and still be rejected as likely unsolicited. Segment the incident by receiving provider, source IP, aligned domain, stream, tenant, campaign, list source, and time. Compare the first failing attempt with volume changes, complaints, hard bounces, stale recipients, new forms, imported lists, compromised credentials, and changed links.

Stop the causal source before requesting delisting or resuming volume. Sending the same traffic through a new IP, From domain, or provider can spread the problem and removes the history needed to verify recovery. Resume with recent, clearly expected traffic only after authentication, suppression, security, and queue state are correct.

Do not retry a permanent failure unchanged

A 550 reply is permanent for the current request under current conditions. It does not mean the human or domain can never receive mail again. A corrected address, changed group permission, repaired authentication configuration, secured account, or remediated reputation condition can justify a deliberate new message. Blind automatic retry is different: it repeats the rejected request without new evidence.

if reply.class == 4:
  retry_with_bounded_backoff_until(message.expires_at)

if reply.class == 5:
  stop_automatic_retry()
  classify_scope(recipient | sender | content | infrastructure)

if enhanced_status == "5.1.1" and evidence.confirms_missing_mailbox:
  suppress_recipient(reason="mailbox_not_found")

if enhanced_status.starts_with("5.7."):
  open_sender_or_policy_incident()  # do not blame recipient by default

What to send your administrator or email provider

• UTC timestamp and timezone of the attempt
• Provider and application message IDs
• Rejected recipient domain and safely redacted address
• Full SMTP reply, enhanced code, and unmodified diagnostic text
• SMTP stage and attempt number
• Outbound IP or pool, From domain, Return-Path, and DKIM signing domain
• Whether other recipients and receivers succeeded during the same window
• Recent volume, template, link, audience, credential, DNS, or infrastructure changes

Frequently asked questions

Is every 550 error a hard bounce?

Providers often label 550 responses as hard bounces because they are permanent failures, but the root cause can be recipient-, sender-, content-, or infrastructure-scoped. Use the label for reporting only after preserving the underlying code and text.

Will a 550 error fix itself?

Do not assume it will. A temporary server condition should normally use 4xx. A 550 requires a changed condition or corrected request before another send is justified, even if a receiver later changes its policy independently.

Why did one recipient fail while others succeeded?

SMTP evaluates recipients individually during RCPT TO. One mailbox can be absent, restricted, suppressed, or governed by a different server. Preserve per-recipient outcomes and do not resend to recipients already accepted.