راهنما: احراز هویت
راه‌اندازی SPF
SPF به سرور گیرنده امکان می‌دهد بررسی کند سروری که پیام را تحویل داده است اجازه ارسال از طرف دامنه پاکت پیام را دارد یا نه. این کار با یک رکورد DNS انجام می‌شود و اشتباه‌های ظریف در آن رایج است.
آخرین بازبینی: ۱۳ آبان ۱۴۰۵
SPF چه چیزی را بررسی می‌کند
Sender Policy Framework یا SPF (استاندارد RFC 7208) یک رکورد TXT روی دامنه شماست که سرورهای مجاز به ارسال ایمیل برای آن دامنه را فهرست می‌کند. وقتی پیامی می‌رسد، سرور گیرنده رکورد دامنه فرستنده پاکت را می‌خواند (همان MAIL FROM در SMTP که Return-Path هم نامیده می‌شود) و آن را با نشانی IP اتصال مقایسه می‌کند.
SPF به نشانی From که گیرنده می‌بیند نگاه نمی‌کند. به همین دلیل SPF به‌تنهایی جلوی نمایش دامنه شما در From را نمی‌گیرد. DMARC این شکاف را می‌بندد، چون می‌خواهد دامنه بررسی‌شده با دامنه From هم‌راستا باشد.
یک رکورد برای همه فرستنده‌ها
هر دامنه فقط می‌تواند یک رکورد SPF داشته باشد. اگر دو رکورد با v=spf1 شروع شوند، بررسی با خطای دائمی شکست می‌خورد. پس وقتی سرویس تازه‌ای اضافه می‌کنید، include آن را به همان رکورد موجود بیفزایید و رکورد دوم نسازید.
رکورد با v=spf1 شروع می‌شود، سازوکارها را فهرست می‌کند و معمولاً با سازوکار all تمام می‌شود که تکلیف بقیه فرستنده‌ها را روشن می‌کند. نمونه زیر فقط برای نشان دادن ساختار است: ارائه‌دهنده فعلی را نگه می‌دارد (به‌جای _spf.example.com، include ارائه‌دهنده خودتان را بگذارید) و Mail.Land را اضافه می‌کند.
- include:domain سرورهایی را که دامنه دیگری مجاز کرده است اضافه می‌کند و روش معمول افزودن یک سرویس ایمیل است.
- ip4: و ip6: نشانی‌ها یا بازه‌های خودتان را مستقیم فهرست می‌کنند.
- a و mx میزبان‌هایی را که در رکوردهای A یا MX دامنه آمده‌اند مجاز می‌کنند.
- ~all (soft fail) فرستنده‌های دیگر را مشکوک علامت می‌زند و -all (fail) می‌گوید مجاز نیستند. رکورد را هرگز با +all تمام نکنید، چون به همه اجازه ارسال می‌دهد.
v=spf1 include:_spf.example.com include:spf.mlnd.net ~allاز سقف جست‌وجوها بیرون نزنید
سازوکارهای include، a، mx، ptr و exists و اصلاح‌گر redirect هر کدام در سقف ۱۰ عبارتِ نیازمند جست‌وجوی DNS در هر ارزیابی شمرده می‌شوند و عبارت‌های درون رکوردی که include شده است هم حساب می‌شوند. بیش از این سقف، نتیجه خطای دائمی است و گیرنده رکورد را خراب به حساب می‌آورد.
سرویس‌هایی را که دیگر استفاده نمی‌کنید حذف کنید، برای سرورهای خودتان بازه ip4 یا ip6 بگذارید و از سازوکار ptr که استاندارد استفاده از آن را توصیه نمی‌کند پرهیز کنید.
نتیجه را بررسی کنید
پس از انتشار، پیامی به صندوقی که در اختیار دارید بفرستید و سربرگ Authentication-Results را بخوانید. این سربرگ یکی از نتیجه‌های spf=pass، fail، softfail، neutral، none، permerror یا temperror و دامنه بررسی‌شده را نشان می‌دهد.
بازارسال (forwarding) اغلب SPF را از کار می‌اندازد، چون سرور بازارسال در رکورد شما نیست. این رفتار طبیعی است. DKIM معمولاً پس از بازارسالی که محتوای امضاشده را تغییر ندهد معتبر می‌ماند و این یکی از دلایل انتشار هر دوست.
ارائه‌دهندگان صندوق پستی چه می‌خواهند
Google از همه فرستنده‌ها می‌خواهد SPF یا DKIM را راه بیندازند و از کسانی که روزانه نزدیک به ۵٬۰۰۰ پیام یا بیشتر به حساب‌های شخصی Gmail می‌فرستند، SPF و DKIM و DMARC را. Yahoo از فرستنده‌های انبوه می‌خواهد هم SPF و هم DKIM را پیاده کنند. انتشار هر دو برای هر دامنه‌ای که ایمیل می‌فرستد انتخاب مطمئن است.
Mail.Land با SPF چه می‌کند
include:spf.mlnd.net را پیش از سازوکار all به تنها رکورد SPF دامنه ارسال خود اضافه کنید. SPF و DKIM و DMARC هر سه باید تأیید شوند تا دامنه بتواند ارسال کند.
دامنه‌های تازه یک Return-Path اختصاصی هم می‌گیرند: یک CNAME از bounce.yourdomain به bounce.mlnd.net. وقتی این رکورد تأیید شد، دامنه پاکت زیردامنه خود شماست و SPF با هم‌راستایی relaxed، که پیش‌فرض DMARC است، با دامنه From هم‌راستا می‌شود. تا آن زمان Mail.Land از Return-Path پیش‌فرض خودش استفاده می‌کند. رکورد را فقط DNS (بدون پراکسی) نگه دارید، وگرنه سرورهای ایمیل آن را نمی‌بینند.
منابع
- RFC 7208، Sender Policy Framework (SPF) (بررسی‌شده در ۱۳ آبان ۱۴۰۵)
- Google، راهنمای فرستندگان ایمیل (بررسی‌شده در ۱۳ آبان ۱۴۰۵)
- Yahoo، بهترین شیوه‌های فرستندگان (بررسی‌شده در ۱۳ آبان ۱۴۰۵)
آموخته‌ها را به کار بگیرید
دامنه خود را به Mail.Land اضافه کنید تا داشبورد دقیقاً همان رکوردهای SPF، DKIM و DMARC را که باید منتشر کنید نشان دهد.