# 550 permanent failure for one or more recipients: how to fix it > A 550 reply means the current SMTP request failed permanently, but the enhanced code and rejection stage identify whether the problem is the address, sender, policy, reputation, relay, or message. - **Category:** Deliverability - **Published:** August 4, 2026 - **Reading time:** 17 min read - **Author:** Maya Chen, Email infrastructure - **Canonical page:** [https://emailbump.com/blog/550-permanent-failure-email](https://emailbump.com/blog/550-permanent-failure-email) “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. > **550 is a class, not one diagnosis** > > A 550 5.1.1 usually points toward an absent recipient. A 550 5.7.1 usually describes security or policy. Both begin with 550, but suppressing the recipient is sensible for the first and can hide a sender-wide incident for the second. ## 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. ### Read every part of the rejection ```text 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 ### Rejection stage and likely scope ```text 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 ### 550 5.1.1 **Bad destination mailbox address** Verify the address and source. Suppress only when the receiver evidence supports a nonexistent mailbox. ### 550 5.1.0 **Other address status** Read the receiver text; this broad code can describe sender or recipient addressing. ### 550 5.2.1 **Mailbox disabled or not accepting mail** Do not assume a typo. The account may exist but be unavailable under policy. ### 550 5.4.x **Routing or network condition** Inspect DNS, route, loops, or a receiver-specific limit named in the diagnostic. ### 550 5.7.1 **Delivery not authorized or security/policy rejection** Investigate recipient restrictions, relay rights, authentication, reputation, content, and receiver policy. ### 550 5.7.26–5.7.40 **Provider-specific authentication and policy detail** Follow the exact Gmail or receiver diagnostic for SPF, DKIM, DMARC, alignment, TLS, or unsolicited-mail failures. ## 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. ### Policy-failure decision tree ```text 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 ``` ## Trace a 550 response to the exact send Connect provider message IDs, attempts, recipient domains, bounce diagnostics, campaigns, and transactional streams before deciding what to suppress or repair. - Message-level delivery activity - Bounce and complaint evidence - Transactional and campaign context [Learn more](https://emailbump.com/signup) ## 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. ### Safe application handling ```text 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 > **Do not post the complete bounce publicly** > > NDRs and provider logs can contain recipient addresses, internal hosts, message identifiers, original headers, or content. Share the full evidence only through an authorized support channel and redact public examples without removing the diagnostic code. ## 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. ## Continue the diagnosis - [Bounce code decoder](https://emailbump.com/tools/bounce-code-decoder) — Classify SMTP and enhanced status codes without discarding the raw diagnostic. - [Email bounce handling](https://emailbump.com/blog/email-bounce-handling-guide) — Build retry, suppression, event, and recovery policies around failure scope. - [ISP email blocking](https://emailbump.com/blog/isp-blocking-email) — Separate receiver blocking from spam placement, blocklists, invalid recipients, and port restrictions. - [Email authentication methods](https://emailbump.com/blog/email-authentication-methods) — Verify SPF, DKIM, DMARC, alignment, and the identities receivers evaluate. ## Sources - [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321) - [RFC 3463: Enhanced Mail System Status Codes](https://www.rfc-editor.org/rfc/rfc3463) - [RFC 5248: SMTP Enhanced Status Code Registry](https://www.rfc-editor.org/rfc/rfc5248) - [Google: Gmail SMTP errors and codes](https://knowledge.workspace.google.com/admin/support/troubleshooting/gmail-smtp-errors-and-codes) - [Microsoft: Fix NDR error 550 5.7.1 in Exchange Online](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/fix-error-code-550-5-7-1-in-exchange-online) - [Microsoft: Exchange Online NDRs and SMTP errors](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online)