Contents
- Why bounce code analysis matters
- The first digit: soft versus hard
- RFC 3463 enhanced status codes
- The 452 family: soft bounces
- The 550 family: hard bounces
- The 550 5.7.1 misdiagnosis trap
- Authentication enforcement codes
- Gmail paired-code escalation
- Greylisting and false soft bounces
- Suppression decision rules
- Reading bounce patterns in accounting
Why bounce code analysis matters
Bounce codes are the receiving environment telling you exactly what happened to a message, and reading them correctly is one of the most consequential skills in email operations. Misread a bounce code and the consequences cascade: suppress an address that should have been retried and you lose a valid recipient; retry an address that should have been suppressed and you waste resources and accumulate bounce rate; treat a sender-side reputation problem as a recipient-side address problem and the root cause stays unaddressed while the symptom recurs campaign after campaign.
PowerMTA records bounce information in the accounting log: the SMTP status code, the enhanced status code, and the human-readable diagnostic text from the receiving server. An operator who can read these accurately diagnoses delivery problems fast; an operator who cannot misclassifies bounces and makes the underlying problems worse.
This guide focuses on 452 and 550 because they are the two codes operators see most and the two most consequential to read correctly. 452 is the archetypal soft bounce; 550 is the archetypal hard bounce; and the variation within the 550 family is exactly where the most expensive misdiagnoses happen. The structure: the first-digit classification, the RFC 3463 enhanced status code system, the 452 family in detail, the 550 family in detail, the specific 550 5.7.1 misdiagnosis trap, the authentication enforcement codes, the Gmail paired-code escalation pattern, greylisting, the suppression decision rules, and the diagnostic workflow for reading bounce patterns from PowerMTA accounting.
The first digit: soft versus hard
The first digit of the three-digit SMTP status code is the critical classifier.
| First digit | Class | Meaning | Default action |
|---|---|---|---|
| 2xx | Success | Message accepted | None, delivered |
| 3xx | Intermediate | Continue the dialogue | Protocol continues |
| 4xx | Transient failure (soft bounce) | Try again later | Retry |
| 5xx | Permanent failure (hard bounce) | This will not work | Action required |
A 4xx code is a soft bounce: the receiving server is saying "not now, try again later", the condition may resolve without any change to the address, and the correct response is to retry. A 5xx code is a hard bounce: the receiving server is saying "this will not work", the condition will not resolve on retry, and the correct response is action, though the specific action depends on the variant.
This first-digit classification is consistent across all receiving systems: Gmail, Outlook, Yahoo, corporate mail servers, security gateways like Barracuda, Mimecast, and Proofpoint. They all follow the same framework, so the first digit always tells you permanent versus temporary.
PowerMTA respects this classification by default: 4xx responses get retried per the retry directives, 5xx responses get bounced. The codes 452 and 550 sit on opposite sides of this divide, which is why they make the clearest teaching examples.
RFC 3463 enhanced status codes
Most modern mail servers supplement the three-digit code with an enhanced status code in the format X.Y.Z, defined in RFC 3463. The enhanced code provides far more specific failure information than the basic three-digit code alone.
The structure is class.subject.detail:
| Position | Meaning | Common values |
|---|---|---|
| X (class) | Aligns with the SMTP first digit | 2 success, 4 transient, 5 permanent |
| Y (subject) | The category of the problem | 1 addressing, 2 mailbox, 7 security/policy |
| Z (detail) | The specific detail | Provider-specific specifics |
The subject digit (Y) is the most diagnostically useful: X.1 means an addressing problem (the address itself), X.2 means a mailbox problem (the mailbox state), X.7 means a security or policy problem (the sender's reputation or authentication). This single digit frequently tells you whether a bounce is a recipient-side problem or a sender-side problem.
For example, a server returning "550 5.1.1" provides both the SMTP code (550, permanent rejection) and the enhanced code (5.1.1, where 5 is permanent, 1 is addressing, 1 is the specific detail bad destination mailbox address). The enhanced code tells you the specific email address does not exist on that domain. A server returning "550 5.7.1" provides 550 (permanent) plus 5.7.1 (5 permanent, 7 security/policy, 1 delivery not authorized), which is an entirely different problem despite the identical 550 base code.
Reading the enhanced status code is what separates accurate bounce handling from the crude approach of treating all 550 codes identically.
The 452 family: soft bounces
452 is a 4xx code, a soft bounce. The base meaning is insufficient system storage.
| Code | Meaning | Type | Action |
|---|---|---|---|
| 452 4.2.2 | Mailbox over quota (full) | Soft | Retry ~72h, suppress after 3-5 repeats |
| 452 (generic) | Insufficient system storage | Soft | Retry, server-side storage issue |
| 421 | Service unavailable | Soft | Retry in 30-60 min |
| 450 4.7.1 | Greylisting or temp block | Soft | Retry, resolves quickly (see below) |
| 451 4.7.1 | Local processing error / temp block | Soft | Retry, server-side |
The most common 452 is 452 4.2.2, mailbox over quota. Gmail phrases this as "over quota". The recipient's inbox hit its storage limit. This is a genuine soft bounce the first time, the recipient may simply have a full inbox they will clear.
The substantive nuance with 452 4.2.2: a single occurrence is genuinely temporary, but a pattern of 452 to the same address across multiple separate campaigns indicates an abandoned account. A mailbox that stays full across many days belongs to someone no longer checking that email. The handling rule: retry a single 452 over roughly 72 hours, but if the same address returns 452 across 3 to 5 separate sends, suppress it as effectively dead.
A specific 451 quirk worth noting: Apple's servers sometimes return 451 4.7.1 service unavailable during inbound load spikes. This trips up operators who mistake it for a permanent block; it is a soft bounce that resolves on retry, not a reputation problem.
The 550 family: hard bounces
550 is a 5xx code, a hard bounce. But the 550 family contains fundamentally different problems behind the same base code, and the enhanced status code is what distinguishes them.
| Code | Meaning | Real problem | Action |
|---|---|---|---|
| 550 5.1.1 | Address does not exist | Recipient-side: bad address | Suppress immediately |
| 550 5.7.1 | Policy / reputation block | Sender-side: reputation | Investigate, do NOT suppress |
| 550 5.7.26 | Unauthenticated mail | Sender-side: authentication | Fix authentication |
| 550 5.7.515 | Missing SPF/DKIM/DMARC | Sender-side: authentication | Fix authentication |
| 551 | User not local | Recipient-side: address moved | Update address |
| 552 | Storage exceeded / quota | Mixed: message size or mailbox | Retry, suppress if persistent |
| 553 | Mailbox name invalid | Recipient-side: bad format | Suppress, fix format |
| 554 5.7.x | Transaction failed / policy rejection | Sender-side: content or auth | Fix content/auth |
The critical observation: the 550 family splits into recipient-side problems and sender-side problems. 550 5.1.1 (address does not exist) and 553 (mailbox name invalid) are recipient-side: the address itself is the problem, and suppression is correct. 550 5.7.1 (policy block), 550 5.7.26 (unauthenticated), 550 5.7.515 (missing authentication), and 554 5.7.x (policy rejection) are sender-side: the address is fine, the sender's reputation or authentication or content is the problem, and suppression accomplishes nothing.
The X.7 subject digit is the tell. Any 550 with a 5.7.x enhanced code is a security or policy problem, which is almost always sender-side. Any 550 with a 5.1.x enhanced code is an addressing problem, which is recipient-side.
The 550 5.7.1 misdiagnosis trap
The single most common bounce-handling mistake is treating 550 5.7.1 as an address problem and suppressing the recipient.
550 5.7.1 means delivery not authorized, message refused. The 5.7 portion is the security/policy class. The receiving server is refusing the message because of the sender's reputation, an authentication failure, a policy block, or a blacklist listing. The recipient address almost certainly exists and is perfectly valid.
Suppressing the recipient on a 550 5.7.1 bounce does nothing to fix the actual problem because the address was never the problem. Worse, it actively harms the operation: the list shrinks while the underlying reputation or authentication problem stays unaddressed, so the next campaign hits exactly the same wall, generates more 5.7.1 bounces, and suppresses more valid recipients. The operator ends up with a smaller list and an unsolved problem.
When you see 550 5.7.1 in PowerMTA accounting, do not suppress the recipient. The 5.7 enhanced class means security/policy, which is a sender-side problem. The correct response is sender-side investigation: check whether the sending IP is on a blacklist, verify SPF, DKIM, and DMARC alignment, review sending reputation at the relevant postmaster tools, examine whether content is triggering policy filters. A cluster of 550 5.7.1 codes, especially concentrated on one campaign or one receiving domain, is a clear signal of a systematic sender-side problem. Treating it as list hygiene leaves the root cause unsolved.
The correct response to 550 5.7.1: investigate the sender side. Is the sending IP blacklisted? Is authentication aligned? Is the reputation degraded at this receiver? Is the content triggering filters? The answer to one of those questions is the actual problem, and fixing it resolves the 5.7.1 bounces. List cleaning does not.
Authentication enforcement codes
Since 2024, Gmail, Microsoft, and Yahoo introduced specific enforcement codes to reject messages from senders who do not meet bulk sender requirements. These are 5.7.x codes, sender-side problems.
| Code | Meaning | Fix |
|---|---|---|
| 550 5.7.26 | Unauthenticated mail (Gmail) | Add proper SPF/DKIM authentication |
| 550 5.7.515 | Missing SPF/DKIM/DMARC | Implement all three authentication mechanisms |
| 554 5.7.x | Policy rejection | Fix content and authentication |
| 553 / 554 (auth) | DMARC/DKIM failure | Fix SPF/DKIM/DMARC alignment |
When 550 5.7.26 appears in PowerMTA accounting, the 26 detail (Gmail uses this for unauthenticated mail) tells you the sending domain is not properly authenticated. When 550 5.7.515 appears, it indicates missing SPF, DKIM, or DMARC. These are not address problems; they are configuration problems with the sending setup, and the fix is implementing the missing authentication.
These codes became substantially more common after the Gmail and Yahoo bulk sender requirements took effect in February 2024. An operator who sees a sudden cluster of 5.7.26 or 5.7.515 codes is almost certainly hitting the bulk sender authentication enforcement, and the fix is authentication, not list cleaning.
Gmail paired-code escalation
Gmail's bulk sender enforcement introduced a paired-code pattern that operators must recognize. The same compliance issue appears first as a 421 temporary warning and escalates to a 550 permanent rejection if it is not fixed.
The escalation pattern:
- A compliance problem (authentication, reputation, complaint rate) first surfaces as a 421 temporary deferral. PowerMTA retries it as a normal soft bounce.
- If the underlying problem is not fixed, Gmail escalates: the same problem starts returning as a 550 permanent rejection.
- At the 550 stage, messages hard-bounce and the operator has lost the grace period the 421 warning represented.
The operational lesson: a cluster of 421 codes from Gmail is a warning, not a routine soft bounce. It is Gmail saying "fix this before we escalate". An operator who treats Gmail 421 deferrals as normal soft bounces and just lets PowerMTA retry them is missing the warning, and the escalation to 550 follows. When Gmail 421 codes appear in a pattern, investigate the cause (authentication, reputation, complaints) during the 421 grace period rather than waiting for the 550 escalation.
Greylisting and false soft bounces
Greylisting is a specific soft-bounce pattern that should not be counted toward soft-bounce thresholds.
450 4.7.1 greylisting is a deliberate temporary rejection: the receiving server rejects the first delivery attempt from an unfamiliar sender, expecting a legitimate sender to retry (spammers frequently do not). Greylisting typically resolves on the first retry after a few minutes.
The handling nuance: greylisting 450 4.7.1 is a normal, expected soft bounce that resolves immediately on retry. It should not count toward an address's soft-bounce threshold, because it is not an indication of any problem with the address or the sender. An operator whose bounce handling counts greylisting retries toward a soft-bounce-suppression threshold will incorrectly suppress valid addresses that simply went through normal greylisting.
PowerMTA's retry handling naturally retries greylisting and the message delivers on the second attempt. The thing to get right is the accounting: do not let a greylisting 450 contribute to a decision to suppress an address, because greylisting is not a problem, it is normal receiving-server behavior.
Suppression decision rules
Pulling the analysis together into clear suppression decision rules:
| Code | Suppress? | Reasoning |
|---|---|---|
| 452 4.2.2 (single) | No | Retry, mailbox temporarily full |
| 452 4.2.2 (3-5 repeats) | Yes | Persistently full = abandoned account |
| 421 (single) | No | Retry, server temporarily unavailable |
| 421 Gmail (pattern) | No, investigate | Compliance warning before escalation |
| 450 4.7.1 (greylisting) | No | Normal, resolves on retry, do not count |
| 550 5.1.1 | Yes, immediately | Address does not exist |
| 550 5.7.1 | No, investigate sender side | Reputation/policy problem, not address |
| 550 5.7.26 | No, fix authentication | Unauthenticated mail, sender config |
| 550 5.7.515 | No, fix authentication | Missing SPF/DKIM/DMARC |
| 551 | Update address | User not local, address moved |
| 552 | Retry, suppress if persistent | Storage or message size |
| 553 | Yes | Invalid mailbox name format |
| 554 5.7.x | No, fix content/auth | Policy rejection, sender side |
The pattern across the rules: suppress recipient-side problems (5.1.1, 553, persistent 452, 551 after address update fails), investigate sender-side problems (any 5.7.x, Gmail 421 patterns), retry genuine transient conditions (single 452, single 421, greylisting). The enhanced status code, specifically the X.7 versus X.1 distinction, is the key to applying these rules correctly.
Reading bounce patterns in accounting
PowerMTA accounting records bounce details in the dsnStatus (enhanced status code) and dsnDiag (diagnostic text) fields. The diagnostic queries for bounce analysis:
Bounce code distribution. What codes are appearing and how often:
SELECT
dsnStatus,
count() AS occurrences
FROM pmta_accounting
WHERE type = 'b'
AND timeLogged >= now() - INTERVAL 7 DAY
GROUP BY dsnStatus
ORDER BY occurrences DESC;Sender-side problem detection. Looking specifically for 5.7.x codes that indicate sender-side problems:
SELECT
dsnStatus,
rcptDomain,
count() AS occurrences
FROM pmta_accounting
WHERE type = 'b'
AND dsnStatus LIKE '5.7.%'
AND timeLogged >= now() - INTERVAL 7 DAY
GROUP BY dsnStatus, rcptDomain
ORDER BY occurrences DESC;A cluster of 5.7.x codes concentrated on one receiving domain points to a reputation or authentication problem with that specific receiver. A cluster spread across many receivers points to a broader sender-side problem (blacklisting, authentication misconfiguration).
Repeated 452 detection. Finding addresses that return 452 across multiple sends, candidates for suppression:
SELECT
rcpt,
count() AS bounce_452_count
FROM pmta_accounting
WHERE dsnStatus = '4.2.2'
AND timeLogged >= now() - INTERVAL 30 DAY
GROUP BY rcpt
HAVING bounce_452_count >= 3
ORDER BY bounce_452_count DESC;The interpretation framework. When analyzing bounce patterns:
- Clusters of the same code point to systematic issues, not random recipient problems.
- 5.1.x codes concentrated anywhere mean address quality problems, clean the list.
- 5.7.x codes concentrated on one campaign mean that campaign's content triggered filters.
- 5.7.x codes concentrated on one receiver mean a reputation problem with that receiver.
- 5.7.x codes spread broadly mean an authentication or blacklisting problem affecting everything.
- 452 codes concentrated on the same addresses across time mean abandoned accounts, suppress them.
- Gmail 421 codes in a pattern mean a compliance warning, investigate before the 550 escalation.
An operator we worked with had a steadily shrinking list and could not understand why. Their bounce handling was aggressive: any 550 triggered immediate suppression of the recipient. Accounting analysis revealed the problem. A large fraction of their 550 bounces were 550 5.7.1, and their bounce handler was suppressing every one of them as if the address were invalid. But 5.7.1 is a policy/reputation problem, not an address problem. The actual root cause was a DKIM alignment issue: their sending domain's DKIM was misconfigured, a subset of receivers rejected the unaligned mail with 550 5.7.1, and the bounce handler suppressed all those perfectly valid recipients. Over several months, they had suppressed thousands of real, valid addresses, each one a recipient who never had anything wrong with their address. The fix had two parts: correct the DKIM alignment (which stopped the 5.7.1 bounces at the source), and reconfigure the bounce handler to distinguish 5.1.x address problems (suppress) from 5.7.x policy problems (investigate, do not suppress). The wrongly-suppressed addresses had to be carefully reviewed and reinstated. The lesson: a bounce handler that treats all 550 codes identically does not clean a list, it destroys one. The enhanced status code distinction between 5.1.x and 5.7.x is not academic, it is the difference between hygiene and self-harm.
Bounce code analysis is a foundational email operations skill, and the 452-versus-550 contrast is the clearest entry point. The first digit classifies soft versus hard. The enhanced status code, particularly the X.7-versus-X.1 subject digit, classifies sender-side versus recipient-side. Get both right and bounce handling becomes accurate: retry genuine transient failures, suppress genuine address problems, investigate genuine sender-side problems. Get them wrong and the consequences compound: valid recipients suppressed, root causes unaddressed, lists shrinking while the real problems recur. PowerMTA gives you the raw bounce data in the accounting log; the skill is reading it correctly, and that skill rests on understanding that not all 550 codes are the same problem and that the enhanced status code is the key to telling them apart.