On a cPanel server, Exim may defer a message with one of these lines:
retry time not reached for any host
all hosts for 'example.net' have been failing for a long timeThis is usually not the original delivery error. Exim records temporary failures for a destination and schedules the next attempt according to its retry rules. When another queue run reaches the same destination too soon, Exim reports that the retry time has not been reached.
Clearing the retry database before fixing the first failure only makes Exim repeat the same unsuccessful connection. Diagnose the destination and the earlier log entry first.
Identify one deferred recipient
List the queue:
exim -bpChoose one affected message and note its message ID and recipient domain. Do not force the entire queue while the cause is unknown. A large forced retry can increase load, trigger remote rate limits and bury the useful error in new log entries.
Use cPanel's recommended exinext tool with an affected recipient or domain:
exinext recipient@example.netThe output can show the destination host, first and last failure, next retry time and the underlying result, such as connection timed out or connection refused. cPanel documents this as the first diagnostic step in its current Exim retry guidance.
Read the message and delivery log
Inspect the selected message's delivery history:
exim -Mvl MESSAGE_IDThen search the main Exim log for the message ID or recipient domain. cPanel's default logs are:
/var/log/exim_mainlog/var/log/exim_rejectlog/var/log/exim_paniclog
The panic log should normally be empty. If it contains current entries, address those before treating the issue as a remote-domain retry.
Read backward to the first defer, not just the later retry time not reached line. The original result determines the fix.
Common original failures
Connection timeout
A timeout can result from blocked outbound port 25, a provider network policy, a firewall rule, broken IPv4 or IPv6 routing, or a remote MX that is not responding.
Resolve the recipient's MX records:
dig +short MX example.netTest the specific address family and destination from the affected server. If IPv6 attempts fail while IPv4 works, correct the server's IPv6 route or Exim configuration rather than repeatedly clearing retry data.
Connection refused
The destination resolved, but nothing accepted the SMTP connection at that address and port. Confirm the current MX result and whether all advertised MX hosts fail. A single remote host failure may be temporary; a wrong DNS record requires the recipient domain's administrator to correct it.
Temporary SMTP response
Responses beginning with 4 are temporary deferrals. They can indicate rate limiting, greylisting, reputation problems, policy limits or a remote service incident. Preserve the complete response text because it often includes a provider-specific explanation.
Do not treat SPF, DKIM and DMARC as a universal fix for a network timeout. Authentication matters when the remote host accepts the connection and evaluates the message, but it cannot repair blocked port 25 or broken DNS.
DNS failure
If MX or address lookups fail, compare command-line DNS results with the resolver messages in Exim's log. Check the server's configured resolvers, firewall access to DNS and DNSSEC-related failures. Avoid replacing resolvers blindly without understanding whether the server or the destination zone is at fault.
Routing or smarthost configuration
After a migration or mail-routing change, confirm that cPanel's Email Routing setting and any smarthost configuration match the intended path. A local domain incorrectly marked remote, or a remote domain treated as local, produces a different fix from a failed Internet delivery.
Correct the cause before clearing retry state
Examples of a real correction include:
- Opening an approved outbound SMTP path with the hosting provider
- Fixing the server's DNS resolver or IPv6 route
- Correcting the recipient domain's MX record
- Repairing a firewall rule
- Updating an incorrect smarthost credential or route
- Waiting for a legitimate remote temporary failure to expire
- Correcting hostname, PTR or sender authentication when the remote response specifically identifies it
If delivery reaches the remote server but messages land in spam, use the separate guide on why server email ends up in spam. That is a deliverability problem, not necessarily an Exim retry-scheduling problem.
Clear the retry database only after the fix
Once the underlying failure is corrected, you can wait for Exim's next scheduled attempt. If delivery needs to resume immediately, cPanel currently recommends:
/usr/local/cpanel/scripts/exim_tidydb -t 1m /var/spool/exim retryThis clears retry records older than one minute. It is safer and more targeted than deleting arbitrary files under /var/spool/exim/db/. See cPanel's current retry database procedure.
Retry the selected message first:
exim -M MESSAGE_IDWatch its new log entries and confirm a completed delivery. Only then allow normal queue processing to handle the remaining messages.
Restart Exim only when the service needs it
The retry message does not normally require an Exim restart. Restart only after a configuration or service problem that requires it. On cPanel, use the supported wrapper:
/usr/local/cpanel/scripts/restartsrv_eximIf the restart fails, read exim_paniclog and the wrapper output rather than entering a restart loop.
Verify the incident is resolved
- Send a controlled message to the previously failing destination.
- Confirm the new message receives a completed-delivery log entry.
- Check that the queue size is falling rather than growing.
- Test more than one recipient domain so a remote-only incident is not mistaken for a server-wide repair.
- Review the oldest queued messages for unrelated failures.
- Confirm monitoring alerts on queue growth and repeated deferrals.
If a cPanel server has recurring queue, routing or reputation problems, cPanel server management can investigate the complete mail path instead of repeatedly clearing Exim's retry history.
Need experienced cPanel and WHM support?
Our engineers manage cPanel servers, troubleshoot service failures and keep hosting systems secure and responsive.
