قرار گرفتن ایمیل‌های سازمانی در پوشه Spam یا رد شدن آن‌ها توسط سرور مقصد، می‌تواند ارتباط با مشتریان و شرکای تجاری را مختل کند. بااین‌حال، علت این اتفاق همیشه یکسان نیست و نمی‌توان درصد ثابتی از موارد را به یک تنظیم خاص نسبت داد. احراز هویت ایمیل، اعتبار دامنه و IP، کیفیت فهرست گیرندگان، میزان شکایت کاربران، الگوی ارسال و محتوای پیام همگی می‌توانند در نتیجه تحویل مؤثر باشند.
در این مقاله چهار مؤلفه مهم را بررسی می‌کنیم: SPF، DKIM، DMARC و رکورد PTR. سپس به عوامل دیگری می‌پردازیم که بر تحویل ایمیل اثر دارند و روش مرحله‌به‌مرحله‌ای برای عیب‌یابی ارائه می‌کنیم. این استانداردها احتمال جعل فرستنده و خطاهای احراز هویت را کاهش می‌دهند، اما هیچ‌کدام به‌تنهایی تضمین نمی‌کنند که همه پیام‌ها وارد Inbox شوند.
چرا ایمیل‌ها به پوشه Spam می‌روند؟
سامانه‌های دریافت ایمیل برای تصمیم‌گیری درباره پذیرش، رد کردن یا دسته‌بندی پیام از مجموعه‌ای از سیگنال‌ها استفاده می‌کنند. احراز هویت ناموفق یکی از عوامل است، اما اعتبار IP و دامنه، سابقه ارسال، شکایت کاربران، آدرس‌های نامعتبر، افزایش ناگهانی حجم ارسال و محتوای پیام نیز ممکن است بر نتیجه اثر بگذارند.
به همین دلیل، ابتدا باید مشخص کنیم پیام واقعاً رد شده، به Spam منتقل شده، تأخیر دارد یا در مقصد دیگری قرار گرفته است. پاسخ SMTP سرور مقصد، گزارش تحویل و سربرگ کامل یک پیام نمونه می‌توانند سرنخ‌های مهم‌تری از حدس زدن علت فراهم کنند.
۱. SPF چیست و چه کاری انجام می‌دهد؟
SPF (Sender Policy Framework) روشی برای اعلام منابع مجاز ارسال ایمیل از طرف یک دامنه است. مالک دامنه با انتشار یک رکورد TXT در DNS مشخص می‌کند کدام IPها یا سرویس‌ها مجازند ایمیل را با هویت دامنه مربوط به مسیر ارسال بفرستند.
برای مثال، اگر سازمان از چند سرویس برای ارسال پیام استفاده می‌کند، باید همه منابع مجاز را شناسایی کند و رکورد SPF را مطابق مستندات آن سرویس‌ها تنظیم کند. رکورد ناقص ممکن است پیام‌های معتبر را با شکست احراز هویت مواجه کند؛ رکورد بیش از حد باز نیز کنترل محدودی فراهم می‌کند.
محدودیت مهم SPF
SPF به‌طور مستقیم هویت دامنه موجود در فیلد قابل‌مشاهده From: را تضمین نمی‌کند؛ معمولاً دامنه مربوط به فرستنده در سطح انتقال SMTP را ارزیابی می‌کند. بنابراین ممکن است SPF موفق باشد، اما دامنه آن با دامنه‌ای که کاربر در فیلد From می‌بیند هم‌تراز نباشد. این تفاوت یکی از دلایل نیاز به DMARC است.
برای یک دامنه، رکورد SPF باید با دقت طراحی شود. اگر سرویس جدیدی به فرایند ارسال اضافه شد، رکورد موجود را بازبینی کنید و از انتشار چند رکورد مستقل SPF برای یک نام دامنه پرهیز کنید.
۲. DKIM چیست و چگونه امضای ایمیل را بررسی می‌کند؟
DKIM (DomainKeys Identified Mail) به سامانه ارسال امکان می‌دهد بخشی از اطلاعات پیام را با امضای رمزنگاری‌شده به دامنه امضاکننده مرتبط کند. سرور فرستنده با کلید خصوصی امضا را ایجاد می‌کند و سرور دریافت‌کننده با استفاده از کلید عمومی منتشرشده در DNS، اعتبار آن را بررسی می‌کند.
در صورت اعتبار امضا، گیرنده می‌تواند بررسی کند که داده‌های امضاشده با روش مورد استفاده سازگار هستند. DKIM به معنی رمزگذاری محتوای پیام نیست و به‌تنهایی ثابت نمی‌کند که تمام محتوای پیام بی‌خطر یا فرستنده آن قابل اعتماد است.
آیا هر تغییر کوچکی امضای DKIM را باطل می‌کند؟
نه لزوماً. نتیجه به الگوریتم استانداردسازی یا canonicalization، بخش‌های امضاشده و نوع تغییر بستگی دارد. برخی تغییرات قالب‌بندی ممکن است با روش relaxed قابل‌تحمل باشند؛ در مقابل، تغییر در محتوای امضاشده می‌تواند اعتبار امضا را از بین ببرد. به همین دلیل، نباید ادعا کرد هر تغییر کوچک مانند افزودن یک ویرگول در همه شرایط امضا را باطل می‌کند.
کلید عمومی و selector باید مطابق راهنمای پلتفرم در DNS قرار گیرند. پس از فعال‌سازی، ارسال آزمایشی به چند مقصد و بررسی نتیجه DKIM در سربرگ پیام ضروری است.
۳. DMARC چگونه SPF و DKIM را به دامنه فرستنده مرتبط می‌کند؟
DMARC (Domain-based Message Authentication, Reporting and Conformance) نتیجه SPF و DKIM را با دامنه قابل‌مشاهده در فیلد From: مرتبط می‌کند و به مالک دامنه اجازه می‌دهد سیاست مدنظرش را برای پیام‌هایی که بررسی DMARC را نمی‌گذرانند منتشر کند.
برای عبور از DMARC، معمولاً کافی است SPF با دامنه هم‌تراز موفق شود یا یک امضای DKIM معتبر با دامنه From هم‌تراز باشد. این به معنی الزام به شکست هم‌زمان هر دو روش برای تصمیم‌گیری نیست. هم‌ترازی می‌تواند بر اساس تنظیمات strict یا relaxed ارزیابی شود.
سیاست DMARC معمولاً یکی از این حالت‌هاست:
- p=none: سیاست پایش؛ مالک دامنه می‌تواند نتیجه بررسی را مشاهده کند، بدون آنکه این سیاست به‌تنهایی درخواست قرنطینه یا رد پیام را مطرح کند.
- p=quarantine: از گیرنده درخواست می‌کند پیام‌های ناموفق را با رویکرد قرنطینه بررسی کند؛ محل نهایی پیام به سیاست گیرنده نیز بستگی دارد.
- p=reject: از گیرنده درخواست رد پیام‌هایی را می‌کند که با سیاست DMARC دامنه سازگار نیستند.
سیاست منتشرشده همیشه به معنی نتیجه یکسان در همه سامانه‌ها نیست؛ گیرنده ممکن است سیاست‌های محلی و سیگنال‌های دیگری هم در تصمیم نهایی لحاظ کند. برای آغاز، بهتر است ابتدا همه منابع واقعی ارسال شناسایی شوند، گزارش‌ها بررسی شوند و سپس سیاست سخت‌گیرانه‌تر به‌صورت کنترل‌شده اعمال شود.
۴. رکورد PTR یا Reverse DNS چه اهمیتی دارد؟
رکورد PTR برای تبدیل یک نشانی IP به نام میزبان در DNS معکوس استفاده می‌شود. در سناریوهایی که سازمان مستقیماً از سرور خود ایمیل ارسال می‌کند، مهم است نام میزبان سرور ارسال و نشانی IP آن به‌درستی با یکدیگر تطبیق داشته باشند.
معمولاً نامی که PTR برمی‌گرداند باید از طریق رکورد A یا AAAA دوباره به همان IP موردنظر برسد. تنظیم PTR اغلب در اختیار مالک نشانی IP یا شرکت ارائه‌دهنده سرور است، نه صرفاً مدیر DNS دامنه. بنابراین ممکن است لازم باشد از ارائه‌دهنده زیرساخت درخواست تنظیم یا اصلاح Reverse DNS کنید.
نبود یا ناهماهنگی PTR می‌تواند در ارزیابی پیام‌ها مشکل ایجاد کند، اما به‌تنهایی اثبات نمی‌کند که پیام حتماً Spam می‌شود. همچنین اهمیت آن به نوع سرویس و مسیر ارسال وابسته است.
این چهار مؤلفه چگونه در کنار هم کار می‌کنند؟
- SPF: بررسی می‌کند آیا منبع ارسال برای دامنه مربوط به مسیر SMTP مجاز است.
- DKIM: اعتبار امضای رمزنگاری‌شده و دامنه امضاکننده را بررسی می‌کند.
- DMARC: نتیجه احراز هویت SPF یا DKIM را با دامنه قابل‌مشاهده From هم‌تراز می‌کند و سیاست دامنه را اعلام می‌کند.
- PTR و DNS معکوس: بخشی از اعتبارسنجی و شناسایی زیرساخت ارسال هستند و باید با DNS مستقیم هماهنگ باشند.
هیچ‌کدام جای دیگری را به‌طور کامل نمی‌گیرد. برای مثال، موفقیت DKIM مشکل اعتبار IP یا شکایت بالای گیرندگان را لزوماً حل نمی‌کند. به همین ترتیب، وجود PTR یا رکورد SPF درست به‌تنهایی کیفیت فهرست گیرندگان را تضمین نخواهد کرد.
عوامل دیگری که بر تحویل ایمیل اثر دارند
اعتبار IP و دامنه
سابقه ارسال، شکایت‌های دریافتی، الگوی ترافیک و وضعیت IP ممکن است بر ارزیابی گیرنده اثر بگذارند. اگر از IP اشتراکی استفاده می‌شود، رفتار سایر فرستندگان آن IP نیز می‌تواند برای اعتبار مشترک اهمیت داشته باشد.
کیفیت فهرست گیرندگان
ارسال مداوم به نشانی‌های نامعتبر، فهرست‌های قدیمی یا افرادی که مایل به دریافت پیام نیستند، احتمال شکایت و مشکلات تحویل را بالا می‌برد. فهرست‌ها را به‌روز نگه دارید، خطاهای دائمی تحویل را بررسی کنید و برای پیام‌های تبلیغاتی، رضایت گیرندگان و روش روشن لغو اشتراک را رعایت کنید.
تغییر ناگهانی حجم ارسال
افزایش سریع تعداد پیام‌ها بدون برنامه، به‌خصوص از دامنه یا IP تازه، می‌تواند مشکلات تحویل ایجاد کند. حجم ارسال را متناسب با نیاز واقعی و ظرفیت سرویس مدیریت کنید و تغییرات را با پایش پاسخ گیرندگان و خطاها همراه سازید.
محتوا و قالب‌بندی پیام
محتوای گمراه‌کننده، عنوان نامتناسب، پیوندهای مشکوک، فایل‌های پیوست خطرناک و پیام‌هایی که کاربران آن‌ها را ناخواسته می‌دانند، می‌توانند بر نتیجه اثر بگذارند. صرف استفاده از واژه خاص یا یک علامت نگارشی، علت قطعی اسپم شدن نیست؛ باید مجموعه شرایط و گزارش واقعی پیام بررسی شود.
TLS و تنظیم زیرساخت
رمزگذاری ارتباط در مسیر انتقال با TLS از الزامات مهم ارسال امن است. گواهی معتبر، تنظیم درست نام میزبان، DNS مستقیم و معکوس و پایش خطاهای اتصال باید در برنامه نگهداری سرور لحاظ شوند.
راهنمای فعلی گوگل برای ارسال ایمیل به Gmail
الزامات ارائه‌دهندگان ممکن است تغییر کند؛ بنابراین پیش از طراحی سرویس، آخرین دستورالعمل مقصدهای اصلی خود را بررسی کنید. طبق راهنمای فعلی گوگل، ارسال‌کنندگان به حساب‌های شخصی Gmail باید الزامات احراز هویت و زیرساخت مربوط را رعایت کنند؛ از جمله SPF یا DKIM، DNS مستقیم و معکوس معتبر برای زیرساخت ارسال و استفاده از TLS.
برای ارسال‌کنندگان انبوه که بیش از ۵۰۰۰ پیام در روز به حساب‌های شخصی Gmail می‌فرستند، گوگل SPF و DKIM و DMARC را مطالبه می‌کند و الزامات دیگری مانند هم‌ترازی دامنه و لغو اشتراک با یک کلیک برای پیام‌های بازاریابی یا اشتراکی نیز مطرح است. این آستانه و الزامات مخصوص سیاست گوگل است و نباید عیناً به همه ارائه‌دهندگان تعمیم داده شود.
گوگل توصیه می‌کند نرخ گزارش‌شده اسپم در Postmaster Tools کمتر از ۰٫۳ درصد باقی بماند. این مقدار تضمین‌کننده ورود پیام‌ها به Inbox نیست؛ بلکه یکی از معیارهای پایش کیفیت ارسال است. آخرین جزئیات را در راهنمای رسمی فرستندگان ایمیل گوگل بخوانید.
چگونه علت اسپم شدن ایمیل را عیب‌یابی کنیم؟
- یک پیام واقعی را انتخاب کنید: زمان ارسال، گیرنده، فرستنده و پاسخ سرور دریافت‌کننده را ثبت کنید.
- سربرگ کامل را بررسی کنید: در بخش
Authentication-Resultsنتیجه SPF، DKIM و DMARC را پیدا کنید. در صورت دسترسی، Return-Path، دامنه امضای DKIM و IP فرستنده را هم بررسی کنید. - نتایج را با DNS مقایسه کنید: رکوردهای فعلی را از منبع معتبر بخوانید و با مقادیر مستندات پلتفرم تطبیق دهید. از حدس زدن مقدار رکوردها یا کپی‌کردن رکورد یک سرویس دیگر خودداری کنید.
- پاسخ SMTP را بررسی کنید: کد و متن خطای مقصد ممکن است علت رد شدن پیام، محدودیت موقت، خطای احراز هویت یا مشکل سیاست ارسال را روشن کند.
- دامنه و IP را پایش کنید: در صورت استفاده از ابزارهای معتبر مانند Google Postmaster Tools، شاخص‌های اعتبار و شکایت را بررسی کنید؛ البته همه دامنه‌ها و حجم‌های ارسال لزوماً به تمام داده‌های این ابزار دسترسی ندارند.
- هر بار یک تغییر کنترل‌شده انجام دهید: پس از اصلاح، پیام آزمایشی بفرستید و سربرگ و نتیجه تحویل را دوباره بررسی کنید. تغییر هم‌زمان چند تنظیم، تشخیص عامل مؤثر را دشوار می‌کند.
اگر مسئله به ساختار سرویس ایمیل مربوط است، راهنمای نصب و راه‌اندازی سرور پست الکترونیکی را ببینید. در صورت احتمال وجود مشکل در زیرساخت یا دسترسی‌های شبکه، مرور پیاده‌سازی امنیت شبکه و مدیریت تهدیدات و انتشار امن سرور سازمانی در اینترنت نیز مفید است.
اشتباه‌های رایج در تنظیم SPF، DKIM و DMARC
- تعریف SPF بدون شناسایی همه سرویس‌هایی که از طرف دامنه ایمیل می‌فرستند.
- فرض اینکه SPF موفق الزاماً هویت دامنه قابل‌مشاهده From را تأیید می‌کند.
- انتشار کلید یا selector اشتباه DKIM، یا فراموش کردن بررسی نتیجه امضا در پیام واقعی.
- اعمال سیاست سخت‌گیرانه DMARC پیش از شناسایی منابع معتبر ارسال و بررسی گزارش‌ها.
- فرض اینکه داشتن PTR یا عبور از DMARC، ورود قطعی همه پیام‌ها به Inbox را تضمین می‌کند.
- نادیده گرفتن اعتبار فرستنده، نرخ شکایت، نشانی‌های نامعتبر، محتوای پیام و روش لغو اشتراک.
- تغییر رکوردهای DNS بدون ثبت وضعیت قبلی، آزمون پس از تغییر و برنامه بازگشت.
پرسش‌های متداول درباره ایمیل‌های اسپم‌شده
اگر SPF، DKIM و DMARC همگی صحیح باشند، چرا ایمیل باز هم وارد Spam می‌شود؟
زیرا این تنظیم‌ها فقط بخشی از سیگنال‌های ارزیابی پیام را پوشش می‌دهند. اعتبار IP و دامنه، شکایت گیرندگان، سابقه ارسال، محتوای پیام و سیاست‌های گیرنده نیز می‌توانند مؤثر باشند. نتیجه واقعی باید از سربرگ پیام و ابزارهای پایش بررسی شود.
آیا باید سیاست DMARC را از ابتدا روی Reject قرار دهم؟
نه بدون بررسی. ابتدا منابع ارسال را شناسایی و هم‌ترازی SPF و DKIM را ارزیابی کنید. سپس سیاست را طبق گزارش‌ها و توان سازمان برای جلوگیری از رد شدن پیام‌های معتبر، مرحله‌به‌مرحله سخت‌گیرانه‌تر کنید.
آیا SPF و DKIM محتوای ایمیل را رمزگذاری می‌کنند؟
خیر. SPF برای ارزیابی مجاز بودن منبع ارسال و DKIM برای بررسی امضای رمزنگاری‌شده پیام به کار می‌روند. TLS ارتباط میان سامانه‌ها را در مسیر انتقال رمزگذاری می‌کند؛ این سازوکارها با رمزگذاری سرتاسری محتوای ایمیل یکسان نیستند.
آیا تنظیم PTR برای همه سازمان‌ها یکسان است؟
خیر. PTR با IP عمومی ارسال‌کننده و زیرساخت ارائه‌دهنده مرتبط است. در سرویس‌های میزبانی‌شده ممکن است ارائه‌دهنده آن را مدیریت کند؛ در ارسال مستقیم از سرور خودمیزبان باید مالکیت IP، نام میزبان و تطبیق DNS معکوس و مستقیم بررسی شود.
آیا این تنظیمات نرخ باز شدن ایمیل‌های تبلیغاتی را افزایش می‌دهند؟
احراز هویت و بهبود تحویل می‌توانند به سلامت ارسال کمک کنند، اما نرخ باز شدن به عوامل دیگری مانند کیفیت محتوا، علاقه گیرنده و روش اندازه‌گیری نیز وابسته است. افزایش مشخصی را نمی‌توان بدون اندازه‌گیری قبل و بعد تضمین کرد.
منابع رسمی و استانداردها
- Google: Email sender guidelines
- Google: راهنمای تنظیم SPF
- RFC 7208: استاندارد SPF
- RFC 6376: استاندارد DKIM
- RFC 7489: استاندارد DMARC
- Microsoft Learn: بررسی و تنظیم DMARC
جمع‌بندی
برای کاهش احتمال اسپم شدن ایمیل، ابتدا احراز هویت SPF، DKIM و DMARC را درست تنظیم کنید و DNS مستقیم و معکوس، TLS و اعتبار زیرساخت ارسال را بررسی کنید. سپس کیفیت فهرست گیرندگان، نرخ شکایت، خطاهای تحویل و محتوای پیام را زیر نظر بگیرید. هیچ تنظیمی به‌تنهایی ورود قطعی به Inbox را تضمین نمی‌کند؛ راهکار مؤثر بر پایه اندازه‌گیری، آزمون و نگهداری مداوم شکل می‌گیرد.
برای بررسی زیرساخت ایمیل، امنیت و سرویس‌های شبکه سازمان، از راه‌های زیر با واریان شبکه گستر در ارتباط باشید:
