Email Error Codes: A Complete Guide to 4xx and 5xx in SMTP

You've opened the send queue log and next to a stuck message it says status=deferred with code 451 4.3.0. The real question is: should I resend this message or let it go? The answer lies in the first digit of that code. As long as you misread that digit, every action you take is a gamble.

An email error code is a three-digit number that the receiving server returns in response to an SMTP command. The first digit determines the response class, not the severity of the error. 4xx means "I can't right now, try again later" and 5xx means "I will never accept it." This difference shapes your entire operational decision-making.

The difference between 4xx and 5xx that determines everything

A 4xx error is temporary. The send queue holds the message and retries according to its own schedule; in Postfix, this interval is controlled by default with the queue_run_delay and maximal_queue_lifetime parameters. The default queue lifetime is 5 days. If the problem isn't resolved by then, the message returns with bounced status and the sender receives a bounce message.

A 5xx error is permanent. The destination server has definitively rejected it and retrying is pointless. The message bounces immediately. If you see 5xx in your own log and manually requeue the message, you're just wasting time.

A practical note: a 4xx code doesn't always mean "the problem isn't on our side." If your own server responds with 421, the problem is inside your own infrastructure.

Common 4xx codes and the right action

Code 452 concerns you more than you think. When the destination server says it doesn't have enough space, it means the recipient's mailbox is full or your server's quota has hit its ceiling. If your own messages are stuck, Email quota management; what to do when the mailbox fills up? opens up exactly this scenario.

Take code 421 seriously. If your server, under a bulk sending load, closes incoming connections with 421, legitimate senders get pushed back too. Here the rate limit should be set based on IP and domain, not a fixed number for everyone.

5xx codes and what never comes back

The most frequent code across all support tickets is 550. But 550 isn't a single error; it's a family. The text after the code determines which one it is:

• 550 5.1.1 — The destination mailbox doesn't exist. You wrote the address wrong or the account was deleted.
• 550 5.7.1 — Rejected due to policy. Usually your IP is on a blacklist or SPF/DKIM isn't configured correctly.
• 550 5.7.26 — Sending without valid authentication from a domain you don't own.
• 551 — The user has moved; the new address appears in the response text.
• 552 — The message is larger than the allowed size limit.
• 553 — The sender or recipient address is syntactically invalid.
• 554 — The transaction was rejected; often due to suspicious content or domain reputation.

Don't underestimate the difference between 5.1.1 and 5.7.1. The first means fix the address and you're done. The second means there's a structural problem with your domain or IP, and until it's resolved, whatever address you send from will be rejected.

Why you see 550 5.7.1 more than you'd expect

Because your domain's authentication records are incomplete. If your domain's SPF doesn't cover the IP of the server you're sending from, the recipient has the right to reject it. A correct record looks like this:

v=spf1 ip4:203.0.113.45 include:_spf.servernet.cloud -all

The -all at the end means "reject any other sender." Some people use ~all, which is softer, but for a domain that only sends from one server, -all is the better choice. If you don't know what your domain's records currently are, first do an MX record lookup and check the TXT records so you have a clear starting point.

This is where they go wrong

The most common mistake I see in tickets is this: the user gets a 550, assumes "the destination server has a problem," and requeues the message ten more times. What's the result? The queue fills up, the server itself gets blacklisted because of the high rate of failed attempts, and now even normal emails go to spam. The sign is also obvious: a few days later, even internal messages arrive with delays and postqueue -p shows hundreds of stuck messages.

The second mistake is the opposite: seeing 450 and immediately deleting the message from the queue. 450 is temporary and the queue does its job on its own. Manual deletion only makes the message disappear without a bounce being recorded, and the sender never finds out.

Tools that actually help

To see queue status in Postfix:

postqueue -p
postqueue -j | jq '.queue_name, .recipients[].delay_reason'

The JSON output is filtered with jq and shows the delay reason for each recipient separately. This is much faster than reading raw logs.

To manually test a connection and see the destination server's response:

swaks --to user@example.com --server mx.example.com --from you@yourdomain.com

If swaks isn't installed, you can also use openssl s_client -connect mx.example.com:25 -starttls smtp to manually issue EHLO and see the responses. This test shows whether the error is on your side or the destination's side.

For checking IP reputation and blacklists, there are many online tools, but before anything else make sure your server's IP is in the domain's SPF. If you're sending transactional emails like order confirmations or password resets from shared hosting, this won't work in the long run; Transactional email; why not send from hosting and what's the right alternative? explains why and what alternative is suitable.

A decision you need to make

When you get a 5xx error, you have two paths: fix the address and resend, or review the entire domain from an authentication standpoint. My choice depends on the code. If it's 5.1.1, just fix the address. If it's 5.7.x, until you've set up SPF, DKIM, and DMARC correctly, resending is a waste of time.

Let me also mention the cost of this review: correctly configuring DMARC with a p=reject policy may cause some legitimate emails to be rejected in the first few days while you review the reports. If your email volume is high, start with p=none and after a week, once you've seen the reports, make it stricter.

For day-to-day mailbox management and checking which accounts have filled up, The complete guide to working with webmail and its features for email management is a good starting point. And if you're planning to migrate, Email migration with IMAP; a complete guide without losing data covers the steps.

If you're working on your own infrastructure and want full control over the queue and logs, a Linux host with full access to Postfix and command-line tools makes this easier.

Frequently asked questions

What's the difference between code 450 and 550 in email?

Code 450 is temporary and the destination server is saying try again later; the send queue does this on its own. Code 550 is permanent and the message bounces immediately. If you get 450, wait; if you get 550, you need to fix the cause.

What does error 550 5.7.1 mean and how is it fixed?

It means the destination server rejected your message due to a security policy, not because of a wrong address. The common cause is the sender IP not being in the domain's SPF record, DKIM not being configured, or the IP being on a blacklist. First check the domain records, then submit a blacklist removal request.

Why do emails bounce with code 452?

Code 452 means there isn't enough space or the number of messages has exceeded the allowed limit. If the recipient is a single person, their mailbox is full. If all recipients get this code, it's probably your own server's quota or a high sending rate.

Should I manually delete stuck messages in the queue?

Only if you're sure the error is permanent (5xx) and the message no longer has value. For 4xx errors, manual deletion makes the message disappear without a bounce being recorded. Let the queue decide on its own according to maximal_queue_lifetime.

Next time you see an error code, just look at the first digit. If it's 4, hold off. If it's 5, look for the cause. That one habit alone eliminates most email tickets.