جدید!
سرور ابری ساعتی فعال شد. ۱۰۰ هزار تومان اعتبار هدیه بگیرید
به اشتراک بگذارید
رفع خطای Retry Time Not Reached در ارسال ایمیل یکی از پرتکرارترین دغدغههای مدیران سرور و صاحبان وبسایت است. تصور کنید ایمیل مهمی را ارسال کردهاید؛ فاکتور مشتری، تأیید سفارش یا یک پیشنهاد تجاری حیاتی. اما بهجای رسیدن به مقصد، با پیغام خطای Retry time not reached for any host after a long failure period مواجه میشوید. این یعنی سرور شما عملاً دست از تلاش برای ارسال ایمیل برداشته و ایمیلهایتان در صف گیر کردهاند.
💡 خلاصه مشکل: خطای Retry Time Not Reached زمانی رخ میدهد که میلسرور Exim نتواند ایمیلها را پس از چند بار تلاش ناموفق مجدداً ارسال کند؛ معمولاً بهدلیل خرابی دیتابیس Retry این خطا رخ می دهد.
حتماً زمانی که این مقاله را باز کردهاید، به دنبال راهحلی سریع و قابلاعتماد برای رفع این مشکل هستید. خبر خوب اینکه این خطا مختص سرورهایی است که از Exim بهعنوان میلسرور استفاده میکنند، یعنی اکثر سرورهای cPanel و بسیاری از سرورهای DirectAdmin. و در بیشتر موارد با چند دستور ساده از طریقSSH قابل حل است. در ادامه، همراه تیم وبداده باشید تا از صفر تا صد، هم دلیل این خطا را درک کنید و هم بهصورت عملی آن را رفع کنید، حتی اگر تازهکار باشید.
سرور مجازی وب دادهVPS وب داده با حضور قدرتمند در بیش از 9 لوکیشن استراتژیک در سراسر جهان…
برای مشاهده موقعیتهای
سرور های مجازی وبداده
روی دکمه زیر کلیک کنید
سرور های مجازی وبداده
روی دکمه زیر کلیک کنید
آنچه در این مقاله میخوانید:
خطای Retry Time Not Reached در ایمیل چیست؟
وقتی از هاست یا سرور خودتان ایمیل میفرستید، پشتصحنه یک نرمافزار قدرتمند به نام Exim مسئول ارسال و تحویل پیامها است. حالا فرض کنید ایمیلی ارسال میکنید و سرور مقصد در دسترس نیست — مثلاً خاموش شده، مشکل شبکه دارد یا DNS درست تنظیم نشده. در این حالت Exim ایمیل را در صف (Queue) قرار میدهد و بعد از مدتی دوباره تلاش میکند.
اطلاعات این تلاشهای ناموفق در یک فایل داخلی به نام Retry Database ذخیره میشود. البته نگران نباشید؛ این یک دیتابیس واقعی مثل MySQL نیست، بلکه فقط یک فایل باینری ساده (از نوع DBM) است که اگزیم اطلاعات زمانبندی تلاشهای مجدد را در آن نگه میدارد. چیزی شبیه یک دفترچه یادداشت مخصوص پستچی سرور.
حالا مشکل از کجا شروع میشود؟ اگر این فایل بر اثر قطعی برق، پر شدن فضای دیسک، یا ریستارت ناگهانی سرور آسیب ببیند و غیرقابلخواندن شود (اصطلاحاً corrupt شود)، اگزیم دیگر نمیتواند بفهمد کِی باید ایمیلها را دوباره ارسال کند. نتیجه؟ پیغام خطای معروف:
retry time not reached for any host after a long failure periodبه زبان ساده، سرور شما میگوید: «من قبلاً تلاش کردم و نشد؛ هنوز وقت تلاش دوباره نرسیده.» ولی مشکل اینجاست که بهخاطر خرابی دیتابیس، این «وقت» هیچوقت نمیرسد و ایمیلها برای همیشه گیر میکنند.
Exim چیست و چه نقشی در ارسال ایمیل دارد؟
Exim یک MTA یا Mail Transfer Agent است؛ یعنی عامل انتقال ایمیل. اگر بخواهیم ساده بگوییم، Exim مثل پستچی سرور شماست. هر وقت ایمیلی ارسال یا دریافت میشود، این اگزیم است که مسئول تحویل آن پیام به مقصد صحیح است.
در اکثر سرورهای cPanel و بسیاری از سرورهای DirectAdmin، اگزیم بهصورت پیشفرض نصب و فعال است. طبق مستندات رسمی Exim در سال 2026، این نرمافزار از مکانیزم Retry هوشمند برخوردار است که بر اساس آدرس IP مقصد (نه بر اساس هر پیام) عمل میکند. یعنی اگر یک هاست مقصد از کار بیفتد، اگزیم ارسال تمام ایمیلها به آن هاست را به تعویق میاندازد، نه فقط یک ایمیل خاص را.
ساختار ارسال ایمیل در سرور:
📧 ایمیل شما
⬇️
🖥️ Exim (MTA)
⬇️
┌─────────────────────┐
│ تلاش اول ارسال │
│ ✅ موفق ➡️ تحویل │
│ ❌ ناموفق ⬇️ │
├─────────────────────┤
│ 🗄️ دیتابیس Retry │
│ ذخیره زمان تلاش │
│ بعدی │
├─────────────────────┤
│ تلاش دوم، سوم... │
│ ❌ بازهم ناموفق │
│ ⬇️ │
│ ⚠️ retry time not │
│ reached! │
└─────────────────────┘دیتابیس Retry اگزیم چطور کار میکند؟
دیتابیس Retry در مسیر /var/spool/exim/db/ قرار دارد و شامل فایلهایی مثل retry، retry.lockfile، wait-remote_smtp و wait-remote_smtp.lockfile است. وقتی ایمیلی ارسال نمیشود، اگزیم اطلاعاتی شامل زمان اولین خطا، زمان آخرین تلاش و زمان محاسبهشده برای تلاش بعدی را در این دیتابیس ثبت میکند.
طبق تنظیمات پیشفرض اگزیم، دادههای قدیمیتر از 7 روز در دیتابیس Retry نادیده گرفته میشوند. اما اگر دیتابیس خراب (corrupt) شود، اگزیم نمیتواند این اطلاعات را بخواند و در نتیجه هیچ تلاش مجددی انجام نمیدهد. مثل اینکه پستچی دفترچه آدرسش پاره شده باشد و دیگر نتواند نامهها را تحویل دهد.
☁️ نکته فنی: طبق داکیومنت رسمی Exim، حذف فایلهای دیتابیس Retry خطری ندارد. اگزیم پس از ریستارت، دیتابیس جدید و سالمی میسازد. این فایلها فقط hints یا راهنما هستند، نه دادههای حیاتی.
دلایل رایج بروز خطای Retry Time Not Reached
مشکل Retry Time Not Reached در ارسال ایمیل میتواند دلایل مختلفی داشته باشد. مهمترین نکته این است که فقط به یک دلیل بسنده نکنید؛ گاهی ترکیبی از چند مشکل باعث بروز این خطا میشود. در ادامه رایجترین دلایل این ارور را بررسی میکنیم.
1- خرابی دیتابیس Retry اگزیم
این شایعترین دلیل است. فایلهای دیتابیس در مسیر /var/spool/exim/db/ ممکن است بر اثر ریستارت ناگهانی سرور، پر شدن فضای دیسک، یا حتی مشکلات سختافزاری خراب شوند. وقتی دیتابیس corrupt میشود، اگزیم نمیتواند رکوردهای retry را بخواند و تمام ایمیلهای صفشده با خطای «retry time not reached» رد میشوند.
2- مشکلات DNS و رکوردهای MX
اگر رکوردهای MX دامنه مقصد درست resolve نشوند، یا DNS سرور شما (فایل /etc/resolv.conf) به nameserver معتبری اشاره نکند، اگزیم نمیتواند آدرس سرور ایمیل مقصد را پیدا کند. این مشکل بعد از چند بار تلاش ناموفق، منجر به ثبت خطا در دیتابیس Retry و در نهایت پیغام retry time not reached میشود.
3- بلاک شدن IP سرور
اگر IP سرور شما در یکی از بلاکلیستهای معتبر مثل Spamhaus یا Barracuda ثبت شده باشد، سرورهای مقصد (مثل Gmail یا Yahoo) اتصال سرور شما را رد میکنند. اگزیم هم بعد از چندین بار تلاش، این میزبان را بهعنوان «شکستخورده» علامتگذاری میکند و دیگر تلاش نمیکند.
4- بسته بودن پورت 25 خروجی
برخی دیتاسنترها و ارائهدهندگان VPS (خصوصاً برای سرورهای جدید) پورت 25 خروجی را مسدود میکنند تا از ارسال اسپم جلوگیری شود. اگر پورت 25 بسته باشد، اگزیم اصلاً نمیتواند به سرورهای مقصد وصل شود و مشکل ارسال ایمیل در سیپنل یا دایرکتادمین پیش میآید. برای تست میتوانید این دستور را بزنید:
telnet gmail-smtp-in.l.google.com 25اگر پاسخ Connected نگرفتید، احتمالاً این پورت خروجی مسدود است و باید با دیتاسنتر تماس بگیرید.
رفع خطای Retry Time Not Reached در ارسال ایمیل با SSH
در این بخش همراه ما باشید تا بهصورت عملی و گامبهگام، رفع مشکل ارسال ایمیل را بررسی کنیم. بسته به کنترل پنل سرور شما سه روش اصلی برای خطای Retry time not reached از طریق SSH وجود دارد.
⚠️ هشدار: تمام دستورات زیر باید با دسترسی Root از طریق SSH اجرا شوند. اگر هاست اشتراکی دارید و دسترسی SSH ندارید، باید از پشتیبانی هاستینگ خود کمک بگیرید.
روش اول: پاکسازی دیتابیس Retry در سیپنل
اگر سرور شما cPanel/WHM دارد، این روش سریعترین راهحل است. مراحل زیر را با دسترسی Root انجام دهید:
🔸 مرحله 1: ابتدا به ترمینال سرور SSH بزنیدیا از بخش Terminal در WHM استفاده کنید.
🔸 مرحله 2: به مسیر دیتابیس اگزیم بروید و فایلهای خراب را حذف کنید. پس ابتدا ابزار پاکسازی cPanel را اجرا کنید:
/usr/local/cpanel/scripts/exim_tidydb
🔸 مرحله 3: فایلهای Retry را بهجای حذف، به یک بکاپ منتقل کنید (روش ایمنتر):
cd /var/spool/exim/db
mv -vi retry{,.$(date +%s)}
mv -vi retry.lockfile{,.$(date +%s)}
mv -vi wait-remote_smtp{,.$(date +%s)}
mv -vi wait-remote_smtp.lockfile{,.$(date +%s)}
📌 با این کار فایلهای قدیمی حذف نمیشوند بلکه با یک پسوند تاریخ تغییر نام میگیرند. اگر مشکلی پیش آمد، میتوانید آنها را برگردانید.
🔸 مرحله 4: سرویس اگزیم را ریستارت کنید تا فایلهای جدید ساخته شوند:
/scripts/restartsrv_exim
📌 نکته مهم: حذف فایل retry باعث از بین رفتن ایمیلهای موجود نمیشود. اگزیم پس از ریستارت، دیتابیس جدیدی میسازد و ایمیلهای موجود در صف را دوباره پردازش میکند.
🔸 مرحله 5: ایمیلهای صفشده را فوراً مجدد ارسال کنید:
exim -qff🔸 مرحله 6: لاگ را بررسی کنید تا مطمئن شوید مشکل حل شده:
tail -f /var/log/exim_mainlog
این روش مطابق با مستندات رسمی پشتیبانی cPanel و منابع فنی معتبر 2026 تأیید شده است.
روش دوم: رفع خطا Retry time not reached ارسال ایمیل در دایرکت ادمین
اگر از DirectAdmin استفاده میکنید، مسیر و دستورات مشابه هستند؛ اما نکات کوچکی تفاوت دارد:
# حذف کامل فایلهای دیتابیس
rm -f /var/spool/exim/db/*
# ریستارت اگزیم
service exim restart
در دایرکتادمین، لاگ ایمیل معمولاً در مسیر /var/log/exim/mainlog قرار دارد (بهجای /var/log/exim_mainlog در سیپنل). برای بررسی وضعیت ارسال:
tail -100 /var/log/exim/mainlog | grep "retry"🔸 نکته فنی: در دایرکتادمین، اگر مشکل تکرار شد، حتماً پورت 25 خروجی و تنظیمات فایروال را هم بررسی کنید. طبق گزارشهای انجمن رسمی DirectAdmin در سال 2025، بسته بودن پورت 25 و مشکلات DNS، شایعترین دلایل این خطا در کنار خرابی دیتابیس هستند.
روش سوم: استفاده از exim_tidydb
اگر نمیخواهید کل دیتابیس را حذف کنید و ترجیح میدهید فقط رکوردهای قدیمی را پاکسازی کنید، ابزار exim_tidydb انتخاب بهتری است:
/usr/sbin/exim_tidydb -t 1d /var/spool/exim retry > /dev/null
/usr/sbin/exim_tidydb -t 1d /var/spool/exim reject > /dev/null
/usr/sbin/exim_tidydb -t 1d /var/spool/exim wait-remote_smtp > /dev/nullاین دستورات تمام رکوردهای قدیمیتر از ۱ روز را حذف میکنند. سپس اگزیم را ریستارت کنید:
service exim restart📌 در سرورهای cPanel، نسخه مخصوص این ابزار هم وجود دارد که طبق مستندات 2026 توصیه شده:
/usr/local/cpanel/scripts/exim_tidydb -t 1m /var/spool/exim retryبررسی لاگ اگزیم بعد از رفع مشکل در ارسال ایمیل
بعد از اجرای هر کدام از روشهای بالا، حتماً لاگ اگزیم را بررسی کنید تا مطمئن شوید خطای Retry timeout exceeded رفع شده:
# برای سیپنل:
tail -f /var/log/exim_mainlog
# برای دایرکت ادمین:
tail -f /var/log/exim/mainlogاگر ایمیلها با موفقیت ارسال شوند، خروجی مشابه زیر را میبینید:
=> user@example.com R=lookuphost T=remote_smtp H=mail.example.com [x.x.x.x]اگر هنوز خطا دارید، باید دلایل ریشهای (DNS، بلاکلیست و پورت) را بررسی کنید.
بررسی تنظیمات DNS و رکوردهای MX
گاهی اوقات مشکل ارسال ایمیل در سیپنل یا دایرکتادمین به دیتابیس Retry مربوط نیست؛ ریشه مشکل در تنظیمات DNS سرور است. وقتی اگسیم نتواند آدرس سرور مقصد را از طریق DNS پیدا کند، ایمیلها در صف میمانند و بعد از مدتی با خطای Retry time not reached برگشت میخورند.
تست صحت رکوردها با Dig و NSlookup
ابتدا مطمئن شوید DNS سرورتان (resolverها) درست کار میکنند:
# بررسی فایل resolver
cat /etc/resolv.conf
# تست resolve یک دامنه
dig gmail.com MX +short
# یا با nslookup
nslookup -type=mx gmail.comاگر خروجی خالی بود یا Timeout گرفتید، NameServerهای فایل /etc/resolv.conf را به یک DNS معتبر مثل Google تغییر دهید. کافی است از طریق دستور nano /etc/resolv.conf وارد محیط ویرایش فایل شوید و نیم سرورهای زیر را جایگزین کنید.
nameserver 8.8.8.8
nameserver 8.8.4.4⚠️ هشدار: در بعضی VPSها، سرویس NetworkManager بعد از ریستارت سرور فایل
resolv.conf را به حالت قبلی برمیگرداند. اگر بعد از ریبوت دوباره مشکل داشتید، باید DNS را از طریق تنظیمات شبکه سیستمعامل تغییر دهید. مثلاً در AlmaLinux/CentOS:nmcli con mod "System eth0" ipv4.dns "8.8.8.8 8.8.4.4"
systemctl restart NetworkManager💡 بیشتر بدانید: چگونه DNS را با dig و nslookup عیب یابی کنیم؟
بررسی بلاک لیست IP سرور
اگر دیتابیس Retry سالم است و DNS هم درست کار میکند، ممکن است IP سرور شما BlackList شده باشد. برای بررسی:
- سایت MXToolbox را باز کنید
- IP سرور خود را وارد کنید
- نتایج را بررسی کنید
اگر IP شما در لیست سیاه بود، باید با هر سرویس بلاکلیست جداگانه درخواست حذف (Delist) بدهید. همچنین دلیل بلاکلیست شدن (مثلاً ارسال اسپم از یکی از اکانتها) را پیدا و رفع کنید.
مقایسه دلایل خطای Retry timeout در ارسال ایمیل
| دلیل خطا | نشانه تشخیصی | راهحل | سطح دشواری |
|---|---|---|---|
| خرابی دیتابیس Retry | خطا بلافاصله بعد از ارسال ظاهر میشود | حذف فایلهای DB و ریستارت Exim | 🟢 آسان |
| مشکل DNS/Resolver | dig نتیجه نمیدهد یا TimeOut میخورد | اصلاح /etc/resolv.conf | 🟢 آسان |
| رکورد MX نادرست | MX به آدرس اشتباه اشاره میکند | اصلاح رکوردهای DNS دامنه | 🟡 متوسط |
| بلاکلیست شدن IP | لاگها حاوی Rejected یا 550 هستند | درخواست Delist و رفع علت اسپم | 🟡 متوسط |
| پورت 25 مسدود | telnet به پورت 25 TimeOut میخورد | تماس با دیتاسنتر | 🔴 نیاز به هماهنگی |
| پر شدن فضای دیسک | df -h فضای پر نشان میدهد | آزادسازی فضا و ریستارت Exim | 🟡 متوسط |
| مشکل فایروال سرور | ایمیلهای داخلی ارسال میشوند ولی خارجی نه | بررسی قواعد IPtables یا Firewalld | 🟡 متوسط |
جلوگیری از تکرار مشکل ارسال ایمیل
رفع مشکل خوب است؛ اما باید از تکرار آن جلوگیری کنید. چند راهکار ساده وجود دارد که میتوانید انجام دهید تا خطای Retry timeout exceeded در ارسال ایمیل دوباره سراغتان نیاید:
- مانیتورینگ فضای دیسک: پر شدن دیسک یکی از دلایل خرابی دیتابیس است. با
df -hوdf -iفضا و inodeها را بررسی کنید. - تنظیم Log Rotation: فایلهای لاگ اگزیم میتوانند حجم زیادی اشغال کنند. مطمئن شوید logrotate فعال است.
- بهروزرسانی منظم: اگزیم و cPanel/DirectAdmin را آپدیت نگه دارید تا باگهای شناختهشده رفع شوند.
- تنظیم Cron Job پاکسازی: میتوانید یک cron job هفتگی برای پاکسازی دیتابیس Retry تنظیم کنید:
# اضافه کردن به crontab
0 3 * * 0 /usr/sbin/exim_tidydb -t 1d /var/spool/exim retry > /dev/null 2>&1- تنظیم SPF، DKIM و DMARC: این رکوردهای DNS از بلاک لیست شدن IP سرور جلوگیری میکنند.
- استفاده از Backup MX: اگر ایمیل برای کسبوکارتان حیاتی است، یک سرور MX پشتیبان تنظیم کنید.
نتیجهگیری: جمعبندی رفع خطای Retry Time Not Reached
در این مقاله از بلاگ وب داده، بهصورت کامل بررسی کردیم که خطای retry time not reached for any host after a long failure period چیست، چرا اتفاق میافتد و چطور میتوان آن را رفع کرد. دیدیم که شایعترین دلیل، خرابی دیتابیس Retry اگزیم است که با چند دستور ساده SSH قابل رفع است.
مهمترین نکاتی که باید به خاطر بسپارید:
- همیشه اول دیتابیس Retry را بازسازی کنید (سریعترین راهحل)
- DNS و رکوردهای MX سرور را بررسی کنید.
- وضعیت بلاکلیست IP را چک کنید.
- پورت 25 خروجی را تست کنید.
- برای پیشگیری، مانیتورینگ و cron job پاکسازی تنظیم کنید.
در صورتی که سوالی داشتید، میتوانید در بخش ثبت دیدگاه با ما در ارتباط باشید. امیدوارم این مقاله از بلاگ وبداده برای شما مفید بوده باشد.
سوالات متداول رفع خطای retry timeout exceeded در Exim
خطای Retry time not reached دقیقاً به چه معناست؟
این خطا به این معناست که اگزیم (Exim) قبلاً تلاش کرده ایمیل شما را ارسال کند و ناموفق بوده. و حالا طبق زمانبندی داخلی Exim، هنوز وقت تلاش مجدد نرسیده. معمولاً دلیل اصلی، خرابی دیتابیس Retry است که باعث میشود این زمانبندی دچار اختلال شود.
آیا حذف فایل Retry باعث از بین رفتن ایمیلها میشود؟
خیر. فایل retry فقط حاوی اطلاعات زمانبندی تلاشهای مجدد است. ایمیلهای موجود در صف (Queue) بهصورت جداگانه در مسیر /var/spool/exim/input/ ذخیره شدهاند و با حذف دیتابیس آسیبی نمیبینند.
چرا ایمیلهای داخلی ارسال میشوند ولی ایمیل به Gmail نمیرود؟
ایمیلهای داخلی نیازی به خروج از سرور ندارند. اگر فقط ایمیلهای خارجی مشکل دارند، احتمالاً پورت 25 خروجی بسته است، IP بلاک لیست شده، یا مشکل DNS وجود دارد.
تفاوت خطای retry time not reached با retry timeout exceeded چیست؟
هر دو از خانواده خطاهای Retry اگزیم هستند. Retry time not reached یعنی هنوز نوبت تلاش مجدد نرسیده. خطای Retry timeout exceeded یعنی تعداد تلاشها تمام شده و اگزیم دیگر سعی نمیکند. در هر دو مورد، بازسازی دیتابیس Retry معمولاً مشکل را حل میکند.
خرابی دیتابیس Retry در Exim سیپنل چطور تشخیص داده میشود؟
اگر بلافاصله بعد از ارسال ایمیل (بدون هیچ تأخیری) خطای retry time not reached در لاگ ظاهر شد، بهاحتمال بسیار زیاد دیتابیس خراب است. میتوانید با دستور exim_dumpdb /var/spool/exim retry هم محتوای دیتابیس را بررسی کنید.
