پیام خطای 550 5.7.1 Daily sending quota exceeded یا 552 5.3.4 Message size exceeds fixed maximum message size را دیده‌اید و حالا دنبال عدد دقیق می‌گردید. مشکل این است که «محدودیت ارسال ایمیل» یک عدد واحد نیست؛ حداقل پنج سقف مستقل روی مسیر یک پیام نشسته‌اند و هرکدام جای متفاوتی اعمال میشود. تا نفهمید کدام لایه پیام شما را رد کرده، هر تغییری در تنظیمات فقط حدس‌وگمان است.
پنج سقفی که روی یک ایمیل اعمال میشود
مسیر یک پیام از mail() در PHP یا از Thunderbird تا صندوق گیرنده، از این لایه‌ها می‌گذرد و هر لایه سقف خودش را دارد:
| لایه | چه چیزی را محدود میکند | مقدار رایج | خطای نمونه |
|---|---|---|---|
| MTA محلی (Exim/Postfix) | تعداد گیرنده در هر پیام | ۵۰ تا ۱۰۰ | 452 Too many recipients |
| MTA محلی | حجم کل پیام پس از Base64 | ۲۵ تا ۵۰ مگابایت | 552 Message size exceeds |
| سهمیه حساب | تعداد پیام در ساعت/روز | ۲۰۰ تا ۵۰۰ در ساعت | 550 Daily sending quota exceeded |
| سرویسدهنده مقصد | نرخ اتصال از یک IP | متغیر، اغلب نامعلن | 421 Too many connections |
| گیرنده نهایی | حجم پیام پس از دریافت | ۱۰ تا ۲۵ مگابایت | رد بی‌صدا یا bounce |
نکته‌ای که خیلی‌ها را غافلگیر میکند لایه آخر است. فرض کنید هاست شما پیام ۳۰ مگابایتی را قبول میکند و با موفقیت ارسال میشود. Gmail همان پیام را در سمت خودش رد میکند، چون سقف واقعی‌اش پایین‌تر است. شما در لاگ هاست فقط 250 OK می‌بینید و فکر می‌کنید همه‌چیز درست بوده. تا وقتی bounce را در صندوق فرستنده باز نکنید، متوجه نمی‌شوید.
چرا حجم پیوست با حجم فایل یکی نیست
یک فایل ۲۰ مگابایتی روی دیسک، در SMTP حدود ۲۷ مگابایت میشود. دلیلش این است که پیوست‌ها با Base64 کدگذاری میشوند و این کدگذاری حدود ۳۳ درصد به حجم اضافه میکند. به آن هدرهای MIME، مرزهای multipart و کدگذاری UTF-8 متن را هم اضافه کنید.
فرمول تقریبی که در عمل جواب میدهد: حجم فایل خام ضربدر ۱٫۳۷، به‌علاوه چند کیلوبایت ثابت. پس اگر سقف پیام ۲۵ مگابایت است، بزرگ‌ترین فایلی که واقعاً رد میشود حدود ۱۸ مگابایت است، نه ۲۵.
اینجا اشتباه می‌کنند: کاربر سقف پیام را در پنل به ۵۰ مگابایت بالا می‌برد و فکر میکند مشکل حل شد. بعد پیامها بی‌سروصدا در صف MTA گیر می‌کنند، صف پر میشود و ارسال کل دامنه متوقف میشود. علامتش این است که ایمیل‌های کوچک هم دیگر نمی‌روند. سقف را فقط تا جایی بالا ببرید که گیرنده‌های واقعی‌تان قبول می‌کنند؛ بالاتر از آن فقط صف را به گروگان می‌گیرد.
سقف تعداد گیرنده و تفاوت To و BCC
سقف گیرنده در هر پیام معمولاً بین ۵۰ تا ۱۰۰ است و روی مجموع To، Cc و BCC حساب میشود، نه فقط To. اگر با BCC به ۳۰۰ نفر ایمیل بزنید، همان خطای 452 Too many recipients را می‌گیرید.
راه‌حل درست، تقسیم به دستههای کوچکتر است، نه حذف BCC. اما تقسیم ساده هم کافی نیست: اگر ۱۰ پیام پشت سر هم و بدون فاصله به یک دامنه بفرستید، سرور مقصد آن را به‌عنوان الگوی ارسال انبوه تشخیص میدهد و اتصال را با 421 می‌بندد. بین دسته‌ها حداقل ۳۰ تا ۶۰ ثانیه فاصله بگذارید.
برای ارسال به لیست بزرگتر از چند صد نفر، SMTP هاست جای درستی نیست. اینجا بحث ایمیل تراکنشی و چرایی نفرستادن از هاست جدی میشود؛ سرویس‌های اختصاصی ارسال انبوه، مدیریت صف، IP گرم‌شده و گزارش bounce را خودشان انجام می‌دهند و شما را از دست‌وپنجه نرم‌کردن با سقف‌های محلی خلاص می‌کنند.
سقف ارسال ساعتی و روزانه از کجا می‌آید
این سقف برای جلوگیری از سوءاستفاده است، نه برای محدود کردن شما. اگر حساب یک کاربر به هر دلیلی (اسکریپت آسیب‌پذیر، فرم تماس بدون captcha، رمز لو رفته) به ابزار اسپم تبدیل شود، سقف ساعتی جلوی ارسال صد هزار پیام در ده دقیقه را می‌گیرد و به شما فرصت میدهد قبل از اینکه IP دامنه در blacklist بیفتد، متوجه شوید.
علامت درگیر شدن با این سقف را در لاگ Exim با این دستور ببینید:
exim -bp | wc -l
grep "sending quota" /var/log/exim/mainlog | tail -20اگر خروجی دستور اول عدد بزرگی برگرداند و در لاگ دوم خطوط تکراری ببینید، یعنی پیامها در صف مانده‌اند و سقف فعال شده. پاک‌کردن صف بدون رفع علت، فقط چند ساعت بعد همان وضعیت را برمی‌گرداند.
سقف ساعتی را چطور بالا ببرید
در بیشتر کنترل‌پنل‌ها این عدد قابل تغییر است، اما هر تغییری باید با دلیل باشد. اگر واقعاً خبرنامه‌ای با ۸۰۰ مشترک دارید که هفته‌ای یک بار می‌فرستید، بالا بردن سقف منطقی است. اگر اسکریپتی دارید که برای هر ثبت‌نام سه ایمیل می‌فرستد و روزی ۲۰۰۰ ثبت‌نام دارید، مشکل شما سقف نیست؛ معماری ارسال است.
سهمیه صندوق، محدودیتی که فراموش میشود
سقف ارسال فقط یک طرف ماجراست. وقتی صندوق گیرنده پر میشود، سرور پیام‌های جدید را با 552 Mailbox full رد میکند و فرستنده فکر میکند دامنه شما خراب است. اگر با پیام «صندوق پر است» یا bounce های عجیب روبه‌رو شده‌اید، مدیریت سهمیه ایمیل و راه‌حل پر شدن صندوق دقیقاً همین سناریو را باز میکند.
یک نکته عملی: سهمیه صندوق و سقف ارسال دو تنظیم جدا هستند و بالا بردن یکی روی دیگری اثر ندارد. اگر هر دو را در یک تیکت مطرح کنید، سریع‌تر به جواب می‌رسید.
چطور بفهمید کدام سقف شما را رد کرده
- کد سه‌رقمی SMTP را بخوانید.
5xxیعنی رد دائمی،4xxیعنی موقت و قابل تلاش مجدد. - متن خطا را کامل کپی کنید، نه فقط کد را. عبارت
quotaبه سقف ارسال اشاره دارد،sizeبه حجم،recipientsبه تعداد گیرنده. - لاگ MTA را با همان بازه زمانی تطبیق دهید تا بفهمید خطا از سمت شما آمده یا از سرور مقصد.
- اگر خطا از سمت مقصد است، رکوردهای دامنه را بررسی کنید. نبودن یا اشتباه بودن SPF و DKIM باعث رد شدن پیام میشود، حتی وقتی هیچ سقفی رد نشده. با ابزار بررسی رکورد MX و رکوردهای دامنه می‌توانید وضعیت فعلی را ببینید.
در تجربه من، بیش از نیمی از مواردی که با عنوان «محدودیت ارسال» گزارش میشود، در واقع مشکل احراز هویت دامنه است. پیام ارسال میشود، سقفی هم رد نمیشود، اما در سمت گیرنده به اسپم می‌رود یا کلاً رد میشود. اگر پیامها ارسال میشوند ولی به دست نمی‌رسند، مسیر عیب‌یابی کاملاً متفاوتی لازم است که در راهنمای رفع مشکل اسپم شدن ایمیل‌ها قدم‌به‌قدم آمده.
انتخاب بین بالا بردن سقف و تغییر معماری
اگر حجم ارسال شما زیر چند هزار پیام در روز است و همه‌شان واقعاً به گیرنده‌های واقعی می‌رود، بالا بردن سقف روی همان هاست کافی است. ساده‌تر، ارزان‌تر و بدون وابستگی اضافه.
اما اگر وارد محدوده ارسال انبوه شده‌اید، بالا بردن سقف اشتباه است. هزینه‌اش این است که IP مشترک هاست را با reputation خودتان گره می‌زنید؛ یک کمپین بد می‌تواند deliverability همه دامنه‌های روی آن سرور را پایین بیاورد. در آن حالت، جدا کردن مسیر ارسال انبوه از مسیر ایمیل کاری، تصمیم درست است، حتی اگر کار بیشتری ببرد.
برای دامنه‌های کاری که روزی چند صد ایمیل معمولی می‌فرستند، یک هاست لینوکس با Exim تنظیم‌شده و سقف‌های شفاف کافی است؛ فقط قبل از راه‌اندازی کمپین، عدد سقف را از پنل بخوانید و دسته‌بندی گیرندگان را از همان اول درست بچینید.
قبل از هر تغییر دیگری، سه چیز را چک کنید: کد و متن کامل خطا، حجم واقعی پیام پس از Base64، و تعداد گیرنده در هر دسته. در بیشتر موارد، جواب در همین سه عدد است. اگر بعد از این‌ها هنوز گیر کردید، مستندات و پایگاه دانش و در نهایت بلاگ سرورنت موارد مشابه را با جزئیات پیکربندی پوشش داده‌اند.
پرسش‌های پرتکرار
سقف ارسال ایمیل در هاست اشتراکی چقدر است؟
عدد ثابتی وجود ندارد و بین سرویسدهندهها متفاوت است؛ محدوده رایج بین ۲۰۰ تا ۵۰۰ پیام در ساعت و چند هزار پیام در روز است. عدد دقیق سرویس خودتان را از پنل کنترل یا مستندات همان سرویسدهنده بگیرید، چون حدس زدن باعث میشود سقف را در بدترین زمان لمس کنید.
چرا ایمیل با پیوست ۲۰ مگابایتی ارسال نمیشود؟
چون کدگذاری Base64 حجم پیوست را حدود ۳۳ درصد افزایش میدهد و یک فایل ۲۰ مگابایتی در SMTP نزدیک ۲۷ مگابایت میشود. اگر سقف پیام ۲۵ مگابایت باشد، این پیام رد میشود. برای فایلهای بزرگتر از ۱۰ مگابایت، لینک دانلود بفرستید نه پیوست.
تفاوت خطای 550 و 452 در SMTP چیست؟
کدهای 5xx خطای دائمی هستند و تلاش مجدد فایدهای ندارد؛ مثل 550 Daily sending quota exceeded که یعنی سقف روزانه پر شده. کدهای 4xx موقتاند و ارسالکننده باید بعداً دوباره تلاش کند؛ مثل 452 Too many recipients که با تقسیم پیام به دستههای کوچکتر حل میشود.
آیا بالا بردن سقف ارسال، مشکل اسپم شدن را حل میکند؟
نه. سقف ارسال و deliverability دو موضوع جدا هستند. اگر پیامها ارسال میشوند ولی به اسپم میروند، مشکل در رکوردهای SPF، DKIM و DMARC یا reputation دامنه است، نه در سقف. اول با بررسی رکوردهای دامنه شروع کنید و بعد سراغ تنظیمات سقف بروید.