An SMTP 550 error means the recipient mail server rejected your message at the final stage: the address does not exist, the sender failed authentication, or the message was flagged as spam. Code 554 is a rejection of the whole transaction. Both codes start with 5, meaning the failure is permanent, and resending without fixing the cause will not help.
This guide explains what SMTP codes 550 and 554 mean, how to read enhanced status codes in the 5.x.x format defined by RFC 3463, lists the common rejection causes (nonexistent recipient, spam filter, SPF/DKIM/DMARC failure, blacklisted IP, relay denied) and clarifies what the sender should do versus what the domain owner should fix.
What SMTP 550 and 554 Mean
SMTP uses three-digit reply codes (RFC 5321). The first digit sets the class: 2xx is success, 4xx is a temporary error (retry later is allowed), and 5xx is a permanent failure. Code 550 is returned when the server cannot deliver a specific message: the mailbox is unavailable and the requested action was not taken. Code 554 is the most generic failure: the transaction failed, often phrased as "Transaction failed" or "Message rejected".
The key difference: 550 usually relates to the recipient or the message content, while 554 often appears at connection setup (the SMTP banner) — for example, when the sending IP is fully blocked. Both codes are final for the current attempt, so you must fix the cause rather than retry.
How to Read the Error Text
After the numeric code the server adds an enhanced code and a human-readable explanation. The reply format is: 550 5.7.1 Message rejected due to policy. Here 550 is the base code, 5.7.1 is the enhanced code (class.subject.detail), and the text explains the cause. The text and the enhanced code tell you exactly what went wrong, so copy the full line from the bounce notice, not just the number 550.
Enhanced Codes 5.x.x per RFC 3463
Enhanced Mail System Status Codes (RFC 3463) refine the reason for rejection. The structure is class (5 = permanent error), subject and detail. Below are the most common enhanced codes seen with 550 and 554.
- 5.1.1 — recipient does not exist (bad destination mailbox address). The mailbox was removed or the address is mistyped.
- 5.1.10 — address cannot be resolved / NULL MX. The domain has no mail server.
- 5.7.1 — delivery not authorized by policy (relay denied, rejected as spam, or blocked by a rule).
- 5.7.26 — multiple authentication checks failed: the message passed neither SPF nor DKIM, so it was rejected by DMARC.
- 5.7.23 — SPF validation failed.
- 5.7.7 — the message looks like sender spoofing (DKIM/DMARC).
Causes of Rejection
A 550/554 failure boils down to a few scenarios. Let's look at each and who should fix it — the person sending the message or the owner of the sending domain.
The Recipient Does Not Exist
The simplest cause: the address is mistyped, an employee left and the mailbox was deleted, or the domain does not accept mail at all. The server replies 550 5.1.1 "No such user" or "User unknown". The danger is that sending to nonexistent addresses hurts sender reputation: providers see a high bounce rate and start routing your mail to spam more often. Clean inactive addresses out of your list regularly.
The Message Was Rejected as Spam
The receiver ran the message through a filter and decided it was spam: a suspicious subject, too many links, an attached archive, missing authentication, or poor IP reputation. The reply is 550 5.7.1 phrased as "rejected as spam" or with a link to a policy page. Unlike a nonexistent-address failure, the message here is technically deliverable, but the content and sender setup do not inspire trust.
SPF, DKIM or DMARC Failure
SPF (RFC 7208) publishes in DNS the list of servers allowed to send mail for the domain. DKIM adds a cryptographic signature to the message. DMARC ties them together and tells the receiver what to do if the checks fail. If the sending server is not listed in SPF and the DKIM signature is missing or does not align, the receiver returns 5.7.23, 5.7.7 or 5.7.26 and rejects the message under a DMARC p=reject policy.
Blacklisted IP or Relay Denied
If the sending IP landed on a DNSBL (spam list), the receiver may drop the session immediately with a 554 banner reading "blocked" and a link to the list. A separate case is "relaying denied": you try to send through someone else's SMTP without authenticating, and the server rightly refuses to relay mail for an unauthenticated client.
Common Error Texts and Fixes
| Error text | Enhanced code | Cause | Fix |
|---|---|---|---|
| 550 No such user here | 5.1.1 | Recipient does not exist | Check the address spelling, confirm the current email with the recipient |
| 550 Message rejected as spam | 5.7.1 | Spam filter rejected the message | Remove spam triggers, set up SPF/DKIM/DMARC, warm up the IP |
| 550 SPF check failed | 5.7.23 | Sending IP is not in the SPF record | Add the server to the domain's SPF TXT record |
| 550 DMARC policy violation | 5.7.26 | SPF and DKIM both failed | Fix SPF and DKIM alignment with the From domain |
| 554 5.7.1 Service unavailable; blocked | 5.7.1 | IP is on a blacklist (RBL) | Check the IP against DNSBLs and request delisting |
| 550 Relaying denied | 5.7.1 | Server will not relay third-party mail | Authenticate on SMTP (SMTP AUTH) or use your own relay |
| 554 Transaction failed | 5.6.0 | Content/attachment problem | Check the message format, size, and MIME headers |
Example SMTP Dialog With a Rejection
This is what a session looks like when the recipient server rejects the message at the RCPT/DATA stage. The 550 reply arrives right after the policy check:
220 mx.example.com ESMTP Postfix
HELO mail.sender.com
250 mx.example.com
MAIL FROM:<info@sender.com>
250 2.1.0 Ok
RCPT TO:<user@example.com>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
...
.
550 5.7.1 Message rejected due to SPF/DKIM/DMARC policy
QUIT
221 2.0.0 ByeTo check whether the recipient's mail server responds and which enhanced code it returns, connect manually with openssl:
openssl s_client -starttls smtp -connect mx.example.com:25 -crlf
# after connecting, type the commands manually:
EHLO mail.sender.com
MAIL FROM:<info@sender.com>
RCPT TO:<user@example.com>How to Fix
The steps depend on your role in the chain. The person sending a single email and the administrator of the sending domain fix different things.
What the Sender Should Do
- Read the enhanced code and the bounce text — they name the cause precisely.
- On 5.1.1, recheck the recipient address letter by letter and confirm the current email.
- On 5.7.1 "spam", do not resend the same message — change the subject and body, remove shortened links and archive attachments.
- If the error is "relaying denied", enable SMTP authentication in your mail client.
What the Domain Owner Should Do
- Configure and verify SPF: a TXT record listing every server that sends your mail.
- Enable DKIM: the server signs messages and the receiver verifies the signature against the public key in DNS.
- Publish DMARC and monitor its reports to see where alignment breaks.
- Check the IP and domain against blacklists (RBL/DNSBL) and request delisting if needed.
- Protect sender reputation: don't send to dead addresses or complaining recipients.
How to Check Your Setup
The fastest way to diagnose the cause is to check domain authentication. The SPF/DKIM/DMARC checker shows which records are published and whether they pass alignment. To confirm the domain resolves and has a valid MX, use the DNS lookup for A/MX/TXT records.
Official Sources
- RFC 5321 — Simple Mail Transfer Protocol
- RFC 3463 — Enhanced Mail System Status Codes
- RFC 7208 — Sender Policy Framework (SPF)
Related Reading
- The complete guide to SPF, DKIM and DMARC
- How to remove your IP and domain from an email blacklist
- Why emails bounce and how to fix it
Frequently Asked Questions
What is the difference between SMTP 550 and 554?
Code 550 is returned when a specific message cannot be delivered: the mailbox is unavailable, or the message was rejected by policy or as spam. Code 554 is a broader failure of the entire transaction that often appears at the SMTP banner stage when the sending IP is fully blocked. Both codes are permanent and require fixing the cause.
What does enhanced code 5.7.1 mean?
Enhanced code 5.7.1 per RFC 3463 means delivery is not authorized by the recipient server's policy. It is the most common rejection code: relay denied, rejected by a spam filter, or blocked by SPF/DKIM/DMARC. Look at the text explanation the server appends after the code for the exact reason.
What should I do about error 5.7.26?
Code 5.7.26 means the message passed neither SPF nor DKIM, so it was rejected by the DMARC policy. The domain owner must configure a correct SPF listing all sending servers and enable DKIM signing so that the record domains match the From domain (alignment).
Will resending the email help?
No. 5xx codes are permanent, so resending the same message produces the same error. First fix the cause: correct the recipient address on 5.1.1, set up authentication on 5.7.x, or request IP delisting from a blacklist. Only then does resending make sense.
How do I know my IP is blacklisted?
The sign is mass 554 rejections phrased as "blocked" or "listed" with a DNSBL reference. Check the IP and domain against major blacklists, and check authentication with an SPF/DKIM/DMARC tool. If the IP really is listed, remove the spam source and submit a delisting request to the list operator.