گرمای تابستان — همه‌چیز آب می‌شود، حتی قیمت‌های ما.−25%−۲۵٪ روی هر پلن سالانه، تا ۳۱ اوتدیدن پلن‌ها
EQVPS

اجرای یک سرور ایمیل روی VPS: چه چیزی واقعاً شما را از اسپم دور نگه می‌دارد

10 تیر 1405 · 5 دقیقه مطالعه · EQVPS Team

سرور ایمیل شما کار می‌کند. Postfix بالا می‌آید، لاگ‌ها تمیز به‌نظر می‌رسند، یک پیام آزمایشی به Gmail خودتان می‌فرستید — و در اسپم می‌نشیند. یا فقط ناپدید می‌شود. هیچ چیز در پیکربندی شما خراب نیست. نرم‌افزار دقیقاً همان کاری را کرد که گفتید.

مشکل این است که سرور آن‌طرف هنوز به IP شما اعتماد ندارد، و ایمیل یک لایهٔ کامل از بررسی‌های کوچک اعتماد را پنهان می‌کند که همه باید ردیف شوند تا صندوق ورودی یک غریبه راهتان بدهد. آن‌ها را درست کنید و تحویل بیشترش خودش را رتق‌وفتق می‌کند. یکی را از دست بدهید و دارید در یک پوشهٔ اسپم فریاد می‌زنید.

سه چیز بیشترِ وزن را حمل می‌کنند: reverse DNS، احراز هویت فرستنده، و اینکه آیا میزبانتان اصلاً می‌گذارد روی پورت 25 حرف بزنید. هیچ‌کدام سخت نیستند. فقط فراموش کردنشان آسان است، و هرکدام یک وتوی خاموش‌اند.

آنی که همه فراموش می‌کنند: reverse DNS

Forward DNS همان بخشی است که می‌شناسید — یک نام به یک IP اشاره می‌کند. Reverse DNS آینه‌اش است: یک IP به یک نام اشاره می‌کند. آن رکورد PTR نامیده می‌شود و پیش کسی که IP را کنترل می‌کند زندگی می‌کند، نه در zone دامنهٔ شما.

اینجا دلیلِ اهمیتش است. وقتی سرور شما یک اتصال به SMTP مربوط به Gmail باز می‌کند، یکی از اولین کارهایی که سمت گیرنده می‌کند یک جست‌وجوی معکوس روی IP شماست — این کیست؟ خودتان اجرایش کنید:

dig -x 203.0.113.19 +short

اگر آن با چیزی مثل static.203-0-113-19.rev.example-isp.net برگردد، یا خالی برگردد، همین حالا امتیاز از دست داده‌اید. آن نام عمومی می‌گوید «یک VPS تصادفی»، و بدتر، با نام میزبانی که سرورتان در سلام HELO خودش را با آن معرفی می‌کند هم‌خوان نیست. سرورهای گیرنده آن ناهم‌خوانی را محکم علامت‌گذاری می‌کنند. برخی یکسره رد می‌کنند.

آنچه می‌خواهند ببینند یک PTR است که با نام میزبان ایمیل شما هم‌خوان باشد. اگر سرور شما HELO mail.example.com می‌گوید، جست‌وجوی معکوس روی IP آن باید mail.example.com را برگرداند. forward و reverse توافق دارند، داستان یکدست است، و شما به‌جای یک ماشین ربوده‌شده مثل یک سرور ایمیل واقعی به‌نظر می‌رسید.

گذاشتن یک PTR به‌طور سنتی یعنی باز کردن یک تیکت پشتیبانی با هرکسی که مالک بلوک IP است و منتظر ماندن. در پلن‌های IP اختصاصی EQVPS این یک فیلد در داشبورد شماست — نام میزبان را تایپ می‌کنید، مستقیم از طریق API ارائه‌دهنده در registry نوشته می‌شود، و در چند ثانیه فعال است. کل هدفِ انجامش به‌صورت سلف‌سرویس همین است: reverse DNS همان گامی است که مردم رد می‌کنند چون قبلاً آزاردهنده بود.

احراز هویت: SPF، DKIM، DMARC

این سه رکورد DNS به سرورهای گیرنده می‌گویند که ایمیلی که ادعا می‌کند از دامنهٔ شماست، واقعاً هست. آن‌ها را رد کنید و شما یک غریبهٔ تأییدنشده‌اید.

هر سه را می‌خواهید. SPF و DKIM ثابت می‌کنند ایمیل به‌طور قانونی مال شماست؛ DMARC آن اثبات را به یک سیاست تبدیل می‌کند. شاید بیست دقیقه ویرایش DNS باشد، و همان تفاوت میان «فرستندهٔ تأییدشده» و «کی؟» است.

پورت 25، و چرا بسته است

اینجا آنی است که مردم را غافلگیر می‌کند. پورت خروجی 25 — پورتی که سرورهای ایمیل برای حرف زدن با هم استفاده می‌کنند — به‌طور پیش‌فرض روی اساساً هر میزبان VPS مسدود است. ما هم همین‌طور.

این عمدی است. پورت 25 توپ کلاسیک اسپم است، پس بسته می‌ماند تا وقتی که بخواهیدش و بگویید واقعاً چه می‌فرستید. ما آن را به‌ازای هر درخواست باز می‌کنیم، نه اینکه برای هرکسی که یک سرور بالا می‌آورد بازش بگذاریم.

و اینجا یک هشدار صادقانه هست که ارزش دارد رک بیانش کنیم: با یک پورت 25 باز مسئولیت هم می‌آید. یک اسکریپت به‌خطرافتاده یا یک relay بدپیکربندی که اسپم بیرون می‌ریزد، و اعتبار IP شما رفته است — گاهی برای هفته‌ها. روی یک subnet اشتراکی آن آشفتگی به همسایه‌هایتان سرریز می‌کند، که دقیقاً همان دلیلی است که میزبان‌ها درباره‌اش محتاط‌اند. اگر از ما بخواهید 25 را باز کنیم، سرورتان را تمیز نگه دارید، چون اعتباری که محافظت می‌کنید تا حدی مال ما هم هست.

چرا IP اختصاصی اختیاری نیست

همهٔ این‌ها به یک الزام برمی‌گردد: IP باید مال شما باشد. روی یک راه‌اندازی NAT یا یک آدرس اشتراکی نمی‌توانید PTR خودتان را بگذارید، چون آدرس منحصراً مال شما نیست که به جایی اشاره‌اش دهید. همچنین هر اعتباری که IP اشتراکی از قبل حمل می‌کند به شما ارث می‌رسد — و هیچ ایده‌ای ندارید که مستأجر قبلی با آن چه کرده.

یک IP اختصاصی به شما یک PTR می‌دهد که خودتان کنترلش می‌کنید، یک اعتبار که مال خودتان است که بسازید، و یک نقطهٔ شروع تمیز. برای ایمیل خروجی این یک امکان خوش‌آیند نیست؛ کف ماجراست.

جمع‌بندی صادقانه

خودمیزبانی ایمیل در سال ۲۰۲۶ یک کار واقعی و مداوم است. تنظیم-کن-و-فراموش-کن نیست — لیست‌های مسدودی را زیر نظر می‌گیرید، کلیدهای DKIM را می‌چرخانید، و گاهی می‌فهمید چرا یک ارائه‌دهندهٔ خاص شروع به greylist کردن شما کرد. اگر این یک پروژهٔ جانبی کم‌اهمیت است، صادقانه، فوروارد کردن از طریق یک ارائه‌دهندهٔ ایمیل موجود دردسر کمتری برایتان می‌سازد.

اما اگر کنترل واقعی می‌خواهید — داده‌تان، دامنه‌تان، کسی دیگر هدرها را نمی‌خواند — روی یک VPS کوچک کاملاً شدنی است. لوله‌کشی اعتمادِ بالا حدود ۹۰٪ نبرد است، و هیچ‌کدامش عجیب‌وغریب نیست. یک IP اختصاصی بگیرید، PTR را طوری بگذارید که با نام میزبانتان هم‌خوان باشد، ‏SPF/DKIM/DMARC را منتشر کنید، از ما بخواهید پورت 25 را باز کنیم، سپس یک پیام آزمایشی از طریق ابزاری مثل mail-tester.com بفرستید و هرچه را که علامت زد درست کنید. این را انجام دهید و دیگر در یک پوشهٔ اسپم فریاد نمی‌زنید — یک سرور ایمیل هستید که صندوق ورودی مردم واقعاً به آن اعتماد می‌کند.

سؤالات متداول

آیا برای اجرای یک سرور ایمیل به یک IP اختصاصی نیاز دارم؟

عملاً بله. قابلیت تحویل به یک رکورد reverse DNS (PTR) بستگی دارد که با نام میزبان ایمیل شما هم‌خوان باشد، و شما فقط روی IPی که منحصراً مال خودتان است می‌توانید یک PTR بگذارید. روی یک آدرس اشتراکی یا NAT شما PTR را کنترل نمی‌کنید، پس سرورهای گیرنده یک نام میزبان عمومی یا ناهم‌خوان می‌بینند و شما را مشکوک می‌پندارند. یک IP اختصاصی خط پایهٔ ایمیل خروجی است.

رکورد PTR چیست و چرا ایمیل به آن نیاز دارد؟

رکورد PTR همان reverse DNS است — IP شما را به یک نام میزبان نگاشت می‌کند، برعکس یک رکورد A معمولی. وقتی سرور شما به Gmail یا Outlook وصل می‌شود، سمت گیرنده جست‌وجو می‌کند چه کسی مالک IP شماست. اگر PTR غایب یا عمومی باشد (مثل static.203-0-113-19.rev.example-isp.net)، این بلافاصله یک امتیاز منفی برای شماست. سرورهای ایمیل انتظار دارند PTR با نامی که سرورتان در HELO اعلام می‌کند هم‌خوان باشد.

چرا پورت خروجی 25 به‌طور پیش‌فرض روی اغلب میزبان‌های VPS مسدود است؟

پورت 25 بزرگ‌ترین بردار تکیِ اسپم است، پس میزبان‌ها آن را بسته نگه می‌دارند تا وقتی که بخواهید و توضیح دهید چه می‌فرستید. این یک باگ نیست — پیشگیری از سوءاستفاده است. یک اسکریپت به‌خطرافتاده که اسپم شلیک می‌کند می‌تواند اعتبار یک IP را بسوزاند، و روی یک subnet اشتراکی آن آسیب به مشتریان دیگر سرریز می‌کند. میزبان‌های معتبر، از جمله EQVPS، آن را به‌جای پیش‌فرض بودن، به‌ازای هر درخواست باز می‌کنند.

آیا می‌توانم یک سرور ایمیل را روی یک IP اشتراکی یا NAT اجرا کنم؟

می‌توانید از طریق port forwarding ایمیل دریافت کنید، اما فرستادن مطمئن داستان دیگری است. بدون IP خودتان نمی‌توانید یک PTR هم‌خوان بگذارید، و هر اعتباری که آدرس اشتراکی از قبل دارد — خوب یا بد — به شما ارث می‌رسد. برای هر چیزی که نیاز دارید تحویل داده شود، از یک IP اختصاصی با تاریخچهٔ تمیز و یک PTR که خودتان کنترلش می‌کنید استفاده کنید.

آیا خودمیزبانی ایمیل در سال ۲۰۲۶ واقعاً ارزشش را دارد؟

بستگی دارد به اینکه چرا. اگر کنترل روی داده‌ها و دامنه‌تان بدون هیچ شخص ثالثی در حلقه می‌خواهید، روی یک VPS کوچک کاملاً شدنی است. اما قابلیت تحویل یک کار مداوم است — لیست‌های مسدودی را زیر نظر می‌گیرید، کلیدهای DKIM را می‌چرخانید، و IP را تمیز نگه می‌دارید. برای یک پروژهٔ جانبی کم‌اهمیت، فوروارد کردن از طریق یک ارائه‌دهندهٔ موجود کمتر دردسر دارد. زمانی خودمیزبانی کنید که کنترل بیش از راحتی برایتان مهم است.

← بازگشت به وبلاگ← پلن‌ها و قیمت‌ها

نظرات

هنوز نظری نیست. اولین نفر باشید.

یک نظر بگذارید

نظرات پیش از نمایش بررسی می‌شوند.