راهاندازی میلسرور اختصاصی روی سرور خودتان، از نظر فنی کاملاً شدنی است و از نظر عملیاتی، یکی از گرانترین کارهایی است که یک تیم کوچک میتواند به خودش تحمیل کند. توصیهٔ ما برای اکثر کسبوکارها استفاده از سرویس ایمیل میزبانیشده است و چون خودمان فروشندهٔ همین سرویس هستیم، این مقاله را طوری نوشتهایم که ذینفعیمان پنهان نماند: تمام سختیهای واقعی خودمیزبانی را با جزئیات فنی میگوییم، و سناریوهایی را هم که خودمیزبانی در آنها انتخاب درستی است، صادقانه فهرست میکنیم تا خودتان قضاوت کنید.
خودمیزبانی دقیقاً یعنی نگهداری چه چیزهایی؟
«یک میلسرور میزنیم روی VPS» جملهای است که سختیاش را پنهان میکند، پس بازش کنیم. پشتهٔ کامل شامل این اجزاست: سرور SMTP برای ارسال و دریافت (معمولاً Postfix)، سرور IMAP/POP3 برای صندوقها (Dovecot)، فیلتر اسپم و آنتیویروس، وبمیل، گواهی TLS با تمدید خودکار، و مجموعهٔ رکوردهای DNS شامل MX و SPF و DKIM و DMARC بهعلاوهٔ PTR (بازگشتی) که باید از ارائهدهندهٔ سرور بگیرید. بستههایی مثل Mailcow همهٔ اینها را یکجا نصب میکنند و همین باعث میشود روز اول، فریبنده آسان به نظر برسد.
سختی از هفتهٔ دوم شروع میشود، چون میلسرور جزو معدود سرویسهایی است که خرابیاش بیسروصدا است: سایت که پایین باشد همه میفهمند، ولی ایمیلی که به اسپم میرود یا اصلاً تحویل نمیشود، هفتهها بدون علامت میماند تا مشتریای شفاهی خبر بدهد که «ایمیلهایتان نمیرسد». به همین دلیل مانیتورینگ صف ارسال، لاگهای تحویل و وضعیت بلکلیستها، بخش جدانشدنی نگهداری است؛ اگر مفاهیم پایهٔ میلسرور برایتان تازه است، اول میل سرور چیست را بخوانید و برگردید.
مشکل اصلی: تحویلپذیری، نه راهاندازی
سختی واقعی خودمیزبانی بعد از نصب شروع میشود: باید Gmail و Outlook را متقاعد کنید که ایمیل شما را به اینباکس برسانند. گیرندههای بزرگ بر اساس سابقهٔ IP و دامنهٔ فرستنده تصمیم میگیرند و الزامات رسمی گوگل برای فرستندهها حالا احراز کامل SPF و DKIM و DMARC را اجباری کرده است. سازوکار این سه رکورد را در راهنمای SPF و DKIM و DMARC به زبان ساده نوشتهایم؛ برای خودمیزبان، تنظیم درست اینها تازه بلیت ورود است، نه برگ برنده.
بعد از احراز، نوبت اعتبار IP است و اینجا زمین بازی ناهموار میشود: IPای که تازه گرفتهاید سابقه ندارد و باید ماهها با حجم کم و کیفیت بالا «گرم» شود؛ رنجهای دیتاسنترهای ارزان اغلب از قبل به خاطر اسپمرهای قبلی بدناماند؛ و بخشی از رنجهای IP منطقه هم در فهرستهای بینالمللی وضعیت خوبی ندارند. یک اشتباه (فرم هکشدهای که اسپم بفرستد، یک خبرنامهٔ بیاجازه) اعتبار چندماهه را صفر میکند. سرویس میزبانیشده دقیقاً همین دارایی نامرئی را میفروشد: زیرساخت گرمشده، اعتبار نگهداریشده، و آدمی که وقتی تحویل خراب شد پیگیری میکند؛ نمونهاش معماری لود بالانس ایمیل برتینا برای پایداری در قطعیهای بینالملل.
چکلیست فنی روز اول؛ اگر تصمیمتان خودمیزبانی است
اگر بعد از همهٔ این هشدارها مسیر خودمیزبانی را انتخاب کردهاید، این فهرست همان چیزی است که قبل از ارسال اولین ایمیل واقعی باید سبز شده باشد:
- PTR و نام همخوان: رکورد بازگشتی IP باید به نام میزبان میلسرور اشاره کند و همان نام در HELO/EHLO سرور تنظیم شده باشد؛ با
dig +short -x YOUR_IPچک کنید. گیرندههای بزرگ، ناهمخوانی این سه را همان ابتدا جریمه میکنند. - پورتها و TLS: پورت ۲۵ برای تبادل بینسروری، ۵۸۷ برای ارسال کلاینتها با STARTTLS و ۹۹۳ برای IMAP امن؛ گواهی معتبر با تمدید خودکار، نه گواهی خودامضا.
- تست Open Relay: مطمئن شوید سرور بدون احراز هویت از بیرون ارسال نمیپذیرد؛ یک میلسرورِ باز، در چند ساعت تبدیل به ماشین اسپم و در چند روز وارد بلکلیستها میشود.
- سه رکورد احراز: SPF با سیاست سختگیرانه، DKIM با کلید مناسب، و DMARC که با
p=noneو آدرس گزارش شروع شود تا اول فقط پایش کنید. - محدودیت نرخ و دفاع: سقف ارسال ساعتی برای هر اکانت، fail2ban روی تلاشهای ورود، و هشدار خودکار برای رشد غیرعادی صف ارسال؛ صفِ ناگهانپرشده، اولین علامت اکانت یا فرم هکشده است.
- پایش بلکلیست: وضعیت IP و دامنه را در فهرستهای اصلی بهصورت زمانبندیشده چک کنید و این چک را کنار بقیهٔ هشدارهای مانیتورینگ سرور بگذارید، نه در حافظهٔ ادمین.
داستان تکراری تیکتها؛ میلسرور خودمیزبان در ماه ششم
الگویی که بارها در پشتیبانی دیدهایم، تقریباً همیشه یک سناریو است. ماه اول همهچیز خوب است؛ نصب تمیز، تستها موفق، مدیر فنی راضی. چند ماه بعد، فرم تماس سایت یا یکی از اکانتها با رمز ضعیف هک میشود و سرور چند شب، بیسروصدا اسپم میفرستد. اولین علامت بیرونی، تماس یک مشتری است: «فاکتورهایتان به اسپم میرود.» بررسی که شروع میشود، IP در چند فهرست سیاه است، صف ارسال پر از پیامهای برگشتی است و ایمیلهای عادی شرکت هم لابهلای همان صف گیر کردهاند.
تازه اینجا هزینهٔ واقعی خودش را نشان میدهد: پاکسازی سرور، پیدا کردن منشأ نفوذ، درخواست حذف از تکتک فهرستها با فرمها و انتظارهای متفاوت، و بعد گرمسازی دوبارهٔ اعتباری که ماهها جمع شده بود؛ روند کامل، معمولاً چند هفته کار متناوب است و در تمام این مدت، ایمیلِ شرکت نیمهفلج است. هیچکدام از اینها با سرویس میزبانیشده غیرممکن نمیشود، ولی مسئولیت و ابزار رفعش با ارائهدهنده است، نه با تنها ادمین شما که آن هفته مرخصی است.
مقایسه در یک جدول
| معیار | میلسرور خودمیزبان | سرویس ایمیل سازمانی |
|---|---|---|
| راهاندازی | یکی دو روز با ابزارهای آماده | چند ساعت؛ ساخت اکانت و تنظیم DNS |
| نگهداری مستمر | واقعی و هفتگی؛ تخصص لینوکس و ایمیل لازم | نزدیک صفر؛ با ارائهدهنده |
| تحویلپذیری | مسئولیت شما؛ وابسته به اعتبار IP و دامنه | مسئولیت ارائهدهنده؛ زیرساخت گرمشده |
| کنترل و مالکیت داده | کامل؛ داده روی سرور خودتان | داده نزد ارائهدهنده؛ با پنل مدیریتی شما |
| مقیاسپذیری | دستی؛ ارتقای سرور و تنظیم مجدد | افزودن صندوق از پنل |
| ریسک پنهان | بلکلیست شدن، از دست رفتن ایمیلها | وابستگی به کیفیت ارائهدهنده |
کی خودمیزبانی انتخاب درستی است؟
چهار سناریو را منصفانه فهرست کنیم. اول، الزام حاکمیتی یا امنیتی که میگوید دادهٔ ایمیل باید فقط روی زیرساخت خود سازمان باشد؛ اینجا بحث هزینه فرع است. دوم، سازمانی با تیم زیرساخت مسلط که همین حالا لینوکس و DNS و مانیتورینگ را حرفهای اداره میکند و ایمیل، یک سرویس دیگر کنار بقیه است. سوم، حجم بسیار بالای صندوقها که در آن محاسبهٔ اقتصادی به نفع زیرساخت اختصاصی میچرخد؛ این نقطه دیرتر از چیزی که تصور میشود میرسد. و چهارم، محیط آزمایش و یادگیری، که اتفاقاً تشویقش میکنیم؛ راه انداختن یک میلسرور شخصی، بهترین کلاس درس پروتکلهای ایمیل است، فقط دامنهٔ اصلی کسبوکارتان را وسط آزمایش نگذارید.
بیرون از این چهار حالت، خودمیزبانی معمولاً یعنی پذیرفتن هزینهٔ مهندسی دائمی برای حل مسئلهای که با هزینهٔ ماهانهٔ بسیار کمتر، حلشده قابل خرید است. اگر مسیر سرویس را میروید، تفاوت گزینهها را در راهنمای ایمیل سازمانی و هاست ایمیل چیست ببینید؛ سرویس ایمیل سازمانی برتینا روی SmarterMail ارائه میشود و اگر از Exchange یا Google Workspace میآیید، راهنمای جایگزینهای Exchange و راهنمای مهاجرت از Workspace مسیر انتقال را قدمبهقدم گفتهاند.
مسیر میانه؛ عاقلانهترین چیدمان برای بیشتر تیمهای فنی
انتخاب، دوقطبی هم نمیماند. چیدمانی که ما به تیمهای فنی توصیه میکنیم این است: صندوقهای انسانی (info، فروش، پشتیبانی) روی سرویس میزبانیشده، و ایمیلهای سیستمی سایت و اپلیکیشن (رسید سفارش، بازیابی رمز، هشدارها) از طریق SMTP همان سرویس یا یک ریلهٔ تراکنشی، نه مستقیم از خود سرور سایت. با این چیدمان، سرور سایت شما هیچوقت وارد بازی اعتبار IP نمیشود، صندوقهای انسانی پشتیبانی دارند، و شما همچنان کنترل کامل DNS و دامنه را نگه میدارید. تنها چیزی که باید خودتان مدیریت کنید، همان رکوردهای SPF و DKIM و DMARC است که یکبار درست تنظیم میشود و سالی یکی دو بار بازبینی میخواهد.
برای DMARC هم مسیر بلوغ مشخصی وجود دارد که مستقل از انتخابتان بین دو گزینه، ارزش اجرا دارد: با p=none شروع کنید و چند هفته گزارشها را بخوانید تا همهٔ فرستندههای مشروع دامنه (سرویس ایمیل، سایت، ابزار خبرنامه) شناسایی و احراز شوند؛ بعد به quarantine و در نهایت reject بروید. دامنهای که به reject رسیده، عملاً جعلناپذیر است و همین، هم اعتبار برند را نگه میدارد هم نرخ رسیدن ایمیلهای واقعیتان را بالا میبرد.
سوالات متداول دربارهٔ میلسرور خودمیزبان
میشود روی همان VPS سایت، میلسرور هم زد؟
میشود و توصیه نمیکنیم، به دو دلیل مشخص: اول، بسیاری از دیتاسنترها پورت ۲۵ خروجی را بهطور پیشفرض میبندند و بازش هم که کنند، IP سایت شما حالا اعتبار ایمیلیاش را هم یدک میکشد؛ دوم، هر مشکل امنیتی سایت (فرم آلوده، افزونهٔ هکشده) مستقیم به اعتبار ایمیل ضربه میزند و برعکس. جداسازی این دو، اولین اصل معماری ایمیل است.
هزینهٔ واقعی خودمیزبانی چقدر است؟
هزینهٔ سرور، کوچکترین جزء است. هزینهٔ اصلی، ساعتهای مهندسی است: راهاندازی اولیه، بهروزرسانیهای امنیتی، پایش بلکلیستها و لاگها، و رسیدگی به حادثههایی که همیشه بدموقع میرسند. برای مقایسهٔ منصفانه، ساعتهای ماهانهٔ این کارها را با نرخ واقعی نیروی فنیتان قیمت بگذارید و کنار هزینهٔ اشتراک سرویس بگذارید؛ در بیشتر ابعاد، جواب محاسبه روشن است.
ایمیلهای تراکنشی سایت (رسید و بازیابی رمز) را چه کنیم؟
از مسیر SMTP احرازشده بفرستید، نه با تابع پیشفرض PHP از خود سرور سایت؛ هم تحویلپذیری بهتر میشود هم لاگ درست دارید. اگر سرویس ایمیل سازمانی دارید، همان SMTP معمولاً برای حجم عادی سایت کافی است و برای حجمهای بالا، ریلهٔ تراکنشی جداگانه منطقیتر است.
اگر همین حالا میلسرور خودمیزبان داریم و اذیت میکند؟
اول وضعیت را اندازه بگیرید: نرخ رسیدن به اینباکس گیرندههای بزرگ، وضعیت IP در بلکلیستهای اصلی، و ساعتهایی که ماهانه صرف نگهداری میشود. اگر تصمیم به مهاجرت گرفتید، انتقال صندوقها به سرویس میزبانیشده بدون از دست دادن ایمیلهای قدیمی شدنی است؛ مسیرش مشابه همان است که در راهنمای مهاجرت از Workspace نوشتهایم و پشتیبانی مقصد هم معمولاً خودش انتقال را انجام میدهد.
با سرویس میزبانیشده، کنترل چه چیزهایی دست ما میماند؟
دامنه، DNS، سیاستهای DMARC، ساخت و حذف صندوقها، و امکان مهاجرت هر وقت که بخواهید؛ به شرط رعایت همان قواعدی که در راهنمای مالکیت دامنه گفتهایم: دامنه و پنل DNS به نام خودتان بماند. سرویس ایمیل، اجارهای است که هر وقت خواستید میتوانید اسبابکشی کنید؛ دامنه، همان ملکی است که نباید از دستتان خارج شود.
خبرنامه و ارسال انبوه را هم از همین سرویس بفرستیم؟
خیر؛ ارسال انبوه، بازی جداگانهای با قواعد خودش است. صندوق سازمانی برای مکاتبات انسانی و ایمیلهای سیستمی سایت طراحی شده و ارسال چند هزار خبرنامه از آن، هم سقفهای ارسال را میشکند هم اعتبار دامنه را به خطر میاندازد. برای خبرنامه از سرویس ارسال انبوه جداگانه استفاده کنید، فهرست را فقط از مشترکان واقعی بسازید، و الزام لغو اشتراک تککلیکی را که در همان الزامات فرستندهٔ گوگل آمده جدی بگیرید؛ ترکیب درست، سه مسیر جدا برای سه نوع ایمیل است: انسانی، تراکنشی، انبوه.
PTR یا Reverse DNS چیست و چرا بدون آن ایمیل نمیرسد؟
PTR ترجمهٔ برعکس DNS است: بهجای «این نام چه IPای دارد»، میگوید «این IP متعلق به چه نامی است». گیرندههای بزرگ، سروری را که IPاش رکورد بازگشتی معتبر و همخوان با نامش نداشته باشد، در بهترین حالت مشکوک و در حالت رایج، رد میکنند. نکتهٔ عملی مهم: PTR را فقط ارائهدهندهٔ سرور میتواند ست کند، پس قبل از خرید سرور برای میل، مطمئن شوید این امکان را میدهد.
برای شروع یادگیری میلسرور از کجا شروع کنیم؟
یک VPS کوچک جدا از هر چیز واقعی بگیرید (سایز مناسبش را راهنمای انتخاب منابع سرور مجازی میگوید)، یک دامنهٔ آزمایشی ثبت کنید و Mailcow را با مستندات رسمیاش بالا بیاورید؛ بعد سعی کنید به Gmail خودتان ایمیل برسانید و لاگها را بخوانید. همین تمرینِ بهظاهر ساده، بهتر از هر مقالهای نشانتان میدهد که چرا تحویلپذیری، شغل تماموقت است؛ و تجربهاش، شما را در انتخاب و ارزیابی هر سرویس ایمیلی هم خریدار آگاهتری میکند.
