ایمیل دامنه به اسپم می‌رود؟ SPF و DKIM و DMARC را تنظیم کنید

اگر ایمیل‌های info@yourdomain.com به پوشهٔ اسپم می‌روند یا گاهی رد می‌شوند، فقط متن پیام را عوض نکنید. سرویس دریافت‌کننده باید بتواند بفهمد چه سروری اجازه دارد از طرف دامنهٔ شما ایمیل بفرستد و آیا پیام در راه دست‌کاری شده است. سه رکورد SPF، DKIM و DMARC به این بررسی کمک می‌کنند. تنظیم نادرست آن‌ها هم می‌تواند ایمیل سالم را رد کند؛ پس اول همهٔ فرستنده‌های واقعی دامنه را فهرست کنید.

یک جدول ساده بسازید و نام هر سامانهٔ ارسال را کنار نوع پیام بنویسید: وب‌سایت و فرم تماس، صندوق cPanel یا DirectAdmin، خبرنامه، فروشگاه و سرویس ارسال پیامک یا ایمیل. شاید هرکدام از سرور جداگانه استفاده کنند. اگر فقط سرور هاست را در SPF وارد کنید ولی خبرنامه از سرویس دیگری بفرستد، بخشی از ایمیل‌ها احراز هویت نمی‌شوند.

از هر سرویس‌دهنده بخواهید دقیقاً بگوید کدام رکورد DNS باید ساخته شود و نام میزبان آن چیست. مقادیر نمونهٔ اینترنتی را جایگزین مقدار حساب خود نکنید؛ رشتهٔ DKIM و بخش include در SPF برای هر فرستنده فرق می‌کند. راهنمای Google برای فرستندگان ایمیل هم می‌گوید SPF و DKIM باید برای دامنهٔ فرستنده تنظیم شوند و DMARC برای سیاست و گزارش به کار می‌رود.

در پنل DNS، رکورد TXT دامنهٔ اصلی را پیدا کنید. معمولاً نام آن @ یا خالی نمایش داده می‌شود، ولی پنل‌ها فرق دارند. مقدار SPF با v=spf1 شروع می‌شود و باید همهٔ فرستنده‌های مجاز را پوشش دهد. اگر رکورد SPF از قبل دارید، همان را ویرایش کنید؛ برای یک دامنه دو رکورد مستقل v=spf1 نسازید. داشتن دو رکورد SPF می‌تواند پاسخ را نامعتبر کند.

برای فهم مقدار درست، رکورد فعلی را کپی کنید و از سرویس‌های خروجی تأییدشده بپرسید کدام include یا IP باید به همان رکورد اضافه شود. بخش پایانی مانند ~all یا -all را کورکورانه تغییر ندهید. اگر یک سامانهٔ فراموش‌شده از دامنه ایمیل بفرستد، قانون سخت‌گیرانه می‌تواند پیامش را رد کند. ابتدا همهٔ فرستنده‌ها را پیدا کنید و رکورد نهایی را با میزبان DNS تطبیق دهید.

DKIM امضای دیجیتالی به پیام اضافه می‌کند تا دریافت‌کننده ببیند پیام از مسیر مجاز آمده و محتوای امضاشده تغییر نکرده است. در cPanel معمولاً بخش Email Deliverability برای ساخت یا نمایش DKIM رکورد کمک می‌کند. در سایر سرویس‌ها ممکن است selector و مقدار TXT را در صفحهٔ تنظیم دامنه ببینید. نام رکورد اغلب شکلی مانند selector._domainkey دارد؛ selector را خود سرویس مشخص می‌کند.

رکورد را دقیق کپی کنید؛ کوتاه‌کردن رشته، حذف کوتیشن لازم یا اضافه‌کردن نام دامنه دوباره می‌تواند آن را خراب کند. بعضی پنل‌ها خودشان نام دامنه را اضافه می‌کنند. برای جلوگیری از رکورد اشتباه، پس از ذخیره، از ابزار جست‌وجوی DNS پنل یا دستور dig TXT selector._domainkey.example.com استفاده کنید. به‌جای selector و example.com مقدار واقعی خودتان را بگذارید.

نام رکورد DMARC معمولاً _dmarc در دامنهٔ اصلی است. مقدارش با v=DMARC1 شروع می‌شود. اگر هنوز همهٔ فرستنده‌ها را نمی‌شناسید، ابتدا سیاست گزارش‌گیری p=none را در نظر بگیرید تا بفهمید چه سامانه‌هایی از طرف دامنه پیام می‌فرستند. یک آدرس واقعی برای گزارش‌ها وارد کنید، وگرنه گزارش‌ها جایی نمی‌رسند. گزارش‌های XML برای انسان خواندن سخت‌اند؛ از ابزار مورداعتماد خودتان برای خلاصه‌کردن آن‌ها استفاده کنید و فایل حاوی اطلاعات را عمومی منتشر نکنید.

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

پس از زمان لازم برای انتشار DNS، از هر سامانهٔ ارسال یک پیام آزمایشی به یک حساب Gmail بفرستید. در Gmail گزینهٔ Show original یا «نمایش نسخهٔ اصلی» را باز کنید. مقابل SPF، DKIM و DMARC نتیجهٔ PASS را ببینید و دامنهٔ هر نتیجه را با نشانی فرستنده مقایسه کنید. یک پیام از فرم سایت و یک پیام از صندوق ایمیل بفرستید؛ موفقیت یکی ثابت نمی‌کند همهٔ فرستنده‌ها درست تنظیم شده‌اند.

اگر SPF شکست می‌خورد، مقدار TXT و فهرست فرستنده‌ها را دوباره بررسی کنید. اگر DKIM شکست می‌خورد، نام selector و مقدار کلید را با پنل ارسال‌کننده تطبیق دهید. اگر هر سه PASS هستند اما پیام هنوز اسپم می‌شود، احراز هویت به‌تنهایی تضمین ورود به صندوق اصلی نیست؛ اعتبار IP، شکایت کاربران، محتوای پیام و الگوی ارسال هم اثر دارند. پشتیبانی ارائه‌دهندهٔ ایمیل می‌تواند گزارش برگشت را بخواند. مقالهٔ ارسال ایمیل وردپرس با SMTP هم تفاوت فرستندهٔ سایت و صندوق دامنه را توضیح می‌دهد.

SPF سقف تعداد جست‌وجوهای include دارد. زنجیرهٔ بلند از سرویس‌های ارسال ممکن است از حد مجاز عبور کند و SPF را نامعتبر کند. اگر چند ارائه‌دهنده دارید، هرکدام را جدا فهرست و مقدار پیشنهادی را با مسئول فنی همان سرویس هماهنگ کنید؛ includeهای ناشناخته را روی هم نچینید. ابزارهای آزمایش DNS می‌توانند خطا را نشان دهند، اما مقدار درست را مستندات فرستنده مشخص می‌کند.

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