فشل SPF: رموز الخطأ والأسباب وطريقة إصلاح DNS

ارتدت رسالتك. تظهر الترويسات spf=fail. وأمامك خطأ 550 5.7.1 أو 550 5.7.26، بينما ينتظر عميل ردا لم يصل قط.

لا يعني فشل SPF وجود مشكلة في المحتوى، بل فشل مصادقة DNS. فحص خادم البريد المستلم سجل SPF، ووجد أن عنوان IP المرسل غير مدرج ضمن العناوين المصرح لها، فرفض الرسالة قبل وصولها إلى مجلد الرسائل المزعجة.

منذ فبراير 2024، قد ترفض Google وYahoo البريد غير الموثق على مستوى البروتوكول بدلا من الاكتفاء بتمييزه كمشبوه. يفسر هذا الدليل رمز الخطأ المحدد، ويوضح موضع عنوان IP المخفق في الترويسات، ويشرح إصلاحات DNS الثلاثة التي تعالج الغالبية الكبرى من حالات فشل SPF. لا تخمن؛ ابدأ بالإصلاح المناسب.

إذا كنت تعد البريد على نطاقك للمرة الأولى، فاضبط إعداد DNS الأساسي قبل تشخيص الأعطال. فكثيرا ما ترجع مشكلات SPF إلى إعداد أولي غير مكتمل.

ما فشل SPF؟

يحدث فشل SPF عندما يقيم خادم البريد المستلم سجل Sender Policy Framework لنطاقك ويجد أن عنوان IP المرسل غير مصرح له. ينشر SPF كسجل DNS TXT على النطاق، ويسرد كل عنوان IP وخدمة بريد مسموح لهما بالإرسال نيابة عنك. عند فشل الفحص، يرفض الخادم الرسالة مباشرة (hard fail) أو يقبلها بوصفها مشبوهة (soft fail). وفي الحالتين تعدها سياسة DMARC فشلا.

يفحص SPF مرسل المغلف، أي عنوان MAIL FROM المتفق عليه أثناء مصافحة SMTP، لا ترويسة "From" الظاهرة للمستلم. وهذا الفرق مهم عند تتبع موضع الخلل.

اقرأ رمز الخطأ قبل تغيير أي شيء

تعيد خوادم البريد رموز SMTP مختلفة عند فشل SPF. يخبرك الرمز بما قرره المستلم وسببه؛ ومعاملة 550 5.7.26 مثل 550 5.7.1 عام تهدر وقت التشخيص. طابق الرمز مع السبب قبل تعديل أي سجل DNS.

الخطوة 1: اعثر على عنوان IP المخفق في الترويسات

لا تخمن عنوان IP الذي سبب فشل SPF. افتح الترويسات الخام للرسالة المرتدة أو إشعار الارتداد وابحث عن Authentication-Results. تعرض هذه الترويسة عنوان IP الذي قيمه المستلم والقرار الذي اتخذه.

Authentication-Results: mx.google.com;
   spf=fail (google.com: domain of team@example.com does not designate
   192.0.2.55 as permitted sender)

تجد هناك معلومتين للتحقيق: عنوان IP المرسل (192.0.2.55) والنطاق الجاري فحصه (example.com). حدد الآن مالك ذلك العنوان:

• أداة SaaS أضفتها مؤخرا؟ (HubSpot, Zendesk, Shopify)
• خادم الويب؟ (WordPress, cPanel)
• خدمة إعادة توجيه؟ (راجع قسم فخ إعادة التوجيه أدناه)

ثم تحقق من سجل SPF الحالي ببحث سريع:

dig +short txt yourdomain.com | grep spf

إذا رأيت أكثر من سطر يبدأ بـ v=spf1، فقد عثرت بالفعل على إحدى المشكلات.

الخطوة 2: إصلاحات فشل SPF الثلاثة الأكثر شيوعا

ترجع معظم الحالات إلى سبب من ثلاثة: include مفقود لمزود، أو سجل مكرر، أو تجاوز حد 10 عمليات بحث في DNS. اختر الإصلاح المطابق لما وجدته في الخطوة 1.

الإصلاح 1: include المفقود (فجوة المزود)

أضفت أداة بريد جديدة - HelpScout أو HubSpot أو Zendesk أو بريد Shopify للمعاملات - لكنك لم تحدث DNS. ترسل الخدمة نيابة عنك بعنوان IP لم تصرح له. وهذا سبب شائع جدا لفشل SPF بعد إضافة مزود جديد.

السجل المخفق:

v=spf1 include:spf.trekmail.net -all

السجل الناجح (بعد إضافة HelpScout):

v=spf1 include:spf.trekmail.net include:helpscoutemail.com -all

ابحث في وثائق المزود عن نص SPF include المطلوب. أضفه إلى سجل SPF TXT الحالي ولا تنشئ سجلا جديدا. يجب إدراج كل خدمة ترسل من خلالها.

الإصلاح 2: السجل المزدوج (خطأ بنية قاتل)

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

خطأ - سجلان منفصلان:

v=spf1 include:spf.trekmail.net -all
v=spf1 include:_spf.google.com -all

صحيح - مدمجان في سجل واحد:

v=spf1 include:spf.trekmail.net include:_spf.google.com -all

سجل الدخول إلى مزود DNS، واحذف كل سجلات SPF TXT ما عدا واحدا، وادمج كل شيء في سطر واحد. يسبب PermError الناتج من سجل مزدوج فشلا صامتا لكل المرسلين حتى تصلحه.

الإصلاح 3: حد 10 عمليات بحث (فشل البنية)

يقصر RFC 7208 تقييم SPF على 10 عمليات بحث DNS لمنع استخدام الخوادم في تضخيم DNS. تحتسب آليات مثل include وa وmx ضمن الحد، وكذلك include المتداخلة التي يضمن فيها مزودك سجل مزود آخر.

إذا تجاوزت 10 عمليات تحصل على PermError ويفشل SPF للجميع. تتبع سجلك لمعرفة العدد الحالي:

dig +short txt yourdomain.com

احسب يدويا كل آلية include وa وmx، ثم تتبع include المتداخلة لكل مزود. إذا تجاوزت الحد، فهناك نهجان واضحان:

1. قسم المرسلين إلى نطاقات فرعية. انقل أدوات التسويق كثيفة الإرسال إلى marketing.yourdomain.com. يحصل النطاق الفرعي على حد مستقل جديد من 10 عمليات بحث، منفصل تماما عن سجل النطاق الرئيسي.
2. سطح السجل. استبدل سلاسل include بعناوين IP الفعلية التي تشير إليها باستخدام ip4: أو ip6:. لا تحتسب هذه كعمليات بحث. المقابل هو تحديث السجل يدويا عندما يغير المزود عناوينه.

هناك أيضا حد عمليات البحث الفارغة. إذا أعادت أكثر من عمليتين في السلسلة NXDOMAIN - بسبب خطأ مثل include:spf.gogle.com مثلا - يبطل السجل وفقا لـ RFC 7208 §11.1. قد يعطل خطأ واحد في أي include متداخلة تقييم SPF كله.

فخ إعادة التوجيه: لماذا يفشل SPF لبريد مشروع

قد يحدث فشل SPF لا علاقة له بإعداد DNS. ترسل إلى عنوان خريج (alice@university.edu) يعيد التوجيه تلقائيا إلى Gmail (alice@gmail.com). ترى Gmail الرسالة واردة من عنوان IP لخادم الجامعة، ولا يصرح سجل SPF الخاص بك لذلك العنوان. يفشل SPF رغم أنك نفذت الإعداد بصورة صحيحة.

المسار: خادمك → خادم الجامعة → Gmail. الفحص: تقيم Gmail المحطة الأخيرة. لا يمكن إصلاح فشل إعادة التوجيه عبر SPF لأنه يصرح فقط لعنوان الإرسال الأصلي. وبمجرد دخول وسيط إعادة التوجيه ينكسر فحص IP.

الإصلاح الصحيح هو DKIM. يوقع DKIM متن الرسالة وترويساتها تشفيريا. لا يغير وسيط إعادة التوجيه المتن عادة، فتظل التوقيعة صالحة بعد الترحيل. وحتى مع فشل SPF، قد تبقي توقيعة DKIM الصالحة الرسالة مقبولة لدى DMARC.

إذا كنت تدير إعادة توجيه على مستوى البنية وتريد إعادة كتابة متوافقة مع SPF، فمن المفيد فهم Sender Rewriting Scheme (SRS). فهو يتيح للوسطاء إعادة كتابة مرسل المغلف كي ينجح SPF في الوجهة النهائية. أما حالات فشل التسليم الأوسع، فيغطي دليل إعداد إعادة توجيه البريد وإصلاحها مسار التشخيص الكامل.

تحقق من الإصلاح قبل المتابعة

بعد تحديث سجل DNS انتظر الانتشار، وهو عادة 5 إلى 30 دقيقة لدى معظم المزودين وقد يصل إلى ساعات قليلة في بعض الحالات. ثم تأكد من وصول التغيير قبل اعتبار العمل منجزا.

أرسل رسالة اختبار إلى Gmail وافتح الترويسات الخام. ابحث عن Authentication-Results. تريد رؤية الآتي:

Authentication-Results: mx.google.com;
   spf=pass (google.com: domain of team@example.com designates
   192.0.2.55 as permitted sender)

إذا بقي spf=fail أو spf=softfail، فإما أن التغيير لم ينتشر بعد أو أن السجل ما زال يحوي مشكلة. قارن عنوان IP في الترويسات بما في السجل المحدث. يجب أن يتطابقا.

يمكنك أيضا التحقق من السجل مباشرة:

dig +short txt yourdomain.com

تأكد من وجود سجل واحد بالضبط يبدأ بـ v=spf1، ومن إدراج كل خدمات الإرسال، ومن انتهاء السجل بـ -all (hard fail) أو ~all (soft fail).

إدارة SPF عبر نطاقات متعددة

إدارة SPF لنطاق واحد مهمة تنفذ مرة: أضف include وادمج المكرر واضبط عدد عمليات البحث. لكن عند إدارة بريد 10 أو 50 أو 500 نطاق، لكل منها سجله ومزودو SaaS الخاصون به، يصبح تشخيص كل فشل يدويا عبئا تشغيليا حقيقيا.

يختصر SMTP المدار من TrekMail - المتاح في Starter بسعر $3.50/شهر فما فوق - الإعداد إلى include واحدة لكل نطاق. تدير TrekMail تدوير IP ومراقبة الارتداد ومحاذاة DKIM وبنية التسليم الأساسية. ويمكن للوكالات في خطة Agency ($23.25/شهر) تطبيق قالب DNS موحد على كل نطاقات العملاء بدلا من تعقب أخطاء SPF في مئات السجلات.

ابدأ تجربة مجانية لمدة 14 يوما إذا أردت معاينة التسليم المدار عمليا.

فشل SPF: الخلاصة

يعني فشل SPF أن الخادم المستلم فحص DNS ووجد أن عنوان IP المرسل غير مدرج وطبق سياستك. يعني hard fail (-all) الرفض. ويعني soft fail (~all) مجلد المزعج. ويعني PermError أن السجل معطوب وأن SPF يفشل لكل المرسلين حتى تصلح السجل نفسه.

نفذ الإصلاحات بالترتيب:

1. اعثر على عنوان IP المخفق في ترويسة Authentication-Results
2. أضف include المزود المفقودة إذا سببت خدمة جديدة فشل SPF
3. ادمج سجلات SPF المكررة في سجل واحد
4. اخفض عمليات بحث DNS إلى أقل من 10 أو قسم المرسلين كثيفي الإرسال إلى نطاقات فرعية
5. إذا فشل SPF في بريد معاد توجيهه، فطبق DKIM؛ لا يستطيع SPF تجاوز محطة ترحيل

ابدأ بالإصلاح الصحيح، وتحقق بالترويسات، ثم أنه العمل.