# What does SMTP 550 permanent failure mean? > SMTP 550 is a permanent negative reply, not one diagnosis. Use the command stage, enhanced status code, and full response to identify the repair. SMTP `550` means the receiving server did not accept the requested action and classified the failure as permanent for the request as sent. That reply alone is not a diagnosis. The same basic reply can identify an invalid recipient, denied relay, unavailable mailbox, or receiver policy block. Preserve the command stage, full reply text, remote hostname, and enhanced status code, such as `5.1.1` or `5.7.1`, before deciding whether to correct an address, suppress it, or repair sender configuration. ## Quick takeaways - `550` is a permanent negative completion reply for the request as made. - The enhanced status code and text provide the useful diagnosis. - The SMTP command that triggered the reply narrows the cause. - Do not retry an unchanged permanent recipient failure indefinitely. - A policy response needs evidence before you change authentication, routing, or content. ## What does the failure mean? Under [RFC 5321's reply semantics](https://www.rfc-editor.org/rfc/rfc5321.html), the first digit places `550` in SMTP's permanent negative completion class. The requested action did not happen, and the client should not repeat the exact request in the same sequence. A person can correct the underlying condition and start a new attempt later. A bare `550` does not tell you enough. [RFC 3463's enhanced status codes](https://www.rfc-editor.org/rfc/rfc3463.html) add a class, subject, and detail. For example, the second field distinguishes addressing, mailbox, mail-system, routing, protocol, content, and security-policy subjects. The response text can add receiver-specific context. The code set can expand through [RFC 5248's IANA registry model](https://www.rfc-editor.org/rfc/rfc5248.html), so preserve the complete received code rather than assuming the original list is exhaustive. The transaction stage narrows it further. A `550` after `RCPT TO` often concerns the recipient, relay permission, or recipient policy. A `550` after `MAIL FROM` can concern the sender identity or relay policy. A final rejection after message data can concern message or security policy. Authentication is only one possible layer. [SPF](/learning/what-is-spf), [DKIM](/learning/what-is-dkim), and [DMARC](/learning/what-is-dmarc) deserve attention when the enhanced code or response text points to sender authentication or policy. ## What usually causes it? ### The recipient address is invalid An addressing status such as `5.1.1` can mean the destination mailbox does not exist. Confirm the address before suppressing it because aliases and migrations can also change valid destinations. ### Relay or delivery is not authorized The server may not accept mail for the domain, or the sender may have reached a submission or relay service that requires authorization. ### Receiver security policy rejected the request A `5.7.x` response can identify a security or policy decision. The exact text and any official remediation link determine whether the issue involves authentication, permission, reputation, or message policy. ### The route, mailbox, or destination system is unavailable A permanent mailbox, system, or routing condition can appear with the same basic `550` reply. The enhanced subject separates these from an invalid address. ## How do I diagnose the failure? ### 1. Capture the full transaction evidence Record the timestamp, remote hostname, recipient, SMTP command, complete `550` line, enhanced status code, queue ID, and sending route. Keep the original non-delivery report. ### 2. Read all three enhanced-status fields The first field is the success or failure class. The second is the subject. The third is the specific detail. Do not treat every `5.1.x` or `5.7.x` response as interchangeable. ### 3. Confirm the recipient and destination route Check the address against an authoritative source, query current MX records, and confirm the connection reached the organization that should receive the message. ### 4. Follow the evidence for policy failures When the response identifies authentication or policy, inspect the production message's SPF, DKIM, DMARC, reverse-DNS, and sending-source evidence. Use only the responding provider's official remediation page. ## How do I fix it? Correct or suppress an invalid recipient rather than retrying it unchanged. Repair the MX route, connector, relay authorization, or mailbox state when the enhanced code points to infrastructure. For an authentication or policy block, fix the condition named in the response and test the same sending path again. Do not rotate IP addresses, forge headers, or weaken a domain's authentication policy to evade a rejection. ## How do I validate the repair? Retry only after the underlying state changes. The new transaction should receive a `250` response at the stage that previously returned `550`. Confirm the message reaches the intended test mailbox and that no new non-delivery report appears. For authentication-related failures, inspect the delivered headers and subsequent DMARC reporting. SMTP acceptance confirms that the receiver accepted responsibility for the message. It does not guarantee inbox placement. Use Palisade's [Email Security Score](/tools/email-security-score) for a public configuration review, but keep DNS answers, SMTP responses, delivered headers, and provider state as the production evidence. ## Make SPF, DKIM, and DMARC easier to manage Palisade's [DMARC Agent](https://docs.palisade.email/page-breakdowns/domain-overview/) turns report data into a prioritized list of sender, SPF, DKIM, and DMARC issues. Your team can see what to fix next and follow a guided path toward stronger authentication and DMARC enforcement. Stronger authentication helps protect your domains and supports better email deliverability. [start a Palisade account](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=smtp_550_permanent_failure&utm_content=smtp_550_permanent_failure). ## Frequently asked questions ### Is every SMTP 550 failure a bad email address? No. An invalid address is one cause, but relay, mailbox, routing, authentication, content, and receiver-policy failures can also use `550`. ### Should a sender retry SMTP 550? Not with the same request indefinitely. Correct the condition identified by the enhanced status code or suppress the invalid recipient before trying again. ### What is the difference between SMTP 450 and 550? `450` is a transient negative reply, so the client can retry. `550` is permanent for the request as made and needs a change before another attempt. ### Can I trust the text after 550? Yes, but treat it as evidence from the responding server. First confirm that the connection reached the intended MX host, then use official remediation links rather than links copied from an unrelated bounce. ### Does SMTP 550 prove the message was spam? No. Only a policy-specific response can point in that direction, and the exact rule still needs investigation.