خبرنامه به Spam نرود؛ SPF و DKIM را پیش از DMARC درست کنید

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

این ترتیب، علت خطا را پیش از سخت‌گیرانه‌کردن سیاست روشن می‌کند. راهنمای فرستندگان Gmail از همهٔ فرستندگان دست‌کم SPF یا DKIM و از فرستندگان انبوه هر سه سازوکار SPF، DKIM و DMARC را می‌خواهد؛ برای پیام مستقیمِ فرستندهٔ انبوه، دامنهٔ From نیز باید با دامنهٔ SPF یا DKIM هم‌تراز باشد و سیاست DMARC می‌تواند p=none باشد. احراز هویت احتمال ردشدن یا رفتن پیام به Spam را کاهش می‌دهد، اما ورود به Inbox را تضمین نمی‌کند.

پیش از تغییر DNS، فرستنده‌های دامنه را پیدا کنید

نشانی From خبرنامه را یادداشت کنید و فهرستی از سرویس‌هایی بسازید که با دامنهٔ شما ایمیل می‌فرستند: سرویس خبرنامه، صندوق کاری و ابزارهای ارسال پیام خودکار. برای هرکدام مشخص کنید نشانی فرستنده چه دامنه‌ای دارد، پیام از چه سرویسی خارج می‌شود و سرویس چه رکوردهایی برای احراز هویت ارائه کرده است. اگر فقط تنظیم پیشنهادی سرویس خبرنامه را جایگزین مقدار موجود کنید، ممکن است مسیر ارسال دیگری را از SPF حذف کنید.

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

SPF را در نام درست و با یک مقدار معتبر تنظیم کنید

SPF به گیرنده امکان می‌دهد سرور ارسال‌کننده را در برابر مجوزهای منتشرشده برای دامنهٔ مورد بررسی بیازماید. این دامنه ممکن است دامنهٔ نشانی بازگشت پیام، یا Return-Path، باشد و الزاماً با نشانی From که مشترک می‌بیند یکسان نیست. بنابراین پیش از افزودن رکورد، نام دامنه‌ای را که سرویس برای SPF تعیین کرده است پیدا کنید و مقدار پیشنهادی آن را با رکورد موجود در همان نام مقایسه کنید.

برای یک نام دامنه، افزودن TXT دومی که آن هم با v=spf1 آغاز می‌شود راه معرفی فرستندهٔ تازه نیست. راهنمای رفع خطای MailerLite چند رکورد SPF، نام میزبان نادرست و عبور از محدودیت جست‌وجوهای DNS را از علت‌های تأییدنشدن رکورد می‌داند. اگر چند مسیر برای همان دامنه SPF می‌خواهند، سازوکارهای لازم را طبق دستور سرویس‌ها در یک مقدار ادغام کنید و مقدارهای SPF اضافی را بردارید؛ رکوردهای TXT مربوط به تأیید مالکیت دامنه را با SPF اشتباه نگیرید.

در پنل‌های DNS، دامنهٔ اصلی ممکن است در فیلد Name یا Host با @، نام کامل دامنه یا فیلد خالی نشان داده شود. ملاک، نام و مقداری است که پس از ذخیره در پاسخ عمومی DNS دیده می‌شود. هنگام ادغام، فقط به حضور نام سرویس تازه نگاه نکنید: بخش‌های مربوط به فرستنده‌های قبلی و نتیجهٔ نهایی SPF نیز باید معتبر بمانند.

DKIM را مطابق رکورد همان سرویس فعال کنید

DKIM امضایی به پیام خروجی می‌افزاید و گیرنده کلید لازم برای بررسی آن را از DNS می‌گیرد. نام رکورد معمولاً شامل selector و بخش _domainkey است، اما selector، نوع رکورد و مقدار آن را باید از سرویس ارسال بگیرید. در راهنمای احراز دامنهٔ MailerLite، تنظیم دستی شامل CNAME برای DKIM و TXT برای SPF است و نام و مقدار رکوردها باید با داده‌های ارائه‌شده در همان سرویس مطابقت داشته باشند.

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

اگر DKIM تأیید نمی‌شود، نام منتشرشده را با نام خواسته‌شده مقایسه کنید. بعضی پنل‌ها نام دامنه را خودکار به انتهای Host می‌افزایند؛ واردکردن دوبارهٔ آن می‌تواند رکورد را در نامی دیگر بسازد. مقدار یا مقصد CNAME نیز باید دقیق باشد، زیرا یک تفاوت کوچک ممکن است باعث شود گیرنده کلید امضای پیام را پیدا نکند.

انتشار DNS و هم‌ترازی را با پیام آزمایشی بسنجید

پس از ذخیرهٔ تغییرات، با پرس‌وجوی عمومی DNS رکورد SPF و نام DKIM خواسته‌شده را بخوانید. اگر مقدار تازه هنوز دیده نمی‌شود، برای به‌روزرسانی پاسخ‌های DNS فرصت بدهید و دوباره همان نام را بررسی کنید. اگر پنل مقدار تازه را نشان می‌دهد اما پاسخ عمومی همچنان قدیمی است، بررسی کنید تغییر را نزد سرویس مدیریت‌کنندهٔ DNS فعال انجام داده‌اید.

وقتی رکوردها دیده شدند، از همان سرویس و همان نشانی From خبرنامه یک پیام آزمایشی بفرستید. در جزئیات احراز هویت پیام دریافتی، نتیجهٔ SPF، دامنهٔ بررسی‌شده برای آن، نتیجهٔ DKIM و دامنهٔ امضای آن را کنار دامنهٔ From بگذارید. «pass» بودن یکی از روش‌ها به‌تنهایی کافی نیست: برای موفقیت DMARC باید همان روشِ موفق با دامنهٔ From هم‌تراز باشد.

برای SPF، دامنهٔ نشانی بازگشت پیام را بررسی کنید؛ برای DKIM، دامنهٔ امضا را در مقدار d= ببینید. در هم‌ترازی معمول، زیردامنه می‌تواند با دامنهٔ سازمانی From هم‌تراز باشد، اما در حالت سخت‌گیرانه نام‌ها باید دقیقاً یکسان باشند. اگر سرویس از دامنهٔ خودش برای Return-Path استفاده می‌کند، ممکن است SPF موفق شود ولی با From شما هم‌تراز نباشد؛ در چنین وضعی امضای DKIM هم‌تراز می‌تواند مسیر موفقیت DMARC باشد.

DMARC را با سیاست نظارتی آغاز کنید

پس از بررسی پیام آزمایشی، برای نام _dmarc دامنهٔ From یک رکورد TXT با سیاست p=none منتشر کنید. این سیاست از گیرنده نمی‌خواهد پیام ناموفق را صرفاً به‌دلیل سیاست DMARC قرنطینه یا رد کند. اگر گزارش‌های تجمیعی می‌خواهید، نشانی دریافت آن‌ها را با rua در رکورد بگذارید و صندوقی را انتخاب کنید که به آن دسترسی دارید.

برای نمونه‌ای کاملاً فرضی با دامنهٔ example.com، نام رکورد _dmarc.example.com و مقدار آن می‌تواند «v=DMARC1; p=none; rua=mailto:[email protected]» باشد. دامنه و صندوق این نمونه باید با مقادیر واقعی شما جایگزین شوند. پیش از تغییر سیاست به quarantine یا reject، گزارش‌ها و همهٔ مسیرهای مجاز ارسال را بررسی کنید؛ سخت‌گیری زودهنگام می‌تواند بر پیام مشروعی اثر بگذارد که هنوز با From هم‌تراز نشده است.

از نتیجهٔ خطا به تنظیم نادرست برگردید

1. اگر رکورد در پاسخ عمومی DNS پیدا نمی‌شود، نام رکورد و میزبان فعال DNS را بررسی کنید و به تغییر فرصت انتشار بدهید.
2. اگر SPF رد می‌شود، دامنهٔ بررسی‌شده، سرور واقعی ارسال و مقدار منتشرشده را کنار هم بگذارید. چند مقدار SPF برای یک نام، حذف‌شدن مسیر قبلی یا مقدار نامعتبر را اصلاح کنید.
3. اگر DKIM رد می‌شود، selector، نام و مقدار رکورد و فعال‌بودن امضا در سرویس ارسال را بررسی کنید.
4. اگر SPF یا DKIM موفق است ولی DMARC رد می‌شود، دامنهٔ From را با دامنهٔ همان روشِ موفق مقایسه کنید. نتیجهٔ موفق برای دامنه‌ای بی‌ارتباط با From، هم‌ترازی ایجاد نمی‌کند.

اگر احراز هویت و هم‌ترازی درست است اما خبرنامه همچنان به Spam می‌رود، فقط با تغییر DNS نمی‌توان مسئله را حل کرد. شکایت گیرندگان، اعتبار دامنه و شیوهٔ ارسال نیز بر تحویل اثر دارند. در این حالت، نتیجهٔ احراز هویت را جدا از بازخورد گیرندگان و وضعیت ارسال بررسی کنید تا رکورد سالم را بی‌دلیل تغییر ندهید.

بیشتر بخوانید:

• RAG را درست ارزیابی کنید؛ یک امتیاز خوب می‌تواند خطای بازیابی را پنهان کند
• تأیید انسانی برای عامل‌ها بسازید؛ توقف را فقط پیش از کار پرخطر بگذارید
• خروجی AI را پیش از ارسال در چهار مرحله راستی‌آزمایی کنید