لماذا يفشل سجل SPF لديك مرارًا، وكيف تُصلحه

ما يتحقق منه SPF فعلًا

إطار SPF – Sender Policy Framework – هو سجل TXT على نطاقك يسرد الخوادم المسموح لها بإرسال البريد باسمك. يقرأ الخادم المستقبِل هذا السجل، ويقارنه بعنوان IP الذي اتصل للتو، ثم يقرّر ما إذا كان الاتصال مصرّحًا به.

تفصيلان عمّا يقارنه يفسّران معظم الالتباس حول SPF:

• يتحقق SPF من مُرسِل المغلّف، لا من عنوان From: الذي يراه مستلمك. فمُرسِل المغلّف (MAIL FROM في محادثة SMTP، ويُسمّى أيضًا مسار العودة) غير مرئي في برنامج البريد. يمكن لرسالة أن تمرّ في SPF وهي تعرض عنوان From: مختلفًا تمامًا ومزيّفًا – ولهذا لا يمنع SPF وحده انتحال الهوية.
• يتحقق SPF من عنوان IP المتصل، ولا شيء غيره. فهو لا يفحص الرسالة ولا الترويسات ولا المحتوى. سؤال واحد فقط: هل كان مسموحًا لهذا العنوان أن يتصل باسمك؟

لذلك لا يعني فشل SPF تقريبًا أبدًا أن سجلك مكتوب خطأً. بل يعني عادةً أن البريد خرج من مكان لا يسرده السجل، أو أن السجل لم يُمكن تقييمه بالكامل. وهاتان مشكلتان مختلفتان بحلّين مختلفين، وبقية هذا الدليل تفصل بينهما.

كيف تقرأ سجل SPF الخاص بك

سجل SPF سطر واحد من TXT، وهو مقروء بسهولة متى عرفت أجزاءه الأربعة.

الآليات: من المسموح له

كل عنصر يضيف مُرسِلين مسموحين. ip4: وip6: تسرد العناوين أو النطاقات مباشرة. وa يصرّح لما يشير إليه سجل A لنطاقك. وmx يصرّح لخوادم بريدك. أما include: فهو الأهم عمليًا: يسحب سجل SPF الكامل لنطاق آخر، وبه تصرّح لـ Google أو Microsoft أو مرسل جماعي دون معرفة عناوينهم.

وinclude: تفويض لا نسخة. فالطرف الآخر يمكنه تغيير قائمته في أي وقت وسجلك يتبعه – وهذا هو المقصود، وهو أيضًا سبب احتمال انكسار سجلك دون أن تلمسه.

المُحدّدات: ما يحدث عند التطابق

قد تحمل كل آلية بادئة. فالعلامة + تعني المرور وهي الافتراضية، لذا فإن mx المجردة تعني +mx. والعلامة - فشل صارم: الرفض. و~ فشل مرن: القبول مع التمييز. و? محايدة: لا رأي، وهو ما يساوي عمليًا غياب أي سياسة.

العنصر all في النهاية

العنصر الأخير هو في الغالب آلية all، وهو يحدّد ما يحدث لكل مُرسِل لم يسرده السجل. فـ-all يقول: ارفض كل ما سوى ذلك. و~all يقول: اقبل مع التمييز. أما +all فيصرّح للإنترنت بأسره، وهو خطأ دائمًا.

ابدأ بـ~all ما دمت تكتشف من يرسل باسمك بشكل مشروع، ثم شدّد إلى -all حين تصبح تقارير DMARC نظيفة. والانتقال مباشرة إلى -all دون هذا الدليل هو ما يجعل نظام فواتير منسيًّا أو مكتب دعم يتوقف عن الوصول إلى أي أحد.

سجل واحد بالضبط، بلا استثناء

يمكن للنطاق أن ينشر سجل SPF واحدًا. وسجلان من نوع TXT يبدأان بـv=spf1 يعنيان permerror، وهذا الخطأ يعني أن التحقق لا يمكن تقييمه إطلاقًا – وعند مستقبِل صارم فذلك أسوأ من فشل عادي. ويحدث هذا كثيرًا: فمعالج إعداد مزوّد جديد يضيف سجله الخاص بدل تعديل سجلك. ودمجهما يعني سجلًا واحدًا يحمل مجموعتي الآليات، لا سجلين.

حدّ الاستعلامات العشرة، القاتل الصامت

هذا أكثر سبب شيوعًا لسجل SPF يبدو مثاليًا ويفشل مع ذلك.

يحدّ المعيار تقييم SPF بـعشرة استعلامات DNS. فكل include: وa وmx و ptr وexists: يكلّف واحدًا – والاستعلامات داخل كل سجل مُضمَّن تُحسب أيضًا. فعنصر include: يحتوي بنفسه على ثلاثة عناصر يكلّف أربعة من عشرتك. وتجاوز الحدّ يعني permerror: لا فشلًا، بل سجلًا غير قابل للتقييم، وكثير من المستقبِلين يعاملونه كغير موثَّق.

وما يجعله سيئًا أنه غير مرئي وينمو بنفسه. فسجلك كان يمرّ يوم كتبته. وبعد أشهر أضاف أحد مزوّديك عنصر include: إلى سجله، فتجاوز إجماليك العشرة، وبدأ بريدك يُوسَم دون أن يتغير شيء من جهتك. والعناصر ip4: وip6: لا تكلّف استعلامات، وهي الرافعة الأساسية بيدك.

عُدّ استعلاماتك قبل أن تفترض أن السجل سليم. استعلم عن سجل TXT لنطاقك، ثم عن سجل كل نطاق مُضمَّن، واستمر حتى لا يبقى ما يُفكّ. وتجعل أداة استعلام DNS ذلك سريعًا: اطّلع على سجل TXT، ثم تابع كل include: واحدًا بعد آخر.

لماذا يفشل البريد والسجل يبدو صحيحًا

إذا كان السجل صحيح الصياغة وداخل حدّ الاستعلامات، فامضِ في هذه بالترتيب.

• شيء يرسل من خدمة غير مسرودة. المشتبهون المعتادون: نظام إدارة علاقات العملاء، أو نظام فواتير أو تذاكر، أو منصة تسويق، أو أداة مراقبة، أو خادم تطبيق يرسل عبر عامل البريد المحلي لديه. وكل منها يحتاج include: أو نطاق عناوينه.
• مُرسِل المغلّف نطاق آخر. فالمنصة التي ترسل «بالنيابة عنك» تستخدم غالبًا مسار عودة خاصًا بها، فيُفحص SPF على نطاقها ويمرّ، بينما يظل اصطفاف DMARC عندك فاشلًا. يمكن أن تكون الرسالة موثَّقة وغير مصطفّة في الوقت نفسه.
• نطاق فرعي بلا سجل خاص. فـ SPF لا يُورَّث. والبريد من mail.example.com يُفحص على هذا الاسم بالضبط، وبلا سجل TXT تكون النتيجة none، لا سياسة الجذر لديك. انشر سجلًا لكل نطاق فرعي مُرسِل، وv=spf1 -all فارغًا على النطاقات الفرعية التي لا ينبغي أن تُرسل أبدًا.
• تغيّر السجل ولم تلحق ذاكرات التخزين. فسجل TXT لديك يحمل مدة TTL مثل أي سجل آخر، والإصلاح لا يسري في كل مكان لحظة الحفظ – كيف تعمل مدة TTL والانتشار يتناول التوقيت.
• عنصر include: قديم. فمزوّد توقفت عن استخدامه ولم يعد نطاقه يُحلّ قد ينتج permerror، وليس من مصلحة أحد أن يخبرك.

التحويل يكسر SPF بحكم التصميم

هذا ليس خطأك ولا يمكن إصلاحه في سجلك، فيستحق أن تفهمه قبل أن تنفق عليه يومًا.

عندما يحوّل مستلم رسالتك – عبر عنوان جامعي، أو قاعدة .forward، أو قائمة بريدية – يتصل الخادم المحوِّل بالجهة النهائية بعنوان IP الخاص به مع إبقاء نطاقك مُرسِلًا للمغلّف. فيفحص المستقبِل سجل SPF لديك على عنوان لم تسمع به قطّ، فيفشل. وبحق: فذلك العنوان ليس مصرّحًا به منك فعلًا.

وهناك إجراءان للتخفيف، وليس أيٌّ منهما تغييرًا في SPF. فـDKIM يوقّع الرسالة تعميًا وينجو من التحويل، فيمكن لرسالة محوَّلة فشلت في SPF أن تمرّ في DKIM وبالتالي في DMARC – وهذا السبب الرئيسي لتشغيل الاثنين. وSRS (مخطط إعادة كتابة المُرسِل) مهمة الجهة المحوِّلة: فهي تعيد كتابة مُرسِل المغلّف إلى نطاقها ليُفحص SPF عليها. ولا يمكنك إلزام محوِّل بعيد بذلك.

الخلاصة العملية: لا تشخّص SPF أبدًا من نسخة محوَّلة من رسالة، ولا تنتقل إلى -all على افتراض أن كل فشل تراه مهاجم.

مرور SPF ليس مرور DMARC

نتيجة pass في الترويسات مع استمرار فشل DMARC تُحيّر الجميع تقريبًا، والسبب هو الاصطفاف.

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

فـ SPF لم يكن يومًا دفاعًا عن انتحال الهوية: يمكن لمهاجم أن ينشر SPF صحيحًا تمامًا لنطاقه ويضع اسمك في حقل From: رغم ذلك. و DMARC هو ما يربط التوثيق بالعنوان الذي يراه المستلم فعلًا، وهو أيضًا ما يرسل إليك التقارير التي تبيّن من يرسل باسمك. دليل SPF و DKIM و DMARC يشرح كيف تتكامل الثلاثة وكيف تطبّق سياسة.

كيف تُصلح سجلًا يفشل

بهذا الترتيب، لأن كل خطوة تستبعد أسبابًا كانت الخطوات التالية ستحجبها.

• تأكّد من وجود سجل واحد بالضبط. استعلم عن سجلات TXT لديك وعُدّ كم منها يبدأ بـv=spf1. فأكثر من واحد هو permerror – ادمج الآليات في سجل واحد قبل أن تحقّق في أي شيء آخر.
• عُدّ الاستعلامات، بما فيها المتداخلة. إن كنت عند العشرة أو قريبًا منها، فاستبدل أثقل include: بنطاقات ip4: التي يُحلّ إليها، واحذف العناصر الخاصة بمزوّدين لم تعد تستخدمهم. وحذف عنصر واحد مهجور كفيل غالبًا بإعادة الإجمالي كله إلى ما دون الحدّ.
• احصر من يرسل باسمك فعلًا. تقارير DMARC المجمّعة هي المصدر الموثوق الوحيد هنا: فهي تسرد كل عنوان يرسل باسم نطاقك، بما في ذلك الأنظمة التي لا يتذكّرها أحد. والتخمين ينتج سجلًا ناقصًا.
• اترك ptr تمامًا. فهو مهجور وبطيء وغير موثوق، وبعض المستقبِلين يتجاهلون السجلات التي تستخدمه.
• ابقَ على ~all حتى تنظف التقارير، ثم انتقل إلى -all. فالفشل الصارم على سجل ناقص يُرجع بريدك أنت.
• خفّض مدة TTL قبل التعديل، ثم تحقّق من الخارج. اطّلع على سجل TXT المنشور فعلًا عبر أداة استعلام DNS بدلًا من الوثوق بلوحة DNS لديك، وأعد التحقق بعد انتهاء المدة القديمة.

أخطاء شائعة

• سجلا SPF لأن معالج إعداد مزوّد أضاف سجله. permerror، وهو أسوأ من الفشل.
• تجاوز الاستعلامات العشرة دون أن تعرف أبدًا، لأن الفشل permerror في سجلات غيرك.
• القفز إلى -all قبل معرفة كل مُرسِل مشروع. والنظام الذي نسيته هو عادةً الذي يصدر فواتير عملائك.
• توقّع أن ترث النطاقات الفرعية السياسة. لا ترثها. انشر سجلًا لكل نطاق فرعي مُرسِل.
• استخدام ptr، أو +all الذي يصرّح للجميع.
• التشخيص من رسالة محوَّلة. فالتحويل يفشل في SPF بحق ولا يقول شيئًا عن سجلك.
• افتراض أن مرور SPF يعني مرور DMARC. فبلا اصطفاف مع نطاق From: المرئي، لا يعني ذلك.
• تعديل السجل والاختبار فورًا. فالسجل القديم ما زال مخزّنًا طوال مدة TTL الخاصة به.

الخلاصة

يقارن SPF عنوان IP المتصل بسجل TXT واحد ويتحقق من مُرسِل المغلّف غير المرئي، لا من عنوان From: الذي يقرأه مستلمك. انشر سجلًا واحدًا بالضبط، وأبقِ إجمالي استعلامات DNS – بما فيها المتداخلة داخل كل include: – عند عشرة أو أقل، واسرد كل خدمة ترسل باسمك بشكل مشروع، وأعطِ كل نطاق فرعي مُرسِل سجله الخاص، وابقَ على ~all حتى تثبت تقارير DMARC أن القائمة كاملة. وسيفشل البريد المُحوَّل في SPF مهما فعلت، ولهذا يوجد DKIM و DMARC إلى جانبه. اقرأ سجل TXT المنشور لأي نطاق، وفُكّ كل include:، واطّلع على المدة المتبقية عبر أداة البحث في DNS المجانية.

أدوات وأدلة ذات صلة:

• بحث DNS — استعلم عن سجلات A وAAAA وMX وTXT وNS والمزيد بالقيم وTTL، بالإضافة إلى DNS العكسي.
• كيف تقرأ تقرير DMARC دون أن تغرق في XML — ما الذي يحتويه تقرير DMARC المجمّع

أسئلة شائعة