SMTP Error Codes Explained

Every SMTP response is a three-digit reply code, optionally followed by an enhanced status code and a human-readable message. The first digit tells you the outcome category, and that is the most important thing to read. Defined in RFC 5321:

The single most useful rule: 4xx is temporary, 5xx is permanent. A 421 deferral should be retried; a 550 rejection should not, because retrying an address that does not exist only harms your reputation. The second and third digits add specificity, but the first digit alone tells you whether to wait or to stop.

The second digit groups the response by what part of the conversation it concerns. A second digit of 0 covers syntax, 2 covers connection state, and 5 covers the mail system itself, which is why the codes you care about most as a sender (the 250s, 421s, and 550s) sit in the 5 group. You do not need to memorize the second and third digits; the practical habit is to read the first digit for the verdict and then read the human-readable text and any enhanced code for the reason. The companion guide common SMTP errors and fixes maps these to concrete actions, and the rest of this article walks each class with the codes you will actually meet.

Three-digit codes are coarse. To add precision, RFC 3463 defines enhanced status codes in the form class.subject.detail, for example 5.7.1. You will see these alongside the basic reply code, like 550 5.7.1.

Common subject values worth knowing: X.1.x addressing problems (bad recipient or sender), X.2.x mailbox problems (full or disabled), X.4.x network and routing, and X.7.x security and policy (auth, SPF/DKIM/DMARC, spam). So 550 5.7.1 is a permanent (5) security/policy (7) rejection, typically relay denied or a policy block, while 550 5.1.1 is a permanent addressing (1) error meaning the recipient does not exist.

Success codes confirm a command was accepted. You rarely act on these, but recognizing them helps when reading a session log.

The one to watch is 250. After your DATA command and the closing dot, a 250 2.0.0 OK with a queued message ID means the receiving server accepted the message. Acceptance is not the same as inbox placement; a 250 only means the server took the message, not that it landed in the inbox rather than spam. Placement depends on reputation and authentication, covered in the email deliverability guide.

A 4xx code is a temporary failure. The correct behavior is to retry later with exponential backoff. These are the ones you will encounter sending cold email at volume:

Greylisting is a common cause of 451: the receiver deliberately defers a first attempt from an unknown sender and accepts the retry. The logic is that spam software often does not retry, while a legitimate mail server always will, so a forced wait of a few minutes filters out a chunk of junk for free. A normal sending system handles this invisibly by retrying; you only notice it as a short delay on the first message to a new recipient domain.

Backoff in practice means waiting longer between each retry rather than hammering the server. A reasonable schedule retries after a few minutes, then a quarter hour, then an hour, then a few hours, giving up after a day or two. Retrying a 4xx immediately and repeatedly looks like abuse and can convert a soft defer into a hard block. A 421 that persists across messages signals a rate or reputation problem, not a transient blip, and the right response is to slow down and investigate, not to retry harder. Provider sending caps that trigger 421 are documented in email sending limits for Google and Microsoft.

A 5xx code is a permanent rejection. Retrying the same command will fail again and, in the case of bad recipients, will hurt your reputation. Fix the underlying cause before resending.

Two of these matter most for cold email. 550 5.1.1 is a hard bounce; a high rate of these damages reputation fast, so keep your list clean per cold email bounce rate benchmarks. 554 5.7.1 often means the receiver flagged your mail as spam or your IP/domain is blocklisted; check with check domain blacklisted.

The X.7.x security and policy subject is where authentication and reputation failures surface. These are the codes that most often mean your SPF, DKIM, or DMARC setup is wrong, or your reputation has slipped.

Code 5.7.26 is increasingly common as Google and Yahoo enforce stricter authentication; it means the message failed the authentication checks required by bulk-sender rules. The wording you see often spells it out, for example a message saying unauthenticated email is not accepted from this domain. The fix is to publish and align SPF, DKIM, and DMARC and meet the Google and Yahoo sender requirements. Alignment is the part people miss: SPF and DKIM can each pass on their own, but DMARC also requires that the domain they pass for matches the visible From domain, and a mismatch still produces a 5.7.26.

The distinction between the X.7.x codes is worth holding onto. A 5.7.1 is about authorization (you are not permitted to send this, often relay scope or a policy block). A 5.7.8 is about identity (your login was rejected). A 5.7.26 is about authentication of the mail itself (the message did not prove it came from the domain it claims). They look similar but lead to different fixes: scope and permission for 5.7.1, credentials or OAuth for 5.7.8, and DNS authentication records for 5.7.26. A 5.7.8 points to the SMTP login itself, fixed by regenerating credentials or moving to OAuth as described in Microsoft 365 SMTP settings.

Bounce messages (non-delivery reports) bundle the reply code, enhanced status code, and a diagnostic string. Reading them in order saves time.

A typical bounce contains:

1. 1The reply code, for example 550, which tells you permanent versus temporary at a glance.
2. 2The enhanced status code, for example 5.7.1, which tells you the category (security/policy).
3. 3The diagnostic text, often the most specific, sometimes naming a blocklist or the failing check.

Example: 550 5.7.1 Service unavailable, Client host 203.0.113.5] blocked using Spamhaus. The 550 says permanent, 5.7.1 says policy, and the text names the cause: a [Spamhaus listing. The fix is delisting, walked through in the email blacklist removal guide, and prevention through ongoing monitoring per email deliverability monitoring setup.

Different providers word their diagnostics differently, so always read the full text, not just the numeric code.

The practical workflow once you understand the code system:

1. 1Read the first digit. 4xx means retry with backoff; 5xx means stop and fix.
2. 2Read the enhanced code. The subject digit (1 addressing, 2 mailbox, 7 security) tells you where to look.
3. 3Read the diagnostic text. It often names the exact cause, including blocklists.
4. 4Fix the root cause, not the symptom. A 5.7.26 is solved by authentication, not by resending.
5. 5Watch trends. A rising rate of 5xx or 421 across mailboxes is a reputation problem, tracked through domain reputation vs IP reputation and Postmaster Tools.

Managed infrastructure reduces how often you read these codes at all. InboxKit configures SPF, DKIM, and DMARC automatically, which prevents most 5.7.x authentication failures, and its InfraGuard monitoring checks blacklists every six hours and auto-pauses sending before a 554 block compounds across a campaign.