SMTP error codes explained

An SMTP error code is the three-digit reply a receiving mail server sends back while it handles your message. The first digit tells you the category.

Resources

Below is what each common code means, why it happens, and what to change. The last two entries, 10060 and 10061, are not SMTP replies at all. They are Windows socket errors.

421: service not available

The server is temporarily unable to accept the message and closes the connection. Because it is a 4xx, the message stays queued and retries on its own.

This usually means rate limiting (too many messages or connections in a short window), a server that is overloaded or in maintenance, or a reputation throttle on your sending IP. Slow your send rate and let the queue handle it. A 421 that shows up constantly rather than in bursts points to a reputation or volume problem. See email deliverability.

450: mailbox unavailable, try again

The mailbox was temporarily unavailable, so the server would not take the action. It falls in the temporary 4xx class.

Greylisting is the usual reason: the server defers a first-time sender on purpose and accepts the retry. A mailbox that is busy or locked, or a soft reputation deferral, can also cause it. A second attempt normally clears greylisting. If 450 keeps returning for the same address, treat it as a reputation or authentication deferral rather than a fluke and check why emails go to spam.

451: local error in processing

The server hit a local error on its side and aborted the action. It is temporary, a 4xx.

The cause can be a transient server fault, a content or anti-spam system holding the message for a closer look, or a reputation-based delay. Retry and watch whether it clears. A 451 that repeats with an enhanced code like 4.7.1 is a policy or reputation deferral, not a one-off glitch.

452: insufficient storage

The server did not have enough storage to take the action, so it deferred. Another 4xx, so temporary.

The recipient mailbox is full, or you sent too many recipients in one message for the server to accept at once. A full mailbox is the recipient’s to clear. On your end, split large recipient lists into smaller batches and retry.

471: server or filter error (non-standard)

471 is not defined in RFC 5321. Some mail servers and anti-spam systems return it as a 4xx to flag a mail filter or configuration error while processing the message.

Because it is provider-specific, the real reason sits in the text after the number, so read the whole response line. Treat it as temporary and retry, but a 471 that repeats means a content or anti-spam filter is holding the message. Tighten authentication and content instead of resending it unchanged. See DMARC and DKIM setup.

550: mailbox unavailable or rejected

The mailbox is unavailable, so the action did not happen. This is a permanent 5xx and one of the rejections you will see most.

It splits three ways: an address that does not exist (5.1.1), a mailbox that has been closed, or a policy block where the server refuses you over reputation or authentication (5.7.1). An invalid address is a receiver-side fact, so stop sending to it. A policy block is about you: check SPF, DKIM, DMARC, and your sending reputation. A rising share of 550s tracks with bounce rate.

551: user not local

The recipient is not on this server, and the server will not relay the message onward. It is a permanent 5xx and rare on modern mail systems.

Usually the route is outdated or the address has moved, and some servers reply with a suggested forwarding address. Correct the destination and resend.

552: message too large or storage exceeded

The message crossed a size or storage limit and was rejected. This is a permanent 5xx, the opposite of the temporary 452.

Either the message and its attachments exceed the receiving server’s size limit, or the mailbox is over its permanent storage allocation. Shrink the message, or host large files behind a link instead of attaching them, then resend.

553: mailbox name not allowed

The mailbox name is not allowed, so the server refused the action. Permanent, a 5xx.

The recipient address is invalid or malformed, or the server rejects your sender address, an unqualified or spoofed-looking From being the usual example. Fix the address syntax, and send your From from a domain you have authenticated.

554: transaction failed

554 is the catch-all rejection: the transaction failed and the server will not accept the message. It is permanent, a 5xx.

Behind it is usually a spam or policy block (554 5.7.1), a sending IP or domain on a blocklist, or relaying that was denied. This one points at the sender almost every time, not the address. Check your domain authentication, your reputation, and whether your IP or domain is on a blocklist. Note that connect error 10060 and 554 are not the same failure: 554 means you reached the server and it refused the message, while 10060 means the connection never completed. Read more on why emails go to spam.

535: authentication failed

535 means the SMTP AUTH credentials were rejected (5.7.8). The server understood the login and turned it down.

The credentials are wrong, the API key or app password has expired or been revoked, or the account needs an app-specific password instead of the main one. This is entirely on the sender: correct the credentials, regenerate the key if it was rotated, and confirm you are using the submission port and auth method the provider expects. See SMTP ports and email protocols.

connect error 10060: connection timed out

10060 is a Windows socket error (WSAETIMEDOUT), not an SMTP reply. Your client opened a connection to the mail server and never heard back before the timeout.

The usual culprit is a blocked outbound port (often port 25, blocked by an ISP or firewall), the wrong server hostname, or a server your network cannot reach. Switch to submission port 587, confirm the hostname, and check the firewall. Nothing was rejected here, so it is a network reachability problem, not a reputation one.

connect error 10061: connection refused

10061 is a Windows socket error (WSAECONNREFUSED), not an SMTP reply. The target actively refused the connection.

That happens when you connect to a port with no mail service listening (a wrong or closed port), when the SMTP service is not running, or when a firewall rejects the connection outright. Confirm the correct submission port and that the mail service is up. As with 10060, this is a connection-level failure, not a message rejection.

4xx versus 5xx and retries

The first digit decides what to do next. A 4xx reply is a temporary failure, so the sending server keeps the message queued and retries on a schedule that backs off over time, usually across several hours up to a few days before giving up. You do not need to resend a 4xx yourself. A 5xx reply is a permanent failure, so retrying the same message to the same address will fail the same way. Fix the underlying cause, or stop sending to that address.

Do not retry a 5xx by hammering the server, because repeated permanent failures to bad addresses hurt your reputation and raise your bounce rate. And do not panic over an occasional 4xx, because greylisting and brief deferrals are normal and clear on retry. The signal to watch is a 4xx that never clears, which usually means a reputation or authentication problem wearing a temporary code.

When the code is about you

Some codes describe the recipient, and some describe you. A 550 for a nonexistent address or a 552 for an oversized message is about that specific message or mailbox. But a 554 spam block, a 550 or 451 policy deferral, a persistent 450, or an authentication failure like 535 points back at your setup.

When the code is about you, the fix is rarely resending. It is authentication and reputation. Confirm SPF, DKIM, and DMARC are aligned with DMARC and DKIM setup, watch your bounce rate, and clean the inputs that let bad addresses into your list. The broader playbook is in email deliverability. If you send through Loops, a hard bounce or spam complaint moves that contact into suppression automatically, so a repeat 550 or 554 to the same address stops after the first failure instead of piling up.