كيف تفحص سجل SPF لبريد التطبيقات؟

ابدأ بالهوية التي يفحصها SPF فعلًا

يحتاج فحص SPF إلى ثلاثة مدخلات: عنوان IP لعميل SMTP، والنطاق الذي تُقيَّم سياسة التفويض الخاصة به، وهوية المُرسِل. في بريد التطبيقات العادي، يؤخذ هذا النطاق من عنوان SMTP MAIL FROM، الذي يُسمّى أيضًا مُرسِل الظرف أو مسار الإرجاع (return path). وقد يختلف عن العنوان الذي يراه الناس في ترويسة From للرسالة. إذا كان MAIL FROM فارغًا، كما هو الحال عادةً في إشعار حالة التسليم، يستخدم SPF هوية HELO لفحص MAIL FROM. سجّل عنوان IP الفعلي للاتصال وهوية الظرف من رسالة اختبار مستلَمة أو من إعدادات مزوّد الإرسال قبل الاستعلام عن DNS. فحص example.test لمجرد ظهوره في From لا يعطي نتيجة حاسمة إذا كان التطبيق يرسل فعليًا بـ MAIL FROM على bounce.provider.test أو bounces.example.test.

استعلم عن TXT على نطاق MAIL FROM بالضبط

استعلم عن سجل DNS من نوع TXT على النطاق الدقيق الذي حدّدته في الخطوة الأولى. يشترط RFC 7208 نشر سياسات SPF من الإصدار 1 كسجلات TXT على اسم المالك الذي تحكمه. تجاهل قيم TXT غير ذات الصلة، واختر السجلات التي يكون قسم الإصدار فيها v=spf1 بالضبط. عدم وجود أي سجل مختار ينتج عنه النتيجة none في SPF. ووجود أكثر من سجل SPF مختار ينتج permerror؛ ونشر سجلات منفصلة لمزوّدين مختلفين ليس طريقة صحيحة للجمع بينهم. قد تقسّم أدوات DNS سجل TXT الواحد إلى سلاسل محارف بين علامات اقتباس، لكن هذه السلاسل تُضمّ دون إدراج مسافات قبل تحليل SPF. احفظ الإجابة كاملة ومحلّل DNS ووقت الاستعلام وقيمة TTL حتى يمكن تكرار الفحص بعد أي تغيير.

تحقّق من الصياغة وقيّم المصطلحات من اليسار إلى اليمين

سجل SPF سياسة مرتّبة، لا قائمة غير مرتّبة من المزوّدين. بعد v=spf1، تُقيَّم الآليات من اليسار إلى اليمين حتى تتطابق إحداها. ويتحكّم المؤهِّل البادئ في النتيجة: + تعني pass وهي الافتراضية، و- تعني fail، و~ تعني softfail، و? تعني neutral. تقارن آليتا ip4 وip6 عنوان العميل بعنوان أو شبكة. وتستعلم آليتا a وmx عن DNS، بينما تقيّم include سياسة SPF لنطاق آخر ولا تتطابق إلا وفق قواعد include. وتُجري exists اختبارًا قائمًا على DNS. أما all فتتطابق دائمًا وتُنهي السجل عادةً. تؤدي أخطاء الصياغة في أي موضع إلى permerror قبل التقييم العادي. ينبغي للأداة المفيدة أن تُبلغ عن الآلية التي تطابقت ومؤهِّلها وكل نطاق جرى توسيعه، بدلًا من إرجاع شارة ملوّنة فقط.

تتبّع include وredirect دون معاملتهما كأسماء مستعارة

تتبّع كل include وredirect ضمن سياق التقييم نفسه. include آلية: فهي تسأل عمّا إذا كانت السياسة المُضمَّنة تُرجع pass للعميل والمُرسِل الحاليين، ثم تواصل في السجل الأصلي إذا لم تتطابق. أما redirect فهو معدِّل يُنظر فيه بعد أن تفشل آليات السجل الحالي في التطابق؛ وهو ينقل التقييم إلى سياسة أخرى مع الإبقاء على عنوان IP للعميل والمُرسِل. ويُتجاهل redirect إذا ظهرت all في أي موضع من السجل. لهذه الفروق أهمية أثناء عمليات الترحيل. فاستبدال include:vendor.test بـ redirect=vendor.test قد يستبدل سياسة الاحتياط الكاملة لمالك النطاق بدلًا من مجرد إضافة مزوّد. اكتشف الحلقات الدائرية والأهداف المفقودة والأهداف غير الصالحة والأخطاء المتداخلة الدائمة أو المؤقتة، واحتفظ بسلسلة الاعتماديات في النتيجة حتى يظهر أي تغيير في السياسة من جهة المزوّد.

احسب ميزانية استعلامات DNS كاملة

احسب المصطلحات التي تستدعي استعلامات DNS عبر التقييم التعاودي كاملًا، لا في السجل الأعلى فقط. يحدّ RFC 7208 مصطلحات include وa وmx وptr وexists وredirect بعشرة مصطلحات خلال تقييم SPF واحد؛ وتجاوز هذا الحد يستوجب permerror. لا تستهلك آليات all وip4 وip6 من هذه الميزانية. ولمعالجة MX وPTR حدود إضافية لاستعلامات العناوين. كما يوصي الـ RFC بقصر الاستعلامات الفارغة، أي الإجابات الناجحة الفارغة أو أخطاء الاسم، على اثنين، وإنتاج permerror عند تجاوز هذا الحد. ولا يُنصح باستخدام آلية ptr لأنها بطيئة وغير موثوقة. قد يبدو السجل قصيرًا بينما تتوسّع عمليات include الخاصة بالمزوّدين إلى مصطلحات متداخلة كافية لإفشاله، لذا أبلغ عن المجموع وكل مصطلح مساهم والاستعلامات الفارغة والفرع الدقيق الذي سُلك لعنوان IP المُختبَر.

فسّر نتيجة SPF دون المبالغة فيها

استخدم مفردات النتائج القياسية. تعني pass أن العميل المُختبَر مفوَّض باستخدام هوية SMTP التي فُحصت. وتعني fail أنه عُثر على تفويض سلبي مطابق. وsoftfail بيان سلبي ضعيف، بينما تعني neutral أن النطاق لا يقدّم أي تأكيد بشأن ذلك العميل. وتعني none عدم وجود سجل SPF مختار. وتعكس temperror مشكلة تقييم عابرة، غالبًا في DNS؛ وتعكس permerror سياسة لا يمكن تقييمها بشكل صحيح. إذا لم تتطابق أي آلية ولم ينطبق أي redirect، تكون النتيجة neutral، وهي تعادل ?all ضمنية. أبلغ عن النتيجة مع الهوية وعنوان IP للعميل والحدّ المطابق وتتبّع DNS والوقت. لا تترجم pass إلى رسالة آمنة أو بريد مرغوب أو قبول لدى المزوّد أو تسليم إلى صندوق البريد أو وصول إلى صندوق الوارد، لأن SPF لا يحدّد هذه النتائج.

افحص رسالة حقيقية، لا السجل المنشور فقط

يجيب الفحص الثابت للسجل عن سؤال ما إذا كان يمكن اكتشاف السياسة وتحليلها. لكنه لا يثبت أن التطبيق استخدم نطاق MAIL FROM أو عنوان IP الصادر المتوقَّعين. أرسل رسالة مضبوطة عبر كل مسار إنتاج حقيقي إلى حساب مستلِم تديره أنت، ثم افحص الترويسات المستلَمة. قارن عنوان IP المتصل ومُرسِل الظرف وإدخال Authentication-Results لدى المستلِم بتقييم DNS. كرّر ذلك لكل مزوّد ومنطقة ومجموعة IP مخصصة أو مشتركة ومسار احتياطي وفئة رسائل يمكن أن تغيّر مسار الإرجاع. احتفظ بالترويسات في تخزين مقيّد لأن العناوين وتفاصيل التوجيه قد تكون حساسة. إذا تعارضت لوحة تحكم المزوّد مع الرسالة المستلَمة، فالرسالة دليل أقوى على المسار الذي جرى فعلًا، مع أن نتيجة مستلِم واحد لا ينبغي تعميمها على سلوك التسليم في كل مكان.

قيّم محاذاة DMARC كخطوة مستقلة

قد ينجح SPF لنطاق مسار إرجاع يملكه المزوّد بينما يظل DMARC عاجزًا عن استخدام هذه النتيجة. تقارن قواعد DMARC الحالية نطاق RFC5321.MailFrom الذي نجحت مصادقة SPF له بنطاق المؤلِّف في حقل RFC5322.From الظاهر. تتطلب المحاذاة الصارمة نطاق DNS نفسه. وتسمح المحاذاة المرنة بالنطاقات التي تؤول إلى النطاق التنظيمي نفسه وفق قواعد الاكتشاف في DMARC. على سبيل المثال، يمكن أن يتحاذى bounces.example.test وexample.test في الوضع المرن، بينما لا يتحاذى bounce.provider.test وexample.test. ويمكن لنتيجة DMARC أن تعتمد بدلًا من ذلك على توقيع DKIM محاذٍ وموثَّق، لذا فإن نتيجة SPF غير المحاذية لا تعني بذاتها فشل DMARC. أبلغ عن المصادقة والمحاذاة بشكل مستقل، واستخدم إجراء اكتشاف النطاق الحالي بدلًا من مقارنة ثابتة لآخر مقطعين من الاسم.

اختبر إعدادات MAIL FROM الخاصة بكل مزوّد

يحدّد إعداد المزوّد هوية SPF التي تظهر فعليًا أثناء النقل. فعلى سبيل المثال، يوثّق Amazon SES نطاق MAIL FROM مخصصًا يحتاج إلى سجل MX وسجل SPF من نوع TXT خاصين به. ويمكن لـ SES الرجوع إلى نطاق MAIL FROM على amazonses.com يعتمد على المنطقة عندما يكون سجل MX للنطاق المخصص مضبوطًا بشكل خاطئ، أو رفض الإرسال، بحسب السلوك المضبوط. وقد يغيّر هذا الرجوع محاذاة DMARC حتى إن لم يتغيّر عنوان From الظاهر. لأي مزوّد، سجّل نطاق مسار الإرجاع المضبوط وقيم DNS المطلوبة وسلوك الرجوع ومناطق الإرسال والملكية. بعد أي تغيير في DNS أو المزوّد، انتظر حتى تنتهي صلاحية الإجابات المخزّنة مؤقتًا ذات الصلة، ثم كرّر تقييم DNS والإرسال المضبوط. لا تنسخ include خاصًا بمزوّد إلى نطاق From الظاهر ما لم يكن هو الهوية الفعلية ويدعمه جرد المُرسِلين الكامل للنطاق.

استخدم تدقيقًا قابلًا للتكرار لـ SPF أثناء التغييرات

احتفظ بصف واحد لكل مسار إرسال يتضمّن المالك والتطبيق وفئة الرسائل ونطاق From الظاهر ونطاق MAIL FROM ونطاق HELO ونطاقات المصدر المتوقعة واعتمادية المزوّد ووقت آخر اختبار مضبوط. خزّن كل فحص SPF مع السجل المختار والتتبّع التعاودي وعدد استعلامات DNS والآلية المطابقة والنتيجة وقرار المحاذاة ومعرّف اختبار غير حساس. أثناء الترحيل، أبقِ المصادر المشروعة القديمة والجديدة مفوَّضة لنافذة الانتقال المطلوبة فقط، وتحقّق من المسار الجديد، ثم أزل التفويض القديم عن قصد. راقب أخطاء المصادقة الدائمة والمؤقتة بدلًا من الاكتفاء بالتفاعل مع حالات الرفض. أعِد تشغيل التدقيق بعد تغييرات المزوّد أو نقل مجموعات IP أو تغيير النطاقات أو تعديلات DNS أو إضافة تطبيقات جديدة. يلتقط سير العمل هذا السياسات الضيقة جدًا التي تحظر مسارات مشروعة، والسياسات الواسعة جدًا التي تُبقي على تفويض غير مستخدم.

افحص SendHQ بمعيار الأدلة نفسه

توثق SendHQ أن الإرسال المباشر يجب أن يستخدم عنوانًا على نطاق مساحة عمل موثَّق. يثبت ذلك هوية المُرسِل، لكنه لا يغني عن تقييم SPF. تحتاج رسالة SendHQ مضبوطة إلى تتبع DNS نفسه وفحص الترويسة المستلمة ونتيجة SPF وفحص محاذاة DMARC الموضحة أعلاه.

الأسئلة الشائعة

المصادر

• RFC 7208: Sender Policy Framework — IETF
• RFC 5321: Simple Mail Transfer Protocol — مرجع IETF
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance — مرجع RFC Editor
• استخدام نطاق MAIL FROM مخصص في Amazon SES — Amazon Web Services
• عقد OpenAPI الخاص بـ SendHQ — SendHQ