لاگ صف ارسال را باز کرده‌اید و روبه‌روی یک پیام گیرکرده نوشته شده status=deferred با کد 451 4.3.0. سؤال واقعی این است: این پیام را دوباره بفرستم یا رهایش کنم؟ پاسخ در رقم اول همان کد است. تا وقتی این رقم را اشتباه بخوانید، هر اقدامی شانسی است.
کد خطای ایمیل یک عدد سه‌رقمی است که سرور مقابل در پاسخ به دستور SMTP برمی‌گرداند. رقم اول کلاس پاسخ را تعیین میکند، نه شدت خطا. 4xx یعنی «الان نمی‌توانم، بعداً دوباره امتحان کن» و 5xx یعنی «هرگز نمی‌پذیرم». این تفاوت، تمام تصمیم‌گیری عملیاتی شما را می‌سازد.
تفاوت ۴xx و ۵xx که همه‌چیز را تعیین میکند
خطای 4xx موقتی است. صف ارسال (queue) پیام را نگه می‌دارد و طبق زمان‌بندی خودش دوباره تلاش میکند؛ در Postfix این فاصله به‌صورت پیش‌فرض با پارامترهای queue_run_delay و maximal_queue_lifetime کنترل میشود. مقدار پیش‌فرض عمر صف ۵ روز است. اگر مشکل تا آن زمان حل نشود، پیام با وضعیت bounced برمی‌گردد و فرستنده نامهٔ برگشتی می‌گیرد.
خطای 5xx دائمی است. سرور مقصد قاطعانه رد کرده و تلاش دوباره هیچ فایده‌ای ندارد. پیام بلافاصله bounce میشود. اگر در لاگ خودتان 5xx می‌بینید و پیام را دستی دوباره به صف می‌فرستید، فقط وقت تلف می‌کنید.
یک نکتهٔ عملی: کد 4xx همیشه به معنی «مشکل از ما نیست» نیست. اگر سرور خودتان با 421 پاسخ می‌دهد، مشکل داخل زیرساخت خودتان است.
کدهای ۴xx رایج و اقدام درست
| کد | معنی | اقدام |
|---|---|---|
421 | سرویس در دسترس نیست، اتصال بسته میشود | بررسی بار سرور و محدودیت نرخ اتصال |
450 | صندوق مقصد موقتاً در دسترس نیست | هیچ کاری نکنید؛ صف خودش تلاش میکند |
451 | خطای پردازش محلی در سرور مقصد | صبر کنید؛ اگر بیش از ۲۴ ساعت ماند، تماس با مقصد |
452 | فضای ناکافی یا تعداد پیام زیاد | کاهش نرخ ارسال، بررسی سهمیه |
454 | خطای موقت احراز هویت (TLS یا AUTH) | بررسی گواهی و تنظیمات رمزنگاری |
کد 452 بیشتر از آنچه فکر می‌کنید به شما مربوط است. وقتی سرور مقصد میگوید فضای کافی ندارد، یعنی صندوق گیرنده پر است یا سهمیهٔ سرور شما به سقف خورده. اگر پیامهای خودتان گیر کرده‌اند، مدیریت سهمیه ایمیل؛ وقتی صندوق پر میشود چه کنیم؟ دقیقاً همین سناریو را باز میکند.
کد 421 را جدی بگیرید. اگر سرور شما زیر بار ارسال انبوه، اتصال‌های ورودی را با 421 می‌بندد، فرستنده‌های معتبر هم پس زده می‌شوند. اینجا محدودیت نرخ (rate limit) باید بر اساس IP و دامنه تنظیم شود، نه یک عدد ثابت برای همه.
کدهای ۵xx و آنچه دیگر برنمی‌گردد
پرتکرارترین کد در تمام تیکتهای پشتیبانی، 550 است. اما 550 یک خطای واحد نیست؛ یک خانواده است. متن بعد از کد تعیین میکند کدام‌یک از این‌هاست:
550 5.1.1— صندوق مقصد وجود ندارد. آدرس را غلط نوشته‌اید یا حساب حذف شده.550 5.7.1— رد شده بهدلیل سیاست (policy). معمولاً IP شما در لیست سیاه است یا SPF/DKIM درست تنظیم نشده.550 5.7.26— ارسال بدون احراز هویت معتبر از دامنه‌ای که مالکش نیستید.551— کاربر جابه‌جا شده؛ آدرس جدید در متن پاسخ می‌آید.552— پیام از سقف حجم مجاز بزرگ‌تر است.553— آدرس فرستنده یا گیرنده از نظر نحوی نامعتبر است.554— تراکنش رد شد؛ اغلب بهدلیل محتوای مشکوک یا شهرت دامنه.
تفاوت 5.1.1 و 5.7.1 را دست‌کم نگیرید. اولی یعنی آدرس را اصلاح کنید و تمام. دومی یعنی مشکل ساختاری در دامنه یا IP شماست و تا رفع نشود، هر آدرسی هم که بفرستید رد میشود.
چرا 550 5.7.1 بیشتر از حد انتظار می‌بینید
چون رکوردهای احراز هویت دامنه ناقص‌اند. اگر SPF دامنه‌تان IP سروری را که از آن می‌فرستید پوشش ندهد، گیرنده حق دارد رد کند. یک رکورد درست به این شکل است:
v=spf1 ip4:203.0.113.45 include:_spf.servernet.cloud -allعلامت -all در انتها یعنی «هر فرستندهٔ دیگری را رد کن». بعضی‌ها ~all می‌گذارند که نرم‌تر است، ولی برای دامنه‌ای که فقط از یک سرور می‌فرستد، -all انتخاب درست‌تری است. اگر نمی‌دانید رکوردهای دامنه‌تان الان چه هستند، اول بررسی رکورد MX و رکوردهای TXT را انجام دهید تا نقطهٔ شروع مشخص شود.
اینجا اشتباه می‌کنند
رایج‌ترین اشتباهی که در تیکت‌ها می‌بینم این است: کاربر یک 550 می‌گیرد، فرض میکند «سرور مقصد مشکل دارد» و پیام را ده بار دیگر به صف برمی‌گرداند. نتیجه چه میشود؟ صف پر میشود، سرور خودش به‌خاطر نرخ بالای تلاش‌های ناموفق در لیست سیاه قرار می‌گیرد، و حالا ایمیل‌های عادی هم به اسپم می‌روند. علامتش هم واضح است: چند روز بعد، حتی نامه‌های داخلی هم با تأخیر می‌رسند و postqueue -p صدها پیام گیرکرده نشان می‌دهد.
اشتباه دوم، برعکس: دیدن 450 و پاک کردن فوری پیام از صف. 450 موقتی است و صف خودش کارش را میکند. پاک کردن دستی فقط باعث میشود پیام گم شود بدون اینکه bounce ثبت شود و فرستنده هیچ‌وقت نفهمد.
ابزارهایی که واقعاً کمک می‌کنند
برای دیدن وضعیت صف در Postfix:
postqueue -p
postqueue -j | jq '.queue_name, .recipients[].delay_reason'خروجی JSON با jq فیلتر میشود و دلیل تأخیر هر گیرنده را جدا نشان می‌دهد. این خیلی سریع‌تر از خواندن لاگ خام است.
برای تست دستی اتصال و دیدن پاسخ سرور مقصد:
swaks --to user@example.com --server mx.example.com --from you@yourdomain.comاگر swaks نصب نیست، با openssl s_client -connect mx.example.com:25 -starttls smtp هم می‌توانید دستی EHLO بزنید و پاسخ‌ها را ببینید. این تست نشان می‌دهد خطا از سمت شماست یا از سمت مقصد.
برای بررسی شهرت IP و لیست‌های سیاه، ابزارهای آنلاین زیادی هستند، ولی قبل از هر چیز مطمئن شوید IP سرور شما در SPF دامنه هست. اگر ایمیل‌های تراکنشی مثل تأیید سفارش یا بازیابی رمز را از هاست اشتراکی می‌فرستید، این کار در بلندمدت جواب نمی‌دهد؛ ایمیل تراکنشی؛ چرا از هاست نفرستیم و جایگزین درست چیست؟ توضیح می‌دهد چرا و چه جایگزینی مناسب است.
یک تصمیم که باید بگیرید
وقتی خطای 5xx میگیرید، دو راه دارید: آدرس را اصلاح کنید و دوباره بفرستید، یا کل دامنه را از نظر احراز هویت بازبینی کنید. انتخاب من بستگی به کد دارد. اگر 5.1.1 است، فقط آدرس را درست کنید. اگر 5.7.x است، تا وقتی SPF و DKIM و DMARC را درست نکرده‌اید، فرستادن دوباره اتلاف وقت است.
هزینهٔ این بازبینی را هم بگویم: تنظیم درست DMARC با سیاست p=reject ممکن است چند روز اول باعث رد شدن بعضی ایمیل‌های معتبر شود تا گزارش‌ها را بررسی کنید. اگر حجم ایمیل‌تان بالاست، با p=none شروع کنید و بعد از یک هفته که گزارش‌ها را دیدید، سخت‌گیرانه‌ترش کنید.
برای مدیریت روزمرهٔ صندوق‌ها و بررسی اینکه کدام حساب‌ها پر شده‌اند، راهنمای کامل کار با وبمیل و امکانات آن برای مدیریت ایمیل نقطهٔ شروع خوبی است. اگر هم قصد جابه‌جایی دارید، انتقال ایمیل با IMAP؛ راهنمای کامل بدون از دست دادن داده‌ها مراحل را پوشش می‌دهد.
اگر روی زیرساخت خودتان کار می‌کنید و می‌خواهید کنترل کامل روی صف و لاگ‌ها داشته باشید، یک هاست لینوکس با دسترسی کامل به Postfix و ابزارهای خط فرمان، این کار را ساده‌تر میکند.
پرسش‌های پرتکرار
تفاوت کد ۴۵۰ و ۵۵۰ در ایمیل چیست؟
کد 450 موقتی است و سرور مقصد میگوید بعداً دوباره تلاش کن؛ صف ارسال خودش این کار را میکند. کد 550 دائمی است و پیام بلافاصله برگشت میخورد. اگر 450 میگیرید صبر کنید، اگر 550 میگیرید باید علت را رفع کنید.
خطای 550 5.7.1 یعنی چه و چطور رفع میشود؟
یعنی سرور مقصد بهدلیل سیاست امنیتی پیام شما را رد کرده، نه بهدلیل آدرس اشتباه. علت رایج، نبودن IP فرستنده در رکورد SPF دامنه، تنظیم نبودن DKIM، یا قرار داشتن IP در لیست سیاه است. اول رکوردهای دامنه را بررسی کنید و بعد درخواست رفع از لیست سیاه بدهید.
چرا ایمیلها با کد ۴۵۲ برمیگردند؟
کد 452 یعنی فضای کافی نیست یا تعداد پیامها از حد مجاز گذشته. اگر گیرنده یک نفر است، صندوقش پر شده. اگر همهٔ گیرندهها این کد را میگیرند، احتمالاً سهمیهٔ سرور خودتان یا نرخ ارسال بالاست.
آیا باید پیامهای گیرکرده در صف را دستی حذف کنم؟
فقط اگر مطمئنید خطا دائمی (5xx) است و پیام دیگر ارزشی ندارد. برای خطاهای 4xx حذف دستی باعث میشود پیام بدون ثبت bounce گم شود. بگذارید صف طبق maximal_queue_lifetime خودش تصمیم بگیرد.
دفعهٔ بعد که کد خطایی دیدید، فقط رقم اول را نگاه کنید. اگر ۴ بود، دست نگه دارید. اگر ۵ بود، دنبال علت بگردید. همین یک عادت، بیشتر تیکتهای ایمیل را از بین میبرد.