Email Error Codes: 421, 422, 501, 550, 554 Decoded

Email error codes are the diagnostic system every mail server uses to explain what went wrong with a delivery attempt. Most senders ignore them until something breaks at scale; by that point, the error patterns have been visible in bounce logs for weeks.

The codes themselves are well-defined and have not changed in decades. What has changed is what the major receiving servers (Gmail, Microsoft, Yahoo) put behind those codes. Receiving servers now return increasingly specific reasons for rejections, often with custom enhanced status codes that point to the exact issue.

This is the practical decoder: what each common SMTP error code means, what causes it, and what to do about it.

The Code Structure

Every SMTP response is a three-digit code, sometimes followed by an enhanced status code (RFC 3463) and a human-readable message.

The first digit signals the outcome category:

• 2xx, success. The action requested completed.
• 3xx, intermediate. The server needs more from the client to continue.
• 4xx, temporary failure (transient). Retry later. The send may succeed on the next attempt.
• 5xx, permanent failure. Do not retry. Something about the message, the sender, or the recipient is wrong in a way the server will not change its mind on.

The second digit signals the failure category:

• x0x, syntax
• x1x, information
• x2x, connection
• x3x, unspecified
• x4x, unspecified
• x5x, mail system

The third digit specifies the exact reason within the category. So 550 ("permanent mailbox failure") and 553 ("permanent mailbox failure, name not allowed") are both 5xx mail-system permanent rejections, but with different specific causes.

The 4xx Codes (Temporary. Retry)

4xx codes mean the send did not succeed but the receiving server is signaling it might in the future. Mail servers typically retry over a 24-72 hour window before giving up.

421. Service not available, closing transmission channel. The receiving server is overloaded, in maintenance, or rate-limiting the sender. Common cause: sending too fast from one IP. Fix: slow down the send rate, retry after a backoff window. Persistent 421s from a specific receiver usually mean reputation throttling.

450. Requested mail action not taken; mailbox unavailable. The recipient mailbox temporarily cannot accept mail. Could be storage full, server-side issue, or a greylist. Fix: retry. If the 450 persists for 48+ hours, treat as permanent.

451. Requested action aborted; local error in processing. Something went wrong on the receiving side that is the receiver's problem, not the sender's. Fix: retry. Worth investigating if 451s spike from one specific receiver, usually indicates a temporary issue on their end.

452. Requested action not taken; insufficient system storage. The receiving server is out of disk space. Rare in modern environments. Retry; if persistent, the receiver has bigger problems than your email.

The 5xx Codes (Permanent. Do Not Retry)

5xx codes mean the send permanently failed. Retrying generates more bounces, which damages sender reputation. Suppress the recipient and move on.

500. Syntax error, command unrecognized. The SMTP client sent something the server did not understand. Almost always a bug in the sending application, not a content or reputation issue.

501. Syntax error in parameters or arguments. Similar to 500, but specifically about the arguments to a valid command. Common cause: malformed email address in MAIL FROM or RCPT TO. Fix: validate addresses before sending.

502. Command not implemented. The server does not support a command the client tried to use. Rare in 2026.

503. Bad sequence of commands. The client tried to do something out of order, sending DATA before RCPT TO, for example. Bug in the SMTP client.

504. Command parameter not implemented. The server understood the command but not a specific parameter. Often related to AUTH or STARTTLS extensions.

550. Requested action not taken; mailbox unavailable. The big one. Most permanent failures return 550. Common reasons:

• Recipient address does not exist (most common; the email is hard-bouncing)
• Recipient domain does not accept mail from this sender (reputation, blocklist, or DMARC failure)
• Sender's domain or IP is on a blocklist the receiver uses
• Content was flagged as spam (Gmail and Microsoft often return 550 with descriptive enhanced status)

The text after the 550 code is where the actual diagnosis lives. Examples:

• 550 5.1.1 The email account does not exist recipient does not exist; suppress from the list
• 550 5.7.1 Message rejected as spam content or reputation problem; do not retry, but investigate the pattern
• 550 5.7.26 Authentication required DMARC alignment failure; fix authentication before sending again

551. User not local; please try forwarding address. Rare. The recipient's mailbox has moved.

552. Requested mail action aborted; exceeded storage allocation. The recipient's mailbox is full. Sometimes returned as 4xx (temporary) instead. Treat as temporary on first occurrence; permanent if it keeps coming back.

553. Requested action not taken; mailbox name not allowed. The address syntax is fine but the receiving server rejects it for policy reasons. Often happens when the sender domain matches the recipient domain (looks like spoofing) or when DMARC alignment fails.

554. Transaction failed. Generic permanent rejection, almost always for content or reputation reasons. Common with Gmail and Yahoo. The text is critical:

• 554 5.7.1 Message rejected as spam by content filtering content flagged
• 554 5.7.1 Sender domain has not authenticated DKIM/SPF failed
• 554 5.7.1 Service unavailable; client host blocked using Spamhaus IP blocklisted

Enhanced Status Codes (RFC 3463)

The enhanced status code is the second number after the 5xx or 4xx, formatted as X.Y.Z. It exists to give more granular detail than the three-digit code alone.

Common enhanced codes worth knowing:

• 5.1.1, bad destination mailbox address (recipient does not exist)
• 5.1.2, bad destination system address (recipient domain does not exist)
• 5.2.1, mailbox disabled, not accepting messages
• 5.2.2, mailbox full
• 5.4.1, no answer from host (network issue)
• 5.7.1, delivery not authorized; rejected for policy or content reasons
• 5.7.7, message integrity failure (DKIM signature failed)
• 5.7.9, authentication mechanism is too weak
• 5.7.26. DMARC policy failed (Microsoft 365's specific code)

The 5.7.x family is the deliverability-relevant set. Most cold email rejections fall here: authentication failures, content filtering, blocklist hits, DMARC misalignment. The enhanced code points to the specific diagnostic.

Provider-Specific Codes

Each major receiving server has its own way of putting detail behind a generic SMTP code.

Gmail. Returns specific reason text after the 550 code. Look for patterns like:

• 421 4.7.0 Try again later, closing connection rate limiting
• 550 5.7.1 Our system has detected an unusual rate of unsolicited mail reputation
• 550 5.7.1 ... DMARC compliance failure DMARC alignment
• 550 5.7.26 This message does not pass authentication checks SPF/DKIM/DMARC failed

Microsoft 365 / Outlook. Uses descriptive text and links to documentation:

• 421 4.7.0 RT:RC ... Server busy rate-limited; back off
• 550 5.7.1 Service unavailable, Client host [IP] blocked using Spamhaus blocklist hit
• 550 5.7.1 Unfortunately, messages from [IP] weren't sent IP reputation
• 550 5.7.26 This message was sent from an unauthenticated email source auth failure

Yahoo / AOL. Often returns 421 for rate limiting and 554 for content/reputation rejections. Less verbose than Gmail or Microsoft; the reason is usually "policy" without further detail.

What Each Code Pattern Tells You

Reading bounce logs is pattern recognition. Specific codes from specific receivers point to specific underlying problems:

• Spike in 550 5.1.1 from any receiver: list quality. The list contains addresses that no longer exist. Verify the list before next send.
• Spike in 421 from one receiver: rate limiting from that receiver. Reduce send rate to that domain or spread sends across more sending IPs.
• 5.7.1 or 5.7.26 across multiple receivers: authentication problem. Check SPF, DKIM, DMARC on the sending domain.
• 5.7.1 with "Spamhaus" or "blocklist" text: sending IP or domain is on a public blocklist. Identify which list (MXToolbox, MultiRBL) and submit a delisting request.
• 554 with "spam" or "policy" text: content or reputation rejection. Either the message looks like spam (content) or the sender's reputation is poor (history). Both require investigation.
• 5.7.7 (DKIM): DKIM signature is failing. Often caused by a key rotation, DNS misconfiguration, or message modification in transit (forwarders, mailing lists).

Acting on Bounces

Bounce handling separates teams that maintain good deliverability from teams that watch it slowly degrade. The basic rules:

• Hard bounces (5xx) get suppressed immediately. Sending again to a 550 5.1.1 address is the fastest way to damage reputation.
• Soft bounces (4xx) retry with backoff. If the same address keeps soft-bouncing for 5+ days, treat as a hard bounce and suppress.
• Track bounce rate per sending domain. A bounce rate consistently above 2-3% signals dirty list or list mismatch and needs intervention.
• Track bounce reasons, not just bounce volume. A spike in 550 5.7.1 is a different problem than a spike in 550 5.1.1, and the fixes are different.

Most sequencers and ESPs handle bounce categorization automatically. If you are sending through SMTP relays directly, the sending application has to interpret the bounce response and update the suppression list. Skipping this step is the most common cause of slow domain burn.

The Larger Pattern

SMTP error codes are the visible symptom of underlying deliverability state. Codes do not exist in isolation. Patterns of codes across time and across receivers describe the health of a sending domain.

A clean sending operation produces almost no 5xx codes, a small percentage of 4xx codes that resolve on retry, and overwhelmingly 250-OK responses. A degrading operation shows climbing 5xx rates, increasingly specific 5.7.x codes from major receivers, and 421 throttling from the receivers that previously accepted volume.

Catching the pattern early is the difference between a domain that needs minor adjustment and a domain that needs replacement. Most teams catch it late.

At ScaledMail, the cold email infrastructure we provision includes continuous monitoring of bounce patterns across every sending domain. Domain reputation is tracked through Google Postmaster, Microsoft SNDS, and direct bounce-log analysis. Sending domains that start showing the early patterns of 5.7.x failures or persistent 421 throttling get retired before they become unrecoverable. The sequencer (Instantly, Smartlead, Apollo) handles campaign mechanics; the infrastructure layer monitors the signals that determine whether the campaigns can land at all. Book a call or see the setup.