SMTP uses two layers of status codes: the basic three-digit code (defined in RFC 5321) and the enhanced status code (defined in RFC 3463), which adds class, subject, and detail subfields for precise diagnosis. In 2024 and 2025, Gmail, Yahoo, and Microsoft introduced new enforcement codes like 550 5.7.26 (unauthenticated mail) and 550 5.7.515 (bulk sender requirements not met) to reject mail that fails the new authentication and unsubscribe requirements. This reference covers every code that matters for deliverability and the specific fix for each.
When an email fails to deliver, the receiving server returns a status code that tells you exactly what went wrong, if you know how to read it. Most senders see a bounce, note that it failed, and move on. Senders who understand SMTP status codes can diagnose the precise failure, apply the correct fix, and protect their Sender Reputation before a single misconfiguration becomes a pattern of rejections.
This reference covers the complete SMTP status code system: the basic codes, the enhanced status codes that add diagnostic precision, and the new enforcement codes that Gmail, Yahoo, and Microsoft introduced during the 2024-2025 bulk sender requirement rollout. For each consequential code, it explains what the code means and exactly how to fix it.
The Two Code Systems
Every SMTP response carries a basic status code, and most modern servers also include an enhanced status code. Understanding both is essential because they work together.
Basic SMTP Codes (RFC 5321)
The basic code is three digits, and the first digit tells you the class of response:
- 2xx (Success): The command was accepted. 250 is the workhorse "OK" response.
- 3xx (Intermediate): The server needs more input. 354 is the "start mail input" response to the DATA command.
- 4xx (Transient failure): A temporary problem. The sending server should retry automatically. These are soft bounces.
- 5xx (Permanent failure): A permanent rejection. The sending server should not retry. These are hard bounces.
Enhanced Status Codes (RFC 3463)
The enhanced code adds three dot-separated subfields in the format class.subject.detail. The basic 550 might mean a typo or a spam block; the enhanced code 5.1.1 versus 5.7.1 tells you which, and they require completely different fixes.
The class (first digit) mirrors the basic code: 2 success, 4 transient, 5 permanent. The subject (second digit) categorizes the problem:
- X.1.X: Addressing problems (bad recipient, bad sender).
- X.2.X: Mailbox problems (full, disabled, does not exist).
- X.3.X: Mail system problems (system full, not accepting mail).
- X.4.X: Network and routing problems.
- X.5.X: Mail delivery protocol problems.
- X.7.X: Security and policy problems (authentication, spam, blocks).
2xx Success Codes
| Code | Meaning | Notes |
|---|---|---|
| 220 | Service ready | The server greeting at connection. |
| 221 | Service closing | Normal connection close after QUIT. |
| 250 | Requested action completed | The standard success response for most commands. |
| 251 | User not local, will forward | Recipient is elsewhere; message will be relayed. |
| 252 | Cannot verify user, will attempt delivery | The server accepts without confirming the mailbox exists. This is why many providers cannot be verified by a simple connection test. |
The 250/252 verification trap: Google Workspace and Microsoft 365 frequently return 250 or 252 for RCPT TO regardless of whether the mailbox actually exists, then bounce later. This is why email verification tools classify these providers as ambiguous; a positive response at connection time does not guarantee the address is real.
4xx Transient Failure Codes (Soft Bounces)
These are temporary. A well-behaved sending server retries them automatically on a schedule. If they persist across many retries, escalate to suppression.
| Code | Enhanced | Meaning | Fix |
|---|---|---|---|
| 421 | 4.7.0 | Service unavailable, too many connections, or temporary block | Reduce connection rate; check for reputation-based throttling. |
| 450 | 4.2.1 | Mailbox temporarily unavailable, often graylisting | Retry after a delay; ensure your retry logic handles graylisting. |
| 451 | 4.3.0 | Local error in processing | Retry; if persistent, the receiving server has an internal problem. |
| 452 | 4.2.2 | Insufficient storage, mailbox full | Retry; if persistent over weeks, treat as an abandoned mailbox and suppress. |
| 421 | 4.7.28 | Gmail rate limit or suspicious traffic | Slow down; review your sending patterns and reputation. |
5xx Permanent Failure Codes (Hard Bounces)
These are permanent. Do not retry. Addresses returning a true 5xx address failure should be added to your suppression list immediately.
| Code | Enhanced | Meaning | Fix |
|---|---|---|---|
| 550 | 5.1.1 | Mailbox does not exist | Suppress immediately. The address is dead. |
| 550 | 5.1.10 | Recipient address does not exist (Microsoft null MX) | Suppress immediately. |
| 553 | 5.1.3 | Invalid mailbox name or syntax | Fix the address format; if truly malformed, suppress. |
| 552 | 5.2.2 | Mailbox full (permanent variant) | Some servers treat full mailboxes as permanent. Suppress after retries. |
| 554 | 5.7.1 | Transaction failed, often a content or reputation block | Not always a dead address. Investigate reputation and content before suppressing. |
| 541 | 5.7.1 | Recipient address rejected by policy | Policy block, not a dead address. Check authentication and reputation. |
Critical classification rule: Not every 5xx is a dead address. A 550 or 554 with enhanced code 5.7.x is a security or policy block (reputation, content, authentication), not a nonexistent mailbox. Suppressing these as if the address were dead permanently removes valid recipients. Always read the enhanced code: 5.1.x and 5.2.x are address and mailbox failures (suppress), while 5.7.x is a policy block (fix the underlying issue, do not suppress the address).
The New Bulk Sender Enforcement Codes (2024-2025)
This is the section most existing SMTP references do not cover, because these codes were introduced as part of the bulk sender requirement rollout that began in February 2024 and tightened through 2025. They all live in the 5.7.x security and policy space and indicate that your mail failed the new authentication, alignment, or unsubscribe requirements rather than that anything is wrong with the recipient address.
| Enhanced Code | Provider | Meaning | Fix |
|---|---|---|---|
| 5.7.26 | Gmail | Unauthenticated mail; message failed authentication requirements | Configure SPF, DKIM, and ensure alignment. This is the flagship Gmail bulk-sender rejection. |
| 5.7.515 | Microsoft | Message does not meet authentication requirements (missing SPF/DKIM/DMARC) | Set up full authentication with DMARC at minimum p=none. |
| 5.7.1 | Gmail, Yahoo | Bulk sender requirements not met; can include missing one-click unsubscribe | Implement one-click unsubscribe, reduce complaint rate, authenticate. |
| 5.7.509 | Microsoft | Access denied; DMARC failure with reject/quarantine policy | Fix DMARC alignment for the sending source. |
| 5.7.25 | Multiple | Reverse DNS (PTR) does not resolve or does not match | Configure a valid PTR record with forward-confirmed reverse DNS. |
| 5.7.27 | Gmail | SPF validation failed (no SPF and unauthenticated) | Publish a valid SPF record that includes all sending sources. |
Gmail typically rolls these out as a warning before a rejection: a sender first sees the failure noted in a non-blocking way, then after the enforcement deadline the same condition becomes a hard 550 rejection. By November 2025, the warning-to-rejection transition was complete for most of these codes, meaning what was previously a tolerated warning now blocks delivery outright.
If you see any 5.7.x code in the 5.7.25 through 5.7.27 range or 5.7.515, the problem is your configuration, not the recipient. Do not suppress these addresses. Fix the underlying authentication, PTR, or unsubscribe issue, then the same addresses will accept mail. Treating enforcement-code rejections as dead addresses is one of the most damaging mistakes in bounce handling because it shrinks your reachable audience over a problem you could have fixed.
How to Read a Bounce in Practice
When a bounce arrives, work through it in this order:
- Read the first digit of the basic code. 4xx is temporary (retry), 5xx is permanent (do not retry).
- Read the enhanced code subject digit. X.1.x and X.2.x are address and mailbox problems. X.7.x is a policy or security problem.
- For X.1.x and X.2.x permanent failures: Suppress the address. It is dead.
- For X.7.x failures: Do not suppress. Diagnose the policy issue (authentication, reputation, PTR, unsubscribe) and fix it.
- For 4xx failures: Let your retry logic handle it. Escalate to suppression only after repeated consecutive soft bounces with no successful delivery.
- Log the diagnostic text for patterns, but never classify on the human-readable text alone because it varies between providers. The codes are standardized; the text is not.
Provider-Specific Quirks
Gmail
Gmail provides detailed enhanced codes and links to its postmaster documentation in many rejection messages. The 5.7.26 unauthenticated mail code is the single most common Gmail enforcement rejection. Gmail also uses 4.7.28 for rate-based throttling, which is a soft signal that you are sending too fast or your reputation is slipping.
Microsoft
Microsoft uses its own S-prefixed codes (like S3150, S3140) alongside standard enhanced codes, particularly for Outlook.com and Hotmail. The 5.7.515 authentication code and 5.7.509 DMARC code are the most common Microsoft enforcement rejections. Microsoft rejections often reference the specific requirement that failed.
Yahoo
Yahoo tends to use 5.7.1 broadly for policy rejections and is particularly strict on DKIM key length, rejecting keys shorter than 1024 bits. Yahoo also enforces non-generic PTR records and will defer or reject mail from generic cloud provider hostnames.
Monitoring Codes at Scale
At any meaningful sending volume, you need to aggregate status codes to spot patterns. A single 5.7.26 is noise; a sudden spike in 5.7.26 across many recipients means your authentication broke and every Gmail recipient is now being rejected. Track:
- The distribution of codes over time, watching for sudden shifts.
- Any appearance of enforcement codes (5.7.25 through 5.7.27, 5.7.509, 5.7.515), which indicate configuration problems affecting all mail to that provider.
- The ratio of 5.1.x and 5.2.x (genuine dead addresses, expected at a low steady rate) versus 5.7.x (policy problems, should be near zero with correct configuration).
- 4xx rates, which if elevated indicate throttling or graylisting that may need sending-rate adjustments.
Use a header analyzer to inspect the full diagnostic output of individual bounces, and monitor your overall deliverability trends so a code-level problem surfaces before it becomes a reputation crisis.
Frequently Asked Questions
550 5.7.26 is a Gmail rejection meaning your message failed authentication requirements. The mail was not properly authenticated with SPF and DKIM, or it failed DMARC alignment. The fix is to configure SPF, DKIM, and DMARC correctly and ensure the From domain aligns with your authenticated domain. This is not a dead-address bounce, so do not suppress the recipient.
A 4xx code is a transient (temporary) failure, meaning the sending server should retry automatically because the problem may resolve. A 5xx code is a permanent failure, meaning the server should not retry. 4xx codes are soft bounces; 5xx codes are hard bounces. However, some 5xx codes in the 5.7.x range are policy blocks rather than dead addresses and can be fixed.
Enhanced status codes are a more detailed companion to the basic three-digit SMTP code, defined in RFC 3463. They use the format class.subject.detail (for example 5.1.1), where the class matches the basic code, the subject categorizes the problem type, and the detail specifies the exact issue. They let you distinguish, for example, a nonexistent mailbox (5.1.1) from a spam block (5.7.1) when both return a basic 550.
Generally no. A 5.7.x code indicates a security or policy rejection, such as failed authentication, a reputation block, or a missing PTR record, not a dead address. Suppressing these recipients removes valid addresses over a problem you can fix on your side. Diagnose the underlying issue, fix your authentication or configuration, and the same addresses will accept mail. Only suppress 5.1.x and 5.2.x permanent failures.
Some providers, notably Google Workspace and Microsoft 365, accept all recipients with a 250 or 252 response at connection time and then bounce undeliverable messages afterward. This means a positive SMTP response does not confirm the mailbox exists. The actual delivery failure arrives as a separate asynchronous bounce, which is why email verification tools classify these providers as ambiguous.