SMTP Error Codes Explained (and How to Fix Them)

SMTP error codes are three-digit replies a mail server returns after every command. Codes in the 2xx range mean success, 4xx means a temporary failure that will be retried, and 5xx means a permanent failure that will not. The first digit tells you whether to wait, retry, or fix something — everything else is detail.

How to read an SMTP reply in ten seconds

A full SMTP response has three parts, and reading them in order saves you a lot of guessing:

1. The basic status code — three digits, e.g. 550. The first digit is the class (2 = success, 4 = transient, 5 = permanent). The second and third narrow the category.
2. The enhanced status code — a dotted triplet like 5.7.1, defined by RFC 3463. This is usually more diagnostic than the basic code, because receivers reuse 550 for a dozen unrelated reasons.
3. The free-text reason — the part after the codes, e.g. "Message rejected due to DMARC policy." This is written by humans at the receiving provider and is very often the only part that actually tells you what happened.

So in 550 5.7.1 Unauthenticated email from example.com is not accepted due to domain's DMARC policy, the useful information is almost entirely in the enhanced code and the text. Always log the whole line. Systems that store only the three-digit code throw away the diagnosis.

The 4xx codes: temporary failures (soft bounces)

A 4xx reply means "not now." Your sending server should queue the message and retry on a backoff schedule, typically for 24 to 72 hours before giving up. You generally should not remove the address from your list on a single 4xx.

Code	Typical meaning	What to do
421	Service not available, connection closing	Reduce concurrent connections; retry later
450	Mailbox unavailable / temporarily busy	Let the queue retry; check if it repeats for the same domain
451	Local error in processing, often greylisting	Retry — greylisting expects a second attempt minutes later
452	Insufficient system storage or too many recipients	Reduce recipients per transaction; retry
4.7.0 / 4.7.1	Policy or rate limiting by the receiver	Throttle your send rate to that domain and warm up gradually

Repeated 4xx replies from one large provider are the single most common early warning sign of a reputation problem. A mailbox provider that does not trust you will not always reject outright; it will simply slow you down. If Gmail or Microsoft starts deferring you at volumes they accepted last week, treat it as a reputation issue and not a network issue.

The 5xx codes: permanent failures (hard bounces)

Code	Typical meaning	What to do
500	Syntax error, command unrecognized	Client bug — check the SMTP library or malformed headers
501	Syntax error in parameters or arguments	Usually a malformed address in MAIL FROM or RCPT TO
503	Bad sequence of commands	Your client sent commands out of order (e.g. DATA before RCPT)
530 5.7.0	Authentication required	Enable SMTP AUTH; check credentials and that STARTTLS ran first
535 5.7.8	Authentication credentials invalid	Regenerate the SMTP key; check for whitespace in stored secrets
550 5.1.1	Recipient address does not exist	Remove permanently — this is a true hard bounce
550 5.7.1	Rejected by policy (SPF/DKIM/DMARC, blocklist, content)	Fix authentication or review content; read the text portion
552 5.2.2	Mailbox full / over quota	Often treated as soft in practice — suppress after repeats
554 5.7.1	Transaction failed, message refused	Frequently a blocklist hit; check listings and reputation

The five errors that account for most real-world pain

550 5.1.1 — user unknown

The address is dead. Suppress it immediately and permanently. Continuing to mail addresses that hard-bounce is the fastest way to damage your reputation, because it signals to receivers that you are not maintaining your list. A healthy campaign hard-bounce rate sits well under 2%; above that, stop sending and clean the list before you continue.

550 5.7.1 — DMARC or policy rejection

This means your message failed authentication alignment or hit a policy rule. Check that SPF includes your sending service, that DKIM is signing with a key published at the right selector, and that the visible From domain aligns with one of them. If you are managing DNS by hand, this is where most teams lose a week; IGSendMail sets up SPF, DKIM, and DMARC automatically so alignment is correct from the first send.

421 4.7.0 — too many connections or rate limited

You are sending faster than the receiver will accept from a sender at your reputation level. Lower concurrency, spread the send over a longer window, and if the domain is new, follow a warm-up ramp rather than blasting your full list on day one.

535 5.7.8 — authentication failed

Nearly always a credentials problem, and nearly always one of three things: the key was rotated and the app still holds the old one, the username is the account email when it should be the SMTP username, or the client is trying AUTH on a port where TLS was never negotiated. Verify on the correct port before you debug anything else — a full breakdown of ports and connection settings lives in the SMTP relay setup guide.

554 5.7.1 — message refused

Usually a blocklist or content rejection. Check whether your sending IP or domain appears on a major blocklist, look for URL shorteners and link-shortener domains in the body (a classic trigger), and confirm you are not sending from a shared IP with a noisy neighbor.

Common SMTP ports and when the error is really a port problem

Port	Encryption	Use for
587	STARTTLS	Default for authenticated application sending
465	Implicit TLS (SMTPS)	Widely supported alternative to 587
25	Optional STARTTLS	Server-to-server relay; blocked by most cloud hosts
2525	STARTTLS	Fallback when 587 is filtered by the network

If your app hangs with no reply at all rather than returning a code, that is not an SMTP error — that is a blocked port. Cloud providers routinely block outbound 25. Move to 587 or 2525.

A repeatable triage process

1. Capture the full reply string, not just the number. Store it against the recipient and the campaign.
2. Split 4xx from 5xx in your reporting. They require completely different responses.
3. Group 5xx by enhanced code and domain. A hundred 5.1.1 across many domains is a list-hygiene problem; a hundred 5.7.1 at one domain is an authentication or reputation problem.
4. Suppress hard bounces automatically and never re-import them from an old CSV.
5. Watch soft-bounce trend lines. A rising 4xx rate at a single provider is your earliest reputation signal.
6. Re-test after each fix with a small seed send before resuming full volume.

Frequently asked questions

What is the difference between a soft bounce and a hard bounce?

A soft bounce is a 4xx temporary failure — the server may accept the message on retry, so the address stays on your list. A hard bounce is a 5xx permanent failure, such as a nonexistent mailbox, and the address should be suppressed immediately.

What does SMTP error 550 5.7.1 mean?

It means the receiving server rejected the message on policy grounds, most often failed SPF, DKIM, or DMARC alignment, or a blocklist match. Read the free-text portion of the reply — it usually names the specific policy that triggered the rejection.

Should I retry a 5xx error?

No. A 5xx is permanent by definition, and retrying it wastes reputation. The one common exception is 552 mailbox-full, which some senders treat as soft and retry a limited number of times before suppressing.

Why am I getting 421 errors only from one provider?

That is rate limiting tied to your sender reputation at that provider, not a general outage. Reduce concurrency and daily volume to that domain, and ramp back up over one to two weeks.

Which SMTP port should I use?

Use 587 with STARTTLS for authenticated application sending. Use 465 if your library prefers implicit TLS, and 2525 if your host blocks the standard ports. Avoid port 25 for application sending entirely.

Tired of decoding bounce logs by hand? Launch on IGSendMail — automatic SPF/DKIM/DMARC, clear bounce classification, and 99% inbox deliverability from $19/mo.