Postfix Operations Guides on Netdata

How Postfix actually works in production: a mental model for operators

Mon, 01 Jan 0001 00:00:00 +0000

Postfix is not a monolith. It is a collection of small, specialized programs that a supervisor process spawns on demand, coordinated by a single-threaded queue manager, with all durable state living as files on disk. Every operational failure in Postfix, from queue gridlock to inode exhaustion to silent DNS degradation, traces back to how these pieces interact.

The specific symptom matters less than the architecture underneath it. The same model that explains why one slow destination stalls all outbound mail also explains why a burst of inbound traffic degrades delivery performance, and why a restart on a large queue looks like recovery before it looks like failure again.

Postfix active queue saturation: hitting qmgr_message_active_limit

Mon, 01 Jan 0001 00:00:00 +0000

Mail stops flowing. The deferred queue grows. CPU is low, network paths are healthy, and DNS resolves fine. You run postqueue -p and see tens of thousands of messages in the active queue. The queue manager has hit qmgr_message_active_limit and cannot schedule new deliveries.

This is head-of-line blocking by design. The active queue has a hard ceiling (default 20,000 messages). Once reached, the queue manager stops scanning both the incoming and deferred queues. No new messages enter active delivery until an existing one is delivered or deferred. The system does not degrade gradually; it works, then it stops.

Postfix backscatter storm: bounces to forged senders and blocklisting

Mon, 01 Jan 0001 00:00:00 +0000

Your mail queue is growing with bounces to envelope senders at domains you have never heard of. Within hours, your IP lands on a DNSBL and legitimate mail stops reaching its destination.

This is a backscatter storm. Postfix accepted mail for recipients it could not deliver to, then generated non-delivery reports (NDRs) to the forged envelope sender. Those NDRs hit innocent third parties whose addresses the spammer forged.

The fix: reject unknown recipients at SMTP time instead of accepting and bouncing later. The challenge is identifying which misconfiguration let the mail through, stopping the storm without losing legitimate mail, and repairing your sender reputation.

Postfix bounce rate spike: 5xx failures, bad address lists, and reputation risk

Mon, 01 Jan 0001 00:00:00 +0000

A bounce rate spike is easy to miss. Postfix records a bounce as a completed transaction, so naive delivery metrics stay green while mail permanently fails. The status=bounced entries pile up in the logs, sender reputation degrades with every message, and sustained high bounce rates trigger blocklist listings at major destinations.

This guide covers how to identify a bounce rate spike, classify the 5xx failure codes driving it, and stop the bleeding before reputation damage compounds.

postfix check warnings: configuration drift and permission problems

Mon, 01 Jan 0001 00:00:00 +0000

postfix check walks the Postfix file tree, verifies permissions against the postfix-files manifest, and reports drift. It returns non-zero when it finds problems but does not stop or restart the running master. Safe to run in production at any time, which also makes the warnings easy to ignore.

What this means

The expected filesystem state is defined in postfix-files, which ships with the package and encodes ownership, group, and permission bits for every file and directory Postfix touches. When reality diverges from the manifest, you get a warning.

Postfix Connection refused: blocked port 25 and rejected outbound delivery

Mon, 01 Jan 0001 00:00:00 +0000

You see status=deferred (connect to mx.example.com[192.0.2.1]:25: Connection refused) filling your mail logs. The deferred queue is growing. Postfix cannot establish outbound TCP connections to destination mail servers.

“Connection refused” is not the same as “Connection timed out.” Connection refused means the TCP handshake was actively rejected with a RST packet: the destination IP is reachable, but nothing is listening on that port, or something in the path is rejecting the connection. Connection timed out means the SYN packet was silently dropped: a firewall rule, a network partition, or an ISP dropping egress traffic.

Postfix connection storm: dictionary attacks, anvil rate limits, and connection floods

Mon, 01 Jan 0001 00:00:00 +0000

A flood of inbound SMTP connections hits your Postfix server. The smtpd process count climbs, file descriptors tighten, and legitimate mail starts queuing behind connection churn. Throughput drops even though the system is busy. The likely cause is a connection storm: a dictionary attack harvesting recipient addresses, a credential-stuffing run against your submission port, or a misbehaving client with a broken connection pool.

The distinguishing signal is the ratio of connections to messages. A dictionary attack opens many connections, probes for valid recipients, and disconnects without delivering mail. A legitimate flash crowd opens connections that carry real messages. Telling them apart quickly determines whether you throttle, block, or scale.

Postfix Connection timed out: delivery deferrals to unreachable destinations

Mon, 01 Jan 0001 00:00:00 +0000

The mail log shows the same deferral line for every message to one or more destinations:

status=deferred (connect to mx.example.com[192.0.2.1]:25: Connection timed out)

Postfix sent a TCP SYN to the destination MX on port 25 and received no SYN-ACK within smtp_connect_timeout (default 30 seconds). Something on the network path silently dropped the SYN. Postfix defers the message and schedules a retry with exponential backoff.

Distinguish this from two other errors that produce similar queue growth but need different fixes:

Postfix content_filter backpressure: incoming queue growth when Amavis or Rspamd slows

Mon, 01 Jan 0001 00:00:00 +0000

When your content filter (Amavis, Rspamd, or a commercial scanner) slows down or stalls, mail accumulates in Postfix’s incoming queue while the active queue stays small. This is the reverse of the more familiar queue gridlock pattern where a slow destination fills the active queue, and it confuses operators who expect active to be large whenever mail is stuck.

The signature is specific: incoming queue growing, active queue flat or small, deferred queue low, and the filter port (commonly 127.0.0.1:10024 for Amavis) refusing connections or timing out. SMTP clients may experience slow DATA-phase responses. Upstream senders start retrying, which amplifies load on a system that is already falling behind.

Postfix daemon memory growth: leaking RSS and OOM risk

Mon, 01 Jan 0001 00:00:00 +0000

Postfix daemons are disposable. Each smtpd, smtp, cleanup, or local process handles one session or message, then exits, keeping per-process RSS bounded at roughly 1 to 5 MB. When RSS climbs steadily on a qmgr process or a delivery agent that should have been recycled hours ago, you are looking at either a memory leak or a queue structure grown beyond normal operating size.

The one daemon that is legitimately long-lived is qmgr(8). It holds active queue entries, per-destination concurrency state, and recipient lists in memory. Its RSS scales with queue depth. But sustained RSS growth on short-lived daemons, or qmgr growth that does not recede after the queue drains, points at a leak heading toward the OOM killer.

Postfix deferred queue growing: why mail piles up and how to drain it

Mon, 01 Jan 0001 00:00:00 +0000

Sustained growth in /var/spool/postfix/deferred/ means delivery failures are outpacing retry successes. The queue is accumulating messages faster than the queue manager can drain them.

The problem compounds in two ways. First, every message that fails retry stays in the deferred queue while fresh mail continues to enter the system. Second, the queue manager uses exponential backoff, so older deferred messages may not be retried for up to maximal_backoff_time (default 4000s, roughly 66 minutes). Even after you fix the root cause, the queue takes hours to drain because most messages are in their backoff cool-off period.

Postfix destination concurrency limit: tuning per-destination delivery

Mon, 01 Jan 0001 00:00:00 +0000

Postfix does not open unlimited outbound connections to a single destination. The queue manager (qmgr) enforces a per-destination concurrency cap controlling how many simultaneous delivery attempts may target the same recipient domain at once. This parameter, smtp_destination_concurrency_limit, is behind two common operational failures: queue gridlock from one slow destination monopolizing active queue slots, and reputation penalties from hammering a fragile destination that then throttles or blocklists your IP.

The default works for general-purpose MTAs sending moderate volume to healthy destinations. But with rate-limited providers, corporate servers with strict connection caps, or a backlog that needs draining fast, the default can be either too aggressive or too conservative. Since Postfix 2.5, the concurrency limit is a ceiling that an adaptive feedback algorithm approaches and retreats from based on delivery outcomes, similar to TCP congestion control. Understanding both the limit and the feedback algorithm is necessary before making changes.

Postfix DNS resolver failure: when a broken resolver defers mail to everyone

Mon, 01 Jan 0001 00:00:00 +0000

Mail is deferring to every destination. Gmail, Outlook, corporate partners, even your own relayhost. The master process is running, the queue manager is responsive, and the SMTP listener accepts connections. But the deferred queue keeps growing, and the deferral reasons point to DNS: “Host or domain name not found” or “Name service error for name=… type=MX: Host not found, try again.”

Postfix depends entirely on DNS for MX resolution, A/AAAA address lookups, reverse PTR verification, and DNSBL queries. It has no internal DNS cache. When the resolver breaks, deliveries defer rather than bounce. The deferral reason is often generic enough that operators chase the wrong problem.

Postfix double-bounce loop: MAILER-DAEMON mail multiplying in the queue

Mon, 01 Jan 0001 00:00:00 +0000

The Postfix queue is growing fast and postqueue -p output is dominated by messages from MAILER-DAEMON or double-bounce@<your hostname>. The count climbs steadily despite no corresponding increase in legitimate mail volume. Queue slots, disk I/O, and inodes are being consumed by bounce generation, and legitimate mail is getting delayed or stuck behind the noise.

Left unchecked, the loop can exhaust inodes on the queue filesystem (each queued message is a separate file), starve the queue manager of active delivery slots, and delay legitimate mail for hours.

Postfix file descriptor limits: raising ulimit and systemd LimitNOFILE

Mon, 01 Jan 0001 00:00:00 +0000

Postfix logs fatal: socket: Too many open files or begins silently dropping connections when per-process file descriptor limits are too low. The default soft limit on many distributions is 1024, which is adequate for a development mail server but insufficient for any production MTA handling concurrent SMTP sessions and active queue processing simultaneously.

The most common operator mistake is editing /etc/security/limits.conf, restarting Postfix, and finding the limit unchanged. On systemd-managed distributions, services do not read PAM limits. The effective file descriptor limit for a systemd service comes from the unit file’s LimitNOFILE directive, the global DefaultLimitNOFILE in /etc/systemd/system.conf, or the kernel’s compiled-in default. Editing only one layer leaves the limit silently unchanged.

Postfix flushing and clearing the deferred queue: postqueue and postsuper

Mon, 01 Jan 0001 00:00:00 +0000

A deferred queue is growing and you need to act. The difference between using postqueue and postsuper well and badly is the difference between controlled recovery and a self-inflicted stampede.

Postfix holds messages that failed temporary delivery in the deferred queue for retry with exponential backoff. The retry scheduler uses minimal_backoff_time (default 300s) and maximal_backoff_time (default 4000s) to space out attempts. When you intervene manually, you are overriding that scheduler. Sometimes that is the right call, like when a relay host has recovered and the mail is now deliverable. Often it is not.

Postfix greylisting delays: 450 4.7.1 deferrals and slow first delivery

Mon, 01 Jan 0001 00:00:00 +0000

Mail to Gmail, Yahoo, Hotmail, and other major destinations shows a consistent delay of roughly 300 seconds on first delivery. The mail log shows 450 4.7.1 or 451 4.7.1 deferrals from the destination MX. The deferred queue climbs slowly but not explosively. On retry, the messages deliver successfully. This is greylisting, not a Postfix fault.

Greylisting intentionally rejects the first delivery attempt from an unknown sender triplet (client IP, sender address, recipient address) with a 4xx temporary failure. The destination expects legitimate MTAs to retry and spam bots to give up. Postfix handles this correctly by deferring the message and scheduling a retry. The goal is to align retry timing with the destination’s greylisting window, and to whitelist trusted senders if you run postgrey for inbound filtering.

Postfix HELO command rejected: need fully-qualified hostname

Mon, 01 Jan 0001 00:00:00 +0000

You see lines like this filling your mail log:

NOQUEUE: reject: RCPT from unknown[203.0.113.45]: 504 5.5.2 <desktop-abc123>: Helo command rejected: need fully-qualified hostname; from=<user@example.com> to=<recipient@example.org> proto=ESMTP helo=<desktop-abc123>

Postfix is rejecting the connection because the client sent a bare hostname in its HELO or EHLO command instead of a fully-qualified domain name. The restriction responsible is reject_non_fqdn_helo_hostname in your smtpd_helo_restrictions.

Most rejections are legitimate: bots and spam scripts routinely send garbage or bare names in HELO. The problem starts when a legitimate client gets caught – a desktop mail client sending its machine name, an internal monitoring server using a short hostname, or an application hardcoded with localhost as its HELO string. All trigger the same 504 rejection.

Postfix Host or domain name not found: DNS name service errors deferring mail

Mon, 01 Jan 0001 00:00:00 +0000

Mail is piling up in the deferred queue. Postfix logs the same deferral repeatedly:

status=deferred (Host or domain name not found. Name service error for name=example.com type=MX: Host not found, try again)

The enhanced status code is 4.4.3 (directory server failure). Postfix will retry, but retries keep producing the same error because the resolver is broken, not the destination.

The key tell: all destinations are affected equally. If Gmail, Outlook, and a corporate partner all fail with “Host not found” at the same time, your resolver is the problem. If only one domain fails, that is a real DNS issue at the destination.

Postfix inode exhaustion: the queue filesystem blind spot behind No space left on device

Mon, 01 Jan 0001 00:00:00 +0000

Postfix reports No space left on device in your logs. You check df -h /var/spool/postfix and see 50% free space. Mail acceptance is failing and queue operations are erroring. The obvious explanation does not match reality.

The cause is almost always inode exhaustion on the queue filesystem. Postfix creates one file per queue entry: every incoming message, every deferred retry, every bounce notification. Each file consumes one inode regardless of how few bytes it occupies. A deferred queue with 500,000 tiny messages might use only a couple of GB of block space but exhaust every inode on the partition.

Postfix IP blocklisted: deliverability collapse and sender reputation

Mon, 01 Jan 0001 00:00:00 +0000

A blocklist entry is a symptom, not the root cause. Your sending IP appeared on Spamhaus, SpamCop, SORBS, or a provider-internal list because something in your mail stream triggered their detection. Delisting requests fail or the IP is relisted within hours until you identify and stop that activity.

The first sign is usually deferrals spiking against one provider, bounces climbing, and the deferred queue growing while injection holds steady. Two patterns dominate: sudden listing from a compromised account or spam outbreak flooding garbage through your server, and gradual erosion from chronic issues like bad recipient lists, backscatter, or weak authentication accumulating negative reputation signals over weeks until a threshold is crossed. The diagnostic path differs for each.

Postfix mail flow: injection rate outpacing delivery rate

Mon, 01 Jan 0001 00:00:00 +0000

The queue is growing, delivery latency is climbing, and the gap between what Postfix accepts and what it delivers is sustained. This divergence surfaces before queue-depth alerts fire.

Injection rate and delivery rate should track within about 10% over any 5-minute window. When they diverge consistently, the outbound path is constrained. The constraint might be a single slow destination monopolizing active queue slots, a DNS resolver failure silently deferring all deliveries, a content filter that has stopped responding, or destination-side rate limiting. Each cause has a distinct signature in the logs and queue directories.

Postfix mail for domain loops back to myself: MX and myhostname misconfiguration

Mon, 01 Jan 0001 00:00:00 +0000

The bounce message “mail for example.com loops back to myself” is a routing error, not a delivery timeout. It appears in logs as status=bounced (mail for example.com loops back to myself) with DSN 5.4.6. Postfix resolved the destination domain’s MX record, found the best-preference MX points at this host, but found no matching entry in mydestination, virtual_mailbox_domains, virtual_alias_domains, or relay_domains. Instead of looping, Postfix bounces the message.

This typically surfaces after a DNS or MX change, a relay-host migration, adding a virtual domain without updating delivery maps, or converting a null client to a full internet site. The fix is to align the domain ownership tables with the MX record. Raising retry limits will not help because the routing decision itself is wrong.

Postfix maildrop queue growing: pickup daemon and local submission failures

Mon, 01 Jan 0001 00:00:00 +0000

Files are accumulating in /var/spool/postfix/maildrop/. Cron output is not arriving in mailboxes. Monitoring alerts that depend on local mail delivery are silently failing. postqueue -p shows normal SMTP traffic flowing, but locally submitted messages are stuck in a directory that should be transient.

The maildrop queue is the only Postfix queue that does not receive mail from the network. It holds messages submitted locally through the sendmail command or the postdrop setgid helper. Every cron job that produces output, every monitoring script that sends mail, and every local application that invokes /usr/sbin/sendmail writes here. The single-threaded pickup daemon drains it within seconds, handing each message to cleanup for header rewriting and content normalization before it enters the incoming queue.

Postfix master process not running: the whole MTA is down

Mon, 01 Jan 0001 00:00:00 +0000

When the Postfix master process is not running, the entire MTA is down. No mail is received on port 25. No delivery agents are spawned. The queue manager cannot run. Local submissions via sendmail queue up but go nowhere. Upstream senders either timeout, defer, or bounce.

Symptoms are uniform regardless of cause: postqueue -p returns a fatal error, SMTP connections to port 25 are refused, and no master process appears in the process table. The underlying cause varies: OOM kill, stale lock file from an unclean shutdown, port conflict, configuration error, or PID namespace confusion in a container.

Postfix message size exceeds fixed limit: 552 5.3.4 and message_size_limit

Mon, 01 Jan 0001 00:00:00 +0000

The error 552 5.3.4 Message size exceeds fixed limit appears in Postfix logs when a message, including headers, body, and MIME encoding overhead, exceeds message_size_limit. This is a hard rejection, not a deferral. The sender receives a bounce, and the message never enters the queue.

The default message_size_limit is 10240000 bytes (approximately 10 MB). Base64 encoding inflates binary attachments by roughly 33 percent, so a 7 MB attachment becomes approximately 9.3 MB of encoded data before headers are added. Many operators discover this only when users report that “sometimes attachments work, sometimes they don’t.”

Postfix Milter timeouts: smtpd hangs when a milter stops responding

Mon, 01 Jan 0001 00:00:00 +0000

When a before-queue milter like OpenDKIM, milter-greylist, or a custom policy daemon stops responding, smtpd processes block during the SMTP transaction. Each connection that hits a milter callback waits for the full timeout duration before Postfix gives up. During that wait, the smtpd process handling that connection is occupied and counts toward the service’s maxproc limit.

The first visible symptom is usually not mail bouncing or deferring. It is mail acceptance slowing down. SMTP clients connect, get a 220 greeting, then stall during the DATA phase. As more smtpd processes accumulate waiting for milter responses, fewer remain available for new connections. Eventually new connections queue in the listen backlog or are refused entirely.

Postfix monitoring checklist: the signals every production mail server needs

Mon, 01 Jan 0001 00:00:00 +0000

A production Postfix server fails in ways that look healthy until they suddenly do not. Deferred queues fill with retrying messages while disk space appears fine. Inodes exhaust on a filesystem that df reports at 50% free. A single slow destination silently monopolizes the active queue, starving all other mail. Outbound TLS certificates expire on connections nobody monitors, and deliveries start deferring with cryptic SSL errors.

Four cumulative maturity levels: survival, operational, mature, expert. Walk through each as a gap analysis. Confirm you collect and alert on every signal at each level before moving up.

Postfix monitoring maturity model: from survival to expert

Mon, 01 Jan 0001 00:00:00 +0000

Postfix is a modular, queue-based MTA where mail flow depends on a chain of cooperating daemons, filesystem-backed queues, DNS resolution, and external filters. Monitoring maturity is not about collecting more metrics for their own sake. It is about closing the gap between what you can detect and what actually causes incidents: inode exhaustion hiding behind “No space left on device,” active queue saturation from one slow destination, silent filter backpressure, or deferred queues that grow for hours before anyone notices.

Postfix No space left on device: disk and inode exhaustion halting the queue

Mon, 01 Jan 0001 00:00:00 +0000

Postfix logs show fatal: ... No space left on device or warning: not enough free space in mail queue. You run df -h and the queue filesystem has free space. Mail acceptance stalls, delivery stops, and the queue grows.

The most common cause is inode exhaustion. Postfix creates one file per queued message across its queue subdirectories: maildrop, incoming, active, deferred, bounce, defer, hold, and corrupt. A mail storm, a backscatter loop, or months of accumulated deferred messages can exhaust millions of inodes while disk space barely moves. df -h looks fine. df -i shows 100%.

Postfix not listening on port 25 or 587: connection refused

Mon, 01 Jan 0001 00:00:00 +0000

“Connection refused” on port 25 or 587 means no process on the host is completing the TCP handshake on that port. This is distinct from a timeout, where something accepts the SYN but never responds. “Refused” means either no process is listening, or the kernel is actively rejecting the connection.

The most common real-world causes: the master process is down, Postfix is bound to loopback only, the smtpd process pool is exhausted, or a firewall is intercepting traffic before Postfix sees it. Less common but worth checking: inet_protocols mismatch on IPv6-disabled hosts, port conflicts with other MTAs, and postscreen handoff failures.

Postfix open relay: unauthorized relay through a misconfigured server

Mon, 01 Jan 0001 00:00:00 +0000

A Postfix server that accepts mail from unauthenticated, non-local clients and forwards it to arbitrary external domains is an open relay. Treat any confirmed occurrence as a PAGE-level security incident: automated scanners find open relays within hours, and a single relayed spam batch can trigger blocklist listings that take days to clear.

The most common causes are configuration changes that widen trust: mynetworks set too broadly, restrictions evaluated in the wrong order, a SASL backend that accepts empty credentials, or a backup-MX setup without recipient validation.

Postfix process limit reached: smtpd 'to limit' warnings and connection delays

Mon, 01 Jan 0001 00:00:00 +0000

The warning: service smtpd: ... to limit message in your mail log means Postfix has run out of smtpd processes. The master daemon caps concurrent instances of each service at a maxproc value defined in master.cf. For smtpd, that cap defaults to 100, inherited from default_process_limit. When all 100 smtpd processes are busy, new TCP connections on port 25 either queue in the kernel listen backlog or get refused.

This is an info-level log entry, which means it is easy to miss in default alerting. The first symptom most teams notice is external: clients reporting slow mail delivery, monitoring showing connection timeouts to port 25, or deferred mail piling up because inbound messages are not being accepted.

Postfix queue gridlock: one slow destination stalls all mail

Mon, 01 Jan 0001 00:00:00 +0000

Mail delivery has stopped for everyone, but nothing looks broken. CPU is low. Network throughput is low. The active queue is full, the deferred queue is growing, and none of the usual suspects (DNS failure, content filter backpressure, disk exhaustion) explain it. This is Postfix queue gridlock: a single slow or throttling destination has consumed the active queue, and the queue manager’s fair scheduler is letting it starve every other destination.

Postfix queue message age: the delivery latency queue depth cannot show

Mon, 01 Jan 0001 00:00:00 +0000

A queue of 10 messages whose oldest is 3 hours old is worse than 10,000 messages aged 5 seconds. Depth tells you volume. Age tells you latency. They answer different questions, and conflating them leads to missed incidents.

Postfix exposes no built-in “oldest message age” metric. The showq daemon reports per-message arrival times to postqueue, but no aggregate age, no percentile, no histogram. Most monitoring setups track queue depth as a count and stop there. A flat depth line looks healthy. But if messages enter and leave the queue at the same rate, depth stays constant even when every message takes 4 hours to deliver instead of 4 seconds.

Postfix queue partition disk full: /var/spool/postfix out of space

Mon, 01 Jan 0001 00:00:00 +0000

When the filesystem holding /var/spool/postfix runs out of bytes, all mail I/O stops. The queue manager cannot write new queue files, cleanup cannot inject messages, and pickup cannot move mail from maildrop into incoming. Postfix may still listen on port 25 and accept TCP connections, but every accepted message eventually fails with “No space left on device” or is rejected by the SMTP server’s free-space check.

This is a cliff-edge failure with no graceful degradation. The master process may also fail to update its PID file at /var/spool/postfix/pid/master.pid, leaving stale state that complicates recovery.

Postfix rate limited by destination: 421 and 4.7.1 throttling from major providers

Mon, 01 Jan 0001 00:00:00 +0000

When a major email provider starts throttling your Postfix server, the symptom is distinctive: mail to that one provider defers while everything else flows. You see 421 “too many connections” or 4.7.1 rate-limit responses in your mail logs, the deferred queue fills with messages to that domain, and retries with exponential backoff make the pile worse. Other destinations deliver normally.

Postfix itself is not malfunctioning. The remote MX is enforcing per-IP or per-domain rate limits, and Postfix’s queue manager is correctly deferring and retrying. The problem is that your sending pattern exceeds what the provider will accept, or your IP reputation has degraded to the point where the provider tightens those limits.

Postfix Relay access denied: 554 5.7.1 and blocked senders

Mon, 01 Jan 0001 00:00:00 +0000

The mail log shows a pattern like this:

NOQUEUE: reject: RCPT from unknown[10.0.2.15]: 554 5.7.1 <user@external.example>: Relay access denied; from=<app@internal.corp> to=<user@external.example> proto=ESMTP helo=<app01.internal.corp>

A client connected to Postfix, sent MAIL FROM and RCPT TO for a recipient on an external domain, and Postfix rejected the message before queuing it. The recipient domain is not one Postfix considers local or a configured relay destination, and the client failed every authorization check. This is Postfix enforcing relay control exactly as designed.

Postfix relay recipient map stale or slow: rejected valid recipients and smtpd hangs

Mon, 01 Jan 0001 00:00:00 +0000

In a relay or gateway Postfix setup, relay_recipient_maps validates recipients before mail enters the queue. When this map goes stale or responds slowly, you see one of two failure modes: valid recipients rejected with a 550 response (stale .db file, no queue entry to investigate), or smtpd processes hanging during RCPT TO because a network-backed lookup never returns (connection capacity drops, new connections queue or fail).

The same failure modes and fixes apply to local_recipient_maps.

Postfix SASL authentication failed: brute force on submission and credential errors

Mon, 01 Jan 0001 00:00:00 +0000

Postfix logs “SASL LOGIN authentication failed” or “SASL PLAIN authentication failed” when an SMTP client on port 587 (submission) or 465 (smtps) sends an AUTH command that the SASL backend rejects. Postfix does not verify credentials itself. It delegates to a backend via smtpd_sasl_type (dovecot or cyrus), which may in turn proxy to LDAP, Active Directory, PAM, or SQL.

The critical first distinction: sporadic failures from specific clients indicate misconfigured credentials, a password rotation, or an expired app password. A sustained flood of failures from one or many IPs with varying usernames is a credential brute-force. When all authentication fails for every client simultaneously, the backend is down or unreachable.

Postfix TLS certificate expiry: expired certs and handshake failures

Mon, 01 Jan 0001 00:00:00 +0000

An expired TLS certificate on a Postfix server breaks mail delivery in two distinct ways, and teams frequently detect only one. The inbound symptom is loud: clients that require STARTTLS fail handshakes, connections drop, and complaints arrive quickly. The outbound symptom is quiet: mail to destinations enforcing mutual TLS or DANE silently defers into the deferred queue, where it sits under Postfix’s increasing backoff schedule until someone notices the queue growing.

Postfix TLS downgrade: mandatory TLS falling back to plaintext

Mon, 01 Jan 0001 00:00:00 +0000

When mail to a destination configured for mandatory TLS is delivered in plaintext, that is a security incident, not a delivery problem. Postfix TLS security levels exist to prevent this: at encrypt and above, the message should be deferred if TLS is unavailable, not silently downgraded. If plaintext delivery is happening where policy forbids it, the policy enforcement chain is broken.

The default logging makes this symptom nearly invisible. With smtp_tls_loglevel at its default of 0, no TLS negotiation details are logged for outbound connections. Failed handshakes and silent fallbacks to plaintext produce no log output at all. By the time someone notices, the policy violation may have been ongoing for hours or days.

Postfix TLS handshake failures: SSL_accept errors and cipher mismatches

Mon, 01 Jan 0001 00:00:00 +0000

SSL_accept error in your mail logs means the TLS handshake on an inbound connection failed mid-negotiation. The remote SMTP client connected, STARTTLS was offered, and the OpenSSL handshake aborted before a session was established. Postfix either rejects the message (mandatory TLS) or silently falls back to plaintext (opportunistic TLS).

Default Postfix does not log failed opportunistic TLS handshakes. Both smtpd_tls_loglevel and smtp_tls_loglevel default to 0. You see successful TLS connections but not the ones that failed and fell back to cleartext. You may be delivering mail in plaintext to destinations you believe require encryption, with the only visible symptom being a deferred queue growing with delivery delays.

Postfix too many open files: file descriptor exhaustion and refused connections

Mon, 01 Jan 0001 00:00:00 +0000

Postfix logs “too many open files” or “unable to fork.” Inbound SMTP connections fail. Queue files cannot be opened or written. The master process is still running, ports are still bound, and the disk has free space and inodes.

This is file descriptor exhaustion: a Postfix process has reached its per-process soft limit on open file descriptors. Each open socket, queue file, and pipe handle counts toward the limit. On most Linux distributions the default soft limit is 1024, which is inadequate for a production MTA. Under enough concurrent load, a process hits the ceiling and Postfix fails.

Postfix User unknown in recipient table: 550 recipient address rejected

Mon, 01 Jan 0001 00:00:00 +0000

A sender gets 550 5.1.1 <user@domain>: Recipient address rejected: User unknown in local recipient table (or the virtual mailbox or relay variant). Postfix rejected the recipient at SMTP RCPT TO time, before queueing, because the address was not found in the map for that address class. This validation is controlled by smtpd_reject_unlisted_recipient (default: yes).

The problem is either that a legitimate recipient is missing from the map, or that the domain is in the wrong address class and Postfix is checking the wrong map. Before changing restrictions or disabling validation, identify which map Postfix consulted, test the lookup with postmap -q, and reconcile the map against your authoritative directory. The reject string identifies the address class.