DMARC يفشل لكن SPF وDKIM ينجحان؟ إصلاح التوافق (2026)

نُشر 2026-07-08

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

DMARC يحتاج أكثر من النجاح — النطاق الذي نجح في SPF أو DKIM يجب أن يتطابق مع نطاق From. معظم بريد “SPF ينجح، DMARC يفشل” نجح SPF عليه بنطاق ارتداد المورد لا نطاقك. 7.4% فقط من 261,086,232 نطاق مُصنَّف ينجح في SPF مع توافق تحت سياسة DMARC مُطبَّقة، وفقاً لإحصاء Defaults.Exposed (2026-06-29).

الإصلاح أسرع مما يوحي الارتباك. اقرأ ترويسة Authentication-Results لمعرفة أي ركيزة — SPF أو DKIM — تنجح على النطاق الخاطئ؛ ثم إما فعّل توقيع DKIM بنطاق مخصص لخدمة الإرسال (عادةً بضعة CNAMEs، والإصلاح الذي يصمد أمام التوجيه)، أو اضبط Return-Path المخصص ليمر SPF على نطاقك. ركيزة واحدة متوافقة كافية لـ DMARC.

كيف يفشل DMARC حين ينجح كل من SPF وDKIM؟

لأن DMARC لا يسأل أبداً “هل نجح SPF؟” بل يسأل: هل نجح SPF أو DKIM لنطاق يتطابق مع عنوان From الذي يراه متلقّيك؟ هذا الشرط الإضافي يُسمى التوافق، وهو نقطة DMARC كلها — بدونه يستطيع أي أحد تمرير SPF على نطاق يملكه بينما يعرض نطاقك في ترويسة From.

كل فحص يُصادق نطاقاً مختلفاً:

الفحص	النطاق الذي يُقيّمه فعلاً	أين تراه
SPF	الـ Return-Path (RFC5321.MailFrom، عنوان الارتداد/المغلف) — لا ترويسة From	`smtp.mailfrom=` في Authentication-Results
DKIM	النطاق في وسم `d=` للتوقيع — ما اختاره الموقِّع	`header.d=` في Authentication-Results
DMARC	نطاق ترويسة From — ويشترط أن يتطابق معه نطاق SPF أو `d=` لـ DKIM	`header.from=` في Authentication-Results

هكذا عادةً تسير الأمور خطأ: منصة نشرتك أو CRM ترسل بـ Return-Path مثل [email protected]، يُفحَص SPF مقابل vendor.com وينجح، DKIM ينجح بـ d=vendor.com — ويفشل DMARC، لأن أياً من النطاقَين الناجحَين لا يتطابق مع yourcompany.com. كل فحص قال الحقيقة؛ لا أحد منهم صادقك أنت. تحرير سجل SPF الخاص بك لا يُصلح هذا — لم يُستشر أصلاً. إنه الفخ نفسه المُغطى في SPF الفاشل لأدوات SaaS.

الإحصاء يُظهر كم عدداً قليلاً من المُرسِلين يُكمل هذه الخطوة الأخيرة: 27,640,987 من 261,086,232 نطاق مُصنَّف (10.59%) لديه سياسة DMARC مُطبَّقة أصلاً، و7.4% فقط ينجح في SPF مع توافق تحتها. من بين 77.5 مليون نطاق ينتهي SPF الخاص بها بـ softfail (~all)، 9.2% فقط يقع تحت سياسة DMARC مُطبَّقة؛ من بين ناشري hardfail (-all)، 12,142,351 مُطبَّقون بينما 42,514,532 ليسوا كذلك. معظم النطاقات تتوقف عند “SPF ينجح” — الذي دون DMARC يتصرف عليه لا يحمي كاد شيئاً.

كيف أقرأ Authentication-Results لأرى أي ركيزة غير متوافقة؟

أرسل لنفسك رسالة عبر الخدمة الفاشلة، افتح المصدر الخام، وابحث عن ترويسة Authentication-Results. نتيجة غير متوافقة نموذجية تبدو هكذا:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounces.espmail.net;
       dkim=pass header.d=espmail.net;
       dmarc=fail (p=NONE) header.from=yourcompany.com

اقرأها في ثلاث مقارنات:

ركيزة SPF: هل تنتهي smtp.mailfrom= بنطاقك؟ هنا إنها bounces.espmail.net — غير متوافقة.
ركيزة DKIM: هل تنتهي header.d= بنطاقك؟ هنا إنها espmail.net — غير متوافقة.
حكم DMARC: header.from= هو النطاق الذي يُدافع عنه DMARC. لم تتطابق أي ركيزة معه، فنتيجته dmarc=fail — حتى مع أن كلا الفحصَين يقول pass.

أيا كانت الركيزة التي تتضمن بالفعل نطاقك الخاص (أو يمكن جعلها كذلك) هي التي تُصلحها. تحتاج واحدة فقط.

ما الفرق بين التوافق relaxed والصارم؟

DMARC يقدم وضعَين للمطابقة، مضبوطَين بالوسمَين aspf (SPF) وadkim (DKIM) في سجل DMARC:

Relaxed (r، الافتراضي): يجب أن يتشارك النطاقان نفس النطاق المؤسسي — النطاق القابل للتسجيل وفق Public Suffix List. bounce.yourcompany.com يتوافق مع yourcompany.com؛ وكذلك DKIM بـ d=mail.yourcompany.com. لهذا تعمل Return-Paths المخصصة للموردين وDKIM المخصص الذي يقيم على نطاقات فرعية.
Strict (s): يجب أن تتطابق النطاقات بدقة حرفاً بحرف. bounce.yourcompany.com لم يعد يتوافق مع yourcompany.com.

إن لم يذكر سجلك aspf أو adkim، أنت في وضع relaxed — وعلى الأغلب تريد البقاء فيه. الوضع الصارم لا يُضيف أمناً ذا معنى لمعظم المُرسِلين ويكسر بصمت كل مرسِل نطاق فرعي مشروع أعددته. إن كان DMARC يفشل وسجلك يحتوي aspf=s أو adkim=s، هذا وحده قد يكون الخطأ.

كيف أُصلح توافق DMARC؟

شغّل الفحص المجاني على defaults.exposed قبل أن تلمس DNS. يُظهر سجل DMARC والسياسة، وهل SPF وDKIM مُعدَّتان للتوافق، وما الذي يحتاج إصلاحاً — فتُصلح الركيزة الصحيحة أولاً.
اختبر كل خدمة إرسال واقرأ Authentication-Results (كما أعلاه). أدرج كل مصدر — مزوّد صندوق البريد، أداة النشرة، CRM، تطبيق الفواتير — وسجّل لكل مصدر هل smtp.mailfrom وheader.d هما نطاقك أم نطاق المورد.
فعّل توقيع DKIM بنطاق مخصص لكل مورد — الإصلاح الدائم. كل خدمة إرسال جادة تقدم “مصادقة النطاق”: بضعة سجلات CNAME تتيح لها التوقيع كـ d=yourcompany.com (أو نطاق فرعي، يتوافق في وضع relaxed). DKIM المتوافق عادةً الإصلاح الأسهل والوحيد الذي يصمد أمام التوجيه، لأن التوجيه يكسر SPF بالتصميم.
لتوافق SPF، فعّل Return-Path المخصص للمورد (يُسمى كثيراً نطاق الارتداد المخصص) — عادةً CNAME واحد مثل bounce.yourcompany.com يُشير إلى المورد. SPF يمر بعدها على نطاقك المؤسسي ويتوافق. افعل هذا حيث يُقدَّم، لكن عامله كالركيزة الثانية لا بديلاً عن DKIM المتوافق.
ابقِ التوافق في وضع relaxed ما لم يكن لديك سبب محدد ومفهوم لـ aspf=s/adkim=s.
أعد الفحص وتأكد من كلتا الركيزتَين، ثم تحرك نحو التطبيق. سياسة DMARC بـ p=none تُبلِّغ ولا تحجب شيئاً؛ بمجرد توافق مُرسِليك الحقيقيين، المسار الكامل إلى سياسة تحميك موجود في صفحة إصلاح DMARC، وأدلة الإعداد لدى المزوّدين مثل DMARC على IONOS تُغطي نقرات لوحة DNS.

هل أُصلح توافق SPF أم توافق DKIM؟

تحتاج ركيزة واحدة متوافقة لكل مصدر إرسال. إن لم تستطع إلا واحدة، الاختيار واضح:

الإصلاح	ما يتضمنه	يصمد أمام التوجيه؟
DKIM متوافق (توقيع بنطاق مخصص)	بضعة CNAMEs في لوحة “مصادقة النطاق” للمورد	نعم — التوقيع يُسافر مع الرسالة
SPF متوافق (Return-Path / نطاق ارتداد مخصص)	CNAME واحد، حيث يقدمه المورد	لا — IP أي مُوجِّه يستبدل IP المورد

الحالة الخاصة التي تستحق المعرفة: Google Workspace وMicrosoft 365 سيُوقِّعان بريدك بـ DKIM بصورة افتراضية بنطاقات احتياطية خاصة بهما (gappssmtp.com، onmicrosoft.com) — فيُظهر DKIM pass بينما DMARC لا يزال يفشل. إنها الحالة المحددة الأشيع لهذه المشكلة كلها، ولها دليل خاص: DKIM ينجح لكن DMARC لا يزال يفشل: فخ التوقيع الافتراضي.

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

هل يجب توافق كل من SPF وDKIM لنجاح DMARC؟ لا — تجاوز متوافق واحد كافٍ. أفضل الممارسات توافق كليهما على أي حال، حتى حين يكسر التوجيه ركيزة SPF تظل ركيزة DKIM تحمل نجاح DMARC. من 261,086,232 نطاق مُصنَّف في إحصاء 2026-06-29، 3.87% فقط يُكمل ثلاثية SPF+DMARC+DKIM الكاملة.

لوحة إدارة ESP لديّ تقول SPF وDKIM “مُتحقَّق منهما” — لماذا يفشل DMARC؟ “مُتحقَّق” عادةً يعني إرسال المورد الخاص ينجح على نطاقات المورد. ما لم تُكمل خطوات النطاق المخصص (CNAMEs للـ DKIM، Return-Path المخصص)، البريد يُصادَق كالمورد لا كأنت — وDMARC يُقارن بنطاق From الخاص بك.

هل سجل SPF الصارم -all كافٍ بدون توافق؟ لا. المُحدِّد الصارم يُقوّي حكم SPF على نطاق Return-Path، لكن DMARC لا يزال يحتاج ذلك النطاق أن يكون نطاقك. بتاريخ إحصاء 2026-06-29، 12,142,351 فقط من النطاقات التي تنشر -all يقع تحت سياسة DMARC مُطبَّقة — الـ 42,514,532 الأخرى لديها سجل صارم لا تتصرف عليه أي سياسة.

هل أتحول إلى التوافق الصارم (aspf=s/adkim=s) للمزيد من الأمان؟ نادراً جداً. التوافق Relaxed يشترط بالفعل نفس النطاق القابل للتسجيل، الذي لا يملكه المزيِّف. الوضع الصارم في الغالب يكسر مُرسِلي النطاقات الفرعية الخاصة بك — تحقق منه حين يفشل التوافق بصورة غير متوقعة.

DMARC يفشل فقط على بريد يُوجّهه المتلقون — نفس الإصلاح؟ هذه ركيزة SPF تموت في العبور: خادم المُوجِّه ليس في أي سجل SPF لـ Return-Path الخاصة بك. لا يمكنك إصلاح SPF للبريد المُوجَّه؛ DKIM المتوافق هو الحل، إذ يصمد التوقيع أمام التوجيه سليماً. التفاصيل في البريد المُوجَّه يفشل في SPF.

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

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

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