رکورد SPF سامانههایی را مشخص میکند که مجازند از دامنهای که در تحویل ایمیل استفاده میشود پیام بفرستند. SPF بهتنهایی نشانی From قابل مشاهدهٔ مشتری را تأیید نمیکند یا مطلوببودن پیام را ثابت نمیکند. کار عملی مالک فروشگاه، شناخت نام میزبان درست، حفظ فرستندگان مجاز و استفاده از رکوردهای حساب ارسال مشخص است.
نام میزبان و فرستندگان موجود را شناسایی کنید
از فرد مسئول DNS بخواهید نام میزبان دقیق را بررسی کند. ایمیل کارکنان و سرویس بازاریابی شاید از تنظیمات ارسال متفاوتی استفاده کنند؛ فرض نکنید همهٔ رکوردها باید یکجا قرار بگیرند.
از مقادیری استفاده کنید که برای حساب شما ارائه شدهاند. نسخهای از پیکربندی پیشین نگه دارید و سرویسهای فعلیِ وابسته به آن را بشناسید. افزودن سیاست SPF دومی که در همان نام میزبان با اولی رقابت کند شاید بهجای گسترش مجوز، خطا بسازد.
بدانید SPF چه چیزی را شناسایی میکند و چه چیزی را نه
SPF معمولاً دامنهٔ تراکنش زیربنایی ایمیل را ارزیابی میکند؛ اغلب این دامنه در اطلاعات return-path پیام دیده میشود. ممکن است با نشانی From قابل مشاهده فرق داشته باشد. بنابراین نتیجهٔ موفق SPF را باید همراه دامنهای که برایش موفق شده و نتیجهٔ همترازی DMARC تفسیر کرد.
سیاست در DNS منتشر میشود، اما زیرساخت مجاز ارسال را مشخص میکند، نه فهرست کارکنانی را که اجازهٔ نوشتن ایمیل دارند. افزودن کاربر صندوق پستی با مجازکردن سرویس ارسال تازه یکی نیست. پیش از تصمیمگیری دربارهٔ سیاست DNS، بپرسید سرویس واقعاً از کدام دامنه استفاده میکند.
برای هر نام میزبانی که ارزیابی میشود نباید دو سیاست SPF رقیب وجود داشته باشد. این با رابط DNS که یک رکورد TXT بلند را به رشتههای نویسهایِ نقلقولشده میشکند فرق دارد. مدیر واجد صلاحیت باید نمایش رابط را از چند سیاست مستقل تشخیص دهد. رکوردها را فقط بر اساس تعداد سطرهایی که صفحه نشان میدهد ادغام یا حذف نکنید.
بر پایهٔ حدس و گمان ویرایش نکنید
رکورد SPF ممکن است به رکوردهای دیگری ارجاع دهد و محدودیت جستوجو یا وابستگی ایجاد کند. زنجیرهٔ بلند افزودهها حتی وقتی هر فرستندهٔ جدید جداگانه معقول است ممکن است از کار بیفتد. اگر تنظیم پیچیده شده، مدیر فنی واجدصلاحیت باید پیکربندی ترکیبی را ارزیابی کند.
ورودی ناآشنا را تا وقتی نمیدانید چه چیزی از آن استفاده میکند حذف نکنید. درعینحال، سرویس بازنشسته را فقط بهدلیل موفقبودن آزمون برای همیشه مجاز نگه ندارید. فهرست کوتاهی از فرستندگان واقعی و مسئول هر سرویس تهیه کنید.
بدانید چرا افزودن یک مورد ممکن است سیاست را خراب کند
استاندارد SPF در هر ارزیابی حداکثر ۱۰ عبارتِ نیازمند جستوجوی DNS را مجاز میداند؛ عبور از این حد باید به نتیجهٔ PermError بینجامد. SPF در ارزیابی، سازوکارها و اصلاحگرهای نیازمند جستوجوی DNS را محدود میکند. رکوردی کوتاه شاید از راه ارجاعهای تودرتو جستوجوهای زیادی ایجاد کند. در نتیجه افزودن include دیگری ممکن است خطای دائمی ارزیابی بسازد، حتی اگر نحوِ همان افزوده درست باشد. باید مسیر ارزیابی کامل را بررسی کرد، نه تعداد نویسهها را.
از مدیر بخواهید ارجاعهای فعلی را بررسی و موارد هنوز لازم را مشخص کند. فقط برای سادهتر بهنظررسیدن ابزار بررسی، پیکربندی پشتیبانیشدهٔ سرویس را دستی با فهرستی ثابت از IP جایگزین نکنید؛ این نشانیها ممکن است عوض شوند. از روش موردپشتیبانی ارائهدهنده استفاده کنید و پیچیدگی را با تیم فنی مسئول حل کنید.
نتیجهٔ پیام تحویلشده را تأیید کنید
پس از انتشار تغییر، از پیکربندی موردنظر Sendvio پیام آزمایشی کنترلشده بفرستید و نتیجههای احراز هویت را بررسی کنید. SPF را کنار DKIM و همترازی DMARC بسنجید؛ برچسب موفقیت یکی را پاسخ کامل ندانید.
نام میزبان تأییدشده و تاریخ را در یادداشت تنظیمات ثبت کنید. با تغییر دامنه یا سرویس ارسال آزمون را تکرار کنید. اصلاح SPF یک نوع خطای احراز هویت را کم میکند، اما مجوز، شکایت، محتوا و رفتار ارسال همچنان بر تجربهٔ گیرنده اثر میگذارند.
اگر مشکل را ارجاع میدهید، دامنهٔ ارسالِ متأثر، زمان آزمایش کنترلشده، نتیجه و هویت ارزیابیشدهٔ SPF و سرآیندهای احراز هویتِ مرتبط و پاکسازیشده را ارائه کنید. بگویید آیا ایمیل عادی کارکنان هم شکست میخورد یا فقط تنظیم بازاریابی. این اطلاعات به تفکیک تغییر سراسری دامنه از مسئلهٔ سرویس خاص کمک میکند.
پس از اصلاح، همهٔ مسیرهای مجاز ارسال را که سیاست تغییرکرده پوشش میدهد آزمایش کنید. اصلاح کمپین بازاریابی نباید مجوز ارسال پشتیبانی یا پیام عملیاتی را حذف کند. فهرست فرستندگان تأییدشده را کنار مسئول رکورد و تاریخ آخرین بررسی نگه دارید. نگهداری SPF وقتی موفق است که فرستندگان مجاز بمانند و موارد منسوخ با قصد حذف شوند، نه اینکه فقط یک کمپین یکبار موفق شود.