لقد تعلمت عن SPF بالطريقة الصعبة — قمت بتحويل نطاق الإنتاج من softfail إلى hardfail في ظهر يوم جمعة وشاهدت تدفق البريد الإلكتروني يختفي بالكامل. اتضح أنني نسيت بعض الأحداث التي أنشأتها قبل أشهر على منصة معينة. هذا الخطأ علمني شيئًا حاسمًا: قبل أن تعدل سجل SPF الخاص بك، عليك أن تعرف كل مكان يُرسل منه البريد، وعليك أن تتحمل العواقب إذا أخطأت.

دعني أشرح ما يهم حقًا هنا. SPF (Sender Policy Framework) هو بشكل أساسي إبلاغ نطاقك لخوادم الاستقبال: إليك سجل DNS TXT الخاص بي الذي يوضح أي المضيفين يمكنهم إرسال البريد بشكل شرعي نيابة عني. عندما يصل بريد إلكتروني، يتحقق المستلم من سجل SPF الخاص بك مقابل نطاق Return-Path، ويقيم آلياتك (ip4، ip6، a، mx، include)، ويقرر ماذا يفعل. يعتمد القرار على شيء واحد: المؤهل الذي تختاره في النهاية — الوضع الذي تختاره.

إليك الفرق الأساسي الذي يربك الناس. softfail (~all) يقول "هذا يبدو غير مصرح به، لكن ربما يكون مقبولًا — تابع بحذر." عادةً ما يؤدي ذلك إلى تصفية البريد المزعج، وليس الرفض التام. أما hardfail (-all) فيقول "فقط المضيفون الذين ذكرتهم هم الشرعيون — احظر كل شيء آخر." إنه حاسم، وعندما يتوافق مع DMARC، تحصل على رفض حقيقي للرسائل.

أفكر في الأمر كالفرق بين البيئة التجريبية والإنتاجية. softfail هو وضع الاختبار الحذر أثناء محاولة فهم الأمور. hardfail هو كإيقاف التيار في الإنتاج وتحمل العواقب.

النهج العملي الذي أتبعه هو منهجي: أبدأ بـ ?all للمراقبة الصافية، ثم أتحول إلى softfail (~all) بمجرد أن أبدأ في مراقبة تقارير تجميع DMARC، ثم أتحول إلى hardfail (-all) فقط بعد أن أتحقق من كل مرسل مخول وأن الإيجابيات الكاذبة تكاد تكون معدومة. لا أستعجل أبدًا في ذلك. أعمل على جرد كل شيء — CRM، أتمتة التسويق، التذاكر، الموارد البشرية، الفوترة، وحتى الأشياء الغريبة مثل الطابعات. أؤكد من يدير كل تغيير.

شيء واحد قد يسبب لك مشكلة بسرعة: SPF لديه حد صارم وهو 10 استعلامات DNS. رأيت أشخاصًا يداخلون include بشكل متداخل لدرجة أنهم يصلون إلى هذا الحد فجأة، ثم يتعطل كل شيء. قم بتبسيط includes، ويفضل نطاقات IP على السلاسل المتداخلة، وقم بتنظيف الخدمات غير المستخدمة. إذا كان المرسل الجماعي يدور عناوين IP باستمرار، اطلب منهم تضمين ثابت مع اتفاقيات مستوى الخدمة (SLAs).

إعادة التوجيه (Forwarding) مشكلة أخرى. فهي تكسر SPF لأن عنوان IP المتصل يتغير. إذا كان الموجه يستخدم SRS (Sender Rewriting Scheme)، فالأمر جيد. إذا لم يكن كذلك، فإن softfail قد يكون الشيء الوحيد الذي يمنع الضرر غير المقصود. لهذا السبب أ leaning أكثر على DKIM و DMARC لتحقيق التوافق في تلك الحالات.

قائمة التحقق من التنفيذ الواقعي التي قمت بتحسينها مع الوقت: خريطة كل خادم بريد وسير العمل، والتحقق من DKIM في كل مكان، وتمكين DMARC على p=none لجمع البيانات، وتحويل SPF إلى softfail ومراقبته على الأقل خلال دورتين إرسال، والتحقيق في كل مرسل غير مصرح به إما لمنحه إذنًا أو إيقاف التدفق، ثم تنفيذ سياسة رفض تدريجية مع تطبيق DMARC قبل الانتقال إلى hardfail. الخطوة الأخيرة — الانتقال إلى hardfail فقط عندما يكون تغطية المرسلين الشرعيين كاملة — غير قابلة للتفاوض.

شيء آخر لاحظته: جوجل وياهو قد شددا معاييره بشكل كبير. الآن، تنفيذ سياسة البريد الإلكتروني يجمع بين وضع SPF، توقيعات DKIM، سياسة DMARC، تحليل المحتوى، وتقييم السمعة. لهذا السبب لا أتعامل مع SPF بشكل مستقل أبدًا. فشل SPF في وضع hardfail بدون دعم DKIM قوي يمكن أن يضر بالتوصيل إذا كان إعادة التوجيه شائعًا في بيئتك.

أكبر الأخطاء التي أراها الناس يرتكبونها: تداخل includes حتى يتجاوزوا حد 10 استعلامات DNS، نسيان البائعين الموسميين الذين يرسلون باسم نطاقك، الاعتقاد أن DMARC سينقذك من إعداد SPF المكسور، الاعتماد على softfail إلى الأبد مع تكيف المهاجمين، أو الانتقال إلى hardfail قبل أن يكون DKIM مفعلاً في كل مكان. الأخير خاصة — جيد للأمان، لكنه كارثي على التوصيل عند وجود إعادة توجيه كثير.

إذا كنت تستخدم softfail الآن وتتساءل عما إذا كان ينبغي عليك الانتقال، فالجواب: فقط عندما تكون مستعدًا. هل قمت بالتحقق من كل مرسل؟ هل DKIM متوافق؟ هل الإيجابيات الكاذبة تكاد تكون معدومة؟ إذا كانت الإجابة نعم على الثلاثة، فإن hardfail منطقي. إذا لم تكن، فابقَ صبورًا. softfail ليست حالة دائمة — إنها نقطة تفتيش. ويجب أن تنفذ سياسة الرفض التدريجي مع تطبيق DMARC قبل أن تنتقل إلى hardfail. تلك الخطوة الأخيرة — الانتقال إلى hardfail فقط عندما يكون تغطية المرسلين الشرعيين كاملة — غير قابلة للتفاوض.