Why Bounce Handling Is a Shared Responsibility: MTA and Application

• March 2022
• Engineering Memo · External Release

Bounce handling in email infrastructure is typically discussed as though it belongs to a single layer — either the MTA or the sending application. In production systems, it is a shared responsibility, and failures occur specifically at the handoff between the two.

The MTA receives SMTP-level bounce signals: 5XX permanent failures, 4XX temporary deferrals, and complex multi-line responses that require classification. The MTA's job is to classify these signals, retry appropriately, and — when classification indicates a permanent failure — report the bounce back to the sending application so that the address can be suppressed.

The sending application's job is to receive that suppression signal and act on it: remove the address from active lists, write it to the global suppression list, and ensure it does not re-enter any future campaign. This seems straightforward. In practice, it breaks in predictable ways.

The Common Failure Modes

The MTA classifies correctly, the application doesn't read the signal. PowerMTA's accounting log records every bounce with a disposition code and response message. If the sending application only reads from the MailWizz bounce server — an IMAP-based system that receives bounced message copies — and the bounce server is misconfigured or delayed, hard bounces accumulate in the accounting log but never reach the suppression list. The result: hard-bounced addresses receive the next campaign. ISPs see repeated sends to invalid addresses. Bounce rate at the ISP level rises.

Soft bounce promotion logic is absent or wrong. A 4XX response is a soft bounce — temporary. If an address returns a soft bounce across multiple campaigns over multiple weeks, it is functionally invalid: the mailbox may be abandoned, over quota permanently, or the domain may have expired. Without soft-bounce-to-hard-bounce promotion logic, these addresses stay on the active list indefinitely, consuming sending capacity and accumulating deferral records that increase queue depth.

Bounce classification is done at the wrong layer. Some applications attempt to classify bounces from the bounce message text delivered via IMAP rather than from the MTA's SMTP-layer classification. Text-based classification is less reliable — ISPs change their response messages, regional providers use non-standard text, and the message content does not always match the SMTP response code semantics.

The Correct Architecture

In a correctly functioning PowerMTA + MailWizz environment: PowerMTA classifies bounces at the SMTP layer and writes accounting log entries with disposition codes. MailWizz's bounce server processes the IMAP queue from the dedicated bounce address (bounce@yourdomain.com) and matches returned messages to campaign recipients. Both systems write to the MailWizz global blacklist — which suppresses the address from all future campaigns, not just the one that triggered the bounce. Soft bounces are promoted to hard status after a configurable number of failures across a configurable time window (typical: 3 failures over 30 days).

The monitoring requirement: run daily checks on bounce server queue depth (a growing queue indicates the IMAP connection is failing), on the accounting log undeliverable rate by ISP (trend analysis reveals ISP-specific patterns), and on the global blacklist growth rate (a sudden spike indicates a bad list segment entering the programme). Without active monitoring of both layers, bounce handling failures are invisible until they cause delivery incidents.