RETRY DECISION
Do not repeat unchanged
Do not repeat the exact SMTP request unchanged. Correct the address, sender identity, authentication, content, size, or policy cause before a deliberate new attempt.
All tools
DELIVERABILITY TOOL / 05SMTP bounce
SMTP bounce
code decoder
Paste a receiving-server response. Separate recipient failures from sender, authentication, message, policy, and infrastructure problems before acting.
- RFC-aware parsing
- Safe retry guidance
- No response stored
Paste the SMTP response
TRY AN EXAMPLE
Decoding happens locally. Paste the response—not an entire customer record or message body—and remove addresses or identifiers you do not need.
PERMANENT SMTP FAILURE
Bad destination mailbox address
The destination mailbox address does not exist or cannot accept mail as addressed. The exact request should not be repeated until the cause is reviewed or corrected.
highconfidence
SMTP reply550
Enhanced status5.1.1
Likely scoperecipient
Recommended actionSuppress recipient
SUPPRESSION DECISION
Suppress this address
The response is a permanent destination-mailbox failure. Suppress this address from future sends while retaining the exact evidence and timestamp.
NEXT SAFE ACTIONS
A runbook, not a guess.
- 01
Preserve the exact response, timestamp, receiving host, SMTP stage, message ID, recipient domain, sending domain, IP, and provider event ID.
- 02
Suppress this destination address across every stream that shares the same recipient identity.
- 03
Trace the address to its acquisition or product source; correct upstream forms, imports, or account data if the pattern repeats.
HOW THE CODE READS
Class, subject, detail.
Permanent failure
Address status
Bad destination mailbox address
Signals detected in the response
No specific text signal
Incident note
SMTP bounce analysis Classification: Permanent SMTP failure SMTP reply: 550 Enhanced status: 5.1.1 Likely scope: recipient Recommended action: Suppress recipient Confidence: high SMTP stage: RCPT TO Message stream: marketing Interpretation: The destination mailbox address does not exist or cannot accept mail as addressed. The exact request should not be repeated until the cause is reviewed or corrected. Retry: Do not repeat the exact SMTP request unchanged. Correct the address, sender identity, authentication, content, size, or policy cause before a deliberate new attempt. Suppression: The response is a permanent destination-mailbox failure. Suppress this address from future sends while retaining the exact evidence and timestamp. Next actions: 1. Preserve the exact response, timestamp, receiving host, SMTP stage, message ID, recipient domain, sending domain, IP, and provider event ID. 2. Suppress this destination address across every stream that shares the same recipient identity. 3. Trace the address to its acquisition or product source; correct upstream forms, imports, or account data if the pattern repeats. Raw response: 550 5.1.1 The email account that you tried to reach does not exist.
Do not let a generic “hard bounce” label erase the scope.
A permanent sender-authentication, content, or reputation rejection is not proof that the recipient address is invalid. Suppressing the recipient hides the sending incident and loses a potentially valid customer.
CLASSIFY BEFORE SUPPRESSING
Only recipient-invalid evidence belongs on the recipient.
An explicit permanent unknown-mailbox response such as 5.1.1 is strong suppression evidence. A 5.7.x authentication or policy rejection, a message-too-large response, or a sender-reputation block describes the sender, content, stream, or infrastructure—not the address.
550 5.1.1Destination mailbox does not existSuppress recipient
550 5.7.26Authentication checks failedFix sender
552 5.3.4Message exceeds receiving-system limitFix message
421 4.7.0Temporary policy or reputation deferralQueue + investigate
ONE DELIVERY OWNER
Do not turn a deferral into duplicate email.
The transport queue should own retries for an accepted application request. If the application sends a second message while the provider is still retrying the first, both may eventually arrive. Preserve a stable message identifier, expose provider state, and let one system decide when the attempt is terminal.
Retry the delivery attempt, not the business event. A delayed receipt or password-reset message should not be recreated as a second logical message.
COMMON QUESTIONS
Before you automate the response.
Is every 5xx response a hard bounce?+
Many platforms use hard bounce as a broad label for permanent SMTP failure, but the scope still matters. A permanent authentication, sender-policy, or message-content failure is not evidence that the recipient address is invalid.
Should I retry a 4xx response immediately?+
No. Let the sending MTA or provider queue own retries with backoff and jitter. Immediate application resends can amplify rate limits, damage reputation, or create duplicates.
Can I trust the human-readable response text?+
Preserve and read it, but prioritize structured reply codes. Server text varies by provider and context. The three-digit class determines the broad SMTP action, while a registered enhanced status code gives more portable detail.
What if the classic and enhanced codes disagree?+
Treat the response as malformed or ambiguous. Preserve the exact line, SMTP stage, timestamp, receiving host, sending identity, and provider event; avoid irreversible suppression until the inconsistency is understood.
When should a mailbox-full response suppress a contact?+
Not after the first response. Mailbox full is normally a persistent transient condition. Follow the provider's controlled retry and expiration policy, then decide whether long-term repeated failures justify moving the address out of regular sends.
KEEP THE RAW SIGNAL
See every delivery event in context.
Send campaigns and product email with searchable activity, bounce detail, and customer history connected.
Start for free