میل سرور شخصی روی VPS: پورت 25، PTR و چرا ایمیل شما در اسپم می‌افتد

گیرنده‌ی ایمیل واقعاً چه تصمیمی می‌گیرد و به چه ترتیبی؟

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

اولین تصمیم در همان اتصال TCP گرفته می‌شود: این کیست، و اصلاً باید با او صحبت کرد یا نه؟ در آن لحظه گیرنده فقط آدرس IP شما، DNS معکوس آن، و هر اعتباری را که خودش یا ارائه‌دهندگان لیست سیاهش به آن آدرس نسبت داده‌اند در اختیار دارد. دومین تصمیم روی پاکت SMTP گرفته می‌شود — HELO و MAIL FROM — جایی که SPF در برابر IP متصل‌شونده ارزیابی می‌شود. سومین تصمیم همراه با داده‌ی پیام می‌رسد، جایی که امضاهای DKIM بررسی می‌شوند و DMARC تعیین می‌کند که آیا نتیجه‌ی هرکدام از این احراز هویت‌ها با دامنه‌ی موجود در هدر قابل‌مشاهده‌ی From: هم‌تراز است یا نه. تنها پس از همه‌ی این مراحل چیزی شبیه فیلتر محتوا آغاز می‌شود، و تا آن زمان بیشتر نتیجه از پیش تعیین شده است.

از این دو نتیجه می‌گیریم. ارزان‌ترین پیروزی‌ها در بالای زنجیره‌اند: یک رکورد PTR درست تنها یک فیلد در پنل کنترل هزینه دارد و کل یک دسته از ردشدن‌ها را از بین می‌برد. و پایین زنجیره — همان بخشی که همه نگرانش هستند، یعنی متن پیام — بخشی است که کمترین کنترل را روی آن دارید، و تنها زمانی اهمیت پیدا می‌کند که همه‌چیز بالای آن تمیز باشد.

پورت 25، ارزان‌ترین بخش مسئله است

تقریباً همه‌ی کلاودهای بزرگ به‌طور پیش‌فرض پورت 25 خروجی را مسدود می‌کنند، و باز کردنش یعنی باید درخواست بدهید. AWS، Google Cloud، Azure، Oracle Cloud و بیشتر برندهای بزرگ VPS با ترافیک خروجی فیلترشده روی پورت 25 عرضه می‌شوند، و درخواست رفع مسدودی فرمی است که به حسابی وصل می‌شود که از قبل هویت، کارت بانکی و شماره تلفن شما را دارد. این‌جاست که بیشتر برنامه‌های میل سرور شخصی بی‌سروصدا از بین می‌روند، و به همین دلیل است که جست‌وجویی که بیشتر افراد را به صفحه‌ای مثل این می‌رساند، نسخه‌ای از کدام VPS پورت 25 باز دارد است.

دقیق بودن درباره‌ی این‌که هر پورت چه کاری انجام می‌دهد کمک می‌کند، چون این سه پورت مدام با هم اشتباه گرفته می‌شوند. پورت 25 سرور-به-سرور است: همان راهی است که یک MX پیام را به MX دیگر می‌سپارد، هرگز احراز هویت نمی‌شود، و تنها پورتی است که برای تحویل ایمیل به افرادی که کاربر شما نیستند اهمیت دارد. پورت 587 برای submission است — کلاینت‌های خود شما پیش از این‌که سرورتان پیام را برایشان relay کند، در برابر آن احراز هویت می‌شوند. پورت 465 همان کار را با TLS از همان بایت اول انجام می‌دهد؛ در دهه‌ی نود منسوخ اعلام شد، سپس رسماً توسط RFC 8314 بازگردانده شد، و امروز گزینه‌ی پیش‌فرض معقول است. از دست دادن پورت 25 خروجی جلوی ارسال شما به دنیا را می‌گیرد؛ از دست دادن پورت 25 ورودی جلوی رسیدن ایمیل دنیا به شما را می‌گیرد، و کاملاً ممکن است یکی را داشته باشید و دیگری را نه، و یک بعدازظهر را صرف مقصر دانستن DNS کنید.

در BitVPS پورت 25 خروجی روی هر پلن و در هر لوکیشن به‌طور پیش‌فرض باز است. هیچ فرمی و هیچ فرایند استثنایی وجود ندارد، چون چیزی برای برداشتن نیست. پورت‌های ورودی 25، 465 و 587 پشت یک لایه‌ی اسکراب آگاه به میل قرار دارند نه یک فیلتر عمومی لایه‌ی سه، و همین تفاوتی است که در زمان حمله اهمیت پیدا می‌کند: فیلتری که SMTP را می‌فهمد می‌تواند یک سیل ترافیک را دفع کند بدون این‌که مکالمه‌ی مشروع MX پشت آن را هم از بین ببرد. صفحه‌ی میل سرور جزئیات را دارد، و توضیح DDoS پوشش می‌دهد که اسکراب به‌طور کلی چه معنایی دارد و چه معنایی ندارد.

باز بودن پورت 25 یک شرط لازم است، نه حتی نزدیک به یک شرط کافی — و دقیقاً به همین دلیل است که این راهنما برای سه هزار کلمه‌ی دیگر ادامه دارد.

آدرسی که به شما داده می‌شود، بیشتر از تنظیمات شما تعیین‌کننده است

تنظیمات شما فقط چند رکورد DNS و یک روز کار است. اما آدرس IP، تاریخچه‌ای است که شما ننوشته‌اید. یک /24 که در سال 2019 اسپم داروخانه‌ای فرستاده، به یاد سپرده می‌شود؛ آدرسی که از مشتری‌ای بازیافت شده که ماه گذشته حسابش بسته شده، از قبل قضاوت‌شده وارد می‌شود؛ رنجی که همسایه‌هایش پرسروصدا هستند، در گیرنده‌هایی که در سطح /24 امتیاز می‌دهند، بر اساس همنشینی قضاوت می‌شود. هیچ‌کدام از این‌ها از داخل ماشین دیده نمی‌شود، و هیچ‌کدام با یک main.cf بهتر تغییر نمی‌کند.

پس پیش از تعهد بررسی کنید، نه بعد از آن. لیست‌های سیاه عمومی بخشی از داستان را می‌گویند: Spamhaus همان چیزی است که واقعاً روی تحویل تأثیر می‌گذارد، با SBL و CSS که فرستنده‌های مشاهده‌شده را فهرست می‌کنند، PBL که رنج‌هایی را فهرست می‌کند که اپراتورشان اعلام کرده نباید مستقیماً ایمیل بفرستند، و DBL که به‌جای آدرس، دامنه فهرست می‌کند. Barracuda و SpamCop هم ارزش نگاه کردن دارند و وقتی علت رفع شود، سریع پاک می‌شوند. اما دو اعتباری که بیشترین تأثیر را روی نتیجه‌ی شما دارند، خصوصی هستند: Google و Microsoft هر کدام امتیازهای per-IP و per-domain را نگه می‌دارند که اصلاً نمی‌توانید آن‌ها را query کنید، مگر از طریق Postmaster Tools و SNDS، و آن‌هم فقط زمانی که به‌اندازه‌ی کافی ایمیل بفرستید تا آن‌ها نظری داشته باشند.

دو هشدار درباره‌ی چک‌لیست‌هایی که در جاهای دیگر پیدا می‌کنید. نیمی از آن‌ها هنوز می‌گویند SORBS را بررسی کنید: SORBS در تاریخ 5 June 2024 توسط مالکش از رده خارج شد و zoneهایش اکنون هیچ پاسخی نمی‌دهند، پس یک lookup در آن، گواهی سلامت نیست بلکه یک query مرده است. و با UCEPROTECT سطح 2 و سطح 3 با شک برخورد کنید — این‌ها همسایه‌ها و کل سیستم‌های خودمختار را بر اساس همنشینی فهرست می‌کنند و سپس شما را دعوت می‌کنند برای حذف سریع پول بدهید، به همین دلیل بیشتر گیرنده‌های جدی آن‌ها را نادیده می‌گیرند. دنبال کردن یک لیست‌شدن سطح 3 راهی است برای صرف یک آخر هفته بدون هیچ نتیجه‌ای. پورتال اعتبار خود Spamhaus همان چیزی است که باید جدی گرفت.

این هم بخشی است که یک هاست یا کمک می‌کند یا نمی‌کند. BitVPS در زمان provisioning هر آدرس را در برابر لیست‌های اصلی بررسی می‌کند و اگر آدرسی در آن‌ها دیده شود، پیش از این‌که شما حتی وارد شوید آن را عوض می‌کند، مشتریان میل را از /29هایی تخصیص می‌دهد که طی دوازده ماه گذشته از مشتری میل قبلی بازیافت نشده‌اند، و یک /29 را می‌تواند بین ماشین‌های همان دیتاسنتر جابه‌جا کند بدون این‌که IP شما را عوض کند — نکته‌ای که وقتی آدرسی اعتباری دارد که شش ماه برایش زحمت کشیده‌اید، اهمیت زیادی پیدا می‌کند. هیچ‌کدام از این‌ها یک آدرس را خوب نمی‌کند؛ فقط آن را خنثی می‌کند، که صادقانه‌ترین چیزی است که هر هاستی می‌تواند ارائه دهد.

PTR، HELO و رکورد A باید یک داستان را روایت کنند

این تنها رایج‌ترین دلیلی است که یک میل سرور به‌درستی نصب‌شده رد می‌شود، و ارزان‌ترین چیز در این صفحه برای درست کردن است. سه نام باید با هم توافق داشته باشند. سرور شما در HELO یک نام میزبان اعلام می‌کند؛ آن نام میزبان یک رکورد A دارد که به آدرسی که از آن متصل می‌شود اشاره می‌کند؛ و آن آدرس یک رکورد PTR دارد که به همان نام میزبان برمی‌گردد. آن را رو به جلو resolve کنید به آدرس می‌رسید؛ رو به عقب resolve کنید به نام می‌رسید. این رفت‌وبرگشت forward-confirmed reverse DNS نامیده می‌شود، و از February 2024 یک رکورد PTR معتبر در Gmail دیگر یک لطف نیست بلکه الزامی اعلام‌شده برای هر فرستنده است، چه حجم بالا و چه نه.

چهار حالتی که این کار خراب می‌شود، به ترتیب نزولی فراوانی. اصلاً PTR وجود ندارد، چون هاست این فیلد را ارائه نمی‌دهد. یک PTR هست، اما همان PTR عمومی ارائه‌دهنده است — چیزی که به دامنه‌ی شرکت هاستینگ ختم می‌شود، که به هر گیرنده‌ای اعلام می‌کند این یک آدرس اجاره‌ای در رنجی است که بیشترش ایمیل نمی‌فرستد. نام HELO اشتباه است: پیش‌فرض نصب‌کننده، یک نام میزبان کوتاه و ناقص، یا localhost، که هیچ‌کدام resolve نمی‌شوند. و موردی که افراد دقیق را هم گیر می‌اندازد: ماشین دارای IPv6 است، MTA وقتی گیرنده رکورد AAAA منتشر کرده IPv6 را ترجیح می‌دهد، و روی آدرس v6 هیچ PTRای نیست — پس ایمیل به Gmail از طریق IPv4 کاملاً کار می‌کند در حالی که همان ایمیل روی IPv6 رد می‌شود. یا PTR نسخه‌ی شش را درست تنظیم کنید، یا تا زمانی که این کار را نکرده‌اید transport را با smtp_address_preference = ipv4 ثابت کنید.

در BitVPS فیلد PTR برای هر آدرس IPv4 و IPv6 به‌صورت self-serve در پنل در دسترس است، هر FQDN دلخواهی را بدون پسوند اجباری ارائه‌دهنده می‌پذیرد، تغییرات در کمتر از پنج دقیقه در سطح جهانی منتشر می‌شوند، و ویرایش گروهی تا ده آدرس را همزمان پوشش می‌دهد. صفحه‌ی شبکه جزئیات را دارد، و دلیل اهمیت این موضوع دقیقاً همین بخش است: هاستی که شما را مجبور می‌کند برای تنظیم DNS معکوس تیکت باز کنید، همان هاستی است که هر بار rebuild می‌کنید مجبورتان می‌کند دوباره تیکت باز کنید.

SPF، DKIM و DMARC: هرکدام چه چیزی را ثابت می‌کند و هم‌ترازی یعنی چه

این سه مورد به‌صورت رکورد DNS منتشر می‌شوند، راه‌اندازی‌شان یک ساعت طول می‌کشد، و تقریباً همه‌جا بد توضیح داده می‌شوند — معمولاً به‌عنوان سه طلسم ضداسپم قابل‌جایگزین به‌جای سه ادعای متفاوت. SPF (RFC 7208) می‌گوید کدام آدرس‌ها مجازند ایمیل حامل یک فرستنده‌ی پاکت مشخص بفرستند. DKIM (RFC 6376) یک امضای رمزنگاری‌شده روی هدرها و بدنه ضمیمه می‌کند، تا پیام بتواند ثابت کند کدام دامنه مسئولیتش را برعهده گرفته. هیچ‌کدام از این دو، چیزی درباره‌ی آدرسی که گیرنده‌ی شما واقعاً می‌بیند نمی‌گویند.

این کار DMARC (RFC 7489) است، و به همین دلیل است که هم‌ترازی کلمه‌ای است که اهمیت دارد. DMARC زمانی پاس می‌شود که SPF یا DKIM پاس شود و دامنه‌ای که احراز هویت شده با دامنه‌ی هدر قابل‌مشاهده‌ی From: یکی باشد. این‌جاست که شکست کلاسیک اتفاق می‌افتد: ایمیل شما SPF را پاس می‌کند چون آدرس bounce روی دامنه‌ای است که هاست فرستنده کنترلش می‌کند، اما آن دامنه همان دامنه‌ی From: نیست، پس هم‌تراز نمی‌شود، و بدون امضای DKIM برای تکیه‌کردن، DMARC روی پیامی شکست می‌خورد که در لاگ‌ها کاملاً احراز هویت‌شده به نظر می‌رسید. مورد کلاسیک دیگر این است که از روز اول p=reject منتشر کنید، پیش از این‌که حتی یک گزارش خوانده شود، و یک ماه بعد بفهمید سیستم صدور فاکتور تمام این مدت بی‌سروصدا رد شده است. با p=none همراه با یک آدرس rua شروع کنید، آن‌چه می‌رسد را بخوانید، و بعد سخت‌گیرتر شوید.

دو نکته‌ی عملیاتی که بیشتر از ظاهرشان اهمیت دارند. رکورد SPF را زیر ده جست‌وجوی DNS نگه دارید — هر include: یکی حساب می‌شود، و تودرتو کردن سه فروشنده‌ی SaaS از محدودیت رد می‌شود و به‌جای یک شکست نرم، به یک خطای دائمی تبدیل می‌شود. و selectorهای DKIM را هرازگاهی بچرخانید، نه هرگز: افزودن یک selector ارزان است، و داشتن از پیش یک selector دوم منتشرشده، تفاوت میان یک چرخش کلید پنج‌دقیقه‌ای و یک قطعی است.

کف الزامات در 2024 جابه‌جا شد، و دوباره در 2025

برای بیست سال، خط پایه‌ی ارسال ایمیل تقریباً همین بود: «یک PTR داشته باش و روی Spamhaus نباش». این وضعیت در February 2024 تغییر کرد، وقتی Google و Yahoo الزامات فرستندهی تقریباً یکسانی منتشر و اجرایشان کردند. هر فرستنده‌ای — از جمله شما که روزی چهار پیام می‌فرستید — اکنون به یک رکورد PTR معتبر forward-confirmed، TLS روی اتصال، و دست‌کم یکی از SPF یا DKIM نیاز دارد. فرستنده‌های بالای تقریباً پنج هزار پیام در روز به یک گیرنده باید هم SPF و هم DKIM و یک رکورد DMARC داشته باشند، یک هدر working one-click unsubscribe طبق RFC 8058، و نرخ شکایت اسپم زیر 0.3%.

Microsoft در تاریخ 5 May 2025 با همان شکل قانون برای Outlook.com، Hotmail و Live دنبال کرد: دامنه‌هایی که بیش از پنج هزار پیام در روز به آن صندوق‌های مصرف‌کننده می‌فرستند باید SPF، DKIM و DMARC داشته باشند، در غیر این صورت ایمیل ابتدا به Junk و سپس مستقیماً رد می‌شود. پشتیبانی فرستنده‌ی Microsoft و بهترین شیوه‌های Yahoo هر دو ارزش ده دقیقه خواندن پیش از ارسال هر چیزی را دارند.

پیامد عملی برای یک سرور شخصی یا تیم کوچک این نیست که آستانه‌ها گریبان شما را می‌گیرند — نخواهند گرفت — بلکه این است که خط پایه‌ی بدون احراز هویت اکنون واقعاً غیرعادی به نظر می‌رسد. ایمیل بدون رکورد DMARC از آدرسی بدون سابقه، زمانی عادی بود. در 2026 دقیقاً همان الگویی است که فیلترها برای متوقف کردنش ساخته شده‌اند. طوری تنظیم کنید که انگار یک فرستنده‌ی حجیم هستید، حتی اگر نیستید، چون هزینه‌اش فقط یک بعدازظهر است و جایگزینش این است که در برابر جمعیتی امتیازدهی شوید که به آن تعلق ندارید.

گرم کردن آدرسی که کسی هرگز ندیده

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

با ابزارهایی که خود گیرنده‌ها در اختیارتان می‌گذارند اندازه بگیرید، نه با نگاه کردن به صندوق خودتان. Postmaster Tools گوگل، پس از تأیید دامنه، اعتبار دامنه و IP، نرخ شکایت اسپم و نرخ پاس احراز هویت را نشان می‌دهد — هرچند تا زمانی که به‌اندازه‌ی کافی نفرستید خالی می‌ماند تا چیزی برای aggregate کردن داشته باشد، که برای یک سرور شخصی می‌تواند یعنی هرگز، و اشکالی هم ندارد. SNDS مایکروسافت همین کار را برای Outlook.com انجام می‌دهد و با Junk Mail Reporting Program جفت می‌شود، که شکایت‌ها را مستقیم به شما می‌فرستد. یک سرویس امتیازدهی یک‌باره برای پیدا کردن یک رکورد خراب در ده ثانیه مفید است، و برای هر چیز دیگری بی‌فایده — چون درباره‌ی اعتبار چیزی به شما نمی‌گوید، چون با شما هم سابقه‌ای ندارد.

درباره‌ی سخت‌ترین گیرنده صادقانه انتظار داشته باشید. Outlook.com جایی است که یک آدرس جدید بیشترین مدت را دست‌وپنجه نرم می‌کند: عادی است که یک سرور با تنظیمات درست و احراز هویت کامل، هفته‌ها آنجا در Junk بماند، در حالی که Gmail از همان پیام اول قبولش می‌کند. راه‌حل زمان است، ثبات، و گیرندگانی که پیام را از Junk بیرون می‌آورند — نه یک رکورد DNS دیگر. اگر تحویل‌پذیری در Outlook.com از روز اول یک الزام کسب‌وکاری باشد نه یک ترجیح، این یکی از سیگنال‌هایی است که نشان می‌دهد به یک relay نیاز دارید نه یک فرستنده‌ی self-hosted، که موضوع بخش آخر است.

چه چیزی اجرا کنید، و چقدر ماشین لازم دارد

چهار شکل تقریباً همه را پوشش می‌دهد. Postfix همراه با Dovecot برای IMAP و rspamd برای فیلتر کردن، همان استقرار مرجع است: سه daemon، تنظیمات متنی ساده، و هر پیام خطایی که ممکن است ببینید از قبل جایی جواب داده شده. OpenSMTPD همان کار را با یک فایل تنظیمات انجام می‌دهد که در یک نشست می‌توانید بخوانید، که ساعت سه صبح بیشتر از ظاهرش ارزش دارد. Stalwart یک باینری تکی است که SMTP، IMAP و JMAP را با فیلترینگ داخلی صحبت می‌کند، و امروز خوشایندترین گزینه‌ی greenfield است. و Mailcow یا Mail-in-a-Box کل چیز را برایتان سرهم می‌کنند، با webmail، به قیمت یک استکی که خودتان انتخابش نکرده‌اید و به‌راحتی هم نمی‌توانید بازش کنید.

اندازه‌گیری کمتر درباره‌ی صندوق‌ها و بیشتر درباره‌ی چیزی است که جلویش سوار می‌کنید. خود SMTP و IMAP ارزان هستند؛ چند ده صندوق روی هر ماشین مدرنی یک خطای گرد کردن است. حافظه صرف فیلترینگ می‌شود. rspamd سبک است، چند صد مگابایت با mapهایش بارگذاری‌شده. ClamAV این‌طور نیست: فقط پایگاه‌داده‌ی امضایش بیش از یک گیگابایت حافظه‌ی resident می‌گیرد، و محتمل‌ترین جزئی است که یک instance کوچک را وارد swap می‌کند — که روی یک میل سرور یعنی صف پر می‌شود و تحویل آن‌قدر کند می‌شود که گیرنده‌ها شروع به defer کردن شما می‌کنند. اگر RAM دارید اجرایش کنید، اگر ندارید ردش کنید و بگذارید rspamd بار را بکشد.

روی پلن‌های واقعی: یک Starter با قیمت $8.50 با 2 vCPU، 4 GB رم و 60 GB فضای NVMe، Postfix، Dovecot و rspamd را برای یک دامنه‌ی شخصی به‌راحتی اجرا می‌کند، به شرط این‌که ClamAV را کنار بگذارید. یک Growth با قیمت $13.50 با 4 vCPU، 8 GB و 120 GB همان اندازه‌ای است که دیگر لازم نیست نگرانش باشید — بیست تا سی صندوق با فیلترینگ کامل، با فضای زیاد برای مخزن ایمیلی که سال‌ها رشد می‌کند. فضای ذخیره‌سازی همان محوری است که واقعاً اول تمام می‌شود، چون ایمیل برای همیشه توسط هرکسی که آن را دریافت کرده نگه داشته می‌شود.

بالا آوردنش به ترتیب درست

۱. دامنه را نشانه بگیرید و instance را مستقر کنید. تصمیم بگیرید سرور با چه نام میزبانی خودش را معرفی می‌کند — mail.example.com رسم رایج است — رکورد A آن را منتشر کنید، AAAA را فقط اگر قصد ارسال روی IPv6 دارید اضافه کنید، و رکورد MX دامنه را به همان نام اشاره دهید. لوکیشنی را انتخاب کنید که به افرادی که با آن‌ها مکاتبه می‌کنید نزدیک‌تر است؛ در BitVPS instance حدود شصت ثانیه پس از تأیید پرداخت زنده است، با پورت 25 خروجی که از قبل باز است.

۲. DNS معکوس را همسو تنظیم کنید. رکورد PTR آدرس IPv4 — و آدرس IPv6 هم اگر AAAA منتشر کرده‌اید — را دقیقاً به همان نام میزبان مرحله‌ی اول تنظیم کنید. رفت و برگشت باید توافق داشته باشند. این فقط یک فیلد پنل است و باارزش‌ترین دقیقه‌ی کل فرایند است.

۳. پورت‌های درست را در هر دو جهت باز کنید. پورت 25 خروجی برای تحویل دادن، پورت 25 ورودی برای دریافت کردن، 587 و 465 برای این‌که کاربران خودتان پیام ارسال کنند، 993 برای IMAP، بقیه بسته. یک فایروال که پورت 25 خروجی را اجازه می‌دهد اما ورودی را نه، در ساعت اول دیباگ دقیقاً شبیه یک مشکل DNS به نظر می‌رسد، در حالی که نیست.

۴. MTA را نصب کنید و یک هویت واقعی به آن بدهید. Postfix، OpenSMTPD یا Stalwart؛ نام HELO را به همان نام میزبان مرحله‌ی اول تنظیم کنید؛ TLS را با یک گواهی برای آن نام فعال کنید. Let's Encrypt رایگان است و همان چیزی است که بیشتر اینترنت ارائه می‌دهد. پیش از ادامه، یک پیام برای خودتان بفرستید و هدرها را بخوانید — هر مرحله‌ی بعدی فرض می‌کند این یکی جواب داده.

۵. SPF، DKIM و DMARC را منتشر کنید. یک رکورد SPF که آدرس فرستنده را فهرست کند و تا زمانی که در حال تست هستید به ~all ختم شود. یک کلید DKIM 2048-bit با selectorاش منتشر و امضا فعال. یک رکورد DMARC روی p=none با یک آدرس rua تا گزارش‌ها شروع به رسیدن کنند. سه رکورد DNS، بدون هزینه، حداکثر یک ساعت.

۶. نتایج احراز هویت را بخوانید، نه صندوق ورودی را. به Gmail، به Outlook.com و به یک گیرنده‌ی سازمانی بفرستید، سپس Authentication-Results را روی هرکدام باز کنید. دنبال spf=pass، dkim=pass، dmarc=pass بگردید، و این‌که هم‌ترازی با دامنه‌ی موجود در From: قابل‌مشاهده باشد. Junk با سه پاس، یک مشکل اعتبار است؛ Junk با یک شکست، یک مشکل تنظیمات است. این دو به شکل‌های کاملاً متفاوتی رفع می‌شوند، و اشتباه گرفتنشان هفته‌ها هدر می‌رود.

۷. وقتی گزارش‌ها تمیز شدند، سخت‌گیرتر شوید. پس از یک یا دو هفته گزارش DMARC که در آن هیچ منبع مشروعی fail نشده، به p=quarantine و بعد به p=reject بروید، و SPF را از ~all به -all تغییر دهید. سخت‌گیر شدن پیش از خواندن گزارش‌ها، همان راهی است که مردم فاکتورهای خودشان را برای یک ماه بدون این‌که متوجه شوند مسدود می‌کنند.

۸. بخش‌هایی که همه فراموش می‌کنند را اضافه کنید. MTA-STS و TLS-RPT منتشر کنید تا فرستنده‌های دیگر بدانند باید روی TLS با شما اصرار کنند، اگر zone شما امضا شده DANE اضافه کنید، rspamd را جلوی صندوق ورودی بگذارید، مخزن ایمیل را جایی غیر از همین ماشین پشتیبان‌گیری کنید، و آن را در حالت سکون رمزنگاری کنید — راهنمای رمزنگاری کامل دیسک پوشش می‌دهد که این کار چه محافظتی می‌کند و چه محافظتی نمی‌کند. سپس صف خروجی را زیر نظر بگیرید: صفی که بی‌سروصدا در حال رشد است، اولین علامت یک مشکل اعتبار است، و روزها پیش از این‌که متوجه پاسخ‌های گم‌شده شوید ظاهر می‌شود.

وقتی self-hosting ابزار اشتباهی است

مواردی هست که اجرای فرستنده‌ی خودتان معامله‌ی بدی است، و صریح بودن درباره‌شان مفیدتر از یک پاراگراف دیگر تشویق است. بازاریابی حجیم با شروع سرد بدیهی‌ترین مورد است: آدرسی تازه بدون سابقه که هزاران پیام می‌فرستد، دقیقاً همان الگویی است که فیلترها برای گرفتنش ساخته شده‌اند، و هیچ تنظیماتی نجاتش نمی‌دهد. ایمیل تراکنشی که گم شدن یک پیام هزینه‌ی مالی دارد — بازنشانی رمز عبور، تأیید سفارش، کد دو-مرحله‌ای — باید روی زیرساختی با اعتبار جاافتاده باشد، چون آن دو هفته‌ای که یک آدرس تازه صرف اثبات خودش می‌کند، دو هفته تیکت پشتیبانی است. و هر تیمی که کسی را نداشته باشد که یکشنبه‌ها به صف ایمیل نگاه کند، تیمی است که کشف می‌کند خروجی‌اش از جمعه به تعویق افتاده.

یک معامله‌ی حریم‌خصوصی هم هست که در بیشتر نوشته‌ها نادیده گرفته می‌شود. یک میل سرور کم‌ناشناس‌ترین چیزی است که می‌توانید اجرا کنید. یک دامنه منتشر می‌کند، یک آدرس ثابت، یک رکورد PTR که آن دامنه را نام می‌برد، یک رکورد MX که آن‌ها را به هم گره می‌زند، و به هر گیرنده‌ای مجموعه‌ی کاملی از هدرهایی می‌دهد که مسیر را توصیف می‌کنند. ناشناسی و یک MX عمومی در جهت‌های مخالف می‌کشند، و اگر دلیل حضور شما اینجا حریم‌خصوصی است نه کنترل، پیش از ساختن آن این‌که میزبانی کریپتویی واقعاً چقدر قابل‌ردیابی است را بخوانید. self-hosting واقعاً یک شخص ثالث را از ایمیل و متادیتای ذخیره‌شده‌ی شما حذف می‌کند، که یک دستاورد واقعی و باارزش است — اما خود ایمیل را ناشناس نمی‌کند، و نمی‌تواند، چون نیمی از هر مکالمه در صندوق شخص دیگری زندگی می‌کند.

ترتیبی که برای بیشتر افراد جواب می‌دهد یک تقسیم است. ایمیلی که حتماً باید برسد را نزد ارائه‌دهنده‌ای با اعتبار نگه دارید، یک دامنه‌ی دوم را برای مکاتباتی که می‌خواهید از زیرساخت شخص ثالث دور باشد self-host کنید، و بگذارید هرکدام باری را بکشد که در آن خوب است. هزینه‌اش یک zone DNS اضافه است، یعنی هیچ‌کدام از دو سیستم کاری را انجام نمی‌دهد که در آن بد است، و این همان کاری است که بخش بزرگی از کسانی که میل سرور روی BitVPS اجرا می‌کنند واقعاً انجام می‌دهند. هرچه می‌فرستید، فقط opt-in — لیست‌های خریداری‌شده خارج از سیاست استفاده‌ی مجاز ما هستند و سریع‌ترین راه برای سوزاندن آدرسی است که وقتی به شما تحویلش دادیم تمیز بود.