SMTP Response Codes Explained: The Complete Reference Guide (2026)

Every time an email server communicates with another server, it responds with a three-digit SMTP response code. These codes tell you whether your email was accepted, temporarily rejected, or permanently bounced — and why.

Understanding SMTP codes is critical for diagnosing deliverability problems, debugging email integrations, and reducing bounce rates. This guide covers every code you'll encounter in production.

How SMTP Response Codes Work

SMTP codes follow a consistent three-digit structure:

• First digit — indicates the overall result: success (2xx), temporary failure (4xx), or permanent failure (5xx)
• Second digit — categorizes the response: syntax (0), information (1), connection (2), mail system (5)
• Third digit — provides specific detail within the category

Most SMTP servers also include a human-readable message after the code, like 250 OK or 550 5.1.1 User unknown.

2xx — Success Codes

These codes mean the server accepted your request. No action needed.

Code	Meaning	When You See It
211	System status	Server returning system information (rare in practice)
214	Help message	Response to HELP command
220	Service ready	Server greeting after TCP connection — always the first response you see
221	Closing connection	Server confirming QUIT command — clean disconnect
235	Authentication successful	After AUTH LOGIN or AUTH PLAIN succeeds (outbound SMTP)
250	Requested action completed	The most important success code. Server accepted your HELO, MAIL FROM, RCPT TO, or DATA command.
251	User not local; will forward	Server accepts but recipient is on another system (mail forwarding)
252	Cannot verify user; will attempt delivery	Server won't confirm the mailbox exists but will try delivering anyway

Key takeaway: 250 doesn't always mean the mailbox exists

Providers like Google Workspace and Microsoft 365 return 250 OK for RCPT TO regardless of whether the mailbox actually exists. They accept all recipients and bounce later. This is why email verification tools classify these providers as "ambiguous" — a 250 response alone doesn't confirm deliverability.

3xx — Intermediate Codes

Code	Meaning	When You See It
334	Server challenge	SMTP AUTH handshake — server expects credentials
354	Start mail input	After DATA command — server is ready to receive the email body. End with CRLF.CRLF

4xx — Temporary Failure Codes

4xx codes mean "try again later." The server is temporarily unable to process your request. Your mail transfer agent (MTA) should retry automatically.

Code	Meaning	Common Cause & Fix
421	Service not available	Server is overloaded, restarting, or rate-limiting you. Fix: Wait and retry with exponential backoff.
450	Mailbox unavailable	Mailbox locked or temporarily full. Also used for greylisting — the server deliberately rejects the first attempt. Fix: Retry after 30-120 seconds.
451	Local processing error	Server-side error (database down, policy check failed, DNS lookup error). Fix: Retry. If persistent, check your sender reputation and rDNS/PTR records.
452	Insufficient storage	Server ran out of space or is rate-limiting per-connection recipients. Fix: Send fewer recipients per connection, retry later.
455	Server unable to accommodate	General temporary failure. Fix: Retry with backoff.

Greylisting: The most misunderstood 4xx response

Greylisting is an anti-spam technique where the server returns 450 or 451 on the first delivery attempt from an unknown sender. Legitimate mail servers retry after a delay; spambots typically don't.

If you're building email verification tools or sending transactional email, you must handle greylisting with retry logic. Mailthentic retries up to 3 times with 30/60/120-second delays to handle greylisted servers correctly.

5xx — Permanent Failure Codes

5xx codes mean "this will never work." The server is permanently rejecting your message. Do not retry — the email address or message must be fixed.

Code	Meaning	Common Cause & Fix
500	Syntax error (command not recognized)	Malformed SMTP command. Fix: Check your SMTP client for protocol compliance.
501	Syntax error in parameters	Invalid arguments to a valid command. Fix: Verify email address format in MAIL FROM / RCPT TO.
502	Command not implemented	Server doesn't support this command. Fix: Check server capabilities via EHLO.
503	Bad sequence of commands	Sent commands out of order (e.g., RCPT TO before MAIL FROM). Fix: Follow the SMTP handshake sequence.
504	Command parameter not implemented	Server doesn't support the parameter used. Fix: Check EHLO extension support.
550	Mailbox unavailable / User unknown	The most common bounce code. The email address doesn't exist. Fix: Remove from your list immediately. This is a hard bounce.
551	User not local	Recipient is not on this server. Fix: Check the recipient's MX records.
552	Storage allocation exceeded	Recipient's mailbox is full. Fix: Consider this a soft bounce and retry later, but remove if persistent.
553	Mailbox name not allowed	Invalid mailbox syntax on the server side. Fix: Verify the email address format.
554	Transaction failed	Catch-all rejection or policy block. Often seen as 554 5.7.1 Relay access denied (you're not authorized to send through this server) or content-based rejection. Fix: Check your authentication, sender domain, and content.

Enhanced status codes (RFC 3463)

Many servers include enhanced status codes like 5.1.1 or 4.7.1 after the base code. The format is class.subject.detail:

• X.1.X — Address-related (invalid recipient, bad destination)
• X.2.X — Mailbox-related (full, disabled, doesn't exist)
• X.3.X — Mail system issues (not accepting mail)
• X.4.X — Network/routing issues (no answer from host)
• X.5.X — Protocol issues (invalid commands)
• X.6.X — Content/media issues (message too large)
• X.7.X — Security/policy issues (authentication required, blocked by policy)

Common SMTP Errors and How to Fix Them

550 5.1.1 — User Unknown (Hard Bounce)

What it means: The mailbox doesn't exist on the server.

What to do:

1. Remove the address from your mailing list immediately
2. Check for typos (e.g., gmial.com instead of gmail.com)
3. If this is a new list, verify it in bulk before sending

421 4.7.0 — Rate Limited / Too Many Connections

What it means: You're sending too fast or have too many simultaneous connections.

What to do:

1. Reduce sending speed (messages per second)
2. Limit concurrent SMTP connections per domain
3. Implement exponential backoff on retries
4. Spread sending across multiple IPs if sending at scale

550 5.7.1 — Blocked by Policy

What it means: The receiving server is blocking your email based on sender reputation, IP blacklists, or content policy.

What to do:

1. Check if your sending IP is blacklisted (use MXToolbox or similar)
2. Verify your SPF, DKIM, and DMARC records are correctly configured — use our free checker
3. Ensure your rDNS (PTR record) matches your sending domain
4. Review your email content for spam triggers

450 4.1.1 — Greylisting

What it means: The server is temporarily rejecting you as an anti-spam measure.

What to do:

1. Wait 30-120 seconds and retry
2. Ensure your MTA is configured to retry (most are by default)
3. If you're building email tools, implement retry logic with delays

SMTP Response Codes by Provider

Different email providers have quirks in how they use SMTP codes:

Provider	Behavior
Gmail / Google Workspace	Returns 250 for all RCPT TO commands — never reveals if a mailbox exists. Bounces are sent later via NDR.
Microsoft 365 / Outlook	Similar to Gmail — accepts all recipients. Uses 550 5.1.10 for invalid recipients in some configurations.
Yahoo / AOL	Aggressive rate limiting with 421. Returns 550 for invalid mailboxes.
ProtonMail	Accepts all addresses (250) — cannot verify individual mailboxes.
Self-hosted (Postfix, Exim)	Typically returns 550 for unknown users. Behavior depends on configuration. Most reliable for verification.

The SMTP Handshake Sequence

Here's the complete SMTP conversation flow with response codes at each step:

← Server: 220 mx.example.com ESMTP ready
→ Client: EHLO mail.yourdomain.com
← Server: 250-mx.example.com Hello
← Server: 250-STARTTLS
← Server: 250 OK
→ Client: STARTTLS
← Server: 220 Go ahead
   ... TLS handshake ...
→ Client: MAIL FROM:<sender@yourdomain.com>
← Server: 250 OK
→ Client: RCPT TO:<recipient@example.com>
← Server: 250 OK    # ← This is where verification happens
→ Client: QUIT
← Server: 221 Bye

Email verification tools like Mailthentic perform this handshake up to the RCPT TO step and then disconnect with QUIT — no actual email is ever sent.

Quick Reference: All SMTP Codes at a Glance

Code	Summary	Action
220	Service ready	None
250	OK / Action completed	None
354	Start mail input	None
421	Service unavailable (rate limit)	Retry later
450	Mailbox busy / Greylisting	Retry later
451	Local processing error	Retry later
452	Insufficient storage	Retry later
550	User unknown / Mailbox not found	Remove
551	User not local	Remove
552	Mailbox full	Retry once
554	Transaction failed / Policy block	Investigate

How to Prevent SMTP Bounces

The best way to avoid SMTP errors is to verify email addresses before sending:

1. Validate at signup — Use real-time API verification on your registration forms
2. Clean your lists regularly — Bulk verify your lists before every campaign
3. Monitor bounce rates — Keep hard bounces below 2% and total bounces below 5%
4. Set up authentication — Configure SPF, DKIM, and DMARC for your sending domain
5. Warm up new IPs — Gradually increase sending volume on new IPs