Bounce processing

Turning delivery failures into actions: retry temporary problems, suppress dead addresses, and investigate policy or reputation blocks.

what to do when an email comes backhandling failed email deliverieswhat do i do with all these mailer daemon repliesbounse processingstop sending to dead addressessorting temporary and permanent email failuresreturned mail handlingshould i delete an address after one bounce

See it

Live demo coming soon

What it is

Bounce processing turns a provider's delivery-failure event into a decision. It records the recipient, provider message ID, SMTP reply, enhanced status code, and whether the failure is temporary, a dead recipient, or a sender-side policy problem. A confirmed permanent recipient failure such as '5.1.1 user unknown' goes onto the suppression list; a temporary 4xx stays eligible for retry.

Run it from signed delivery webhooks as soon as mail matters to your product. Classification belongs in one shared pipeline so a campaign tool, a transactional sender, and a backup provider cannot develop three different answers to the same rejection. Store the raw event beside the normalized class so you can repair old decisions when a provider changes its event vocabulary.

The trap is equating every 5xx reply with a dead address. SMTP 5xx means the current transaction failed permanently, but '5.7.1 rejected for policy' says something about your authentication, content, or reputation, not that the mailbox vanished. Suppressing that recipient hides the real outage. Webhooks can also arrive twice or out of order, so processing must be idempotent and a later duplicate must not undo a final state.

Ask AI for it

Implement bounce processing for Amazon SES event notifications delivered through Amazon SNS. Verify the SNS message, persist the raw event once by provider message ID plus recipient, and normalize the SES bounceType, bounceSubType, status, action, and diagnosticCode into temporary, permanent-recipient, or sender-policy classes. Use RFC 3463 enhanced status codes as evidence: suppress confirmed 5.1.x recipient failures, keep temporary failures retryable, and alert on 5.7.x policy or authentication failures without suppressing the address. Make the handler idempotent under duplicate and out-of-order SNS delivery, keep the unmodified payload for reclassification, and add tests for user unknown, mailbox full, throttling, and policy rejection events.

You might have meant

hard bouncesoft bouncesuppression listemail delivery event webhooksbounce rate

Go deeper