How can I change the retransmission time in Postfix?
Published 18 Jun 2025
Updated 18 Oct 2026
12 min read
Summarize with
Updated on 18 Oct 2026: We clarified Postfix retry timing, corrected the slower retry example, and separated queue backoff from connection timeouts.
In Postfix, change retransmission timing for deferred mail with minimal_backoff_time, maximal_backoff_time, and queue_run_delay in main.cf. For a normal 450 greylisting response that says to wait 300 seconds, start with minimal_backoff_time = 300s and queue_run_delay = 300s. These have been the defaults since Postfix 2.4. If the effective values already match, confirm that the whole delivery attempt has finished and follow the next automatic retry in the logs.
The setting that looks tempting, transport_retry_time, is usually not the answer for greylisting. It controls how often the queue manager retries a malfunctioning delivery transport. A remote MX returning 450 4.2.0 is not the same failure as a broken smtp transport.
Postfix retry settings
For greylisting, tune deferred-message backoff, not the transport retry timer.
- Deferred mail: Use minimal_backoff_time for the minimum retry delay after a temporary delivery failure.
- Queue scans: Keep queue_run_delay less than or equal to minimal_backoff_time.
- Upper bound: Use maximal_backoff_time to cap later retry intervals.
- Transport fault: Use transport_retry_time only when the local delivery transport is malfunctioning.
Change the Postfix retry interval
The direct change belongs in main.cf, normally /etc/postfix/main.cf. Record the effective values first, then use postconf -e to update each parameter without creating duplicate active entries. Compare the installed defaults with postconf -d. The following baseline matches a common 300 second greylist window and keeps later retries bounded by the standard upper limit. Keep queue_run_delay <= minimal_backoff_time <= maximal_backoff_time. Use explicit time units, such as s for seconds or m for minutes.
Greylisting-friendly Postfix baselinebash
postconf minimal_backoff_time queue_run_delay maximal_backoff_time postconf -d minimal_backoff_time queue_run_delay maximal_backoff_time sudo postconf -e "minimal_backoff_time = 300s" sudo postconf -e "queue_run_delay = 300s" sudo postconf -e "maximal_backoff_time = 4000s" sudo postfix check && sudo postfix reload
The Postfix tuning guide describes the queue manager defaults that matter here: queue scans, minimum backoff, maximum backoff, and queue lifetime. A reload applies the current configuration but does not force every deferred message to retry. Existing queue files retain their eligibility timestamps until a normal scan or an explicit delivery request selects them.
On a host managed by a control panel or configuration system, make the same change in its source configuration. Otherwise, a package update or automated reconciliation can overwrite the values in main.cf.
|
|
|
|
|---|---|---|---|
minimal_backoff_time | 300s | Minimum deferred retry delay | Too low repeats early |
queue_run_delay | 300s | Deferred queue scans | Lower means more I/O |
maximal_backoff_time | 4000s | Maximum scheduled cooldown | Scans and queue load add delay |
maximal_queue_lifetime | 5d | Expiry after temporary failures | Short values bounce sooner |
transport_retry_time | 60s | Broken transport | Not normal 4xx |
Postfix retry controls for deferred delivery
Webmin Postfix settings for queue scans and deferred mail backoff timing.
Understand retry backoff and queue lifetime
Postfix does not retry every deferred message on one fixed interval. The qmgr queue manager uses message-age-based exponential backoff, with the scheduled cooldown bounded by minimal_backoff_time and maximal_backoff_time. The queue_run_delay value controls how often Postfix scans the deferred queue. It is not a promise that every eligible message will run at that exact second.
- Minimum retry delay: The interval cannot be shorter than minimal_backoff_time during normal queue scheduling.
- Later attempts: Scheduled cooldowns grow with message age, up to maximal_backoff_time.
- Dead destinations: The minimum backoff also limits how long an unreachable destination stays in the short-term destination status cache.
- Message expiry: The maximal_queue_lifetime setting decides when a message with temporary failures becomes undeliverable.
- Bounce expiry: The bounce_queue_lifetime setting applies separately to queued MAILER-DAEMON messages and also defaults to five days.
A delay notice does not expire mail
The delay_warning_time setting controls when the sender receives a delayed-mail notice. Its default is 0h, which disables that notice. It does not control retries or the total time a message stays queued.
Setting maximal_queue_lifetime = 0 allows only one delivery attempt. It does not mean unlimited retries.
Queue load, deferred queue scan timing, and the destination status cache can move an actual retry later than the minimum. The maximum backoff caps the scheduled cooldown, not the total elapsed time until delivery. Verify real behavior by following the same queue ID in the logs. These retry controls apply to temporary failures (4xx). Permanent recipient rejections (5xx) normally bounce the affected recipient instead of entering the deferred retry cycle.
What happens with greylisting
A greylist message that says Greylisted for 300 seconds is human-readable SMTP response text, not a timer field that Postfix parses. Postfix sees a temporary SMTP failure, records the delivery as deferred, and schedules the message according to queue backoff after the delivery attempt has finished.
An anonymized greylisting log patterntext
postfix/smtp[22475]: A88B418003D5B: to=<user@example.com>, relay=mx1.destination.example[192.0.2.10]:25, delay=969, dsn=4.2.0, status=deferred host mx1.destination.example said: 450 4.2.0 Recipient address rejected: Greylisted for 300 seconds
In that log pattern, dsn=4.2.0 and status=deferred are the key pieces. The delay value tells you how long the message has been in the queue or active delivery path, but it does not prove that Postfix waited the wrong amount before the next queue retry.
Postfix does not have a per-response timer that waits 300 seconds before trying the next MX because one MX returned greylist text. Postfix can try another usable MX during the same delivery attempt. The backoff controls the next queue attempt after deferral, not the gap between MX hosts inside that attempt.
Deferred message retry
- Trigger: A remote temporary failure leaves the message in the deferred queue.
- Settings: Use minimal_backoff_time, queue_run_delay, and maximal_backoff_time.
- Scope: It affects deferred messages, not just one provider response string.
- Best use: Let the greylist window finish before the next queue attempt.
Transport retry
- Trigger: The local delivery transport cannot be contacted by the queue manager.
- Setting: Use transport_retry_time.
- Scope: It is about the transport service, not normal remote MX policy.
- Best use: Recover from a broken local delivery path.
Greylist retry timing
Interpret retry scheduling when the receiver requests a 300 second wait. These examples distinguish the first retry from later backoff.
Before the wait ends
Under 300s
An early retry is still inside the receiver's stated greylist window.
Minimum configured delay
300s
A 300 second minimum is the baseline for this stated wait period.
Actual first retry
300s or later
Queue scan timing and delivery load add time after the minimum cooldown.
Default later retry cap
4000s (66m 40s)
The default maximum scheduled cooldown is over an hour; actual delivery can occur later.
If the log is about throttling rather than greylisting, retry timers are only one input. For destination pacing, review smtp_destination_rate_delay and smtp_destination_concurrency_limit; use a dedicated transport when only one domain needs different limits. Follow the separate guidance on provider rate limits because changing queue backoff alone does not fix a sender that is hitting a receiver's volume controls.
Verify Postfix retry timing
Do not test retry changes by flushing a whole production queue. That creates a delivery burst and can turn a small greylisting delay into a throttling problem. Follow one queue ID at a time and change only one parameter. Observe an automatic retry before requesting immediate delivery.
Inspect one deferred message before its automatic retrybash
postconf minimal_backoff_time queue_run_delay maximal_backoff_time postconf transport_retry_time maximal_queue_lifetime bounce_queue_lifetime postqueue -p sudo postcat -q QUEUEID | sed -n '1,80p'
For a large deferred queue, check age buckets before changing timers. If qshape is installed, run sudo qshape deferred to inspect the queue by destination and age. The Postfix bottleneck analysis explains why repeated deferred queue waves can fill the active queue. That is the operational reason to avoid aggressive retry settings on a busy hosting server.
Avoid queue-wide retries
A queue flush is a delivery event, not just a diagnostic command. Use it with the same care as a send-rate increase.
- Single message: Watch one automatic retry before requesting immediate delivery of that queue ID.
- Busy queue: Use queue age and destination shape before reducing scan intervals.
- Receiver policy: Repeated attempts inside the greylist window can extend waiting at some receivers.
- Evidence: Compare timestamps for the same queue ID across automatic delivery attempts.
To verify the interval, compare automatic attempts for the same queue ID in your mail logs, commonly /var/log/mail.log or /var/log/maillog, or the system journal. If immediate attempts still appear, check for automated queue flushes or multiple MX hosts within one delivery attempt.
After the receiver's wait window has ended, an optional forced retry tests recovery. postqueue -i requests immediate delivery and bypasses normal deferred scheduling, so it does not measure the configured retry interval. Replace QUEUEID with the deferred message's queue ID.
Optional immediate retry of one deferred messagebash
sudo postqueue -i QUEUEID
When Postfix timing is not the root cause
Retry timing controls delivery cadence. It does not fix a receiver that distrusts the sender, a domain with broken authentication, missing reverse DNS, or an IP under reputation pressure. Once the timer is appropriate, check the sender signals around the MTA.
Postfix deferred mail troubleshooting flow for SMTP responses, retry backoff, queue checks, and sender reputation.
Use Suped's domain health checker to review DNS and authentication records. Also confirm the sending IP's reverse DNS separately before assuming that queue timing is the whole problem.
When deferrals mention blocklist (blacklist) policy, use Suped's blocklist monitoring to review listings alongside the receiver's SMTP response. A blacklist listing alone does not establish why a specific delivery was deferred.
After a Postfix configuration change, send a controlled message to Suped's email tester. Queue logs explain when Postfix tried; a delivered test message provides authentication results for that sample. Acceptance by the test inbox does not guarantee acceptance by another mailbox provider.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Suped is our DMARC reporting and email authentication platform. Add the domain, review its DNS checks, send a controlled test message, and filter DMARC aggregate reports for the sending source. These reports provide receiver-reported authentication results, not Postfix queue status or exact retry times. Use Postfix logs to measure queue recovery.
Email tester sample report showing total score, email preview, issue summary, and per-section results
Practical configuration patterns
The right numbers depend on the failure being solved. Keep a greylisting baseline close to the modern defaults. Increase the values only when a large queue keeps returning the same temporary failures and the sender needs to reduce retry pressure.
Balanced default-style retry timingtext
minimal_backoff_time = 300s queue_run_delay = 300s maximal_backoff_time = 4000s maximal_queue_lifetime = 5d transport_retry_time = 60s
That pattern is suitable when the receiver asks for a five minute greylist wait and the queue size is normal. It gives the first retry enough time to clear the greylist without delaying every temporary failure for an hour.
Slower retries without earlier message expirytext
minimal_backoff_time = 10m queue_run_delay = 5m maximal_backoff_time = 2h maximal_queue_lifetime = 5d
This example lengthens the minimum and maximum cooldowns while keeping the default five day queue lifetime. It reduces retry pressure but also delays legitimate recoveries. Consider it only when logs show repeated temporary failures across a large queue. Shortening queue lifetime is a separate decision that returns undeliverable mail sooner; it does not slow retries.
Do not use retry timing as reputation repair
If authentication is failing or the IP has a reputation problem, longer retry intervals only make the symptoms quieter. They do not make the mail more trusted.
- Authentication: Fix SPF, DKIM, and DMARC before changing delivery cadence again.
- Reputation: Treat blocklist or blacklist listings as sending-risk evidence.
- Content: Check the actual message that leaves the server, not just queue age.
- Connections: Separate retry backoff from concurrency and connection timeout errors.
Separate retry intervals from connection timeouts
If the log shows connection failures or remote servers that do not answer, distinguish connection timeouts from deferred-message backoff. SMTP connection errors require checking the failure stage. A connection refused response is an immediate rejection of the connection; a connection timeout means the connection did not complete before the deadline. Check routing and outbound port 25 access before reducing timeouts.
|
|
|
|---|---|---|
smtp_connect_timeout | 30s | Outbound TCP connection establishment |
smtp_helo_timeout | 300s | Remote SMTP greeting and HELO/EHLO exchange |
smtpd_timeout | 300s normally; 10s under stress | Inbound SMTP read and write operations |
Connection and protocol timers do not set the deferred retry interval
The Postfix stress configuration guide describes inbound SMTP overload handling. Those smtpd_ settings do not schedule outbound queue retries. The operating system controls TCP packet retransmission; main.cf queue timers control message delivery attempts after deferral.
Views from the trenches
Best practices
Set minimal_backoff_time to at least 300s when the receiver requires a five minute wait.
Check qshape before reducing queue_run_delay, because faster scans increase disk I/O on busy MTAs.
Read the 4xx text, but tune Postfix from the status code and queue behavior rather than the prose.
Reload Postfix before testing, then follow one queue ID through its next automatic retry.
Common pitfalls
Changing transport_retry_time rarely fixes greylisting because the SMTP transport is working.
Lowering retry intervals too far makes greylisted providers see repeated unnecessary attempts.
Forcing the whole deferred queue can create a surge and trigger rate controls elsewhere.
Treating every MX reply separately hides that one message has one deferred queue state.
Expert tips
For 300 second greylisting, modern Postfix defaults are already near the right timing.
Use destination rate delay to pace deliveries; queue backoff controls deferred retries.
Keep delivery evidence outside Postfix too, including authentication and reputation checks.
When a provider defers by policy, slow the stream before changing global queue timers.
Marketer view
Marketer from Email Geeks says Postfix can change retry timing in main.cf, but the setting has to match the failure mode rather than the wording in one log line.
2020-08-05 - Email Geeks
Marketer view
Marketer from Email Geeks says a greylisted 450 response should be treated as a temporary deferral, and retrying too quickly can keep a sender waiting.
2020-08-05 - Email Geeks
