Defaults.Exposed › الإصلاحات › Guides

DMARC من p=none إلى p=reject دون فقدان البريد الشرعي: الطرح المتدرج (2026)

نُشر 2026-07-08

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

انتقل بـ DMARC من p=none إلى p=reject في أربع مراحل: راقب تقارير rua لمدة 2–4 أسابيع، أصلح كل مرسِل شرعي، ارفع p=quarantine مع pct، ثم reject — لا تقفز مباشرةً إلى reject. 70,368,600 من 261,086,232 نطاق مُقيَّم تقف متوقفة عند SPF الليّن بلا تطبيق DMARC، وفق تعداد Defaults.Exposed.

هذا هو الدليل التشغيلي: جدول المراحل مع معايير الخروج، والسجل لكل مرحلة، ودقّة pct وفق RFC 7489 التي تُغيّر معنى “50%” عند reject، ووسم sp= للنطاقات الفرعية. إذا كنت تُقرّر هل تُطبّق، اقرأ 6 مراحل نضج DMARC أولاً — ذلك هو الإطار؛ وإذا كانت مستويات السياسة جديدة عليك، فـما يعنيه p=none وp=quarantine وp=reject فعلاً هو التمهيد. هذه الصفحة للتنفيذ.

لماذا لا يمكنك القفز مباشرةً إلى p=reject؟

لأن p=reject يأمر كل مستقبِل يحترمها بإرجاع البريد الذي يفشل DMARC — وحتى تُشاهد تقاريرك، لا تعرف ما الذي يفشل. كاد كل نطاق يُفعّل المراقبة يكتشف مرسِلين شرعيين نسيهم: CRM، أداة إصدار فواتير، نموذج تواصل. اقفز إلى reject في اليوم الأول وذلك البريد لا يذهب إلى مجلد الرسائل غير المرغوب فيها؛ يختفي في وقت SMTP. فقدان دورة فواتير يُعلّم المؤسسة الخوف من DMARC، ويُعاد ضبط السجل إلى p=none بصورة دائمة — من 261,086,232 نطاق مُقيَّم، 37,312,637 متوقفة بالضبط هناك، وفقط 10.59% (27,640,987) تصل إلى سياسة مُطبَّقة.

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

ما المراحل الأربع للطرح؟

البيانات حتى 2026-06-29؛ سلوك السياسة وفق RFC 7489.

المرحلة 3 هي حيث تتوقف النطاقات أو تتذعر. البريد في مجلد الرسائل غير المرغوب فيها قابلٌ للتعافي — يجد المستخدمون البريد، تُخفّف pct، تُصلح المصدر. الرفض غير قابل للتعافي، وهذا لماذا quarantine عند pct=100 يعمل بنظافة هو تذكرة الدخول إلى المرحلة 4.

كيف تُشغّل الطرح خطوةً بخطوة؟

1. شغّل الفحص المجاني على defaults.exposed قبل لمس DNS. يُؤكّد سياستك الحالية وما إذا كان SPF وDKIM موجودَّين في الأسفل — الطرفَّان اللذان يقوم عليهما التطبيق.
2. فعّل المراقبة إن لم تكن قد فعلت. نشر p=none مع rua= هو الخطوة الخمس دقائق في “سياسة DMARC غير مفعَّلة”. اجمع تقارير 2–4 أسابيع — كافيةً للإمساك بالمرسِلين الشهريين كدورات الفواتير.
3. جرّد كل مصدر في التقارير. صنّف المرسِلين إلى مرسِليك، مرسِلي موردّيك، ومجهولين. التقارير الخام تصل كـ XML — أداة معالجة تقارير (أو لوحة مزوّدك) تحوّلها إلى جرد مرسِلين مقروء.
4. اجعل كل مصدر شرعي يجتاز بتوافق. فعّل DKIM المخصص للنطاق لكل مورّد (عادةً سجلَّا CNAME في لوحة تحكمه) حتى تحمل التوقيعات نطاقك لا نطاقه. فضّل DKIM للتوافق: يصمد أمام إعادة التوجيه، SPF لا يصمد.
5. انتظر أسبوعَّين نظيفَّين. اخرج من المرحلة 2 فقط عندما تكون الفشل المُبلَّغ عنه حصراً حركةً لا تعرفها — التزوير الذي تريد حجبه.
6. انتقل إلى p=quarantine; pct=10 — عدّل سجل _dmarc TXT الموجود (مثال عملي: إعداد DMARC على IONOS)، وانتبه للبنية: خطأ إملائي في وسم السياسة قد يُلغي السجل كلياً. ارفع pct إلى 25 ثم 50 ثم 100 خلال 2–4 أسابيع مع مراقبة التقارير وتذاكر الدعم. أي بريد شرعي في مجلد الرسائل غير المرغوب فيها: خفّض pct، أصلح المصدر، استأنف.
7. انتقل إلى p=reject بعد 1–2 أسبوع نظيف عند pct=100. احتفظ بـ rua= بشكل دائم — كل أداة تتبنّاها شركتك مستقبلاً هي مرسِلٌ فاشل محتمل.

ما الذي يفعله pct فعلاً؟ دقة RFC 7489

pct يطلب من المستقبلين تطبيق سياستك على تلك النسبة المئوية من البريد الفاشل. الدقة، من RFC 7489 §6.6.4: البريد الذي لا يقع في العيّنة لا يرجع إلى “يُسلَّم طبيعياً” — بل يأخذ السياسة الأقل صرامة بمرتبة واحدة. تحت p=quarantine; pct=25، الـ 75% الأخرى تُعامَل كـ p=none وتُسلَّم. لكن تحت p=reject; pct=50، الـ 50% الأخرى تُوضع في مجلد الرسائل غير المرغوب فيها، لا تُسلَّم. لا يوجد reject ليّن: لحظة يقول سجلك reject، كل رسالة فاشلة على الأقل تُوضع في مجلد الرسائل غير المرغوب فيها عند المستقبلين الذين يحترمونها.

مستخدَمٌ بعمد، هذه ميزة — p=reject; pct=1 يتصرف كـ”ضع كل شيء تقريباً في مجلد الرسائل غير المرغوب فيها، ارفض قطرة”، وهي مرحلة نهائية مشروعة قبل التطبيق الكامل. تحذيران: المستقبلون لا يطبّقون العيّنة بنفس الطريقة، لذا عامل pct كمقياس تقريبي؛ وأزل الوسم (أو اضبط pct=100) حين تستقر المرحلة 4، لكي يقول سجلك ما تعنيه.

ماذا عن النطاقات الفرعية — وسم sp=؟

افتراضياً، ترث النطاقات الفرعية سياسة النطاق التنظيمي: p=reject على yourdomain.com يشمل mail.yourdomain.com أيضاً. يُتيح وسم sp= الاختلاف، في اتجاهَّين نافع وخطير. نافع: p=quarantine; sp=reject يُقفل النطاقات الفرعية التي لا ترسل منها أبداً بينما النطاق الرئيسي لا يزال في منتصف الطرح — يستهدف المزوِّرون النطاقات الفرعية للنطاقات المُراقَبة عمداً. خطير: sp=none منسي يُعفي بصمت كل نطاق فرعي من سياسة reject التي أمضيتَ ستة أسابيع في كسبها. تحقّق منه في المرحلة 4؛ إذا احتاج نطاق فرعي معيّن سياسة أرخى، انشر سجل _dmarc على ذلك النطاق الفرعي بدلاً من تخفيف الكل.

هل يعني NIS2 أن الشركات الأوروبية مُلزَمة بذلك؟

DMARC يعمل بنفس الطريقة في كل مكان — لا شيء في هذا الدليل يتغيّر عند الحدود الأوروبية. ما يتغيّر هو الدافع للامتثال. تُلزم المادة 21(2)(ي) من NIS2 الجهات المشمولة بتأمين اتصالاتها، وتُحدّد لائحة التنفيذ (EU) 2024/2690 المتطلبات التقنية للجهات البنية التحتية الرقمية التي تشملها — تتطلب ملحقها (البند 6.7.2(ك)) خطة تنفيذ لنشر معايير أمان البريد الإلكتروني الحديثة المتفق عليها دولياً، والبند (6.7.2(ل)) يتطلب أفضل ممارسات أمان DNS. سياسة DMARC المُطبَّقة مع SPF وDKIM في الأسفل هي الضابط المدقَّق المعترف به لمكافحة التزوير؛ p=none هي مراقبة بشكل واضح لا تأمين. إذا كان عملاؤك مشمولين بـ NIS2، فاستبياناتهم للموردين تطلب هذا بشكل متزايد.

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

كم يستغرق الطرح كله؟ ستة إلى عشرة أسابيع نموذجياً: 2–4 أسابيع مراقبة، 1–3 أسابيع إصلاح مصادر، 2–4 أسابيع ترفيع quarantine، ثم reject. إنه وقتٌ تقويمي لا جهد — معظمه انتظار للتقارير لتأكيد كل تغيير. 89.41% من 261,086,232 نطاق مُقيَّم بلا سياسة مُطبَّقة (بيانات حتى 2026-06-29) لم تبدأ الساعة في معظمها لأنها لم تنطلق أصلاً.

هل يمكنني تخطي quarantine واستخدام p=reject مع pct منخفضة؟ يمكنك — وفق RFC 7489 §6.6.4، p=reject; pct=10 يعني 10% مرفوضة و90% في مجلد الرسائل غير المرغوب فيها، تقريباً آخر المرحلة 3. لكن p=quarantine أولاً أسهل في التفكير، والمستقبلون يختلفون في دقة تطبيقهم للعيّنة. في كلا الحالَّين، المرحلتان 1–2 غير قابلتَّين للتفاوض: لا نوع من أنواع التطبيق آمنٌ بينما لا تزال مرسِلون شرعيون يفشلون.

ماذا عن البريد الذي لا أستطيع إصلاحه — برامج إعادة التوجيه والقوائم البريدية؟ إعادة التوجيه تكسر SPF بطبيعتها، وبعض القوائم البريدية تُعيد كتابة المحتوى فتكسر DKIM أيضاً. DKIM المتوافق يصمد أمام إعادة التوجيه العادية، مما يُعالج معظم الأمر؛ البقية الصغيرة هي لماذا توجد مرحلة quarantine — البريد في مجلد الرسائل غير المرغوب فيها قابلٌ للتعافي بينما تُقيّم التأثير. التفاصيل في يفشل بريد إعادة التوجيه في SPF.

هل التوقف عند p=quarantine كافٍ؟ إنه يُحقّق معظم القيمة، وأفضل بكثير من 37,312,637 نطاق متوقفة عند p=none (من 261,086,232 مُقيَّمة، بيانات حتى 2026-06-29) — لكن البريد المزوَّر لا يزال يصل إلى مجلدات الرسائل غير المرغوب فيها حيث يُستخرج. reject هو نقطة الوصول: فقط 10.59% من النطاقات المُقيَّمة تُطبّق أصلاً، والإتمام هو ما تُحسبه أدوات الفحص والمؤمّنون وأوراق الاستبيانات.

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

إذا كنت تُشغّل هذا الطرح لعميل أو صاحب عمل، خط النهاية قابلٌ للعرض. أعِد تشغيل الفحص المجاني بعد حل p=reject وأرسل التقرير المُقيَّم: النطاق ينتقل إلى سياسة مُطبَّقة، مؤرَّخاً وبلغة بسيطة. تلك الصفحة الواحدة تُجيب عن سطر أمان البريد الإلكتروني في تجديدات تأمين الأمن السيبراني واستبيانات موردّين NIS2 أفضل من لقطة شاشة للوحة DNS.

افحص سياسة DMARC الخاصة بك مجاناً

اعرف ما هي سياستك الحالية — وما إذا كان SPF وDKIM يستطيعان حمل التطبيق — بصورة خاصة وللمالك فقط.

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