Troubleshooting

Email error "retry time not reached for any host"

Reviewed on 3 min read email SMTP errors mail queue timeout

The text "retry time not reached for any host" means Exim has put off new attempts to that destination until the next scheduled time. If the bounce adds "after a long failure period", the retry period is already over and that particular message won't be delivered automatically again.

It isn't usually a sender password error. It is a mail queue state related to the receiving domain.

Common causes

  • The recipient's MX servers don't respond or refuse the connection.
  • There is a DNS problem on the receiving domain.
  • A firewall blocks the SMTP connection or lets it time out.
  • All the servers the recipient publishes are temporarily out of service.
  • The same destination has been failing for a long period and Exim has spaced out the retries.

What to check

  1. Open Track Delivery in cPanel and find the message by recipient and date; keep its ID too if it is shown.
  2. Review the earlier lines of the history: they usually show the timeout, rejection or DNS error that caused the retry state.
  3. Check whether it affects only one receiving domain or many different destinations.
  4. Check publicly that the recipient domain publishes valid MX records.

Don't resend repeatedly while the cause is unknown. If the message is still deferred, Exim will carry on according to its schedule; if you have already received a bounce saying after a long failure period, fix the problem first and then send it again.

When to step in

If only one domain fails, this text alone can't tell you who is responsible. The earlier attempts have to be reviewed to tell a failure of their MX or firewall apart from a retry state, cache or block on the sending server.

Contact support with the sender, recipient, date and full message. We can trace the delivery, check the queue and see whether the retry state needs clearing or the firewall checking. Don't send the mailbox password.

Avoid duplicate deliveries

Before resending an urgent message, confirm whether the original is still queued or has already received a final bounce. Sending it again doesn't remove the earlier one: both could be delivered when the destination recovers. If you use another channel to let the recipient know, make it clear that the original email may still be pending.

The retry interval and duration depend on the Exim configuration; this text doesn't let you work out an exact delivery time. Don't delete retry databases or force the whole queue based on generic instructions: support needs to assess the specific destination and earlier error.

You may also find useful

Something wrong or out of date? Tell us and we will review it.