guide · email bounce back
How should a product team diagnose and handle email bounce-backs safely?
Treat an email bounce-back as delivery evidence tied to one recipient and attempt, not as a generic failed flag. Preserve the original message identifier, envelope sender, recipient, SMTP or enhanced status code, diagnostic, reporting server, and event time. Separate an immediate SMTP rejection from a later delivery-status notification. Retry only temporary 4.x outcomes with bounded backoff and queue-age limits; stop and suppress recipient-scoped retries after a confirmed permanent 5.x failure. Authenticate provider events, deduplicate them, avoid generating backscatter, and keep provider acceptance, destination-server acceptance, later nondelivery, and inbox placement as separate states.
Identify where the failure was observed
A product can learn about nondelivery during the live SMTP transaction, through a later delivery-status notification, or through an authenticated provider event. These observations have different evidence. An immediate RCPT TO refusal applies to that recipient before message data is accepted. A DATA-stage rejection can apply to the submitted transaction. A later DSN reports that a system accepted responsibility and subsequently could not deliver or relay the message. Record the stage, server, recipient scope, attempt, timestamp, SMTP reply, enhanced status code, diagnostic, and original correlation identifiers. Do not collapse every case into bounced. Keep the raw provider payload or standards-form DSN only as long as operational and policy needs require, with restricted access. A support screenshot or human paraphrase is not sufficient evidence for automated retries, suppression, or customer-facing status.
Separate temporary and permanent outcomes
SMTP uses 4yz replies for transient negative completion and 5yz replies for permanent negative completion. Enhanced status codes add a class beginning with 4 for persistent transient failure or 5 for permanent failure, followed by subject and detail values. Preserve both basic and enhanced codes because the text alone is provider-specific and can change. A temporary result can justify retrying the same logical message after delay; it does not justify immediate loops or unlimited queue residence. A permanent recipient failure should stop automatic replay for that recipient and attempt until the address or policy changes through an authorized process. Do not infer hard or soft solely from informal provider labels. Build policy from the exact status, stage, diagnostic, message class, recipient, and current provider documentation. Unknown or malformed responses should fail closed into review or dead-letter handling rather than defaulting to resend.
Parse delivery-status notifications defensively
RFC 3464 defines a machine-readable delivery-status notification format carried in multipart/report with message/delivery-status fields. Useful fields can include Reporting-MTA, Final-Recipient, Action, Status, Remote-MTA, Diagnostic-Code, and arrival or last-attempt times. Treat every field as untrusted input even when the MIME structure parses. Bound message size, header count, part count, nesting, character decoding, and stored diagnostic length. Never execute attachments, follow diagnostic links automatically, or accept a recipient address as tenant identity. Correlate with an application-owned attempt using a stable provider message identifier, original envelope metadata, or a privacy-safe correlation header. A DSN can contain portions of the original message and recipient data, so restrict logs and retention. If correlation is ambiguous, preserve the evidence without suppressing an unrelated address or revealing another tenant's message history.
Model recipient-level state transitions
One message can target several recipients and receive different outcomes. Store status per recipient and attempt, not only on the message row. A provider can accept some RCPT commands and refuse others, or later report delivery for one recipient and failure for another. Define monotonic transitions so a delayed accepted or deferred event cannot overwrite a later confirmed permanent failure, complaint, or unsubscribe. Preserve the event ledger and derive the current display state through explicit precedence rules. Separate submitted, provider accepted, recipient server accepted, temporarily deferred, permanently failed, suppressed, complained, unsubscribed, and unknown. A destination-server acceptance still does not reveal final mailbox folder or human reading. Make retries create linked attempts under the same logical event key so duplicate risk and evidence remain visible. Do not mark a planned retry as a new customer action.
Retry transient failures with strict bounds
For eligible transient outcomes, schedule exponential backoff with jitter, a finite attempt count, and a maximum queue age. Use the provider's documented retry behavior and do not layer an aggressive application loop on top of an already retrying relay. Keep the same logical message identity and suppression check for every attempt. Stop retrying when the recipient becomes suppressed, consent changes, the event expires, the sender identity is revoked, or a later permanent response arrives. Rate-limit by tenant, destination domain, sender, and failure class so one receiver outage cannot monopolize the queue. Respect Retry-After or documented deferral guidance when present, but never trust arbitrary message content as retry instructions. Alert on rising queue age, repeated temporary codes, unusual domains, and attempts nearing expiry. A transient code can mask a persistent policy or reputation issue; bounded retries buy time for recovery, not permission to ignore the cause.
Suppress confirmed permanent recipient failures
A confirmed permanent address or mailbox failure should update a product-owned suppression record before any later job is submitted. Store tenant, normalized recipient key, scope, source event, status and diagnostic category, effective time, and evidence reference without exposing the address broadly. Apply suppression at send time, not only during list import. Differentiate invalid address, nonexistent domain, policy rejection, message-content rejection, authentication failure, quota, and sender reputation because their safe remedies differ. An invalid recipient supports recipient-scoped suppression; a sender authentication rejection should pause the sender configuration rather than suppress every recipient. Protect manual removal with strong authorization, a reason, and audit history. Reconfirmation or correction must create a new verified decision, not delete the old evidence. Provider suppression lists are useful but do not replace an application consent and safety ledger, especially during provider migration.
Avoid bounce loops and backscatter
SMTP uses a null reverse path for delivery-status notifications so a failure while delivering the notification does not generate another bounce. Preserve this behavior in relays and do not send automatic replies to DSNs, auto-responses, or messages with signals that indicate automated generation. RFC 3834 provides recommendations for automatic email responses, including loop and amplification concerns. Never generate a bounce to an unverified visible From address after accepting a suspicious message, because forged sender identities can turn the system into a backscatter source. Reject invalid recipients during SMTP where possible instead of accepting and later notifying a forged address. Bound automatic responses per sender and conversation, and use controlled reply identities. A product webhook or internal error event is often safer than generating new Internet mail. Test forged From, null envelope sender, repeated DSN, auto-submitted headers, mailing-list traffic, and malformed reports in isolated fixtures.
Authenticate provider events before applying them
If a provider delivers bounce events through webhooks, validate the documented signature or authentication mechanism over the exact request before parsing business fields. Enforce timestamp freshness, replay protection, body-size limits, and tenant correlation. Persist or enqueue the authenticated event before returning success, then deduplicate on a stable provider event identifier or a conservative composite that cannot merge recipients or attempts. Store occurrence time separately from processing time because events can be delayed and out of order. Reject events whose sender domain, account, workspace, message identifier, or recipient scope cannot be linked to the expected tenant. Rotate webhook secrets separately from SMTP or API credentials. Monitor signature failures, duplicate rates, lag, dead letters, and unknown event types. An authenticated webhook proves origin under the configured secret; it does not prove the event was mapped to the correct internal job until correlation succeeds.
Diagnose by status family, not by guessed wording
Start with the enhanced status subject: address status, mailbox status, mail system status, network or routing status, mail delivery protocol status, message content or media status, or security and policy status. Then use the detail code and full diagnostic with the current receiver or provider documentation. Verify recipient syntax and domain DNS for address failures; mailbox existence and quota evidence for mailbox failures; MX, routing, TLS, and network evidence for transport failures; size, MIME, encoding, and content for message failures; and SPF, DKIM, DMARC, credentials, sender policy, or reputation for security failures. Change one variable per controlled retest. Do not rotate IPs, domains, or providers to evade a permanent policy decision. Preserve the original response and rollback any configuration change that broadens sender authority or weakens authentication without correcting the observed cause.
Measure bounce health without leaking recipient data
Track first-attempt acceptance, temporary deferral, permanent failure, retry recovery, unknown outcome, complaint, suppression, and queue age by privacy-safe cohort. Useful dimensions include sender domain, destination domain at an approved aggregation level, message class, template revision, provider, status family, and time. Avoid full addresses, message content, diagnostic blobs, or raw headers in routine analytics. Separate invalid-recipient rate from policy, authentication, content, reputation, and transient infrastructure failures; a single bounce rate hides actionable causes. Use denominators based on recipient attempts and report late events against their original cohort. Set alerts from historical baselines and business risk, not one universal percentage. Audit suppression application and manual overrides. Retain only the evidence needed for operations, security, legal obligations, and disputes, then delete or aggregate it. A low bounce rate does not prove consent, engagement, or inbox placement.
How SendHQ fits
SendHQ documents delivery and bounce tracking and suppressions. See the current documentation for its supported behavior.
Frequently asked questions
What is an email bounce-back?
It is evidence that an SMTP recipient or later delivery attempt failed or was deferred, reported during SMTP, through a DSN, or through a provider event.
What is the difference between a 4xx and 5xx bounce?
A 4xx reply is transient and may justify bounded retry. A 5xx reply is permanent for that attempt and normally requires correction or suppression.
Should every bounced address be suppressed?
No. Suppress confirmed permanent recipient failures. Sender authentication, content, reputation, quota, or temporary infrastructure failures require different scoped remedies. Apply the remedy to the observed cause and recipient scope.
Can one message partially bounce?
Yes. SMTP can accept some recipients and refuse others, and later DSNs can report different outcomes per recipient. Store recipient-level state.
How should transient bounces be retried?
Use the same durable logical job with exponential backoff, jitter, attempt and queue-age caps, and a fresh suppression check before every attempt.
Does an SMTP 250 response prevent a later bounce?
No. A server can accept responsibility and later generate nondelivery evidence. Destination acceptance also does not establish inbox placement or human engagement.
Why should bounce messages use a null reverse path?
A null reverse path prevents failures while delivering a DSN from generating another DSN, which avoids bounce loops and amplification.
Does SendHQ handle bounces?
Yes. SendHQ documents delivery and bounce tracking and suppressions.