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

منذ ذلك الحين، أتعامل مع تغييرات SPF كما يتعامل الطيارون مع قوائم التحقق—بطريقة منهجية، مع وجود وسائل حماية، ودون استعجال أبدًا.

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

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

إليك الجانب العملي. مع الفشل الناعم، عادةً ما ترى وضع الرسائل في مجلد البريد المزعج أو الحجر الصحي. مع الفشل الصلب، خاصة عندما يكون هناك توافق DMARC، يمكنك أن تتلقى رفضًا مباشرًا عند خادم البريد. تميل Microsoft 365 و Outlook إلى دمج SPF مع DKIM ومرشحات المحتوى. جوجل وياهو يعتمدان بشكل كبير على DMARC وسمعة المرسل. لذا، قد ينتهي بك الأمر إلى وضع الرسائل في قسم العروض الترويجية مع الفشل الناعم؛ بينما مع الفشل الصلب وتوافق DMARC، يمكن أن يعني الحظر الحاسم.

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

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

لقد رأيت فرقًا تتجاوز حد 10 استعلامات DNS عبر التداخل المفرط في include. رأيتهم ينسون موردين موسميين مثل Livestorm أو Prismic Webhooks. وشاهدت أشخاص يظنون أن DMARC سينقذ سجل SPF المعطل—لن يفعل، ليس بدون التوافق.

الدرس الحقيقي: عامل SPF، DKIM، وDMARC كنظام، وليس كقطع منفصلة. إعادة التوجيه تكسر SPF لأن عنوان IP المتصل يتغير. إذا كنت تستخدم SRS )Sender Rewriting Scheme(، أنت بخير. وإذا لم تفعل، قد يكون الفشل الناعم هو كل ما يمنع الحريق الودي. لهذا أراقب تقارير DMARC بشكل مكثف وأقرأ رؤوس Authentication-Results عندما يفشل شيء.

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

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

أكبر خطأ أراه حتى الآن: أن الفرق تتبدل إلى الفشل الصلب قبل أن يصبح DKIM متاحًا بشكل كامل، أو يعتمدون على الفشل الناعم إلى الأبد بينما يتكيف المهاجمون ويزدهر انتحال البريد الإلكتروني في تلك الحالة الغامضة. إنها توازن، لكن الطريق واضح إذا كنت تتبعه بطريقة منهجية.