Skip to content
Postfix Insights

Deferred vs bounced in Postfix: how to tell them apart

In the Postfix mail log, status=deferred signals a temporary failure that Postfix will retry. status=bounced signals a permanent failure that Postfix has given up on. The distinction matters: a rising defer rate is an early warning sign; a rising bounce rate is lost mail.

The key signal is the Enhanced Status Code (DSN) in the dsn= field. According to RFC 3463, the first digit of the code classifies the failure:

  • dsn=2.x.x: Success.
  • dsn=4.x.x: Persistent Transient Failure (temporary; Postfix will retry).
  • dsn=5.x.x: Permanent Failure (bounce; Postfix gives up).

This guide shows you how to read the two states from the log and why the distinction matters for monitoring.

2.x.x Success. Accepted by the receiving server. status=sent
4.x.x Transient failure. Stays queued; Postfix retries with backoff. status=deferred
5.x.x Permanent failure. Postfix gives up and sends a non-delivery report to the sender. status=bounced
The first digit of the dsn= enhanced status code (RFC 3463) determines the outcome.

Deferred: Transient failure, Postfix retries

Section titled “Deferred: Transient failure, Postfix retries”

When Postfix encounters a temporary problem sending to a recipient, it logs status=deferred with a dsn=4.x.x code. The message stays in the queue. Postfix will retry according to its retry schedule.

Example deferred log line (mailbox temporarily full):

Jun 17 10:22:33 mail postfix/smtp[12345]: E1234567890ABC: to=<user@example.org>, relay=mail.example.org[192.0.2.1]:25, delay=0.45, delays=0.01/0.02/0.15/0.27, dsn=4.2.2, status=deferred (450 4.2.2 Mailbox full, try again later)

The dsn=4.2.2 (mailbox full, transient) tells Postfix: “This might be temporary. Retry.” Postfix will try again in minutes, hours, or days depending on how long the message has been queued.

How long does Postfix keep retrying? Two parameters control queue lifetime:

  1. maximal_queue_lifetime (default: 5 days). A message that cannot be delivered within 5 days is bounced, regardless of the DSN code. This is a hard limit to prevent messages from sitting in the queue forever.

  2. bounce_queue_lifetime (default: 5 days). This controls how long Postfix retries sending a bounce notification (DSN email) back to the original sender if the bounce itself fails. It does not govern deferred messages; it governs the bounce notification retry.

So a message with status=deferred will keep trying for up to 5 days. If it is not delivered by then, Postfix bounces it and notifies the sender.

Bounced: Permanent failure, Postfix gives up

Section titled “Bounced: Permanent failure, Postfix gives up”

When the remote server explicitly rejects a message with a permanent error, Postfix logs status=bounced with a dsn=5.x.x code. Postfix immediately stops trying and notifies the sender of the failure.

Example bounced log line (user unknown):

Jun 17 10:22:33 mail postfix/smtp[12345]: F9876543210XYZ: to=<user@example.org>, relay=mail.example.org[192.0.2.1]:25, delay=0.45, delays=0.01/0.02/0.15/0.27, dsn=5.1.1, status=bounced (550 5.1.1 user unknown)

The dsn=5.1.1 (bad destination mailbox) tells Postfix: “This is permanent. Do not retry.” Postfix immediately generates a Delivery Status Notification (DSN, RFC 3464) and sends it back to the original sender with the reason for the bounce.

A DSN is a structured email message. It includes a human-readable part explaining the failure, plus a machine-readable part (multipart/report) with:

  • Final-Recipient: The address that bounced (e.g., rfc822; user@example.org).
  • Action: The outcome (e.g., failed).
  • Status: The Enhanced Status Code (e.g., 5.1.1).
  • Diagnostic-Code: The remote server’s SMTP code and text (e.g., smtp; 550 5.1.1 user unknown).
  • Returned headers: A copy of the original message’s top headers, so the sender can identify which message bounced.

The original sender receives the DSN and can see exactly why the delivery failed. The DSN is generated by your Postfix bounce daemon, not by the remote server.

The same code can be temporary or permanent

Section titled “The same code can be temporary or permanent”

The Enhanced Status Code is not always a strict classifier of the underlying problem. The receiving server decides whether an error is temporary or permanent. For example, 4.2.2 means “mailbox full, try again” (temporary), but some servers send 5.2.2 (“mailbox full, do not retry”) if the quota is permanently exhausted.

In the log, the prefix digit (first digit of the DSN code) tells you what Postfix will do:

  • First digit is 4: status=deferred. Temporary. Postfix retries.
  • First digit is 5: status=bounced. Permanent. Postfix gives up and sends a DSN to the sender.

The remote server’s decision is final. Your Postfix instance does not override it.

One message, mixed outcomes: partly deferred, partly bounced

Section titled “One message, mixed outcomes: partly deferred, partly bounced”

A single email can reach multiple recipients and produce different outcomes for each. One recipient address might succeed, another might defer, and a third might bounce, all from the same message. This happens because each recipient has a separate SMTP conversation with a potentially different mail server.

Here is a scenario. A message with queue ID G5678901234DEF is sent to two recipients in the same domain:

Jun 17 10:22:33 mail postfix/smtp[12345]: G5678901234DEF: to=<alice@example.org>, relay=mail.example.org[192.0.2.1]:25, delay=0.45, delays=0.01/0.02/0.15/0.27, dsn=4.4.2, status=deferred (connection timed out)
Jun 17 10:22:34 mail postfix/smtp[12345]: G5678901234DEF: to=<bob@example.org>, relay=mail.example.org[192.0.2.1]:25, delay=0.46, delays=0.01/0.02/0.16/0.27, dsn=5.1.1, status=bounced (550 5.1.1 user unknown)

In this example:

  • alice@example.org got dsn=4.4.2, status=deferred. The connection timed out (temporary). Postfix will retry this recipient later.
  • bob@example.org got dsn=5.1.1, status=bounced. The server says the user does not exist (permanent). Postfix stops trying and will send a bounce notification to the original sender about bob’s address.

Both log lines share the same queue ID (G5678901234DEF), but the outcomes are different. This is why log correlation by queue ID is essential for understanding what happened to a message. Postfix tracks recipient status independently; you cannot infer the outcome for bob from the outcome for alice.

Why this matters for monitoring

Section titled “Why this matters for monitoring”

Defer rate: A rising number of deferred messages suggests a systemic issue that may self-resolve (remote server overloaded, network flakiness, temporary policy block). These are often worth investigating but frequently recover without intervention. A monitoring tool should alert on a sustained high defer rate.

Bounce rate: A rising number of bounced messages indicates permanent problems: bad addresses, authentication failures, policy rejections. These do not recover. High bounce rates signal reputation issues, list hygiene problems, or configuration errors. A monitoring tool should alert aggressively on bounce rate spikes, as they indicate lost mail.

For more on log correlation and why it is hard, see Postfix log correlation.

Manual inspection: viewing deferred and bounced messages

Section titled “Manual inspection: viewing deferred and bounced messages”

If you want to inspect the queue manually, use the standard Postfix tools:

View the deferred queue:

Terminal window
mailq
# or
postqueue -p

Output shows queue ID, size, arrival time, sender, and recipients. Messages with status=deferred are still in the queue. Messages with status=bounced are gone (already processed by the bounce daemon).

Force a retry of deferred messages:

Terminal window
postqueue -f

This tells Postfix to retry all messages in the queue immediately, rather than waiting for the normal retry schedule.

Delete a stuck message from the queue:

Terminal window
postsuper -d QUEUE_ID

Example:

Terminal window
postsuper -d G5678901234DEF

Use with caution. Once deleted, the message is gone and the original sender will not be notified (unless you manually notify them).

Count deferred vs bounced in your mail log:

Terminal window
grep "status=deferred" /var/log/mail.log | wc -l
grep "status=bounced" /var/log/mail.log | wc -l

How Postfix Insights surfaces deferred and bounced

Section titled “How Postfix Insights surfaces deferred and bounced”

Postfix Insights parses the status= and dsn= fields from each delivery attempt and groups related lines by queue ID and recipient. The dashboard aggregates defer and bounce rates by hour, day, and week, and breaks down by domain and DSN code so you spot patterns fast. Search results show the raw log line, the parsed status, and the DSN code for each recipient in a single message.

Get started with Postfix Insights. The source code is at https://github.com/Xodus-CO/postfix-insights.

References

Section titled “References”