البريد المُوجَّه يفشل في SPF — لماذا لا يمكنك إصلاحه، وما الذي ينجح فعلاً (2026)

نُشر 2026-07-08

الأرقام بتاريخ 2026-06-29 · المنهجية v7. بيانات إحصاء مجمّعة عبر 261 مليون نطاق مُصنَّف. اطلع على طريقة التصنيف.

لا يمكنك إجبار SPF على النجاح للبريد المُوجَّه — التوجيه يكسر SPF بالتصميم، والإصلاح الصادق هو DKIM المتوافق الذي يصمد أمام التوجيه. الحجم واسع على مستوى الإحصاء: 7,355,985 من 138,927,207 نطاق ينشر SPF يُفوِّض include التوجيه الخاص بـ Namecheap وحده، مع نسبة SPF صارم بـ <0.1%، وفقاً لإحصاء Defaults.Exposed لـ 261 مليون نطاق.

أدناه: لماذا لا يصمد أي سجل SPF تكتبه أمام التوجيه، لماذا SRS وARC ليسا أدوات تتحكم فيها، والإصلاح الذي يثبت — توقيع DKIM بنطاقك الخاص كتجاوزك في DMARC — بالإضافة إلى الحالة الوحيدة التي تكسر DKIM أيضاً (القوائم البريدية التي تُعيد كتابة الرسائل) وما تفعله حيال هذا البقاء.

لماذا يكسر التوجيه SPF؟

يُقيِّم المستقبِلون SPF مقابل نطاق Return-Path (RFC5321.MailFrom)، لا ترويسة From. حين ترسل مباشرةً، IP خادمك موجود في سجل SPF الخاص بك ويجتاز الفحص. حين يُوجِّه متلقّيك الرسالة تلقائياً — إلى Gmail شخصي، عبر اسم بديل جامعي، أو عبر منتج توجيه مُسجِّل — يُعيد خادم المُوجِّه إرسالها، عادةً محتفظاً بنطاقك على Return-Path. يسأل المستقبِل النهائي الآن: هل خادم التوجيه هذا مُفوَّض في سجل SPF الخاص بك؟

ليس كذلك، ولن يكون أبداً: لم تختر المُوجِّه، لا تعلم بوجوده، ونفس الرسالة المُوجَّهة عبر خدمة مختلفة غداً ستفشل من IP مختلف. SPF يُجيب عن سؤال واحد — “هل جاء هذا الـ IP من خادم فوَّضه نطاق Return-Path؟” — وللبريد المُوجَّه الإجابة الصحيحة لا. الفشل هو SPF يعمل كما حُدِّد، لا سجلك خاطئاً.

الإحصاء يُظهر مدى سيادة هذا المسار: 7,355,985 نطاق يُفوِّض include التوجيه الإلكتروني لـ Namecheap (spf.efwd.registrar-servers.com) — منتج توجيه مزوّد واحد، مستخلَص من 139 مليون ناشر SPF — مع نسبة SPF صارم بـ <0.1% و0.2% فقط يُطبِّق DMARC. ذلك القالب المرن ليس إهمالاً: التوجيه هو بالضبط حيث يُخطئ -all الصارم، والمزوّد الذي منتجه هو التوجيه يشحن وفقاً لذلك. قصة المُحدِّد الكاملة في تقرير ~all مقابل -all، والصورة لكل مزوّد في أي مزوّد بريد يمنح أقوى SPF.

ألا يمكنني إضافة خادم المُوجِّه إلى سجل SPF؟

لا — والسبب هو المقالة كلها:

لا يمكنك حصر المُوجِّهين. أي متلقٍّ، في أي مكان، يستطيع توجيه بريدك عبر أي خدمة. سجل SPF الخاص بك يحتاج لإدراج خوادم لا يمكنك معرفتها مسبقاً.
إدراجها يُفوِّت الغرض. خدمات التوجيه الكبيرة تُعيد إرسال البريد لملايين العملاء. ضع نطاقاتها في سجلك وكل رسالة يُعيد توجيهها أي من مستخدميها — بما في ذلك رسالة مزيِّف — ستجتاز SPF كأنها منك.

المنطق ذاته يستبعد تخفيف مُحدِّدك لـ”جعل التوجيه يعمل”: المُحدِّد ليس سبب فشل البريد المُوجَّه، وبمجرد وجود DMARC يُغيِّر أقل مما تدّعي معظم الأدلة — انظر بيانات المُحدِّد. السجل ليس الرافعة هنا. أوقف السحب عليه.

ماذا عن SRS وARC — ألا يُصلحان التوجيه؟

يعالجانه — لكن أياً منهما ليس لك نشره:

الآلية	ما تفعله حين يُوجَّه البريد	من يتحكم فيها	تُصلح DMARC لديك؟
SPF	تفشل: IP المُوجِّه ليس في سجلك	تنشرها أنت؛ التوجيه يهزمها	لا
SRS (Sender Rewriting Scheme)	المُوجِّه يُعيد كتابة Return-Path بنطاقه الخاص فيجتاز SPF إعادة الإرسال	المُوجِّه	لا — نجاح SPF الآن ينتمي لنطاق المُوجِّه الذي لا يتوافق مع From
ARC (RFC 8617)	المُوجِّه يختم نتائج المصادقة الأصلية؛ المستقبِل النهائي قد يثق بالسلسلة المختومة	المُوجِّه والمستقبِل	أحياناً — حسب تقدير المستقبِل لا تقديرك
DKIM المتوافق	التوقيع يُسافر داخل الرسالة ويتحقق بعد التوجيه، مع نطاقك عليه	أنت	نعم

بيانات وحالة الآليات بتاريخ 2026-06-29.

SRS يُحل مشكلة SPF للمُوجِّه، لا لك: إعادة كتابة Return-Path تُغيِّر SPF أي شخص يُفحَص، بينما ترويسة From — النطاق الذي يُدافع عنه DMARC — لا تُمَس. ARC قرار ثقة بين مشغّلي البنية التحتية. إن أخبرك دليل أن “تطبّق SRS” كمالك نطاق، فقد خلطك بمزوّد التوجيه.

كيف أجعل بريدي يصمد أمام التوجيه؟

اجعل DKIM، المتوافق مع نطاقك، تجاوزك في DMARC. توقيع DKIM هو تشفير محمول في ترويسات الرسالة: يتحقق أينما انتهت الرسالة، مهما أعاد إرسالها من خادم، طالما لم يُعدَّل المحتوى الموقَّع. DMARC يحتاج تجاوزاً متوافقاً واحداً فقط — SPF أو DKIM — فحين يقتل التوجيه ركيزة SPF، يظل DKIM المتوافق يُصادق الرسالة.

شغّل الفحص المجاني على defaults.exposed قبل أن تلمس DNS. يُظهر هل لديك DKIM أصلاً، وهل يُوقِّع بـنطاقك، وأين يقف DMARC — فتُصلح الفجوة الحقيقية بدلاً من محاربة سجل SPF.
تأكد أن التوجيه هو مشكلتك فعلاً. في ترويسة Authentication-Results لرسالة متأثرة، البريد المباشر ينجح في SPF بينما النسخة المُوجَّهة تفشل من IP خدمة التوجيه. إن نجح SPF وDKIM لكن DMARC لا يزال يفشل، لديك مشكلة توافق بدلاً من ذلك — انظر DMARC يفشل لكن SPF وDKIM ينجحان.
شغّل توقيع DKIM بنطاقك الخاص في كل خدمة إرسال — مزوّد صندوق البريد أولاً، ثم ESPs والمرسلون المعاملاتيون. الافتراضيات كثيراً ما تُوقِّع بنطاق المزوّد الذي لا يتوافق؛ تريد d=yourdomain. ابدأ من كيف تُصلح DKIM، مع خطوات لـ Google Workspace وMicrosoft 365.
تحقق من التوافق لا مجرد النجاح. نطاق d= في التوقيع يجب أن يتطابق مع نطاق From؛ dkim=pass على نطاق شخص آخر لا يُفيد DMARC.
اترك سجل SPF كما هو. ابقِه دقيقاً لبريدك المباشر — لا يزال يُصادق معظم حركتك ويظل ركيزة DMARC الثانية. فقط أوقف محاولة جعله يغطي المُوجِّهين.
أعد الفحص، ثم طبّق DMARC بصورة مرحلية بوعي — القسم التالي، ودليل التدرج من p=none إلى p=reject.

هذا التوليف — SPF بالإضافة إلى DMARC مُطبَّق راكباً على DKIM المتوافق — هو النمط المقاوم للتوجيه، وهو نادر: من 77.5 مليون نطاق ينشر ~all، 9.2% فقط (7,116,774) يدعمه بسياسة DMARC مُطبَّقة، و**3.87% فقط من 261 مليون نطاق مُصنَّف (10,092,481)** يُكمل ثلاثية SPF+DKIM+DMARC المُطبَّقة الكاملة، وفقاً للإحصاء (2026-06-29).

ماذا عن القوائم البريدية التي تُعيد كتابة الرسائل؟

المسار التوجيهي الوحيد الذي لا يصمد أمامه DKIM المتوافق: القوائم البريدية التي تُعدِّل الرسالة — وسم موضوع [list-name]، تذييل إلغاء الاشتراك، مرفق مُجرَّد. عدِّل المحتوى الموقَّع ولن يتطابق hash الجسم بعد الآن، فيفشل DKIM أيضاً (dkim=fail: body hash did not verify هو دليل ذلك الفشل الخاص). الآن كلتا ركيزتَي DMARC معطَّلتان، ولا يملك التخفيف إلا القائمة نفسها (إعادة كتابة From، ختم ARC).

هذا البقاء بالضبط ما تُوجد له مرحلية تطبيق DMARC. المرور عبر p=quarantine مع رفع تدريجي لـ pct بينما تراقب التقارير المجمَّعة يُظهر كم من بريدك الحقيقي يتدفق عبر قوائم تُعيد الكتابة قبل أن تبدأ سياسة p=reject في ارتداده. لا تقفز إلى reject على نطاق مستخدموه يعيشون على القوائم البريدية؛ لا تتجمّد عند p=none إلى الأبد أيضاً. دليل التدرج يسير معك في المراحل.

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

هل التوجيه يكسر DKIM أيضاً؟ التوجيه العادي، لا: التوقيع يُسافر مع الرسالة ويتحقق عند المستقبِل النهائي. DKIM ينكسر فقط حين يُعدَّل المحتوى الموقَّع أثناء العبور — وسوم موضوع القوائم والتذييلات هي الحالة الكلاسيكية — ولهذا يُعالَج بقاء القوائم بمرحلية سياسة DMARC، لا بأي شيء في DNS.

هل أتحول من -all إلى ~all لإيقاف فشل التوجيه؟ تغيير المُحدِّد لن يجعل المُوجِّهين ينجحون — ليس لهذا يفشلون. من الدلالات أن include التوجيه لـ Namecheap، 7,355,985 نطاقاً وأكبر مجتمع توجيه مخصص في الإحصاء (2026-06-29)، يشحن بنسبة SPF صارم بـ <0.1%: SPF المرن هو القالب الصحيح على الأرجح لمنتج توجيه. انظر تقرير ~all مقابل -all لما يُغيِّره المُحدِّد فعلاً.

لماذا ينجح بريدي في SPF حين يُرسَل مباشرةً لكنه يفشل حين يُوجِّهه أحد؟ يتحقق المستقبِل هل IP آخر خادم إرسال مُفوَّض بسجل SPF لنطاق Return-Path. مباشر: خادمك، في سجلك، نجاح. مُوجَّه: خادم المُوجِّه، غير موجود في سجلك، فشل. سجلك لم يتغير — تغيَّر IP الإرسال.

هل يمكنني إعداد SRS لإصلاح هذا؟ فقط إن كنت أنت المُوجِّه. SRS يعمل على الخادم الذي يُجري التوجيه، وحتى حيث يعمل، نجاح SPF الناتج ينتمي لنطاق المُوجِّه ولا يتوافق مع From — DMARC لديك لا يزال يحتاج ركيزة DKIM.

هل SPF بلا قيمة إن كان التوجيه يكسره على أي حال؟ لا. معظم البريد يُسلَّم مباشرةً، حيث يعمل SPF بالضبط كما هو مقصود، ويظل إحدى ركيزتَي DMARC. من 261,086,232 نطاق في الإحصاء (2026-06-29)، 138,927,207 ينشر SPF — ابقِ سجلك دقيقاً عبر صفحة إصلاح SPF، ودع DKIM يحمل الباقي المُوجَّه.

أرسل للمالك التقرير

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

افحص نطاقك ← · DMARC يفشل لكن SPF وDKIM ينجحان ← · إصلاح DKIM ← · طريقة التصنيف ← · بيانات إجمالية فقط. البيانات مخزّنة ومعالَجة في الاتحاد الأوروبي.