> ## Content Index > Fetch the complete content index at: https://itsamir.ir/llms.txt > Use this file to discover other available public pages before exploring further. # راه‌اندازی ایمیل سرور با Stalwart و Docker؛ تجربه من تو PXLAds - URL: https://itsamir.ir/stalwart-mail-server-docker-vps/ - Published: 2026-09-14T20:26:08.000Z - Updated: 2026-09-14T20:26:08.000Z - Description: تجربهٔ راه‌اندازی ایمیل PXLAds با Stalwart روی VPS: از نصب Docker و تنظیم DNS تا خطای یاهو و ایمیلی که Gmail پذیرفت، اما به Spam فرستاد. - Author: ItsAmir - Tags: Docker, Stalwart, DevOps, لینوکس, ایمیل سرور وقتی داشتم روی [PXLAds](https://pxlads.ir/?ref=itsamir.ir) کار می‌کردم، کنار بخش‌های مختلف پروژه یه سرویس ایمیل هم روی دامنه خودم راه انداختم. چیزی که می‌خواستم این بود که آدرسی مثل `info@pxlads.ir` داشته باشم و ارسال و دریافت ایمیل‌ها رو روی زیرساخت خودم مدیریت کنم. برای این بخش از **Stalwart + Docker** روی یه VPS تو هلند استفاده کردم. سرویس بالا اومد، صندوق ایمیل ساخته شد و تنظیمات DNS رو هم انجام دادم. ولی بعد از این‌ها تازه چالش‌های ارسال خودشون رو نشون دادن. یه بار Gmail به PTR ایراد می‌گرفت، Yahoo ایمیل رو با خطای `TSS09` برمی‌گردوند و بعد هم ایمیلی که تو لاگ سرور با موفقیت ارسال شده بود، تو Gmail رفت داخل Spam. گفتم تجربه **راه‌اندازی ایمیل سرور با Stalwart** رو اینجا بنویسم؛ هم بخش نصب و تنظیماتش، هم چیزهایی که موقع ارسال به Gmail و Yahoo باهاشون برخورد کردم. چون بالا اومدن سرویس فقط یه قسمت از این مسیره. ## توی این پست چی می‌خونید؟ - [انتخاب Stalwart](#why-stalwart) و شکل سرویس ایمیلی که برای PXLAds راه انداختم - [آماده‌کردن VPS و DNS](#server-dns)، از پورت ۲۵ تا تنظیم PTR - [نصب با Docker و تنظیم TLS](#docker-setup) برای اتصال برنامه‌های ایمیل - [تنظیم SPF، DKIM و DMARC](#email-auth) برای مشخص‌شدن هویت فرستنده - [تجربه Gmail و Yahoo](#delivery-experience) و تفاوت ارسال موفق با رسیدن به Inbox - [گزارش‌ها و نگهداری سرویس](#reports-maintenance)، از MTA-STS تا پشتیبان‌گیری ## سرویس ایمیل من چه شکلیه؟ برای PXLAds از Stalwart استفاده کردم که SMTP، IMAP و JMAP رو همراه با یه پنل مدیریت وب در اختیارمون می‌ذاره. توی این نوشته بیشتر با SMTP برای ارسال و IMAP برای دسترسی به صندوق کار داریم. [راهنمای شروع Stalwart](https://stalw.art/docs/install/get-started/?ref=itsamir.ir) سرویس ایمیل روی VPS هلند قرار داره. بخش وب پروژه مسیر جداگانه‌ای داره؛ لازم نیست سایت و ایمیل حتماً روی یه سرور باشن. رکورد MX مشخص می‌کنه ایمیل‌های دامنه باید به کجا برسن. برای نمونه‌های پایین از `example.com` و IP مستندسازی `203.0.113.10` استفاده کردم. این‌ها رو باید با دامنه و IP خودتون جایگزین کنید. نمونه نصب هم برای **یه VPS تازه و Stalwart 0.16** نوشته شده؛ استقرار واقعی من Caddy هم داره که تفاوتش رو جلوتر میگم. ## قبل از نصب؛ VPS، پورت ۲۵ و تنظیم DNS برای شروع به یه دامنه، دسترسی به DNS، یه VPS با IP ثابت و دسترسی SSH نیاز دارید. Docker و Compose هم باید روی سرور نصب باشن. اگه هنوز نصبشون نکردید، [راهنمای رسمی Docker برای Ubuntu](https://docs.docker.com/engine/install/ubuntu/?ref=itsamir.ir) مسیر نصب رو توضیح داده. قبل از خرید VPS حتماً از ارائه‌دهنده بپرسید که پورت ۲۵ ورودی و خروجی باز هست یا نه، و امکان تنظیم PTR رو داره یا نه. باز بودن پورت ۵۸۷ به‌تنهایی برای ارسال مستقیم به سرورهای ایمیل کافی نیست؛ ارتباط بین خود سرورهای ایمیل معمولاً روی پورت ۲۵ انجام میشه. [استاندارد SMTP](https://www.rfc-editor.org/rfc/rfc5321.html?ref=itsamir.ir) مشخصات نمونه ما این‌هاست: | مورد | مقدار نمونه | | ----------- | ---------------- | | دامنه | example.com | | سرور ایمیل | mail.example.com | | IPv4 | 203.0.113.10 | | صندوق ایمیل | info@example.com | ### رکوردهای A و MX توی پنل DNS این رکوردها رو اضافه کنید: | نوع | نام | مقدار | اولویت | | --- | ---- | ----------------- | ------ | | A | mail | 203.0.113.10 | — | | MX | @ | mail.example.com. | 10 | اگه DNS شما گزینه Cloud یا Proxy داره، برای `mail` خاموشش کنید تا این نام به IP واقعی سرور برسه. پروکسی معمول وب برای SMTP و IMAP کافی نیست. دامنه اصلی سایت همچنان می‌تونه پشت CDN بمونه. ### PTR رو باید ارائه‌دهنده IP تنظیم کنه PTR همون Reverse DNS هست. با رکورد A میگیم `mail.example.com` چه IPای داره؛ با PTR مسیر برعکس رو مشخص می‌کنیم: ```text mail.example.com → 203.0.113.10 203.0.113.10 → mail.example.com ``` این بخش معمولاً دست پنل DNS دامنه نیست و باید از ارائه‌دهنده VPS بخواید انجامش بده. برای من هم پشتیبانی سرور PTR رو تنظیم کرد. بعد از اعلام پشتیبانی، نتیجه رو از DNS عمومی بررسی کردم: ```bash dig @1.1.1.1 +short A mail.example.com dig @1.1.1.1 +short MX example.com dig @1.1.1.1 +short -x 203.0.113.10 ``` باید هم IP به نام درست برگرده، هم اون نام به همون IP. Google هم DNS مستقیم و معکوس معتبر رو جزو الزامات فرستنده‌ها آورده. اگه از IPv6 ارسال می‌کنید، اون مسیر هم تنظیمات خودش رو لازم داره؛ نبودن AAAA به این معنی نیست که ارسال خروجی IPv6 خاموش شده. [الزامات ارسال به Gmail](https://support.google.com/a/answer/81126?hl=en&ref=itsamir.ir) ## نصب Stalwart با Docker Compose روی سرور یه پوشه می‌سازیم: ```bash mkdir -p ~/stalwart-mail cd ~/stalwart-mail ``` داخلش فایل `compose.yaml` رو با این محتوا قرار میدیم: ```yaml services: stalwart: image: stalwartlabs/stalwart:v0.16 restart: unless-stopped ports: - "25:25" - "465:465" - "587:587" - "993:993" - "443:443" - "127.0.0.1:8080:8080" volumes: - stalwart_config:/etc/stalwart - stalwart_data:/var/lib/stalwart logging: driver: json-file options: max-size: "10m" max-file: "5" volumes: stalwart_config: stalwart_data: ``` مسیرهای volume توی این نمونه مربوط به نسخه ۰٫۱۶ هستن. تگ `v0.16` هم نسخه دقیق و تغییرناپذیر نیست؛ برای محیط اصلی، تگ دقیق یا digest بررسی‌شده خودتون رو ثابت کنید. اگه از نسخه قدیمی‌تر میاید، راهنمای مهاجرت همون نسخه رو بخونید. [نصب Stalwart با Docker](https://stalw.art/docs/install/platform/docker/?ref=itsamir.ir) توی این فایل فرض کردم پورت ۴۴۳ آزاد هست. اگه Caddy یا Nginx روی سرور دارید، قبل از اجرا مسیر HTTPS رو مشخص کنید تا سر اشغال پورت به مشکل نخورید. سرویس رو بالا میاریم و لاگ رو می‌بینیم: ```bash docker compose up -d docker compose logs --tail=100 stalwart ``` اولین اجرا اطلاعات ورود موقت مدیر رو توی لاگ bootstrap می‌نویسه. این اطلاعات رو نگه دارید و از کامپیوتر خودتون یه تونل SSH بزنید؛ نام کاربر و پورت رو با اطلاعات سرورتون عوض کنید: ```bash ssh -p 22 -L 8080:127.0.0.1:8080 user@203.0.113.10 ``` حالا توی مرورگر، `http://127.0.0.1:8080/admin` رو باز کنید. توی راه‌انداز، hostname رو `mail.example.com` و دامنه رو `example.com` بذارید. تولید DKIM و دریافت خودکار گواهی رو هم فعال کنید. توی حالت DNS دستی، صدور خودکار گواهی به دسترسی مستقیم پورت ۴۴۳ نیاز داره. اطلاعات مدیر دائمی رو ذخیره کنید و بعد از تکمیل راه‌انداز سرویس رو restart کنید. [جزئیات راه‌انداز](https://stalw.art/docs/install/platform/docker/?ref=itsamir.ir) ```bash docker compose restart stalwart ``` بعد از فعال‌شدن HTTPS، از `https://mail.example.com/admin` وارد بشید و حساب ایمیل رو بسازید. دسترسی HTTP مربوط به نصب رو هم غیرفعال کنید. توی نمونه بالا، ۸۰۸۰ از اول فقط روی loopback سرور منتشر شده تا از طریق تونل بهش برسیم. ### پورت‌ها و اتصال برنامه ایمیل برای اتصال Apple Mail، Thunderbird یا اپلیکیشن خودتون، تنظیمات معمول این شکلیه: | کاربرد | سرور | پورت و اتصال | | ----------------- | ---------------- | --------------- | | دریافت با IMAP | mail.example.com | 993 با SSL/TLS | | ارسال با SMTP | mail.example.com | 465 با SSL/TLS | | روش جایگزین ارسال | mail.example.com | 587 با STARTTLS | نام کاربری معمولاً آدرس کامل حساب، مثل `info@example.com` هست. احراز هویت ارسال باید فعال باشه. دریافت پیام برای صندوق‌های دامنه خودمون با اجازه ارسال آزاد برای همه فرق داره؛ سرور نباید به Open Relay تبدیل بشه. سرویس‌هایی که لازم ندارید، مثل POP3، رو هم منتشر نکنید. [تنظیمات امنیتی Stalwart](https://stalw.art/docs/install/security/?ref=itsamir.ir) یه نکته سمت Docker هم هست: پورت‌های publishشده ممکنه قواعد UFW رو دور بزنن. برای بررسی دسترسی‌ها فقط به `ufw status` تکیه نکنید. [ملاحظات فایروال Docker](https://docs.docker.com/engine/install/ubuntu/?ref=itsamir.ir) ### اگه Reverse Proxy داشته باشیم توی استقرار من Caddy هم هست، ولی نمونه این پست مستقیماً پورت ۴۴۳ رو به Stalwart داده. با Reverse Proxy باید مشخص کنید گواهی رو چه سرویسی می‌گیره و خود SMTP و IMAP چه گواهی‌ای ارائه میدن. HTTPS درست پنل، به‌تنهایی درست بودن TLS ایمیل رو ثابت نمی‌کنه. بسته به معماری، میشه از DNS-01 برای صدور گواهی استفاده کرد یا گواهی رو با یه مسیر مشخص برای نصب و تمدید در اختیار Stalwart گذاشت. [مدیریت گواهی در Stalwart](https://stalw.art/docs/domains/tls-certificates/?ref=itsamir.ir) برای بررسی STARTTLS با OpenSSL می‌تونید این دستور رو اجرا کنید: ```bash openssl s_client \ -starttls smtp \ -connect mail.example.com:587 \ -servername mail.example.com \ -verify_hostname mail.example.com \ -verify_return_error ._domainkey Value: v=DKIM1; k=rsa; p= ``` این نمونه رو با همین placeholderها منتشر نکنید. selector و کلید عمومی باید مال نصب خودتون باشه؛ کلید خصوصی هم باید روی زیرساخت خودتون بمونه. گیرنده از selector توی هدر پیام استفاده می‌کنه تا کلید عمومی رو پیدا و امضا رو بررسی کنه. [استاندارد DKIM](https://www.rfc-editor.org/rfc/rfc6376.html?ref=itsamir.ir) ### DMARC؛ نتیجه بررسی‌ها با دامنه فرستنده جور درمیاد؟ برای شروع پایش یه دامنه تازه، میشه از این TXT استفاده کرد: ```text Name: _dmarc Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com ``` صندوق یا alias آدرس `dmarc@example.com` رو هم بسازید تا گزارش‌ها رو بگیره. بعد از بررسی گزارش‌ها و درست بودن همه فرستنده‌های مجاز، می‌تونید سیاست رو به‌صورت کنترل‌شده به `quarantine` یا `reject` تغییر بدید. برای عبور DMARC، حداقل یکی از SPF یا DKIM باید هم موفق باشه، هم با دامنه `From` هم‌راستا باشه. `p=none` امکان مشاهده و گزارش‌گرفتن میده؛ قرار نیست به‌خودی‌خود اعتبار IP رو درست کنه. [استاندارد DMARC](https://www.rfc-editor.org/rfc/rfc7489.html?ref=itsamir.ir) روی PXLAds الان `p=reject` فعاله، ولی برای یه دامنه تازه بهتره قبل از سخت‌گیرانه‌کردن سیاست، مسیرهای ارسالش رو بشناسیم. ## تجربه ارسال به Gmail و Yahoo بعد از این تنظیمات، یه پیام با عنوان مشخص و چند جمله طبیعی به صندوقی که کنترلش دست خودتونه بفرستید. از همون صندوق هم جواب بدید تا دریافت روی سرورتون رو تست کنید. برای پیدا کردن ارسال توی لاگ، آدرس گیرنده واقعی رو جای نمونه پایین بذارید: ```bash docker compose logs --since=30m stalwart 2>&1 \ | grep -F 'recipient@example.net' ``` بعد با شناسه صف یا نشست، ادامه همون ارسال رو دنبال کنید. این دستور برای حالتیه که لاگ به Console میره؛ اگه مقصدش رو تغییر دادید، فایل مربوط یا Telemetry رو ببینید. ### PTR درست شد، ولی Yahoo همچنان ایمیل رو رد می‌کرد توی روزهای اول، Gmail خطای PTR ناقص یا نامنطبق می‌داد. بعد از تنظیم Reverse DNS و بررسی تطابقش با A، ارسال‌های بعدی به Gmail پذیرفته شدن. ولی Yahoo همچنان این خطا رو می‌داد: ```text 553 5.7.2 [TSS09] ``` توی بررسی لاگ و اتصال مشخص شد که ارتباط و STARTTLS انجام میشن، ولی Yahoo موقع `MAIL FROM` ارسال رو رد می‌کنه. یعنی هنوز نرسیده بودیم به جایی که بدنه و هدرهای پیام رو تحویل بدیم. برای همین، از این خطا نمیشه نتیجه گرفت که متن اون پیام یا کلید DKIM مشکل داشته. چیزی که مشخص بود، محدودیت Yahoo برای IP فرستنده بود. دلیل اولیه این تصمیم رو هم از لاگ سرور خودم نمی‌شد فهمید. برای پیگیری، درخواست بررسی رو توی [Yahoo Sender Support](https://senders.yahooinc.com/contact/?ref=itsamir.ir) ثبت کردم. تا زمان نوشتن این پست، رفع محدودیت تأیید نشده. توی پاسخ سرور هم صریحاً گفته شده بود که تکرار ارسال موفق نمیشه، پس ارسال پشت‌سرهم کمکی به بررسی این مورد نمی‌کرد. این قسمت برای من مشخص کرد که درست‌شدن PTR لزوماً به معنی تغییر فوری تصمیم سرویس مقصد نیست. ### Gmail پیام رو گرفت، ولی فرستاد داخل Spam توی یه تست دیگه، Gmail این پاسخ رو به سرور داد: ```text 250 OK ... - gsmtp ``` توی لاگ، تحویل کامل شده بود. ولی وقتی صندوق مقصد بررسی شد، پیام داخل Spam بود. در واقع سرور من وظیفه تحویل به Gmail رو انجام داده بود؛ اینکه Gmail پیام رو توی کدوم پوشه قرار بده، مرحله بعدیه. توی گزارش‌های تجمیعی قبلی Google، ارسال مستقیم از IP من با SPF و امضای RSA معتبر ثبت شده بود. ولی اون گزارش‌ها نتیجه همین پیام جدید رو ثابت نمی‌کنن. برای این پیام باید نسخه دریافت‌شده رو توی Gmail باز کنیم و از **Show original** وضعیت SPF، DKIM و DMARC رو ببینیم. توضیحی که Gmail بالای پیام Spam نشون میده هم می‌تونه کمک کنه. اعتبار IP و دامنه، الگوی ارسال و بازخورد گیرنده‌ها از چیزهایی هستن که روی تحویل اثر دارن. با این حال، فقط از `250 OK` نمیشه فهمید دقیقاً کدوم عامل باعث Spam شده. [راهنمای فرستنده‌های Gmail](https://support.google.com/a/answer/81126?hl=en&ref=itsamir.ir) پیام تست من عنوانی شبیه `TEST` و یه متن خیلی کوتاه داشت. برای اینکه ببینم Gmail پیام رو می‌گیره کافی بود، ولی نمونه خوبی از یه ایمیل واقعی کسب‌وکار نبود. این هم به معنی اثبات علت Spam نیست؛ برای نتیجه قطعی‌تر هنوز هدر همون پیام لازمه. اگه پیام معتبره، گیرنده می‌تونه **Not spam** رو بزنه. این کار به تجربه همون صندوق کمک می‌کنه، ولی نباید ازش نتیجه بگیریم که مشکل برای تمام گیرنده‌ها رفع شده. [راهنمای Spam در Gmail](https://support.google.com/mail/answer/1366858?hl=en&ref=itsamir.ir) ## گزارش‌های Google و نگهداری سرویس بعد از راه‌اندازی، ایمیل‌هایی هم از Google برای گزارش DMARC و TLS می‌رسیدن. اول باید حواسمون باشه که خود این ایمیل‌ها خطا نیستن. وقتی توی DNS آدرس گزارش‌گیری گذاشتیم، داریم از سرویس‌های پشتیبان این استانداردها می‌خوایم نتیجه بررسی‌ها رو برامون بفرستن. ### MTA-STS و TLS-RPT MTA-STS به سرورهایی که ازش پشتیبانی می‌کنن میگه MXهای معتبر دامنه چی هستن و اتصال TLS رو چطور ارزیابی کنن. یه سیاست اولیه برای مشاهده می‌تونه این باشه: ```text version: STSv1 mode: testing mx: mail.example.com max_age: 604800 ``` این متن باید با گواهی معتبر از این آدرس در دسترس باشه: ```text https://mta-sts.example.com/.well-known/mta-sts.txt ``` خود `mta-sts.example.com` هم باید به میزبانی که این فایل رو ارائه میده resolve بشه. برای کشف سیاست، TXT زیر رو می‌ذاریم: ```text Name: _mta-sts Value: v=STSv1; id=2026091401 ``` با تغییر سیاست، `id` رو هم عوض کنید. حالت `testing` برای بررسیه؛ بعد از اطمینان از مسیرها میشه درباره `enforce` تصمیم گرفت. این بخش روی امنیت انتقال ورودی کار می‌کنه و درمان مستقیم Spam ایمیل خروجی نیست. [استاندارد MTA-STS](https://www.rfc-editor.org/rfc/rfc8461.html?ref=itsamir.ir) برای گزارش TLS هم میشه یه صندوق یا alias ساخت و این رکورد رو گذاشت: ```text Name: _smtp._tls Value: v=TLSRPTv1; rua=mailto:tls-reports@example.com ``` داخل گزارش، تعداد ارتباط‌های موفق و خطاها رو ببینید. TLS-RPT درباره انتقال به دامنه گزارش‌شده است؛ از روی اون نمی‌تونیم بفهمیم ایمیل خروجی ما توی Inbox گیرنده قرار گرفته یا نه. [استاندارد TLS-RPT](https://www.rfc-editor.org/rfc/rfc8460.html?ref=itsamir.ir) ### چیزهایی که بعد از نصب هم باید بهشون برسیم وقتی سرویس بالا اومد، چند تا کار همچنان باقی می‌مونه: - گرفتن پشتیبان از داده‌ها و تنظیمات، همراه با اطلاعات لازم برای بازیابی کلیدها؛ - نگه‌داشتن یه نسخه رمزگذاری‌شده بیرون از همون VPS؛ - تست بازیابی توی یه محیط جداگانه؛ - بررسی فضای دیسک، صف ارسال، انقضای گواهی و خطاهای ورود؛ - خوندن تغییرات و راهنمای مهاجرت قبل از آپدیت نسخه. Volumeهای Docker کمک می‌کنن با بازسازی کانتینر داده‌ها از بین نرن، ولی جای backup رو نمی‌گیرن. روش پشتیبان‌گیری هم به storage backend بستگی داره. کپی معمولی فایل‌های یه دیتابیس زنده رو بدون بررسی سازگاری، پشتیبان مطمئن فرض نکنید. ابزار export/import داخلی Stalwart هم برای کار با دیتابیس الزام توقف سرویس داره. [ملاحظات نگهداری دیتابیس](https://stalw.art/docs/management/maintenance/migration/?ref=itsamir.ir) ## هنوز این بخش از پروژه چالش‌های خودش رو داره فعلاً سرویس ایمیل PXLAds راه افتاده، ولی پیگیری محدودیت Yahoo و بررسی دقیق‌تر Spam شدن اون پیام Gmail هنوز باقی مونده. برای همین نمی‌خوام این تجربه رو به‌عنوان روشی برای رسیدن قطعی همه ایمیل‌ها به Inbox معرفی کنم. چیزی که تا اینجا برام مفید بوده، جدا بررسی‌کردن هر بخشه: DNS درست resolve میشه؟ اتصال TLS برقراره؟ سرور مقصد پیام رو پذیرفته؟ هدر پیام دریافت‌شده چه نتیجه‌ای داره؟ با همین تفکیک میشه فهمید قدم بعدی کجاست، بدون اینکه هر بار چند تا رکورد رو بی‌دلیل عوض کنیم. امیدوارم اگه شما هم می‌خواید برای پروژه خودتون ایمیل سرور راه بندازید، این تجربه به کارتون بیاد. اگه با Stalwart یا چالش‌های ارسال به Gmail و Yahoo تجربه‌ای داشتید، خوشحال میشم بخونمش.