يحدّد سجل SPF الأنظمة المصرح لها بإرسال البريد نيابة عن نطاق يُستخدم في التسليم. لكنه لا يتحقق وحده من عنوان «من» الذي يراه العميل، ولا يثبت أن المستلم يرغب في الرسالة. والمهمة العملية لصاحب المتجر هي تحديد اسم المضيف الصحيح، والإبقاء على المرسلين الشرعيين، واستخدام السجلات المقدمة لحساب الإرسال المعني تحديدًا.
حدّد اسم المضيف والمرسلين الحاليين
اطلب من مسؤول DNS فحص اسم المضيف المحدد. فقد يستخدم بريد موظفيك وخدمة التسويق ترتيبات إرسال مختلفة؛ لذلك لا تفترض أن جميع السجلات تنتمي إلى الموضع نفسه.
استخدم القيم المقدمة لحسابك. احتفظ بنسخة من الإعداد السابق وحدد الخدمات الحالية التي تعتمد عليه. قد تؤدي إضافة سياسة SPF ثانية تتعارض مع الأولى لاسم المضيف نفسه إلى خطأ بدلًا من توسيع نطاق الإذن.
افهم ما الذي يحدده SPF وما الذي لا يحدده
يفحص SPF عادةً النطاق المستخدم في معاملة البريد الأساسية، ويظهر غالبًا في معلومات مسار العودة للرسالة. وقد يختلف ذلك عن العنوان الظاهر في حقل «من». لذلك ينبغي تفسير نجاح SPF مع مراعاة النطاق الذي اجتاز الفحص ونتيجة توافقه مع DMARC.
تُنشر السياسة في DNS، لكنها تصف بنية الإرسال المصرح بها ولا تسرد الموظفين الذين يجوز لهم كتابة الرسائل. إضافة مستخدم جديد إلى صندوق بريد ليست كإذن خدمة إرسال جديدة. اسأل عن النطاق الذي تستخدمه الخدمة فعليًا قبل تحديد سياسة DNS التي تحتاج إلى تعديل.
يجب ألا توجد سياستان متعارضتان لـSPF لاسم المضيف الذي يخضع للفحص نفسه. ويختلف هذا عن تقسيم واجهة DNS سجل TXT طويلًا واحدًا إلى سلاسل أحرف مقتبسة؛ إذ ينبغي للمسؤول المؤهل تمييز طريقة عرض الواجهة عن وجود سياسات منفصلة متعددة. لا تدمج السجلات أو تحذفها استنادًا إلى عدد الصفوف الظاهرة على الشاشة وحده.
تجنب التعديل بالتخمين
قد يشير سجل SPF إلى سجلات أخرى، مما يضيف استعلامات واعتماديات. وقد تتوقف سلسلة إضافات طويلة عن العمل حتى لو بدا كل مرسل جديد معقولًا بمفرده. إذا أصبح الإعداد معقدًا، فاطلب من مسؤول مؤهل تقييمه كاملًا.
لا تحذف مدخلًا غير مألوف قبل أن تعرف الخدمة التي تستخدمه. وفي المقابل، لا تترك خدمات متوقفة مصرحًا لها إلى الأبد لمجرد أن السجل يجتاز اختبارًا حاليًا. احتفظ بقائمة موجزة بالمرسلين الشرعيين والمسؤول عن كل خدمة.
اعرف لماذا قد تفشل السياسة بعد إضافة واحدة أخرى
يضع SPF حدودًا لآليات ومعدّلات تقييم DNS التي تتطلب استعلامات. وقد يُجري السجل القصير ظاهريًا استعلامات كثيرة عبر مراجع متداخلة. لذلك يمكن لإضافة include أخرى أن تسبب خطأ دائمًا في التقييم حتى لو كانت صياغتها سليمة. الفحص المهم هو مسار التقييم كاملًا، لا عدد الأحرف.
اطلب من المسؤول مراجعة المراجع الحالية وتحديد ما زال ضروريًا منها. ولا تستبدل يدويًا إعدادًا تدعمه الخدمة بقائمة ثابتة من عناوين IP لمجرد أن أداة الفحص تبدو أبسط؛ فقد تتغير تلك العناوين. استخدم الطريقة التي يدعمها مزود الخدمة، واستعن بالفريق التقني المسؤول لحل التعقيد.
تحقق من النتيجة بعد التسليم
بعد انتشار التغيير، أرسل رسالة اختبار مضبوطة عبر إعداد Sendvio المقصود وافحص نتائج المصادقة. تحقق من SPF وDKIM وتوافق DMARC معًا بدلًا من اعتبار نجاح أي علامة منفردة جوابًا كاملًا.
سجّل اسم المضيف الذي تم التحقق منه وتاريخ الفحص في ملاحظات الإعداد. وأعد الفحص عند تغيير النطاقات أو خدمات الإرسال. يقلل تصحيح SPF نوعًا واحدًا من أخطاء المصادقة، لكن الموافقة والشكاوى والمحتوى وسلوك الإرسال تظل مؤثرة في تجربة المستلمين.
عند تصعيد مشكلة، قدّم نطاق الإرسال المتأثر ووقت الاختبار المنضبط ونتيجة SPF والهوية التي جرى تقييمها وترويسات المصادقة ذات الصلة بعد إزالة البيانات الحساسة. وضّح ما إذا كان بريد الموظفين العادي يفشل أيضًا أو إن كانت المشكلة في إعداد التسويق وحده. يساعد ذلك على التمييز بين تغيير يؤثر في النطاق كله ومشكلة خاصة بخدمة معينة.
بعد الإصلاح، اختبر كل مسارات الإرسال الشرعية التي تشملها السياسة المعدّلة. يجب ألا يؤدي إصلاح حملة تسويقية إلى إزالة الإذن عن بريد الدعم أو الرسائل التشغيلية. احتفظ بقائمة المرسلين المعتمدة مع اسم مسؤول السجل وتاريخ آخر تحقق. تنجح صيانة SPF عندما يظل المرسلون الشرعيون مصرحًا لهم وتُزال الجهات القديمة عن قصد، لا عندما تجتاز حملة واحدة الاختبار لمرة واحدة.