مراحل نضج DMARC الست

نُشر 2026-07-03 · حُدّث 2026-07-03

الأرقام حتى تاريخ 2026-06-29 · المنهجية الإصدار v7. هذا نموذج مرجعي مدعوم بإحصاء دوري متكرر؛ تعيد كل نسخة قياس المجتمع نفسه بحيث يمكن تتبّع الأرقام عبر الزمن. جميع الأرقام إجمالية — نحن لا ننشر أبداً درجة نشاط تجاري بعينه.

نشر DMARC ليس مثل أن تكون محمياً

عبر 261 مليون نطاق تم قياسها، تنشر 24.89% سجل DMARC — لكن 10.59% فقط تُطبّقه فعلياً. بعبارة أخرى: من بين نحو 65 مليون نطاق بدأت رحلة DMARC، 57.5% منها لم تصل قط إلى الجزء الذي يحجب أي شيء. لقد نشرت سجلاً، ووجّهت التقارير إلى مكان ما، ثم تعثّرت. وتجد الدراسات المستقلة الأصغر النمط نفسه — فقد قدّر أحد تقارير القطاع لعام 2026 النسبة عند نحو 9% تطبّق فعلياً من بين نحو 938,000 نطاق فحصها.

لم يعد التبنّي هو المشكلة. الحماية هي المشكلة. وتتعثّر النطاقات لسبب بنيوي: الخرائط التي يستخدمها الجميع تتوقف قبل الأوان. إنها تنتهي مبكراً أكثر مما ينبغي، ولا واحدة منها تمنح الخطوة الأصعب اسماً خاصاً بها.

أين تتوقف الخرائط الموجودة قبل الأوان

كانت النماذج التي يهتدي بها القطاع صحيحة لعصرها، وتستحق قراءة منصفة:

نموذج النشر ذو المراحل الخمس الذي روّجت له dmarcian (والذي شارك مؤسسها في تأليف DMARC نفسه) يسير عبر النشر ← المراقبة ← تشديد السياسة — ويعامل الوصول إلى p=reject باعتباره الوجهة النهائية.
تدرّج RFC — p=none → quarantine → reject — هو ثلاثة مستويات من التطبيق، وليس نموذج نضج. فهو لا يقول شيئاً عن المتطلبات المسبقة ولا شيئاً عمّا يأتي بعده.
“احبُ، امشِ، اركض” نموذج شعبي: صحيح في الاتجاه، فارغ في البنية.

تتشارك الثلاثة جميعاً في قيدين. أولاً، تتوقف عند p=reject — كأن التطبيق هو خط النهاية. وهو ليس كذلك: فالمعيار نفسه قد تجاوز ذلك (DMARCbis — RFC 9989 و9990 و9991 — نُشر في مايو 2026، ليحل محل RFC 7489 الأصلي)، والتطبيق لا يفعل شيئاً لأمن النقل أو الثقة بالعلامة التجارية. ثانياً — وهذا هو القيد الذي يُعلّق النطاقات فعلاً — لا واحد منها يجعل “احتساب كل مُرسِل” مرحلةً مُسمّاة. ومن باب الإنصاف، فإن أدلة النشر تذكر هذا العمل بالفعل: نموذج dmarcian يتضمّن تحديد المصادر كمهمة داخل مرحلة المراقبة لديه. لكن مهمة مدفونة داخل مرحلة هي بالضبط الطريقة التي يُعامَل بها هذا العمل — كجزء من “المراقبة” بدلاً من كونه الإنجاز المنفصل الذي هو عليه. مشاهدة التقارير وهي تتوارد تبدو كتقدّم. لكنها ليست كذلك، بعد. السبب الأكبر منفرداً في بقاء النطاقات عند p=none لسنوات هو أنها تستطيع أن ترى بريدها لكنها لم تحتسبه — فلا تجرؤ على التطبيق، خشية أن تعطّل شيئاً حقيقياً.

النموذج المفيد يحتاج أن يمنح تلك الخطوة اسمها الخاص ومعايير خروجها الخاصة. وهذا النموذج يفعل ذلك. نسمّيه نموذج نضج تبنّي DMARC — DAMM: ست مراحل، خطوة واحدة لكل منها، واسم يمكنك أن تستشهد به.

النموذج

مراحل نضج DMARC الست — من غير المحمي إلى المُحصَّن، مع الجدار الفاصل بين المراقبة والرؤية

المرحلة 1 — غير محمي. لا سجل DMARC — أو أن SPF وDKIM ناقصان تحته. يستطيع أي شخص إرسال بريد باسم نطاقك، ولا شيء في أي مكان يتحقّق. الخطوة: اضبط SPF و DKIM لبريدك الأساسي، وتأكّد من أنهما يوثّقان ويتوافقان (align). فـ DMARC مبنيّ على كليهما؛ لا يمكنك تخطّي هذا الأساس.

المرحلة 2 — موثَّق. SPF وDKIM صحيحان ومتوافقان لتدفّق بريدك الرئيسي. يُثبت بريدك المشروع مصدره — لكن لا شيء يخبر صناديق البريد الواردة في العالم بما ينبغي فعله بالبريد الذي لا يفعل ذلك. الخطوة: انشر سجل DMARC عند p=none مع عنوان إبلاغ rua=.

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

المرحلة 4 — الرؤية. كل مُرسِل مشروع محدَّد ومتوافق — منصة النشرة البريدية، ونظام الفوترة، ونظام CRM، والأداة التي اشترك بها التسويق الربيع الماضي. أنت تعرف بريدك. لن يتعطّل أي شيء مشروع إذا طبّقت. هذه هي المرحلة التي تتخطّاها الخرائط القديمة، والجدار الذي لا تتسلّقه معظم النطاقات أبداً. الخطوة: ارفع السياسة — p=none → p=quarantine (وضع الاختبار t=y في DMARCbis يساعد هنا) → p=reject.

المرحلة 5 — مُطبَّق. p=quarantine أو p=reject مفعّل، مع تغطية النطاقات الفرعية بسياسة sp= صريحة. البريد الذي يفشل في التوثيق يُحجَز الآن فعلاً أو يُرفض عند المستقبِلين المشاركين — وهذا يشمل كل مزوّد صناديق بريد رئيسي — فيتوقّف الانتحال المباشر لنطاقك بالضبط عن الوصول حيث يُفحص DMARC. الخطوة: أضِف طبقة التحصين — تغطية np= وتجوال الشجرة (tree-walk) في DMARCbis، وMTA-STS وTLS-RPT للنقل، وBIMI إن كان عرض العلامة التجارية يهمّك.

المرحلة 6 — مُحصَّن ومُستدام. التطبيق إضافةً إلى الحزمة الحديثة: تغطية النطاق الفرعي غير الموجود (np=) من DMARCbis، وMTA-STS وTLS-RPT لتأمين البريد أثناء النقل، وBIMI حيث تستحق مكانها — والأهم، المراقبة المستمرة للانحراف وللمُرسِلين الجدد. هذه ليست شارة؛ بل انضباط. يظهر مُرسِلون جدد، ويغيّر المزوّدون عناوين IP، وتتحلّل الإعدادات. الخطوة: ابقَ هنا.

مسار “لا بريد”. بقياسه عبر كامل مخزون النطاقات — بما في ذلك النطاقات الميتة — 51.5% من النطاقات لا تشغّل أي خدمة بريد على الإطلاق، وبالنسبة لها تنهار الرحلة إلى خطوة واحدة. النطاق الذي لا يُرسل قط ينبغي أن ينشر SPF -all وDMARC p=reject فوراً: لا يوجد بريد مشروع لحمايته، فلا شيء لمراقبته ولا جدار لتسلّقه. تنتقل النطاقات المركونة والخاملة الخاصة بالعلامة التجارية مباشرةً إلى المرحلة المُطبَّقة بتغيير DNS واحد — وبفعل ذلك تُغلق واحداً من أكثر متجهات انتحال الهوية شيوعاً على الإطلاق.

الجدار: المرحلة 3 ← 4

كل انتقال آخر في هذا النموذج هو تغيير DNS. أما هذا فهو عمل تحقيقي — وهو حيث تموت الأشهر.

الانتقال من المراقبة إلى الرؤية يعني إسناد كل مصدر إرسال في تقاريرك إلى نظام حقيقي: أيّ ESP، أيّ CRM، أيّ مُرحِّل بريد لمكتب إقليمي، أيّ أداة SaaS ربطها أحدهم في 2023 ثم نسيها. يعني العثور على مُرسِلي تقنية المعلومات الظلّية (shadow-IT) الذين لم يوثّقهم أحد. يعني إصلاح التوافق لكل ESP على حدة، لأن لكل منصة طريقتها الخاصة في التوثيق نيابةً عنك — وبعضها خاطئ افتراضياً.

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

هذه أيضاً هي المرحلة التي يستعين فيها أصحاب النطاقات بالمساعدة أكثر من غيرها — إذ يستطيع مزوّد تقنية معلومات أو خدمة مراقبة DMARC القيام بعمل تحديد المُرسِلين؛ وتبقى المراحل كما هي في كلتا الحالتين.

الجزء الذي ينساه الجميع: المرحلة 5 ← 6

الوصول إلى p=reject يوقف الانتحال المباشر لنطاقك في سطر From:، عند المستقبِلين الذين يتحقّقون منه. هذا ضروري — وهو ليس كافياً. ويجدر أيضاً تسمية ما لم يغطّه التطبيق قط: النطاقات المشابهة (yourc0mpany.com) وانتحال اسم العرض يقعان بالكامل خارج نطاق DMARC، فيُغلق التطبيق باب النطاق المطابق تماماً ويترك الأبواب المجاورة لليقظة ولضوابط أخرى.

التطبيق لا يفعل شيئاً لـ النقل: فبدون MTA-STS وTLS-RPT، يمكن أن يُخفَّض البريد إلى نطاقك أو يُعترَض أثناء النقل. ولا يفعل شيئاً لـ التعرّف على العلامة التجارية: فـ BIMI — شعارك، معروضاً عند صندوق الوارد — إشارة ثقة، لا ضابط أمني، ومن الأمانة معاملته كذلك (كما أنه يتطلّب شهادة مدفوعة، ولهذا يأتي أخيراً لا أولاً). وp=reject المجرّد يسبق DMARCbis: فوسم np= وتجوال الشجرة في المعايير الجديدة يُغلقان ثغرة النطاق الفرعي غير الموجود التي تتركها عمليات النشر الأقدم مفتوحة.

النطاق عند p=reject دون أيّ مما سبق محميٌّ من الهجوم الأكثر شيوعاً وغير مستعدّ للبقية. هذا تمييز حقيقي، وهو يستحق مرحلته الخاصة.

مرحلتك قابلة للقياس

هذا النموذج ليس مجرد رسم بياني — فمرحلة النطاق قابلة للحساب، وهو ما يميّزه عن ملصق على جدار.

يمكن اشتقاق المراحل من 3 إلى 6 من بيانات إبلاغ DMARC الخاصة بالنطاق نفسه إضافةً إلى سجلاته المنشورة: أيّ سياسة مفعّلة، وهل تتدفّق التقارير، وهل كل مُرسِل مُلاحَظ متوافق. أما المرحلتان 1 و2 فتُقيَّمان بفحص DNS مباشر، إذ لا وجود لتقارير بعد. وثمة قيد صادق في كل اتجاه: المرحلة 4 تُؤكَّد بالأدلة عبر الزمن — عبارة “كل مُرسِل مُلاحَظ متوافق عبر عدد كافٍ من أيام الإبلاغ” مؤشّر قوي، لكن لا تقرير يستطيع أن يكشف المُرسِل الذي لم تربطه بعد. وطبقة تحصين المرحلة 6 — MTA-STS وTLS-RPT وBIMI — غير مرئية في تقارير DMARC؛ يلزم فحص DNS لرؤيتها. يمكن أن يبدو نطاق “مكتملاً” من تقاريره ويحمل مع ذلك فجوة خفية بين المرحلتين 5 ← 6. هذا هو النموذج الذي يقيس بمقابله تحليل الإبلاغ الخاص بنا، بكل معوّقاته.

مثال محلول

شركة متوسطة الحجم تشغّل Microsoft 365 خلف بوابة تصفية بريد. ينتهي SPF بـ -all، وDKIM مضبوط، وDMARC منشور عند p=none، والتقارير تتدفّق إلى أداة مراقبة. على الخرائط القديمة يبدو هذا شبه مكتمل. أما على هذه الخريطة فهو المرحلة 3 — المراقبة: الإعداد الصعب مكتمل، وقد تعثّر النطاق عند الجدار بالضبط — مرئيّ، لا محميّ. الخطوة الأعلى قيمةً هي 3 ← 4 ← 5: تأكّد من أن المُرسِلين المشروعين (القلائل على الأرجح) جميعهم متوافقون، ثم ارفع السياسة على مراحل. بالنسبة لنطاق بهذا الشكل، يكون ذلك عادةً أسابيع من الانتباه، لا أشهراً — فالجدار أعلى ما يكون لمن لا يرسمون خريطته أبداً.

اعرف مرحلتك

السؤال الذي ينبغي إحالته إلى التقاعد هو “هل لدينا DMARC؟” — إذ تستطيع 24.89% من النطاقات أن تجيب بنعم بينما تبقى 57.5% من تلك قابلة للانتحال. السؤال الأفضل هو “في أيّ مرحلة نحن، وما الخطوة الوحيدة إلى المرحلة التالية؟” كل نطاق على الإنترنت يقع اليوم في واحدة بالضبط من هذه المراحل الست. ومعرفة أيّها تحوّل القلق إلى قائمة مهامّ.

أين يقع الإنترنت عبر المراحل الست — معظم النطاقات لا تملك سجل DMARC على الإطلاق؛ ومعظم التي تملكه عالقة قبل التطبيق

أسئلة شائعة

ما هو DAMM؟ نموذج نضج تبنّي DMARC — النموذج ذو المراحل الست في هذه الصفحة: غير محمي، موثَّق، المراقبة، الرؤية، مُطبَّق، مُحصَّن. مرحلة النطاق قابلة للقياس من بيانات DNS الخاصة به ومن بيانات إبلاغ DMARC، وهو ما يميّزه عن ملصق على جدار.

هل نشر p=none بلا قيمة إذن؟ لا — إنه المرحلة 3، والمرحلة 3 حاملة للأساس: فالإبلاغ هو الطريقة التي تجد بها كل مُرسِل قبل أن تطبّق. لا يصبح مشكلة إلا حين يُعامَل كوجهة نهائية. راجع لماذا p=none ليست حماية.

هل يمكنني القفز مباشرةً إلى p=reject؟ إن كان نطاقك لا يُرسل بريداً — فنعم، اليوم، وينبغي أن تفعل. أما إن كان يُرسل بريداً — فلا: التطبيق دون الرؤية (المرحلة 4) هو الطريقة التي يُعطَّل بها البريد المشروع وتحدث بها عمليات التراجع. المراحل هي المسار الآمن، لا مجرد مراسم.

هل أحتاج BIMI لأكون “مكتملاً”؟ لا. BIMI هي طبقة عرض العلامة التجارية في المرحلة 6 والعنصر الأكثر اختياريةً في النموذج — أما MTA-STS وTLS-RPT وتغطية np= في DMARCbis فهي الأجزاء التي تُحصّن النطاق تحصيناً جوهرياً. إن لم تكن تكلفة الشهادة مبرَّرة لك، فتخطَّها واحتفظ ببقية المرحلة 6.

أين يقع SPF وDKIM؟ تحت كل شيء — إنهما المرحلتان 1 ← 2، وSPF بدون DMARC يحمي أقلّ مما يفترض معظم أصحاب النطاقات. ومنذ 2024، اشترط المستقبِلون الكبار أيضاً التوثيق صراحةً من المُرسِلين بالجملة.

افحص أين يقف نطاقك أنت

هذه المراحل أنماط سكانية — نطاقك يقع في واحدة منها بالضبط، والخطوة التالية قابلة للمعرفة. يمكنك الفحص بخصوصية ومجاناً، ورؤية أيّ الفحوص الـ 34 تجتازها وكيف تُصلح ما لا تجتازه.

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