Short answer: “retry time not reached for any host” means an earlier delivery to every server for that domain failed, Exim saved the failure in its retry database, and the next attempt is not due yet. It is a wait, not the real error. Find the original failure with exinext example.com or exim_dumpdb /var/spool/exim retry, fix that cause, then force one message with exim -v -M <message-id>, which overrides the retry time.
Applies to AlmaLinux 9 with cPanel & WHM 11.138 or DirectAdmin 1.712, Exim 4.100
We ran the read-only commands on our lab servers (AlmaLinux 9.8 with cPanel & WHM 11.138, and AlmaLinux 9.8 with DirectAdmin 1.712, both on Exim 4.100.1) on 7 October 2026; the sample output below is from the DirectAdmin lab with hostnames and IPs masked. We did not force deliveries or edit the retry database on the labs; those steps are checked against the Exim specification linked below.
Table of Contents
What “retry time not reached” means
When a delivery fails with a temporary error (connection timed out, 4xx reply, DNS lookup failure), Exim does not hammer the destination. It writes a record to its retry hints database and works out the next allowed attempt from the retry rules. Until that time passes, queue runs skip the address and Exim logs a defer (==) line instead of trying again. You see three different wordings, and they point to different places:
| Message | What it means |
|---|---|
retry time not reached for any host | Every host (MX or smarthost) for the domain has a host retry record that is not due yet. Exim did not connect anywhere this time. |
retry time not reached | A routing or address-level retry record, for example a local delivery that keeps failing or a domain whose DNS lookups failed. No remote host is involved. |
all hosts for 'example.com' have been failing for a long time (and retry time not reached) | The retry rule’s final cutoff has passed. The next failure bounces the message. |
retry timeout exceeded (on a ** line) | Exim gave up and bounced the address. |
Retry data for remote hosts is kept per host and IP address, not per message. One failed connection to mx1.example.com blocks immediate attempts for every message queued for that host, which is why a whole domain can stall after a short outage.
Why you may not see the message in the log
These lines are controlled by the retry_defer log selector, which is on by default. On our labs the panels set it differently:
exim -bP log_selector- cPanel lab:
log_selector = +incoming_port +smtp_connection +all_parents +retry_defer +subject +arguments +received_recipients– “retry time not reached” lines are written to/var/log/exim_mainlog. - DirectAdmin lab: the selector included
-retry_defer, so these lines are suppressed in/var/log/exim/mainlog. Our DirectAdmin lab had 169 deferred messages and zero “retry time not reached” lines in its log. On DirectAdmin, use the retry database commands below instead of grepping the log.
On cPanel, count the messages per domain:
grep "retry time not reached" /var/log/exim_mainlog | grep -oE "for '[^']+'" | sort | uniq -c | sort -rn | headRead the retry database: exinext and exim_dumpdb
Both tools only read the database. Start with exinext, which takes a domain or address, looks up its hosts and prints any retry data:
exinext example.com
exinext bob@example.comOutput from our DirectAdmin lab for a host that had been timing out (masked):
Transport: mail.example.com 203.0.113.25 error 110: Connection timed out
first failed: 06-Oct-2026 14:03:39
last tried: 06-Oct-2026 23:51:13
next try at: 07-Oct-2026 03:13:43That tells you the real cause (error 110, connection timed out), how long it has been failing and when Exim will try next. If exinext says No retry data found, there is no record for the hosts it looked up; dump the whole database to see what is there:
exim -bP spool_directory # /var/spool/exim on both panels
exim_dumpdb /var/spool/exim retryReal entries from the DirectAdmin lab (masked):
T:mail.example.com:203.0.113.25 110 333 Connection timed out
06-Oct-2026 14:03:39 06-Oct-2026 23:51:13 07-Oct-2026 03:13:43
T:root@server.example.net -29 0 User 0 set for local_delivery transport is on the never_users list
05-Oct-2026 15:01:33 05-Oct-2026 15:01:34 05-Oct-2026 23:01:34 *How to read it, per the Exim specification:
- The key starts with
T:(transport) orR:(routing). For remote deliveries it is the host name and the failing IP; for local deliveries it is the local address. - Then an error number, an extra error code and the error text. Error 110 is a connection timeout.
- The second line holds three times: first failure, last attempt, next allowed attempt.
- A trailing
*means the cutoff of the last retry rule has passed, so the next failure will bounce.
The second record shows the plain “retry time not reached” case: it is a local delivery to root that can never succeed because of configuration, not a remote host problem. Forcing that message would just fail again.
Check the retry rules in use
exim -brt example.com
exim -bP retry_data_expire retry_interval_maxBoth labs returned the same rule and limits:
Retry rule: * * F,2h,15m; G,16h,1h,1.5; F,4d,8h;
retry_data_expire = 1w
retry_interval_max = 1dSo: retry every 15 minutes for the first 2 hours, then at growing intervals (starting at 1 hour, multiplied by 1.5 each time) up to 16 hours, then every 8 hours until 4 days, after which the address bounces. Retry records older than retry_data_expire (one week here) are ignored, which is why a host that was down a month ago does not delay new mail.
Force a delivery attempt safely
Only force after you have fixed, or at least tested, the underlying cause. Forcing against a host that is still refusing you just updates the retry record and moves the next attempt further out.
- Test the connection by hand from the server:
exim -bt bob@example.comshows the router and hosts; then try the MX on port 25, for example withopenssl s_client -starttls smtp -connect mx1.example.com:25 -quiet, and check the greeting and reply codes. - Pick one message for that domain:
exiqgrep -r example.com -i | head -1. - Force it with verbose output:
exim -v -M 1xE0Yw-00000000XWj-24Y8(use your own message ID).-Mthaws frozen messages and overrides retry hints for that message, and-vshows the SMTP conversation. - If that delivery succeeds, Exim clears the host’s retry record and the normal queue run delivers the rest. To push all mail for the domain now, run
exim -R example.com: Exim forces the first matching message past its retry time and, if it succeeds, the others follow.
Avoid exim -qff on a busy shared server. It forces a delivery attempt for every message in the queue, including frozen ones, which can mean thousands of connections to providers that are already rate-limiting you, and frozen spam suddenly being sent.
If you really need to clear a stale record (for example a host that was renumbered), the supported way is exim_fixdb: run exim_fixdb /var/spool/exim retry, type the record key exactly as exim_dumpdb showed it, then d to delete. Take a copy of /var/spool/exim/db/ first. cPanel already runs /usr/local/cpanel/scripts/exim_tidydb daily from root’s crontab (06:00 on our lab), and you can run exim_tidydb /var/spool/exim retry yourself to drop records older than 30 days. Our DirectAdmin lab had no tidydb cron job.
When the remote server is really blocking you
If the error behind the retry record is a 4xx reply or a timeout that only affects one provider, the problem is usually reputation or rate limiting, not your server. Typical signs:
- The retry record shows a
4xxreply text that mentions rate limits, “try again later”, or a blocklist name. - Only one big provider (Microsoft, Google, Yahoo) is affected while other domains deliver.
- Port 25 connections time out from your server but work from elsewhere, which can mean your provider blocks outbound SMTP or the remote side drops your IP.
Paste the full reply into our SMTP Bounce Explainer to decode it. If it names Spamhaus or another list, follow the Spamhaus 550 5.7.1 guide; retrying harder will not help until the listing is removed.
Check that it worked
exinext example.comreturnsNo retry data found, or the record’s “last tried” time is recent and the error has gone.- The queue for the domain is shrinking:
exim -bp | exiqsumm, orexiqgrep -c -r example.com. - The main log shows
=>deliveries withC="250 ...confirmations for the domain:grep "example.com" /var/log/exim_mainlog | grep " => " | tail(DirectAdmin:/var/log/exim/mainlog). - No new “retry time not reached for any host” lines for that domain appear after the next queue run (cPanel, where
retry_deferis logged).
Common problems
- You forced delivery and it still says retry time not reached. You probably ran a plain
exim -q, which honours retry times. Use-Mfor specific messages,-qfto force all non-frozen messages, or-R domain. - Every remote domain is stuck. Outbound port 25 may be blocked by the hosting provider or firewall, or a smarthost is down. Check
exim -btfor the route and test the connection by hand. - The retry record keeps coming back. The cause is not fixed: DNS for the domain is broken, the MX points at a dead host, or the receiver keeps deferring you. Read the error text in
exim_dumpdb. - Messages bounce with “retry timeout exceeded”. The address has been failing longer than the final cutoff (4 days with the lab rule). Fix the cause and ask senders to resend.
- Local addresses show retry records. Those are configuration problems, such as mail to root on a server where root cannot receive local deliveries. Set a forwarder for root rather than forcing the queue.
Official documentation: Exim spec: retry configuration · Exim spec: utilities (exinext, exim_dumpdb, exim_tidydb, exim_fixdb) · Exim spec: command line (-M, -q, -R)
Related: cPanel Exim Queue Stuck: Flush, Thaw and Delete Frozen Mail · Spamhaus 550 5.7.1 Blocked: Fix SBL, XBL, CSS, PBL and DBL · SMTP Bounce Explainer: What Your Bounce Message Means · Exim Mail Queue Report · Mail server IP blacklisted: delisting runbook
See also: Exim Log Cheat Sheet: exigrep, exiqgrep, eximstats and Log Flags · cPanel Exim Queue Stuck: Flush, Thaw and Delete Frozen Mail · Dovecot “Too Many Open Files”: Fix on cPanel and DirectAdmin
Frequently asked questions
Is “retry time not reached for any host” an error?
Not by itself. It means Exim is waiting before trying hosts that failed earlier. The real error is the one stored in the retry database, which exinext or exim_dumpdb shows.
How do I make Exim retry immediately?
Fix the cause first, then run exim -v -M with the message ID. That overrides the retry time for that message. exim -R example.com does the same for mail to one domain.
Can I just delete the retry database?
It is a hints database, so Exim can rebuild it, but deleting it removes the protection against hammering failing hosts. Delete single records with exim_fixdb or old ones with exim_tidydb instead.
Why does DirectAdmin not log retry time not reached?
On our DirectAdmin 1.712 lab the Exim log_selector includes -retry_defer, which suppresses those lines. Use exinext and exim_dumpdb to read the retry data directly.
How long does Exim keep retrying before it bounces?
It depends on the retry rule. Both our cPanel and DirectAdmin labs use F,2h,15m; G,16h,1h,1.5; F,4d,8h, which gives up after 4 days of continuous failure. Check yours with exim -brt example.com.
Maintenance record
This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.
- Maintained by
- srvScripts editorial team
- Supported versions
- AlmaLinux 9 with cPanel & WHM 11.138 or DirectAdmin 1.712, Exim 4.100
- Last full review
- Next review