ارسال ایمیل از سرور ایران؛ تنظیم PTR، SPF، DKIM و DMARC برای تحویل بهتر

ارسال ایمیل از یک سرور لینوکسی تنها با نصب سرویس SMTP کامل نمی‌شود. برای اینکه سرویس مقصد بتواند فرستنده را بشناسد، باید هویت IP، نام میزبان و دامنه با یکدیگر هماهنگ باشند و پیام نیز با سازوکارهای احراز هویت امضا شود. در این راهنما مسیر بررسی از شبکه و DNS آغاز می‌شود و تا آزمون پیام واقعی و پایش اعتبار ارسال ادامه پیدا می‌کند.

چرا پیام‌های سرور به پوشه اسپم می‌روند؟

سامانه دریافت‌کننده فقط متن پیام را ارزیابی نمی‌کند. IP فرستنده، سابقه ارسال، نام میزبان اعلام‌شده، نتیجه SPF و DKIM، سیاست DMARC و نرخ ارسال نیز در تصمیم نهایی اثر دارند. سروری که تازه فعال شده و در همان روزهای اول حجم زیادی پیام می‌فرستد، ممکن است رفتاری غیرعادی داشته باشد؛ به‌ویژه اگر فهرست گیرندگان قدیمی یا نامعتبر باشد.

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

بررسی PTR، hostname و دسترسی پورت 25

PTR در DNS معکوس IP تعریف می‌شود و معمولاً باید از ارائه‌دهنده سرور درخواست شود. این رکورد IP را به یک نام کامل مانند mail.example.com مرتبط می‌کند. سپس همان نام باید با رکورد A یا AAAA به IP متناظر برگردد تا تطابق رفت‌وبرگشت برقرار باشد. مدیریت PTR با مدیر DNS معمول دامنه یکسان نیست و ممکن است فقط ارائه‌دهنده IP امکان تغییر آن را داشته باشد.

نام میزبان سیستم را با PTR هماهنگ کنید. سرویس SMTP هنگام اتصال با HELO یا EHLO خود را معرفی می‌کند؛ بنابراین نامی عمومی مانند localhost.localdomain برای سرور عملیاتی مناسب نیست. در Postfix مقدار myhostname و در صورت نیاز smtp_helo_name را بررسی کنید. پس از تغییر، سرویس را با روش مناسب همان توزیع بارگذاری مجدد کنید.

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

نقش SPF، DKIM و DMARC

SPF رکوردی از نوع TXT است که IPها و سرویس‌های مجاز برای ارسال با دامنه را معرفی می‌کند. اگر تنها یک سرور دارید، IP همان سرور را در سیاست قرار دهید. اگر سامانه خبرنامه، فروشگاه یا سرویس ارسال تراکنشی نیز از دامنه استفاده می‌کند، آن مسیرها باید در همان سیاست لحاظ شوند. برای هر دامنه یک رکورد SPF معتبر منتشر کنید؛ ایجاد چند رکورد مجزا می‌تواند نتیجه بررسی را نامعتبر کند.

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

DMARC نتیجه SPF و DKIM را از نظر هم‌ترازی دامنه ارزیابی می‌کند و امکان دریافت گزارش درباره پیام‌های هم‌نام دامنه را می‌دهد. بهتر است ابتدا سیاست پایش را فعال کنید تا همه مسیرهای واقعی ارسال شناسایی شوند. پس از اصلاح سامانه‌هایی که احراز هویت نمی‌شوند، می‌توان سیاست سخت‌گیرانه‌تری را انتخاب کرد. گزارش‌ها را پیش از ردکردن پیام‌ها بررسی کنید؛ ممکن است یک نرم‌افزار قدیمی یا سرویس ثالث هنوز از دامنه شما استفاده کند.

تنظیم TLS و بررسی Postfix

ارتباط SMTP باید امکان استفاده از TLS را داشته باشد. گواهی، نام میزبان و تنظیمات سرویس باید هماهنگ باشند. در Postfix نام میزبان و سیاست TLS را بررسی کنید و پیش از بارگذاری مجدد، صحت پیکربندی را بسنجید. رفتار پیش‌فرض بعضی گزینه‌ها میان نسخه‌های Postfix فرق دارد؛ بنابراین مقدار مؤثر را با نسخه نصب‌شده تطبیق دهید و صرفاً به یک نمونه تنظیمات قدیمی اکتفا نکنید.

برای آزمون نهایی یک پیام به حسابی در سرویس مقصد بفرستید و سربرگ کامل آن را بررسی کنید. نتیجه SPF، DKIM و DMARC معمولاً در Authentication-Results دیده می‌شود. علاوه بر محل قرارگیری پیام، پاسخ SMTP، زمان تحویل، وضعیت TLS و IP گزارش‌شده را نیز ثبت کنید. این اطلاعات کمک می‌کند مشکل DNS از مسئله اعتبار یا محدودیت شبکه تفکیک شود.

مدیریت اعتبار IP و نرخ ارسال

• ارسال را با حجم کم به مخاطبان فعال آغاز کنید و افزایش حجم را تدریجی انجام دهید.
• نشانی‌های نامعتبر و پیام‌های برگشتی را از فهرست ارسال حذف کنید.
• نرخ شکایت کاربران و درخواست لغو عضویت را پایش کنید.
• برای ایمیل تراکنشی و خبرنامه، الگوی ارسال و در صورت نیاز زیردامنه مجزا در نظر بگیرید.
• لاگ Postfix را برای خطاهای احراز هویت، اتصال و صف پیام‌ها بررسی کنید.
• وضعیت IP را در ابزارهای پایش اعتبار و فهرست‌های مسدودی کنترل کنید.

عیب‌یابی خطاهای متداول

پرسش‌های متداول

آیا PTR برای سرور ایمیل اهمیت دارد؟

بله. PTR معتبر و تطابق hostname با رکورد A یا AAAA از نشانه‌های مهم شناسایی سرور فرستنده است و بسیاری از سرویس‌های دریافت‌کننده آن را ارزیابی می‌کنند.

اگر پورت 25 بسته باشد چه باید کرد؟

ابتدا از ارائه‌دهنده درباره فعال‌سازی پورت درخواست کنید. اگر ارسال مستقیم ممکن نیست، از SMTP Relay معتبر و احراز هویت‌شده روی پورت 587 استفاده کنید.

آیا SPF به‌تنهایی مانع اسپم شدن می‌شود؟

خیر. SPF فقط یکی از لایه‌های احراز هویت است. DKIM، DMARC، PTR، TLS و سابقه رفتار ارسال نیز اهمیت دارند.

چند رکورد SPF باید منتشر شود؟

برای هر دامنه یک سیاست SPF معتبر منتشر کنید و همه فرستنده‌های مجاز را در همان رکورد تعریف کنید.

از کجا نتیجه احراز هویت پیام را بخوانم؟

سربرگ کامل پیام دریافتی را باز کنید و مقدار Authentication-Results را برای SPF، DKIM و DMARC بررسی کنید.

جمع‌بندی

برای ارسال پایدار ایمیل از سرور ایران، ابتدا لایه شبکه را بررسی کنید: IP باید PTR مناسب داشته باشد، hostname با DNS هماهنگ باشد و مسیر SMTP خروجی کار کند. سپس SPF و DKIM را تنظیم کنید و DMARC را با مرحله پایش آغاز کنید. در پایان، پیام آزمایشی بفرستید، سربرگ و لاگ‌ها را بخوانید و حجم ارسال را متناسب با اعتبار دامنه افزایش دهید.

تفکیک ایمیل تراکنشی و پیام‌های تبلیغاتی

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

برای هر مسیر، دامنه فرستنده، سرویس ارسال و حجم مورد انتظار را ثبت کنید. اگر چند سامانه از یک دامنه استفاده می‌کنند، پیش از تغییر SPF یا DMARC همه آن‌ها را در فهرست فرستنده‌های مجاز بیاورید. تغییر رکورد بدون شناخت وابستگی‌ها ممکن است پیام یک سامانه سالم را نامعتبر کند.

مدیریت صف پیام و پایش لاگ‌ها

در زمان اختلال شبکه، پیام‌ها ممکن است در صف خروجی باقی بمانند. وضعیت صف را بررسی کنید تا مشخص شود پیام‌ها در حال retry هستند یا با خطای دائمی روبه‌رو شده‌اند. تفاوت خطای موقت و دائمی مهم است؛ خطای موقت ممکن است با برقراری دوباره اتصال رفع شود، اما خطای احراز هویت یا آدرس نامعتبر به اصلاح تنظیمات نیاز دارد.

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

برنامه آزمون پس از هر تغییر DNS

1. رکورد TXT یا PTR را از resolverهای مختلف بخوانید و انتشار آن را بررسی کنید.
2. یک پیام آزمایشی از همان سرور و همان دامنه From ارسال کنید.
3. سربرگ کامل پیام را برای نتیجه SPF، DKIM و DMARC بررسی کنید.
4. در صورت شکست، زمان تغییر DNS و TTL رکورد را در نظر بگیرید.
5. پس از تأیید نتیجه، ارسال عادی را مرحله‌ای افزایش دهید.

تغییر DNS ممکن است فوراً در همه resolverها دیده نشود. اگر رکوردی اصلاح شده اما مقصد هنوز نتیجه قدیمی را گزارش می‌کند، TTL و کش DNS را بررسی کنید. تغییرهای متوالی و سریع بدون ثبت مقدار قبلی، تشخیص علت را دشوار می‌کند؛ بنابراین هر اصلاح را همراه زمان، مقدار قبلی و مقدار جدید مستند کنید.

سیاست دسترسی و حفاظت از سرویس ایمیل

سرویس SMTP را به relay باز تبدیل نکنید. ارسال باید تنها برای کاربران و سامانه‌های مجاز امکان‌پذیر باشد و احراز هویت برای ارسال از شبکه‌های غیرقابل اعتماد فعال باشد. دسترسی مدیریتی به سرور و فایل‌های کلید DKIM را محدود کنید و گذرواژه حساب‌های ارسال را در کدهای عمومی یا مخازن قابل دسترس قرار ندهید.

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

تفکیک فرستنده‌ها و دامنه‌های ارسال

در سازمانی که چند سامانه از یک دامنه ایمیل می‌فرستند، مالکیت هر مسیر باید روشن باشد. فهرستی از وب‌سایت، نرم‌افزار حسابداری، سامانه تیکت، خبرنامه و سرویس‌های بیرونی تهیه کنید و برای هر کدام IP یا سرویس ارسال، دامنه From و روش احراز هویت را ثبت کنید. این فهرست هنگام تغییر SPF یا DMARC مانع حذف ناخواسته یک فرستنده معتبر می‌شود.

می‌توان برای دسته‌های متفاوت پیام، زیردامنه جدا در نظر گرفت؛ برای مثال پیام‌های تراکنشی و خبرنامه از مسیرهای متفاوت ارسال شوند. این تفکیک مدیریت سیاست‌ها و پایش رفتار را آسان‌تر می‌کند، اما باید به‌درستی در DNS و سرویس ارسال پیکربندی شود. ایجاد زیردامنه بدون تنظیم SPF، DKIM و DMARC مستقل، به‌تنهایی اعتبار ارسال را افزایش نمی‌دهد.

رسیدگی به پیام‌های برگشتی و شکایت کاربران

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

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

بررسی تفاوت خطاهای سمت فرستنده و گیرنده

اگر اتصال TCP از سرور برقرار نمی‌شود، بررسی را از DNS، مسیریابی و فایروال آغاز کنید. اگر اتصال برقرار است اما مقصد پیام را نمی‌پذیرد، پاسخ SMTP را بخوانید؛ کدهای 4xx معمولاً به وضعیت موقت اشاره دارند و ممکن است retry شوند، در حالی که خطاهای 5xx معمولاً به اصلاح آدرس، احراز هویت یا سیاست ارسال نیاز دارند. ثبت متن کامل پاسخ از حدس‌زدن علت جلوگیری می‌کند.

اگر پیام پذیرفته می‌شود اما در پوشه Spam قرار می‌گیرد، صرفاً تنظیمات Postfix را تغییر ندهید. سربرگ پیام، نتیجه احراز هویت، اعتبار IP، نرخ شکایت و محتوای پیام را کنار هم بررسی کنید. پذیرش SMTP فقط نشان می‌دهد مقصد پیام را تحویل گرفته است؛ محل نمایش نهایی می‌تواند بر اساس ارزیابی‌های بعدی تعیین شود.

مستندسازی تغییرات DNS و سرویس

پیش از تغییر هر رکورد، مقدار فعلی، TTL و زمان انتشار را ثبت کنید. پس از تغییر، از چند شبکه یا resolver نتیجه را بررسی کنید و یک پیام واقعی ارسال کنید. اگر نتیجه مطلوب نبود، امکان بازگرداندن مقدار قبلی را داشته باشید. ثبت تغییرات به‌ویژه زمانی مهم است که چند مدیر یا پیمانکار هم‌زمان روی DNS و سرویس ایمیل کار می‌کنند.