لماذا DMARCbis ولماذا الآن
كشف نشر RFC 7489 عام 2015 كوثيقة Informational عن ثلاثة قصور: أتاح الوسم pct تطبيق السياسة على نسبة مئوية فقط من الرسائل مما خفّف الحماية وجعل سلوك المستقبِلين غير متوقع؛ وغياب سياسة مخصصة للنطاقات الفرعية غير الموجودة أبقى ثغرة يستغلها المحتالون؛ واعتماد Public Suffix List (PSL) لتحديد النطاق التنظيمي أوجد تناقضات بين تطبيقات MTA المختلفة. تعالج RFC 9989 (نواة DMARC) وRFC 9990 (التقارير التجميعية) وRFC 9991 (تقارير الفشل) كل نقطة من هذه النقاط.
- RFC 9989 (نواة DMARCbis) — تُلغي RFC 7489 وRFC 9091؛ تُدخل الوسم
np، وتحذف pct، وتستبدله بالوسم t(وضع الاختبار)، وتُعرّف آلية Tree Walk DNS لتحديد النطاق الأصل دون الاعتماد على PSL - RFC 9990 (التقارير التجميعية) — تستخرج وتحدّث قسم التقارير التجميعية من RFC 7489؛ يبقى تنسيق XML المضغوط بـGZIP معتمداً لكن التحقق من وجهات التقارير الخارجية يصبح أكثر صرامة
- RFC 9991 (تقارير الفشل) — تستخرج تقارير الفشل؛ تُركّز على مخاطر الخصوصية وتُوجب تحديد معدل الإرسال لدى المولّدين لتفادي إساءة الاستخدام
- حذف
pct— يجب مراجعة أي سجل DMARC يحمل pct=50أو أي قيمة أخرى؛ قد يتجاهل المستقبِلون المتوافقون مع RFC 9989 هذا الوسم ويطبّقون السياسة على 100% من الرسائل - Tree Walk DNS — يصعد المستقبِل شجرة DNS عبر استعلامات متتالية (بحد أقصى 8) للعثور على السياسة المطبّقة، مما يُلغي الاعتماد على PSL ويُحسّن التوافق بين التطبيقات المختلفة
المتطلبات الأساسية قبل أي تعديل
تأكّد قبل أي تعديل من أن بنيتك التحتية تستوفي الأساسيات: يجب تهيئة SPF وDKIM بشكل صحيح على نطاق الإرسال — لا تُضيف DMARCbis شيئاً لهذين الآليتين لكنها تعتمد عليهما كلياً. تحقق أيضاً من توفر أدوات التدقيق (dig، nslookup، وصول SSH إلى VPS) وإمكانية الوصول إلى منطقة DNS. أخيراً، احرص على توفر تقارير DMARC التجميعية الحالية لتأسيس خط قياسي لحركة المرور المشروعة قبل تشديد السياسة.
دقّق سجل DMARC الحالي — نفّذ
dig TXT _dmarc.example.comمن VPS أو طرفية. دوّن القيمة الدقيقة لكل وسم: vوpوspوpctوruaوrufوadkimوaspf. إن كان pctموجوداً بقيمة أقل من 100، خطّط لإزالته.أزِل الوسم
pctأو استبدله — pctمُهمَل في RFC 9989. يحلّ محله في النشر التدريجي الوسمُ t: t=yيُخبر المستقبِل بمعاملة الرسالة كأن السياسة p=noneدون تطبيق الحجر أو الرفض. للانتقال من pct=50، استبدله بـt=y، راقب لأسابيع، ثم احذف t=y. مثال: v=DMARC1; p=quarantine; t=y; rua=mailto:[email protected]أضف الوسم
npللنطاقات الفرعية غير الموجودة — يُحدّد npالسياسة المطبّقة على رسائل تدّعي قدومها من نطاق فرعي غير موجود في DNS. لمنع التصيد عبر نطاقات فرعية وهمية، أضف np=reject. مثال كامل: v=DMARC1; p=quarantine; sp=quarantine; np=reject; rua=mailto:[email protected]افهم Tree Walk DNS وانشر على المستويات الصحيحة — مع Tree Walk، يستعلم المستقبِل عن
_dmarc.mail.app.example.comثم _dmarc.app.example.comثم _dmarc.example.comتوقفاً عند أول رد صالح (8 استعلامات DNS كحد أقصى). دقّق مناطق DNS للكشف عن سجلات _dmarc.*غير مقصودة قد تتجاوز سياستك الرئيسية.حدّث سجل DNS النهائي — بعد مراجعة الوسوم، انشر السجل المحدَّث. مثال كامل لنطاق في مرحلة التشديد:
v=DMARC1; p=quarantine; sp=quarantine; np=reject; adkim=s; aspf=s; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1تحقق من محاذاة DKIM في Postfix — تأكد من أن
adkim=s(صارم) لا يتعارض مع نطاقات فرعية تُوقّع بمفتاح مختلف. في الوضع الصارم، يجب أن يتطابق نطاق رأس From:تماماً مع نطاق d=في توقيع DKIM. عند الشك، استخدم adkim=r(متساهل) مؤقتاً.تحقق من محاذاة DKIM في Exim — تحقق في ملف إعداد Exim من أن
dkim_domainيتطابق تماماً مع النطاق المنشور في سجل DMARC. أي تباين تحت adkim=sيُفضي إلى فشل DKIM وقد يُفعّل سياسة الحجر أو الرفض.اختبر وتحقق من التقارير — انتظر 24 إلى 48 ساعة وحلّل تقارير XML التجميعية المستلمة على عنوان
rua. تُظهر حقول <policy_evaluated><dkim>و<policy_evaluated><spf>ما إذا كانت رسائلك تجتاز المحاذاة. يمكن لأدوات مثل MXToolbox أو mail-tester.com تحليل هذه التقارير.
للتحقق السريع من سجل DMARC من VPS، نفّذ dig TXT _dmarc.example.com +short ثم الصق القيمة في مدقق DMARC التابع لـMXToolbox (mxtoolbox.com/dmarc.aspx). يكشف الأداة عن الوسوم غير المعروفة، وتعارض pct/t، ويُبلّغ إن كان السجل صحيح صياغياً وفق RFC 9989. لمحاكاة Tree Walk، نفّذ dig TXT _dmarc.subdomain.example.com وdig TXT _dmarc.example.com بالتسلسل وقارن السياسات المُعادة في كل مستوى.
استكشاف الأخطاء الشائعة
لمعظم المشكلات سببٌ محدد قابل للحل — إليك الأكثر شيوعاً وكيفية معالجتها.
- تجاهل
pctمن قِبل مستقبِل — إن تجاهلت خوادم MTA المتوافقة مع RFC 9989 قيمة pct=50وطبّقت السياسة على 100% من الرسائل، ستُظهر تقاريرك التجميعية ارتفاعاً مفاجئاً في الرفض أو الحجر. أضف t=yفوراً للتحوّل إلى وضع الاختبار ريثما تُكيّف بنيتك. - سياسة
npمقيّدة أكثر من اللازم — إن كانت خدمة مشروعة ترسل من نطاق فرعي غير منشور في DNS، فإن np=rejectسيحجب رسائلها. ابدأ بـnp=quarantineوحلّل التقارير قبل الانتقال إلى reject. - Tree Walk يُنتج سياسة غير متوقعة — إن وجدت سجل
_dmarc.app.example.comيتيماً موروثاً من خدمة قديمة، سيُطبّقه مستقبِلو Tree Walk أولاً. احذف سجلات _dmarc.*غير المستخدمة بعد جرد شامل لمناطق DNS. - تقارير تجميعية فارغة أو غائبة — تحقق من إمكانية الوصول إلى عنوان
ruaوقبول MX لتقارير XML المضغوطة بـGZIP. قد تحجب بعض مرشّحات البريد غير المرغوب مرفقات .gz. تحقق أيضاً من الحجم الأقصى للرسائل المقبولة في خادم استقبال التقارير. - عدم تطابق
adkim=sمع Postfix متعدد النطاقات — إن كنت تستخدم نسخة Postfix واحدة لعدة نطاقات وكان مفتاح DKIM يُوقّع تحت example.comبينما يحمل From:القيمة newsletter.example.com، فإن المحاذاة الصارمة ستفشل. أضف مفتاح DKIM مخصصاً لكل نطاق فرعي أو انتقل إلى adkim=rلتلك النطاقات.
RFC 7489 مقابل RFC 9989: الفوارق التي تهم
يُلخّص الجدول أدناه الفوارق الجوهرية بين المواصفتين.
مرّر الجدول أفقيًا
| النقطة | RFC 7489 (2015) | RFC 9989 (2026) |
|---|---|---|
| الوسم `pct` | موجود — يطبّق السياسة على نسبة X% من الرسائل للنشر التدريجي | محذوف — يحلّ محله `t=y` (وضع الاختبار)؛ كل مستقبِل متوافق يطبّق السياسة على 100% من الرسائل |
| النطاقات الفرعية غير الموجودة | لا وسم مخصص — تُطبَّق `sp` أو `p` بشكل افتراضي | الوسم `np` مُدخَل — سياسة مستقلة للنطاقات الفرعية الغائبة عن DNS |
| اكتشاف النطاق الأصل | يعتمد على Public Suffix List (PSL) المُدارة خارج IETF وتختلف بحسب المنفّذ | Tree Walk DNS — صعود شجرة DNS عبر استعلامات متتالية بحد 8، مُعرَّف في المعيار |
| التقارير | التقارير التجميعية وتقارير الفشل في RFC 7489 واحدة | ثلاث وثائق مستقلة: 9989 (النواة) و9990 (تجميعية) و9991 (فشل) — قابلية توسعة أفضل |
| الحالة | Informational — مرجع لكن خارج مسار المعايير | Proposed Standard (Standards Track) — سلطة IETF الكاملة، أساس لتطبيقات MTA المستقبلية |
التكيّف الآن أو مواجهة التبعات لاحقاً
لا تُطبّق DMARCbis بشكل موحّد بعد من قِبل جميع خوادم MTA أعلنت Google وMicrosoft وYahoo عن مراحل اختبار لـTree Walk لكن لم تُحدَّد أي مواعيد قطع رسمية. هذا لا يُبرر الانتظار: وثائق RFC 9989 و9990 و9991 موجودة على مسار Standards Track، والتطبيق التدريجي جارٍ، وأولى تباينات تفسير pct بين المستقبِلين تظهر بالفعل. حذف pct وإضافة np وتدقيق مناطق DNS لـTree Walk خطوات دفاعية لا تُعطّل شيئاً على المستقبِلين المتمسكين بـRFC 7489 — يتجاهل القدامى np، وحذف pct لا يُحدث أثراً إلا إن كان المستقبِل يُطبّق RFC 9989 فعلاً.
