DMARC p=none مراقبة وليس حماية

قد يبدو DMARC record كأنه تقدم في email security، لكنه قد لا يحظر شيئاً تقريباً. هذا هو الجزء غير المريح في أرقام CipherCue الجديدة: ضمن 67,336 company domains تم فحصها بين 14 أبريل و28 يوليو 2026، كانت 68.4% إما بلا DMARC record أو ما زالت على p=none.

هذه ليست ثغرة جديدة. إنها control غير مكتمل. DMARC متاح منذ 2012، وفي مايو 2026 استبدلت IETF الوثيقة القديمة RFC 7489 بالعائلة RFC 9989 و RFC 9990 و RFC 9991. أصبح core protocol الآن Standards Track Proposed Standard. المشكلة ليست أن الناس لا يعرفون DMARC، بل أن مؤسسات كثيرة توقفت عند “نجمع reports” ولم تصل إلى “نطلب من المستلمين رفض انتحال نطاقنا”.

DMARC مفيد، لكنه ليس سحراً ضد phishing. هو يعالج exact-domain spoofing في visible From address. لا يوقف lookalike domains أو display-name spoofing أو الحسابات الشرعية المخترقة أو phishing المرسل من منصة كبيرة مع authentication صالح. ومع ذلك، إذا كان نطاق شركتك قابلاً للتزوير المباشر، فأنت تترك للمهاجمين طريقاً سهلاً.

يعتمد DMARC على SPF و DKIM. يحدد SPF الخوادم المسموح لها بالإرسال باسم النطاق. يوقع DKIM الرسائل بمفتاح نطاق. يتحقق DMARC مما إذا كانت authenticated identity متوافقة مع visible From domain، ثم يخبر receiving mail systems بما يريده مالك النطاق عند الفشل.

هناك ثلاث سياسات شائعة. p=none تعني المراقبة وإنتاج reports. p=quarantine تطلب التعامل مع الرسائل الفاشلة كرسائل مشبوهة. p=reject تطلب رفضها. يبقى للمستلمين قدر من القرار، لكن الفرق واضح: p=none إنذار يكتب logs، وليس باباً مغلقاً.

في snapshot الخاص بـ CipherCue، كان 30,362 domains، أي 45.1%، بلا DMARC record. ومن بين النطاقات التي لديها record، كان 15,709 على p=none، و10,258 على p=quarantine، و10,963 على p=reject. تعتبر CipherCue أن enforcement يعني p=quarantine أو p=reject، ولذلك كان 46,071 domains في sample بحالة non-enforcing.

يجب قراءة الأرقام بحذر. تقول CipherCue إن هذا tracked entity set خاص بها، وليس عينة تمثيلية لكل شركات العالم. وفي Hacker News طُرح سؤال منهجي مهم: كم نطاقاً في هذه المجموعات parked أو inactive أو send-only أو بلا MX records عادية؟ هذا لا يلغي المشكلة، لكنه يمنع تحويل vendor dataset كبير إلى إحصاء عالمي كامل.

يبقى gap قائماً لأن p=reject ليس تعديل DNS بسيطاً. إنه inventory project.

يجب أن تعرف المؤسسة كل مصدر شرعي يرسل باسم نطاقها: Microsoft 365 أو Google Workspace، و CRM، و marketing automation، و billing، و helpdesk، و HR tools، و ticketing، وخوادم قديمة، و scanners، و outsourced senders، وتطبيقات منسية. يحتاج كل stream إلى SPF أو DKIM alignment. أما unknown senders فيجب إصلاحها أو نقلها إلى subdomain أو إيقافها.

التقارير نفسها عقبة. DMARC aggregate reports، الموصوفة الآن في RFC 9990، هي XML مقروء آلياً. هذا جيد للأتمتة، لكنه مربك لمؤسسة صغيرة نسخت DNS example ولا تملك أداة تحول XML إلى قرارات.

الخوف من كسر البريد الشرعي حقيقي. إذا فشل نظام الفواتير في DKIM alignment، فقد تضيع invoices مع p=reject. وإذا أرسلت منصة الدعم عبر route سيئ الإعداد، فقد يؤدي enforcement إلى شكاوى العملاء. لا أحد يريد “تحسين الأمن” ثم كسر password resets.

وصفت Microsoft في يناير 2026 phishing يستغل complex routing و misconfigured spoof protections. الدرس العملي: routing و connectors و forwarding و gateways يمكن أن تغير شكل authentication عند المستلم.

المسار الآمن تدريجي. ابدأ بـ domain inventory: primary sending domains و marketing subdomains و transactional subdomains و parked domains والنطاقات التي لا يجب أن ترسل بريداً أبداً. بالنسبة إلى no-send domains، غالباً يساعد SPF v=spf1 -all و DMARC p=reject; sp=reject في إغلاق مسار إساءة بسيط.

بالنسبة إلى active domains، يجب أن تكون p=none temporary monitoring phase فقط. استخدم reporting address يقرأه شخص فعلاً، وأداة تحول XML إلى قرارات. بعد ذلك أصلح alignment، خصوصاً DKIM مع third-party services و forwarded mail.

ثم انتقل على مراحل: p=none ثم p=quarantine ثم p=reject. راقب helpdesk tickets و bounce logs و deliverability dashboards و DMARC reports. سجّل لكل sender: owner و platform و domain/subdomain و authentication method و rollback contact.

DMARC لن يجعل phishing يختفي. لكنه عند enforcement يزيل خدعة رخيصة: رسالة تبدو كأنها جاءت مباشرة من نطاقك بينما authentication يفشل. p=none مفيد كمرحلة تعلم، لكنه كحالة دائمة يصبح control يراقب ولا يحمي.