آیا میزبانی ایمیل شخصی در سال 2026 منطقی است؟

پاسخ کوتاه

میزبانی ایمیل (Self-hosting) در سال 2026 همچنان ارزشمند است، به شرطی که وظیفه آن را به دو بخش تقسیم کنید. دریافت ایمیل روی VPS شخصی ریسک پایینی دارد و به‌خوبی کار می‌کند، زیرا شما گیرنده هستید و نیازی نیست کسی به شما اعتماد کند. ارسال ایمیل به‌گونه‌ای که توسط سرویس‌دهندگان بزرگ ایمیل پذیرفته شود، مقوله‌ای متفاوت است و به اعتبار آدرس IP بستگی دارد که شما آن را به ارث می‌برید، نه اینکه خودتان آن را بسازید.

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

بخش دشوار میزبانی ایمیل، قابلیت تحویل (deliverability) است

نصب یک سرور ایمیل، کاری است که یک آخر هفته زمان می‌برد. یک پشته (stack) مدرن، پروتکل SMTP (پروتکل انتقال ساده نامه) را برای جابه‌جایی ایمیل، IMAP (پروتکل دسترسی به پیام‌های اینترنتی) را برای خواندن آن، فیلتر اسپم و یک رابط کاربری وب‌میل را از طریق یک فایل compose در اختیار شما قرار می‌دهد و راهنمای نصب سرور ایمیل Mailcow روی VPS این موارد را پوشش می‌دهد. هیچ‌کدام از مراحل نصب، بخش دشوار کار نیستند.

دشواری زمانی آغاز می‌شود که سرور شما اتصالی را با ماشینی برقرار می‌کند که توسط شرکتی اداره می‌شود که هیچ شناختی از شما ندارد و از آن می‌خواهد که پیامی را در صندوق ورودی (inbox) شخصی قرار دهد. آن گیرنده دلیلی برای پذیرش ندارد. تصمیم‌گیری بر اساس سیگنال‌ها انجام می‌شود: اعتبار آدرس IP متصل‌شونده، اعتبار دامنه شما، احراز هویت پیام و نحوه واکنش کاربران آن سرویس به ایمیل‌های قبلی شما. یک فرستنده جدید هیچ سابقه‌ای ندارد و نبود سابقه به عنوان وضعیت خنثی امتیازدهی نمی‌شود؛ بلکه به عنوان ریسک در نظر گرفته می‌شود. بنابراین، اولین پیام‌ها به پوشه اسپم می‌روند یا تا زمانی که الگویی شکل بگیرد، به تعویق می‌افتند.

شما این امتناع را مشاهده خواهید کرد. Gmail یک رد دائمی با این فرمت ارسال می‌کند:

550-5.7.1 [203.0.113.5      19] Our system has detected that this message is
550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail,
550-5.7.1 this message has been blocked.

مایکروسافت پیام متفاوتی ارسال می‌کند که به یک کد لیست سیاه (block-list) ختم می‌شود که متغیر است:

550 5.7.1 Unfortunately, messages from [203.0.113.5] weren't sent. Please
contact your Internet service provider since part of their network is on
our block list (S3150).

پیش از هر چیز، رقم اول کد را بخوانید. کدی که با 4 شروع می‌شود موقتی است، بنابراین سرور شما پیام را نگه می‌دارد و دوباره تلاش می‌کند. کدی که با 5 شروع می‌شود دائمی است، بنابراین پیام بلافاصله به فرستنده بازگردانده می‌شود (bounce). یک تعویق (deferral) با کد 4xx که هرگز برطرف نمی‌شود، نشان‌دهنده محدودیت نرخ (rate limit) یا محدودیت اعتبار است و ممکن است خودبه‌خود حل شود. کد 5xx یک تصمیم قطعی است و تغییر نخواهد کرد.

چرا ایمیل‌های یک سرور جدید به پوشه Spam می‌روند؟

دلیل این است که آدرس IP جدید نیست. شما یک آدرس تازه دریافت نمی‌کنید، بلکه آدرسی بازیافتی از استخر آدرس‌های ارائه‌دهنده خود می‌گیرید که تاریخچه فعالیت‌های قبلی‌اش همراه آن است. اگر مستأجر قبلی این آدرس اقدام به ارسال اسپم کرده باشد، اولین پیام شما ممکن است پیش از آنکه فرصت ارسال پیام دوم را داشته باشید، رد شود.

پیش از آنکه هر چیزی روی سرور راه‌اندازی کنید، آدرس را بررسی کنید. لیست‌های سیاه عمومی (Public blocklists) از طریق DNS پاسخ می‌دهند؛ برای این کار باید چهار اکتت آدرس IP را معکوس کنید:

sudo apt update && sudo apt install -y bind9-dnsutils netcat-openbsd swaks
dig +short 10.0.0.10.zen.spamhaus.org

پاسخ خالی به این معناست که آدرس در لیست سیاه قرار ندارد. پاسخی در محدوده 127.0.0.0/8 به این معناست که آدرس لیست شده است و اکتت نهایی نشان می‌دهد کدام لیست با آن مطابقت دارد. یک نکته انحرافی در این تست وجود دارد: Spamhaus درخواست‌هایی را که از طریق resolverهای عمومی بزرگ ارسال می‌شوند رد می‌کند؛ بنابراین همان جستجو اگر از طریق 8.8.8.8 انجام شود، فارغ از وضعیت واقعی آدرس، نتیجه 127.255.255.254 را برمی‌گرداند. این کد به معنای رد شدن درخواست است، نه لیست شدن آدرس. این تست را از طریق resolver سرور خودتان اجرا کنید یا از ابزار جستجوی تحت وب استفاده کنید.

نتیجه پاک (Clean) ضروری است اما کافی نیست. لیست نشدن فقط به این معناست که اخیراً کسی از آن آدرس شکایتی نکرده است. این وضعیت هیچ اعتبار مثبتی به همراه ندارد و اعتبار مثبت همان چیزی است که در نهایت باعث می‌شود ایمیل‌ها به Inbox برسند. این اعتبار با ارسال حجم کمی از ایمیل‌های مورد نیاز در طول چند هفته به دست می‌آید.

همسایگان شما نیز اهمیت دارند، زیرا برخی از دریافت‌کنندگان، اعتبار را به جای یک آدرس واحد، برای کل یک بلوک شبکه محاسبه می‌کنند. وقتی مشتری دیگری در همان محدوده /24 شروع به ارسال اسپم کند، ایمیل‌های شما ممکن است به دلیل هم‌بستگی با آن آدرس‌ها با تأخیر مواجه شوند. همین نگاه در سطح بلوک شبکه است که باعث می‌شود شکایات سوءاستفاده به Inbox یک VPS برسد، حتی برای ترافیکی که صاحب حساب هرگز ارسال نکرده است؛ زیرا شکایت‌ها محدوده آدرس را دنبال می‌کنند.

مواردی که باید پیش از شروع تأیید کنید: پورت 25 و رکورد PTR

پورت خروجی TCP 25 بیشترین سوءاستفاده را در اینترنت دارد، بنابراین بسیاری از ارائه‌دهندگان میزبانی به‌صورت پیش‌فرض آن را روی حساب‌های جدید می‌بندند. برخی با درخواست شما آن را باز می‌کنند. برخی پس از گذشت مدتی از عمر حساب و داشتن تاریخچه پرداخت، آن را باز می‌کنند. برخی نیز هرگز آن را باز نمی‌کنند. سیاست‌ها بین ارائه‌دهندگان متفاوت است و با گذشت زمان تغییر می‌کند، بنابراین به این پست، یک تاپیک قدیمی در انجمن‌ها یا صفحه تبلیغاتی هیچ ارائه‌دهنده‌ای به‌عنوان حقیقت فعلی نگاه نکنید. پیش از پرداخت هزینه، بپرسید و پاسخ را به‌صورت کتبی دریافت کنید.

مسیر را از خود سرور تست کنید:

nc -vz gmail-smtp-in.l.google.com 25

یک مسیر باز، succeeded! را در کمتر از یک ثانیه چاپ می‌کند. یک مسیر مسدودشده متوقف می‌شود و سپس بدون هیچ پیامی که مسدود بودن را اعلام کند، با خطای timeout مواجه می‌شود؛ زیرا یک بسته که بی‌سروصدا حذف (drop) شده است، دقیقاً مانند یک مشکل شبکه معمولی به نظر می‌رسد.

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

dig -x 203.0.113.5 +short
dig +short mail.example.com

اولی باید نام میزبان ایمیل شما را برگرداند. دومی باید همان آدرسی را برگرداند که با آن شروع کردید. فقط مالک یک آدرس IP می‌تواند رکورد PTR آن را منتشر کند، بنابراین این موردی است که میزبان شما برایتان تنظیم می‌کند یا در کنترل پنل در اختیار شما قرار می‌دهد. نبود رکورد PTR یا داشتن یک رکورد عمومی مانند 203-0-113-5.static.example-isp.net، یک سیگنال منفی قوی است؛ زیرا سرورهای ایمیل واقعی تقریباً همیشه نام منطبق دارند و منابع ارسال اسپم انبوه اغلب فاقد آن هستند.

اگر میزبان شما IPv6 نیز اختصاص می‌دهد و سرور شما آن را ترجیح می‌دهد، تمام موارد بالا برای آدرس IPv6 نیز صدق می‌کند و Gmail در این مورد سخت‌گیرتر است. ارسال از طریق IPv6 با آدرسی که رکورد PTR ندارد، منجر به رد شدن پیام می‌شود؛ با این مضمون که پیام با دستورالعمل‌های ارسال IPv6 در مورد رکوردهای PTR و احراز هویت مطابقت ندارد. اگر نمی‌توانید رکورد PTR برای IPv6 تنظیم کنید، فقط از طریق IPv4 ارسال کنید. در Postfix، برای ترجیح دادن IPv4 از smtp_address_preference = ipv4 و برای غیرفعال کردن کامل IPv6 از inet_protocols = ipv4 استفاده کنید.

سه سوالی که باید از هر میزبان بپرسید

1. آیا پورت خروجی TCP 25 روی یک حساب جدید باز است؟ اگر نیست، فرآیند دقیق و زمان‌بندی برای باز کردن آن چیست؟
2. آیا می‌توانم رکورد PTR را برای آدرس IPv4 و آدرس IPv6 خود تنظیم کنم و این کار را کجا باید انجام دهم؟
3. اگر مشخص شود آدرس من به دلیل مشتری قبلی در لیست سیاه (blocklist) قرار دارد، آیا مرا به آدرس دیگری منتقل می‌کنید؟

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

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

سه رکورد DNS اثبات می‌کنند که ایمیل ادعاشده از طرف دامنه شما، واقعاً از آنجا ارسال شده است. هر کدام به پرسش متفاوتی پاسخ می‌دهند و سومی تنها زمانی کار می‌کند که دو مورد اول را درک کرده باشید.

SPF (مخفف sender policy framework) یک رکورد TXT است که فهرست سرورهایی که مجاز به ارسال ایمیل برای دامنه شما هستند را مشخص می‌کند. گیرنده آن را با فرستنده پاکت (envelope sender) تطبیق می‌دهد؛ این همان آدرسی است که در دستور SMTP MAIL FROM ارائه می‌شود و با هدر From: که خواننده می‌بیند، متفاوت است.

DKIM (مخفف domainkeys identified mail) یک امضای رمزنگاری‌شده به هدرهای پیام اضافه می‌کند که بدنه و فهرستی از هدرهای انتخاب‌شده را پوشش می‌دهد. کلید عمومی متناظر در DNS تحت یک selector که شما انتخاب می‌کنید، قرار می‌گیرد. هر کسی می‌تواند تایید کند که پیام از طرف دارنده کلید خصوصی شما ارسال شده و در مسیر تغییر نکرده است.

DMARC (مخفف domain-based message authentication, reporting and conformance) دو مورد دیگر را به دامنه موجود در هدر قابل مشاهده From: متصل می‌کند و به گیرندگان می‌گوید که در صورت عدم تطابق، چه اقدامی انجام دهند.

example.com.                  TXT  "v=spf1 mx -all"
mail._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc.example.com.           TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

کلمه کلیدی در اینجا «تطابق» (alignment) است. DMARC صرفاً به این دلیل که SPF تایید شده، پاس نمی‌شود. زمانی پاس می‌شود که SPF یا DKIM تایید شوند و دامنه‌ای که تایید شده، همان دامنه‌ای باشد که در هدر From: قرار دارد. اینجاست که ایمیل‌های رله‌شده (relayed) بی‌سروصدا شکست می‌خورند: رله‌ای که فرستنده پاکت را به دامنه خودش بازنویسی می‌کند، همچنان یک SPF pass ایجاد می‌کند، اما چون دامنه تاییدشده متعلق به رله است، تطابق برقرار نیست و DMARC شکست می‌خورد، مگر اینکه امضای DKIM خودتان موجود و معتبر باشد. با امضا کردن توسط کلیدی که تحت دامنه شما منتشر شده، مشکل برطرف می‌شود.

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

ابتدا p=none را با یک آدرس گزارش‌دهی rua= منتشر کنید و به مدت دو هفته گزارش‌های تجمیعی را بخوانید تا هر چیزی را سخت‌گیرانه‌تر کنید. آن گزارش‌ها تنها جایی هستند که ایمیل‌های ارسال‌شده به نام شما که خودتان نفرستاده‌اید را می‌بینید و تنها راه برای یافتن فورواردکننده‌ای هستند که فراموش کرده‌اید. رفتن مستقیم به p=reject این مرحله را حذف می‌کند و باعث شکست ایمیل‌های قانونی بدون هیچ رکوردی از دلیل خرابی می‌شود.

سپس کل زنجیره را از ابتدا تا انتها تست کنید. یک پیام به حسابی که در یک سرویس‌دهنده بزرگ دارید بفرستید و سورس خام آن را باز کنید:

swaks --to you@gmail.com --from postmaster@example.com --server 127.0.0.1
sudo journalctl -t postfix/smtp -f

swaks مکالمه SMTP را همان‌طور که رخ می‌دهد چاپ می‌کند. خط لاگ خود Postfix برای تحویل پیام با status=sent (250 2.0.0 OK ...) پایان می‌یابد، زمانی که سرور گیرنده پیام را پذیرفته باشد. هر چیز دیگری متن امتناع را عیناً لاگ می‌کند و آن رشته همان چیزی است که باید جستجو کنید. در پیام تحویل‌داده‌شده، سورس خام دارای یک هدر Authentication-Results: است که هر بررسی را با یک pass یا fail و دامنه‌ای که احراز هویت کرده، نام می‌برد. هر سه باید pass باشند و دامنه باید متعلق به شما باشد.

چگونه از وجود مشکل در اعتبار (Reputation) مطلع شویم؟

حلقه بازخورد (Feedback loop) سازوکاری است که در آن ارائه‌دهنده صندوق پستی، هر زمان که یکی از کاربرانش دکمه گزارش اسپم را کلیک کند، یک نسخه از آن پیام را برای شما ارسال می‌کند. بدون این حلقه، اولین نشانه بروز مشکل، عدم تحویل ایمیل‌هاست که در آن زمان دیگر هفته‌ها از وقوع مشکل گذشته است.

این برنامه‌ها با یکدیگر متفاوت هستند و همه آن‌ها برای یک VPS واحد با یک آدرس IP مناسب نیستند. تا اوت 2026، مایکروسافت سرویس داده و شکایات مبتنی بر آدرس ارائه می‌دهد که مالک آدرس می‌تواند در آن ثبت‌نام کند؛ یاهو یک حلقه بازخورد شکایات ارائه می‌دهد که بر اساس دامنه امضاکننده DKIM کار می‌کند؛ و گوگل به‌جای شکایات فردی، داده‌های اعتباری تجمیعی را در داشبوردی منتشر می‌کند که تا زمانی که حجم قابل‌توجهی از ایمیل روزانه به کاربرانش ارسال نکنید، خالی می‌ماند. پیش از تکیه بر هر یک از این سرویس‌ها، شرایط فعلی آن‌ها را مطالعه کنید، زیرا این برنامه‌ها تغییر می‌کنند و هیچ‌کدام تعهدی برای ارائه دسترسی به شما ندارند.

الزامات منتشرشده گوگل برای فرستندگان انبوه که از فوریه 2024 اجرایی شده‌اند، شفاف‌ترین بیانیه عمومی درباره انتظارات فعلی یک دریافت‌کننده بزرگ است. فرستنده‌ای که بیش از 5000 پیام در روز به حساب‌های شخصی Gmail ارسال می‌کند، باید با SPF و DKIM احراز هویت کند، یک سیاست DMARC منتشر نماید، امکان لغو اشتراک با یک کلیک را در ایمیل‌های انبوه فراهم کند و نرخ شکایات اسپم را زیر 0.3 درصد نگه دارد. ایمیل‌های شخصی از یک سرور کوچک بسیار پایین‌تر از این حد آستانه هستند، اما همان سیگنال‌ها در هر حجمی بررسی می‌شوند و نرخ شکایات، موردی است که بدون داشتن حلقه بازخورد قادر به مشاهده آن نخواهید بود.

تفکیک کارآمد: دریافت ایمیل به صورت self-host، ارسال از طریق relay

دریافت ایمیل بخشی است که تقریباً هیچ نقطه ضعفی ندارد. برای اینکه ایمیلی که برای شما ارسال شده را دریافت کنید، هیچ‌کس نیازی به اعتماد به شما ندارد. رکورد MX شما، یعنی همان رکورد DNS که mail exchanger دامنه شما را مشخص می‌کند، به سرور شما اشاره دارد. فرستنده‌ها به شما متصل می‌شوند و تمام تصمیمات پس از آن با شماست: چه چیزی را نگه دارید، تا چه مدت، چگونه ایندکس شود و چه کسی اجازه جستجوی آن را داشته باشد. هزینه ذخیره‌سازی پایین است و آرشیوی که مالک آن هستید، به دلیل تصمیمات خودکار سیاست‌های دیگران بسته نمی‌شود. این کار واقعی و محدود است: فیلتر اسپم را به‌روز نگه دارید، گواهی‌های TLS (امنیت لایه انتقال) را تمدید کنید، از داده‌ها نسخه پشتیبان بگیرید و مراقب پر شدن دیسک باشید.

بخش ارسال، جایی است که شما با پرداخت هزینه، خود را از یک مشکل دشوار خلاص می‌کنید. سرور خود را طوری پیکربندی کنید که به جای صحبت با دنیای خارج روی پورت 25، هر پیام خروجی را به یک relay احراز هویت‌شده روی پورت 587 تحویل دهد. در فایل main.cf پست‌فیکس:

relayhost = [smtp.relay.example]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

اطلاعات کاربری را با یک ویرایشگر در /etc/postfix/sasl_passwd بنویسید تا رمز عبور هرگز در تاریخچه shell شما ذخیره نشود. این یک خط است و نام میزبان در سمت چپ باید دقیقاً همان‌طور که در relayhost ظاهر می‌شود، نوشته شود:

[smtp.relay.example]:587 username:password

sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd.db
sudo systemctl reload postfix

پیامی که پس از آن reload ارسال شود، لاگ‌های relay=smtp.relay.example[...]:587 و status=sent را ثبت می‌کند. خط لاگی که SASL authentication failed را نشان می‌دهد به این معنی است که اطلاعات کاربری پذیرفته نشده‌اند. دلیل معمول این اتفاق، تفاوت در نوشتن نام میزبان در sasl_passwd نسبت به relayhost است، زیرا جستجو بر اساس تطابق دقیق رشته انجام می‌شود.

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

یک جداسازی دیگر نیز ارزش دارد که از همان روز اول انجام شود. هرگونه ارسال انبوه باید از زیردامنه اختصاصی خود با کلید DKIM مخصوص به خود انجام شود: news.example.com برای خبرنامه و mail.example.com برای ایمیل‌های شخصی. اعتبار به دامنه فرستنده متصل است، بنابراین نرخ شکایت در یک خبرنامه Listmonk که به صورت self-hosted اجرا می‌شود، نمی‌تواند اعتبار ایمیل‌های شخصی شما را خدشه‌دار کند.

چه زمانی میزبانی کامل (Self-hosting) همچنان انتخاب درستی است؟

حجم. قیمت‌گذاری بر اساس هر پیام در تعداد صدها پیام در ماه مناسب است، اما در مقیاس میلیون‌ها پیام دیگر صرفه اقتصادی ندارد. در آن مقیاس، شما توانایی تأمین آدرس‌های اختصاصی و برنامه گرم‌سازی (warmup) لازم برای عملکرد صحیح آن‌ها را دارید.

حوزه قضایی. زمانی که یک مقررات یا قرارداد حکم می‌کند که ایمیل نباید روی دیسک شخص ثالث ذخیره شود، کیفیت تحویل دیگر عامل تعیین‌کننده نیست. در این شرایط، استفاده از سرویس relay برای شما امکان‌پذیر نخواهد بود.

کنترلی که نمی‌توان خرید. قوانینی برای نگهداری داده‌ها که با سیاست‌های شما مطابقت دارد (نه با سطوح اشتراک)، اختصاص یک آدرس ایمیل به هر سرویس برای شناسایی منبع نشت اطلاعات، فیلترینگ با استفاده از کدهای اختصاصی خودتان، و عدم تعلیق حساب توسط سیستمی که امکان تجدیدنظر در آن وجود ندارد.

ایمیلی که هرگز شبکه شما را ترک نمی‌کند. هشدارها و سایر ایمیل‌های ماشین‌به‌ماشین هیچ مشکلی در تحویل ندارند، زیرا هر دو سمت ارتباط متعلق به شماست. یک سرور SMTP محلی که ایمیل‌ها را مستقیماً به صندوق‌های پستی خودتان تحویل می‌دهد، پاسخ کامل است؛ این همان الگویی است که در اختصاص یک صندوق پستی self-hosted به دستیار هوشمند از طریق MCP (پروتکل زمینه مدل) استفاده می‌شود.

اگر قصد دارید ایمیل‌های خروجی را مستقیماً ارسال کنید، آدرس خود را گرم (warm up) کنید. با حجم روزانه پایین برای افرادی که منتظر ایمیل شما هستند شروع کنید، آن را به‌تدریج در طول چند هفته افزایش دهید و هرگز از یک آدرس سرد، حجم زیادی ایمیل ارسال نکنید. اعتبار با پذیرش ایمیل‌ها و دریافت شکایات کم در طول زمان ساخته می‌شود؛ بنابراین، جهش ناگهانی در ارسال از آدرسی که هیچ سابقه‌ای ندارد، دقیقاً مانند یک سرور breached (رخنه شده) به نظر می‌رسد و با آن همان‌گونه برخورد خواهد شد.

هزینهٔ سال اول اجرای یک میل‌سرور چقدر است؟

هفتهٔ اول صرف ساختار می‌شود: نصب بسته‌ها، رکوردهای DNS، گواهی‌های TLS، اولین پیام‌های آزمایشی و تنظیم DMARC در p=none.

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

پس از آن، کار به حدود یک ساعت در ماه می‌رسد: به‌روزرسانی بسته‌ها، تمدید گواهی که به‌جای فرض کردن، آن را تأیید می‌کنید، تست بازیابی از نسخه پشتیبان، بررسی رشد حجم دیسک و یک جستجو در لیست‌های مسدود (blocklist).

سپس هفته‌ای فرا می‌رسد که نمی‌توانید برایش برنامه‌ریزی کنید. یک آدرس به دلیلی که شما در آن نقشی نداشته‌اید، در لیست سیاه قرار می‌گیرد. یک دریافت‌کننده بزرگ قوانین خود را تغییر می‌دهد و ایمیل‌های شما دوباره به پوشه اسپم می‌روند. ایمیل‌های در صف، ایمیل‌های ازدست‌رفته نیستند: Postfix به‌طور پیش‌فرض پیام‌های معوق را به مدت 5 روز دوباره ارسال می‌کند که توسط maximal_queue_lifetime = 5d تنظیم می‌شود؛ بنابراین قطعی که در حد چند ساعت باشد، فقط باعث تأخیر می‌شود و هزینه دیگری ندارد. اما قطعی که یک هفته طول بکشد، باعث از دست رفتن ایمیل‌های شما می‌شود.

داشتن یک رکورد MX پشتیبان، راه‌حل ضعیف‌تری نسبت به آن چیزی است که به نظر می‌رسد. سرورهای فرستنده خودشان از قبل برای چند روز تلاش مجدد می‌کنند، بنابراین سرور ثانویه‌ای که فقط ایمیل‌ها را در صف نگه می‌دارد، ارزش چندانی اضافه نمی‌کند. بدتر اینکه، سرور ثانویه‌ای که بدون اطلاع از وجود آدرس‌ها، ایمیل‌های دامنه شما را می‌پذیرد، ایمیل‌های مربوط به آدرس‌های ناموجود را دریافت کرده و سپس آن‌ها را به فرستندگان جعلی بازمی‌گرداند (bounce)؛ این کار پشتیبان شما را به منبعی برای backscatter تبدیل می‌کند. تلاش خود را صرف مانیتورینگ و بازیابی‌ای کنید که واقعاً آن را تست کرده‌اید.

کل این موضوع را با همان سوالی بسنجید که برای هر چیز دیگری روی سرور به کار می‌برید: آیا مالکیت این سرویس چیزی به شما می‌دهد که نمی‌توانید بخرید؟ برای صندوق‌های پستی و آرشیو، پاسخ معمولاً بله است. برای ارسال ایمیل به غریبه‌ها، پاسخ معمولاً خیر است. این همان آزمونی است که بقیه فهرست مواردی که ارزش میزبانی شخصی در سال 2026 را دارند را دسته‌بندی می‌کند.

FAQ

آیا می‌توانم ایمیل را در سرور شخصی میزبانی کنم اگر ارائه‌دهنده VPS پورت 25 خروجی را مسدود کرده باشد؟

بله، برای دریافت ایمیل و همچنین ارسال آن از طریق یک relay. ایمیل‌های ورودی به پورت 25 سرور شما می‌رسند و مسدود بودن پورت خروجی تأثیری بر آن‌ها ندارد. ایمیل‌های خروجی نیز از طریق یک relay احراز هویت‌شده در پورت 587 ارسال می‌شوند که ارائه‌دهندگان آن را مسدود نمی‌کنند. کاری که با بسته بودن پورت 25 نمی‌توانید انجام دهید، ارسال مستقیم به سایر سرورهای ایمیل است، زیرا تحویل ایمیل بین سرورها طبق تعریف در پورت 25 انجام می‌شود. این وضعیت را با nc -vz gmail-smtp-in.l.google.com 25 تست کنید. توقف در اجرا و سپس دریافت خطای timeout به معنای مسدود بودن پورت است.

چرا با وجود عبور موفق از SPF، DKIM و DMARC، ایمیل‌های من به پوشه اسپم می‌روند؟

احراز هویت ثابت می‌کند چه کسی پیام را ارسال کرده است، اما ثابت نمی‌کند که پیام مورد نظر گیرنده است. عبور از هر سه مورد، وضعیت شما را از «ناشناس» به «شناسایی‌شده» تغییر می‌دهد؛ پس از آن، گیرنده به IP و اعتبار دامنه شما امتیاز می‌دهد که فرستنده جدید هنوز آن را کسب نکرده است. این اعتبار را با ارسال حجم کمی از ایمیل‌های مورد انتظار کاربران در طول چند هفته بسازید. سپس تأیید کنید که رکورد PTR با نام میزبان ایمیل شما در هر دو جهت مطابقت دارد و بررسی کنید که محتوای ایمیل، مانند استفاده از کوتاه کننده‌های لینک یا دامنه‌های ردیابی ناشناس، باعث جریمه شدن نشود.

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

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

آیا انتقال آدرس اصلی به سرور شخصی ایمن است؟

انتقال را به‌صورت مرحله‌ای انجام دهید و نه یک‌باره. صندوق پستی فعلی را فعال نگه دارید، سرور خود را به‌عنوان مقصد دوم اضافه کنید و برای چند هفته یک کپی از ایمیل‌ها را به آن فوروارد کنید تا گزارش‌های DMARC را بررسی کرده و از جریان صحیح ایمیل‌ها در هر دو جهت مطمئن شوید. رکورد MX را تنها پس از گذشت یک هفته از دریافت صحیح ایمیل‌های آزمایشی تغییر دهید. شکستی که کاربران از آن پشیمان می‌شوند، تغییر ناگهانی است که منجر به از دست رفتن ایمیل‌های ورودی می‌شود؛ چرا که ایمیل‌های ورودی بخشی هستند که قابل بازیابی نیستند.

کوچک‌ترین پیکربندی برای حفظ کنترل بر ایمیل‌هایم چیست؟

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