ما صيغة سجل SPF، وكيف تؤثر في بريد التطبيقات؟

سجل SPF تعبير سياسة مرتّب

يعرّف RFC 7208 سجل SPF بأنه سلسلة TXT في DNS أول عنصر فيها v=spf1. أما العناصر الباقية المفصولة بمسافات فهي آليات (mechanisms) قد تطابق، ومعدِّلات (modifiers) تغيّر المعالجة. يتقدم التقييم من اليسار إلى اليمين ويتوقف عند أول mechanism مطابق، لذلك يعبّر الترتيب عن السياسة. قد يفوّض سجل نموذجي نطاقي عناوين ثابتين، ويضمّن سياسة مزوّد واحد، ثم ينتهي بـ -all. لا تنسخ هذا النمط دون تعديل: فالسجل الصحيح يعتمد على هويات SMTP MAIL FROM أو HELO الدقيقة ومصادر الإرسال الحقيقية. اجرد أولًا مزوّدي التطبيقات وخوادم البريد وأدوات الدعم ومنصات الهوية وأنظمة التسويق ومسارات إعادة التوجيه ومُرسِلي التعافي من الكوارث. انشر السياسة عند النطاق الذي يجري تقييمه، وليس تلقائيًا عند نطاق From الظاهر. قد يظل سجل واحد سليم الصيغة يفوّض المصادر الخطأ أو يغفل مسار إنتاج أو يتجاوز حدود تقييم DNS.

تربط المؤهِّلات مطابقة الـ mechanism بنتيجة SPF

يمكن أن يبدأ الـ mechanism بمؤهِّل: + لـ pass، أو - لـ fail، أو ~ لـ softfail، أو ? لـ neutral. وإذا لم يظهر مؤهِّل فالمفترض هو +. ينطبق المؤهِّل فقط عندما يطابق ذلك الـ mechanism. ولا يغيّر ما إذا كانت العناصر اللاحقة تُقيَّم عندما لا يطابق الـ mechanism. تركّز الفرق غالبًا على عنصر all الأخير، لكن كل mechanism سابق من include أو عنوان أو a أو mx أو exists له أيضًا مؤهِّل ويمكن أن ينهي التقييم. استخدم مراجعة صريحة بدلًا من افتراض أن ‎~all يعني وضع الاختبار أو أن ‎-all يثبت أن كل المصادر معروفة. نتيجة fail دليل من الجهة المستقبِلة على هوية SMTP وعنوان IP اللذين جرى تقييمهما، وليست أمرًا عامًا بحذف البريد. تطبّق الجهات المستقبِلة سياستها المحلية. ولا تُعد neutral وsoftfail تفويضًا ناجحًا. سجّل النتيجة المقصودة للمصادر المصرّح بها وغير المصرّح بها وغير المحلولة مؤقتًا، وتحقق منها بعناوين IP وهويات اختبارية خاضعة للتحكم.

آليات العناوين مباشرة لكنها تتطلب ملكية

تفوّض الآليتان ip4 وip6 نطاقات الشبكة المطابقة المعبَّر عنها بصيغة كل بروتوكول مع طول بادئة اختياري. وهاتان الآليتان تتجنبان استعلام عنوان إضافي أثناء التقييم، لكنهما قد تتقادمان مع تغيّر شبكات الخروج. استخدم عناوين إرسال عامة، لا عناوين وقت تشغيل خاصة، وأبقِ النطاقات ضيقة قدر ما يسمح به التحويل عند الفشل تشغيليًا. ينبغي أن يكون لكل نطاق مالك ونظام مصدر وبيئة وإجراء تغيير وتاريخ مراجعة. وتحلّ الآلية a اسم A أو AAAA، وتكون افتراضيًا لنطاق SPF الحالي ما لم يُقدَّم domain-spec آخر. وتحلّ الآلية mx مضيفي MX وعناوينهم. تضيف هاتان الآليتان عمل DNS وقد تفوّضان بنية تحتية تتغير خارج إصدارات تطبيقك. لا تستخدم a أو mx اختصارًا ما لم يكن مسموحًا عن قصد لكل العناوين المحلولة بالإرسال بهوية SMTP تلك بالضبط. راقب التغييرات واختبر مساري IPv4 وIPv6 معًا.

يقيّم include سياسة أخرى، وليس مقطعًا نصيًا

تقيّم الآلية include سياسة SPF للنطاق المُشار إليه وتطابق عندما يعيد ذلك التقييم المتداخل pass. وهي لا تلصق العناصر ميكانيكيًا في السلسلة الحالية، وللنتائج المتداخلة الأخرى آثار معرَّفة. استخدم include فقط عندما توثّق المؤسسة المُشار إليها ذلك النطاق صراحةً لعلاقة الإرسال معك. نطاق موقع المزوّد أو نطاق MX أو نطاق From الظاهر ليس تلقائيًا include الخاص بـ SPF. تنشئ عمليات include اعتماديات تشغيلية: فقد يغيّر تعديل سجل المزوّد التفويض أو يضيف استعلامات DNS متداخلة أو ينتج أخطاء مؤقتة ودائمة. سجّل المورّد والخدمة ونطاق include الدقيق ومصدر العقد والمالك وخطة الإزالة. اختبر السياسة الناتجة من عنوان IP الإرسال الفعلي للمزوّد ونطاق الظرف لديك. لا تُسطّح (flatten) عمليات include للمزوّد إلى قوائم IP منسوخة ما لم تقبل أيضًا مسؤولية تتبع كل تغيير في عناوين المزوّد والحفاظ على الدلالات الأصلية.

لكل من all وredirect وexplanation دور مختلف

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

تجنّب ptr وتعامل مع exists والماكرو (macros) على أنها متقدمة

يقول RFC 7208 إنه لا ينبغي استخدام الآلية ptr لأنها بطيئة وغير موثوقة ومرهقة. لا تضف ptr لجعل IP غير مألوف ينجح. يمكن للآلية exists إجراء اختبار وجود في DNS باستخدام domain-spec، ويمكن لماكرو SPF توسيع مكونات الهوية والاتصال داخل الحقول المدعومة. تستطيع هذه الأدوات التعبير عن تفويض مفوَّض أو لكل عميل، لكنها تزيد التعقيد وعمل DNS وانكشاف الخصوصية وأنماط الفشل. صيغة الماكرو ليست قوالب سلاسل تعسفية؛ فالأحرف والمحوّلات والفواصل والسياقات المعرَّفة فقط هي الصالحة. لا تضع أبدًا عناوين مستلِمين كاملة أو أسرارًا أو مدخلات مستأجر غير محدودة في استعلامات DNS. وإذا كانت مجموعة بسيطة من نطاقات IP المملوكة وعمليات include الموثَّقة للمزوّدين تستطيع التعبير عن السياسة، ففضّلها. وفي السياسات المتقدمة، ابنِ ملفات اختبار حتمية لنطاقات ومُرسِلين وعائلات IP ومسارات إرجاع فارغة وتهريب الماكرو (macro escaping) وNXDOMAIN والمهلات وإجابات DNS غير المتوقعة قبل الإنتاج.

احترم حد عشرة عناصر تطلق استعلامات DNS

يحد RFC 7208 تطبيقات SPF بعشرة عناصر تسبب استعلامات DNS أثناء فحص واحد، بما فيها معالجة include وa وmx وptr وexists وredirect ذات الصلة. وتُحتسب عمليات include المتداخلة. كما يوصي المعيار بحصر استعلامات void، أي التي يعيد فيها DNS إجابة فارغة أو خطأ اسم، باثنين. وقد يؤدي تجاوز حدود المعالجة إلى خطأ دائم بدلًا من pass. احسب الرسم البياني الموسّع للتقييم، لا العناصر الظاهرة في سلسلة TXT العليا فقط. فقد يجلب include واحد من مزوّد عدة اعتماديات متداخلة، وقد تطلق الآلية mx استعلامات عناوين لعدة مضيفين. استخدم مقيِّمًا يراعي المعايير مع ملفات DNS مسجّلة للاختبار، لكن افحص شجرة الاعتماديات بنفسك أيضًا. أزل المزوّدين غير المستخدمين والآليات الزائدة. تجنّب التسطيح (flattening) غير الآمن الذي يفقد تحديثات المزوّد بصمت. راقب تغييرات السياسة واترك هامشًا من الاستعلامات لتطور المزوّدين بدلًا من النشر عند الحد الأقصى تمامًا.

انشر سياسة SPF واحدة بالضبط لكل نطاق

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

اربط صيغة SPF بـ DMARC دون الخلط بينهما

يقيّم SPF عادةً نطاق MAIL FROM أو هوية HELO وفق قواعد البروتوكول. أما DMARC فيستخدم نطاق RFC 5322 From الظاهر ويقبل SPF مسارًا واحدًا فقط عندما يحاذي نطاق SPF المصادَق عليه ذلك النطاق الظاهر. لذلك قد ينجح SPF على Return-Path الخاص بالمزوّد بينما يبقى غير محاذٍ لـ DMARC. وعلى العكس، يمكن لنجاح DKIM محاذٍ أن يحقق DMARC عندما يفشل SPF أو يكون غير محاذٍ. سجّل نتيجة SPF والنطاق المقيَّم وعنوان IP المتصل وFrom الظاهر ونتائج DKIM والمحاذاة ونتيجة DMARC بشكل منفصل. غالبًا ما تغيّر إعادة التوجيه عنوان IP المتصل وقد تكسر SPF حتى عندما كان المُرسِل الأصلي مصرّحًا به. لا توسّع SPF ليشمل جهات إعادة توجيه عشوائية. استخدم DKIM، وحيثما يناسب، آليات السلسلة الموثَّقة (authenticated chain) وأدلة الجهة المستقبِلة. نجاح SPF لا يثبت سلامة الرسالة ولا أمان المحتوى ولا موافقة المستلِم ولا قبول الخادم ولا الوصول إلى صندوق الوارد.

تحقق من التغييرات بسير عمل حتمي

قبل تعديل DNS، صدّر السجل الحالي وعدّد كل mechanism أو modifier مع مالكه وغرضه. حلّل السجل المرشح وفق قواعد RFC 7208، ووسّع اعتماديات DNS من لقطات خاضعة للتحكم، واحسب العناصر التي تسبب استعلامات، واختبر عناوين IPv4 وIPv6 مصرّحًا بها وغير مصرّح بها. افحص سلوك include المتداخل عند pass وfail وneutral وsoftfail والخطأ المؤقت والخطأ الدائم. اختبر معالجة مسار الإرجاع الفارغ (null reverse-path) عبر HELO، والنطاقات الفرعية، وReturn-Path الخاص بالمزوّد، ومصدر ينبغي أن يسقط إلى all. انشر عبر ضوابط التغيير المعتادة، واستعلم من خوادم DNS الموثوقة، ثم من محلّلات DNS التكرارية المستقلة، ثم أرسل رسائل خاضعة للتحكم عبر كل مسار حقيقي. احتفظ بـ Authentication-Results الخام من جهات مستقبِلة موثوقة وقارنها بالهويات المتوقعة. تراجع عند غياب مصادر إنتاج، أو اختيار عدة سجلات، أو أخطاء حد الاستعلامات، أو temperror واسع الانتشار، أو تفويض غير مقصود. لا تختبر أبدًا بإرسال بريد غير مطلوب.

هيّئ SPF مع SendHQ

يوفر SendHQ سياسة SPF TXT بوصفها جزءًا من إعداد هوية المُرسِل. ويوقف الإعداد عند وجود سياسات SPF متعارضة ويبلغ عن قيمة SPF مدمجة موصى بها بدلًا من الكتابة فوق سياسة غير مرتبطة بصمت. احتفظ بسياسة SPF واحدة قابلة للاختيار بالضبط؛ راجع وثائق النطاقات وDNS لتفاصيل الإعداد والإصلاح.

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

المصادر

• RFC 7208: إطار سياسة المُرسِل (SPF) — RFC Editor
• RFC 7489: مصادقة الرسائل والإبلاغ والامتثال على مستوى النطاق (DMARC) — محرّر RFC
• RFC 5321: بروتوكول نقل البريد البسيط (SMTP) — محرّر RFC