فحص سجل SPF

ما الذي يفحصه مدقق SPF

يقرأ سجلات TXT للنطاق الذي تدخله ويحدد السجل الذي يبدأ بـ v=spf1. ثم يتتبع كل include وredirect كما يفعل خادم الاستقبال، ويسجل كل عملية بحث تتطلب استعلام DNS، ويتحقق من صياغة كل عنصر.

لا يوجد عنوان IP ضمن هذا الفحص. السؤال هنا هو ما إذا كان السجل صالحًا ولا يتجاوز حدود الاستعلامات لأي جهة تحتاج إلى تقييمه، وليس ما إذا كان يُسمح لخادم معين بالإرسال. للتحقق من ذلك، أرسل رسالة عبر الاختبار الكامل، وسيعرض التقرير النتيجة الفعلية التي حصل عليها خادم الاستقبال.

عدد استعلامات DNS أكبر من المسموح: الحد هو عشرة

يحدد RFC 7208 تقييم SPF بعشرة عناصر كحد أقصى من العناصر التي تتطلب استعلام DNS، وهي: include وa وmx وptr وexists وredirect. يشمل العد الشجرة بأكملها، لذلك فإن include يتضمن بدوره ثلاثة عناصر أخرى يستهلك أربع عمليات. يؤدي تجاوز الحد إلى نتيجة permerror، ويعدّها DMARC إخفاقًا في اجتياز SPF.

يحسب المدقق كل عنصر، بما في ذلك العناصر التي قد لا يصل إليها التقييم مطلقًا، لأن التقييم الفعلي يتوقف عند أول تطابق. تستمر الخوادم المدرجة مبكرًا في الاجتياز، بينما تبدأ الخوادم الموجودة لاحقًا في الإخفاق. ومن الخارج، يبدو ذلك كأن البريد يعمل لبعض الرسائل ولا يعمل لرسائل أخرى.

لا تستهلك عناصر ip4 وip6 أي عمليات بحث. يؤدي استبدال include بنطاقات عناوين، وهو ما يُعرف بالتسطيح، إلى خفض العدد، لكنك ستحتاج إلى مزامنة هذه النطاقات يدويًا مع مزودي الخدمة.

أخطاء يجب البحث عنها

وجود سجلين من نوع SPF على نطاق واحد. يحدث ذلك عندما تطلب إرشادات إعداد مزود ثانٍ إضافة سجل، ولا يدمجه أحد مع السجل الأول. يؤدي وجود سجلين بحد ذاته إلى permerror.

إنهاء السجل بـ +all، ما يسمح لأي خادم على الإنترنت بالاجتياز، أو بـ ?all، الذي لا يحدد شيئًا عن أي جهة، وبالتالي لا يوفر أي حماية. واستخدام عنصر ptr، الذي ينص RFC 7208 على عدم استخدامه. كذلك، تستهلك عناصر include الخاصة بخدمات توقفت الشركة عن استخدامها منذ سنوات عملية بحث لكل منها.