Error: “Retry Time Not Reached for Any Host After a Long Failure Period” – Fix for Exim Email Servers

retry time not reached for any host after a long failure period

Understanding the Error

When a sender tries to deliver mail to your server, their mail server attempts multiple retries before bouncing the message. If your server cannot process the retry request, the message is rejected, and the sender receives this error.

In most cases, the root cause is a corrupt Exim retry database, which prevents retries from being handled correctly. However, there are other possible reasons too.

 

Email delivery issues are frustrating, especially when users report bounce errors like:

“retry time not reached for any host after a long failure period.”

This error commonly appears in cPanel / CentOS servers running Exim mail service. In this guide, we’ll explain why this happens and how you can fix it quickly.

If you receive complaints from people sending mail to you with the following error

What Does This Error Mean?

When someone tries to send you an email, their server attempts to deliver the message. If your server doesn’t respond properly, the sending server retries for a certain period.

The error “retry time not reached for any host after a long failure period” usually means:

  • The Exim retry database is corrupted.

  • Emails cannot be queued or retried correctly.

  • Senders keep receiving bounce messages until the issue is fixed.

Common Causes

  1. Corrupt Exim retry database (/var/spool/exim/db/retry)

  2. Disk space or inode issues on the server

  3. Permission errors in Exim directories

  4. Incorrect Exim configuration updates after cPanel upgrade

 

How to Fix “Retry Time Not Reached” Error in Exim

Follow these steps to resolve the issue:

Step 1: Access Your Server via SSH

Log in to your server as root using SSH.

 
ssh root@your-server-ip

Step 2: Stop Exim Service

Before fixing the retry DB, stop Exim:

 
service exim stop

Step 3: Remove the Corrupted Retry Database

Delete the corrupted retry file:

 
rm -f /var/spool/exim/db/retry

Step 4: Restart Exim Service

Now restart Exim so it regenerates a fresh retry database:

 
service exim start

Step 5: Test Email Delivery

Send a test email to confirm the issue is resolved.

Additional Troubleshooting

  • Check Logs:
    Use tail -f /var/log/exim_mainlog to identify new errors.

  • Check Disk Usage:
    Run df -h and df -i to ensure you have enough space and inodes.

  • Repair Permissions:
    Ensure /var/spool/exim/ has correct ownership (usually mailnull:mail).

  • Run Exim Check:

     
    exim -bV

    This verifies Exim’s build and configuration.

Preventing Future Issues

  1. Schedule Server Monitoring
    Set up alerts for disk usage, inode counts, and Exim service uptime.

  2. Enable Log Rotation
    Prevent log files from filling up disk space.

  3. Apply Regular Updates
    Keep cPanel/Exim updated to avoid compatibility issues.

  4. Use a Backup MX Server
    If mail delivery is critical, configure a backup mail exchanger to reduce bounce risk.

  5. Upgrade Hosting if Needed
    If your server resources are consistently maxed out, consider upgrading to high resource business hosting for stable mail flow.

Conclusion

The error “retry time not reached for any host after a long failure period” is most often caused by a corrupted Exim retry database. Fortunately, the fix is simple: stop Exim, remove the corrupted retry file, restart Exim, and test email delivery.

By monitoring your server, ensuring adequate resources, and keeping Exim updated, you can prevent this issue from recurring. For long-term stability, businesses should consider reliable hosting optimized for email delivery.

 

Extended FAQs

Q: Why do emails keep bouncing with “retry time not reached”?

A:  This happens because Exim cannot process retry requests correctly. The most common cause is a corrupted retry database, but it may also be linked to disk or inode limits on the server.

Q: Does deleting the Exim retry database cause data loss?

A: No, deleting the retry file only removes corrupted retry queue data. When Exim restarts, it automatically generates a new retry database without affecting existing mailboxes.

Q: Can I automate fixing the Exim retry database?

A:  Yes. You can create a cron job that checks if the retry database is corrupted and automatically rebuilds it. However, this should only be done after confirming the root cause of repeated corruption.

Q: Is this error specific to cPanel servers?

A: No. While it is common on cPanel/CentOS environments because they use Exim by default, the same error can also appear on standalone Linux servers running Exim.

Q: Should I switch to another mail server to avoid this issue?

A:  Not necessarily. Exim is stable and widely used. With proper monitoring, maintenance, and updates, this issue can be prevented. Switching mail servers should only be considered if your business has unique needs.

 

Check Our Offshore Hosting Services :

Offshore Hosting – Hassle Free!! cPanel Based Offshore Website Hosting Service
Premium Hosting – cPanel Hosting with power of Virtual Server

 

icon 01 7

Live Chat

Tawk : https://tawk.to/semayra

icon 02 7

24/7 Tech Support

Skype : live:.cid.725d10c0ac466bf5 Telegram : @Semayrahost

Contact us

E-mail Us

sales@semayra.com