Skip to content
Postfix Insights

Rejected, deferred, or bounced: three ways mail fails in Postfix

The distinction between a rejected, deferred, and bounced message is the point in the message lifecycle where the failure occurs. This single fact determines how it is logged, what you see in the queue, whether an NDR is sent, and how you grep for it. Understanding this distinction is essential for diagnosing delivery issues and distinguishing between a policy rejection that never entered your infrastructure from a delivery failure that did.

The core rule: rejected happens at the front door, before the message is queued; deferred and bounced happen after the message is queued and assigned a queue ID.

At the door (smtpd), before queueing
REJECTED no queue ID. The sending server is told live at SMTP time (4xx or 5xx). You never accepted the message, so there is no NDR to send.
NOQUEUE: reject: RCPT from ...: 554 5.7.1 ...
After queueing (a queue ID exists)
DEFERRED transient failure, Postfix retries.
BOUNCED permanent failure, Postfix sends a non-delivery report to the sender.
9F2A1C0A2B: to=<...> status=deferred|bounced ...
A reject happens before Postfix takes responsibility, so it has no queue ID and produces no bounce. Deferrals and bounces happen after the message is queued.

Rejected: Pre-queue, synchronous, no queue ID

Section titled “Rejected: Pre-queue, synchronous, no queue ID”

A rejection happens at the smtpd (SMTP daemon) stage, before Postfix accepts the message into the queue. When your Postfix server declines a message at SMTP time due to an access restriction or policy rule, it logs a NOQUEUE: reject: line and immediately sends an SMTP error reply (4xx or 5xx) back to the sending server. Your server never took responsibility for the message, so there is no queue ID.

Example rejected log line (relay access denied):

Jun 17 10:22:33 mail postfix/smtpd[12345]: NOQUEUE: reject: RCPT from client.example.net[203.0.113.9]: 550 5.7.1 <user@remote.org>: Relay access denied; from=<sender@example.com> to=<user@remote.org>

The sending server receives the error response synchronously at SMTP time. It is responsible for notifying its user; your server does not send a non-delivery report (NDR). The NOQUEUE label is the signal: this message was rejected before entering the queue.

Rejections come from smtpd access restrictions (RCPT-stage checks like reject_unauth_destination, policy-based rejections like DKIM/SPF/DMARC failure, rate limits, greylisting, or explicit blocklists). They can be permanent (5xx) or temporary (4xx). A temporary rejection like 451 4.7.0 Service temporarily unavailable tells the sending server to retry later; Postfix itself never queues the message.

Deferred: Post-queue, asynchronous, has queue ID

Section titled “Deferred: Post-queue, asynchronous, has queue ID”

A deferral happens after Postfix has accepted and queued the message. The message was assigned a queue ID (a hex string like E1234567890ABC) and handed off to the delivery agent (smtp or lmtp). The agent encountered a transient error (a 4.x.x status code) and will retry.

Example deferred log line (mailbox full, temporary):

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 message stays in the queue. Postfix will retry according to its retry schedule (default: several attempts over 5 days). The sending server does not receive an error; it handed off the message and is waiting. No NDR is generated at deferral time; the message may be delivered on a later retry attempt.

Bounced: Post-queue, asynchronous, generates NDR

Section titled “Bounced: Post-queue, asynchronous, generates NDR”

A bounce also happens post-queue, but with a permanent status code (5.x.x). Postfix accepted the message and assigned a queue ID, but a later delivery attempt failed with a permanent error. Postfix immediately stops retrying and generates a non-delivery report (NDR) to send back to the original sender.

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 NDR is generated by your Postfix bounce daemon and sent to the original sender. It includes the recipient address, the DSN code, the remote server’s SMTP reply, and a copy of the original message headers so the sender can identify which message bounced.

Telling them apart at a glance

Section titled “Telling them apart at a glance”

Look for three diagnostic markers:

  1. Service: Rejects come from smtpd. Deferred and bounced come from smtp or lmtp.
  2. Queue ID: Rejects have NOQUEUE in place of a queue ID. Deferred and bounced have a hex queue ID (10-16 characters).
  3. Status field: Deferred and bounced lines have a status= field. Rejects do not.

Here are the three lines side by side (same timestamp for comparison):

Jun 17 10:22:33 mail postfix/smtpd[12345]: NOQUEUE: reject: RCPT from client.example.net[203.0.113.9]: 550 5.7.1 <user@remote.org>: Relay access denied; from=<sender@example.com> to=<user@remote.org>
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)
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 reject has NOQUEUE and service smtpd. The deferred has queue ID E1234567890ABC and status=deferred. The bounced has queue ID F9876543210XYZ and status=bounced.

Searching the log for each

Section titled “Searching the log for each”

To count or audit rejections in your mail log:

Terminal window
grep "NOQUEUE: reject:" /var/log/mail.log | wc -l

To count deferred messages:

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

To count bounced messages:

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

Backscatter: why rejecting early matters

Section titled “Backscatter: why rejecting early matters”

Backscatter occurs when a mail server accepts a message (assigns it a queue ID) and then bounces it to the sender. The problem: if the original sender address was forged or harvested from spam, your bounce (NDR) becomes outbound spam. It lands in the inbox of an innocent person who never sent the original email.

The solution is to reject at SMTP time (smtpd stage) rather than accept and bounce later. A rejection with a 5xx response tells the sending server “this address does not exist” or “this policy blocks you” before the message enters your queue. If the sender is spoofed, the sending server gets the error and should not retry. The innocent recipient never receives a bounce from you.

This is why strict smtpd access rules (recipient verification, SPF/DKIM/DMARC checks at the RCPT stage) reduce backscatter and protect your reputation.

Why this matters operationally

Section titled “Why this matters operationally”

In the Postfix mail log, rejects and deferred/bounced messages tell different stories about your infrastructure’s behavior and your interaction with remote servers:

  • Rejects indicate policy decisions made by your smtpd daemon. A high reject rate on RCPT restrictions suggests aggressive filtering (good for spam defense, potentially risky for false positives). Rejects do not consume your queue or retry resources.
  • Deferred messages are stuck in your queue and consuming disk space and retry attempts. A rising defer rate can indicate a downstream problem (remote server overload, network instability, policy blocks) that may self-resolve, or it can indicate a misconfiguration on your side.
  • Bounced messages represent lost mail. A high bounce rate signals permanent delivery problems: bad addresses, authentication failures, policy rejections from the remote side, or reputation issues. Bounces are time-critical to investigate.

Because rejects are pre-queue and smtpd-based, they are a separate concern from post-queue delivery correlation. Your monitoring should treat them differently: track reject rates to understand inbound traffic filtering, and track bounce/defer rates to understand delivery health.

Postfix Insights and rejections

Section titled “Postfix Insights and rejections”

Postfix Insights focuses on the post-queue delivery record, correlated by queue ID. This means the tool directly surfaces deferred and bounced messages: you can search by recipient, domain, or DSN code, and see which messages failed and why.

Rejections are a distinct pre-queue smtpd event. They do not have queue IDs and cannot be correlated the same way. If you need to analyze rejections in detail, you can grep the smtpd logs directly (NOQUEUE: reject:) or aggregate them with traditional log analysis tools.

For deferred and bounced messages, start with Deferred vs. bounced in Postfix to understand the retry behavior and DSN codes. If you need to diagnose why a specific message bounced, use How to find why an email bounced in Postfix.

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

References

Section titled “References”