كيفية قراءة سياسة DMARC لشركة ما في عشر ثوانٍ (وما الذي لا تخبرك به)

يخبرك بحث DNS واحد بما طلبته الشركة من خوادم البريد في العالم أن تفعله برسائل البريد المزيفة المرسلة باسمها. السجل عام، والأمر هو سطر واحد: dig +short TXT _dmarc.example.com. ما يظهر هو سلسلة نصية قصيرة من الإعدادات، وداخلها تعليمة واحدة — p=none أو p=quarantine أو p=reject — تحدد تفضيل صاحب المجال عندما تفشل رسالة تستخدم ذلك المجال في المصادقة.

المواصفة الحالية، RFC 9989، التي نُشرت في مايو 2026 كمستند مسار معايير IETF [معهد مهندسي الكهرباء والإلكترونيات]، حلّت محل RFC 7489 الأقدم. وهي تعرّف القيم الثلاث بإيجاز شديد:

• p=none — "صاحب المجال لا يعبّر عن أي تفضيل."
• p=quarantine — "يعتبر صاحب المجال هذا البريد مريباً. من الممكن أن يكون البريد صحيحاً، لكن الفشل يثير قلقاً كبيراً."
• p=reject — "يعتبر صاحب المجال جميع حالات الفشل هذه دليلاً واضحاً على أن استخدام اسم المجال غير صحيح."

أعد قراءة هذه الكلمات، لأنها أضعف من معظم الشروحات التي يقدمها DMARC. السياسة هي تفضيل، ينشره المرسل ليأخذه المستقبلون في الاعتبار. وليست تعليمة يجب على المستقبل تنفيذها. تقول RFC 9989 ذلك في جملة واحدة: "المعالجة النهائية لأي رسالة هي دائماً مسألة سياسة محلية وتُترك لتقدير مستقبِل البريد." والقسم نفسه يضيف كلا جانبي النتيجة — يمكن لمستقبلي البريد "أن يختاروا رفض أو عزل رسالة حتى لو اجتازت فحص التحقق من DMARC"، و"يجب ألا يرفضوا الرسائل فقط لأنها تأتي مع سياسة منشورة تقول 'رفض'"، تماماً لأن البريد الشرعي المرسل بطرق لا يستطيع DMARC أن يصفها، وقوائم البريد، قد لا تُدمّر في هذه العملية.

فما الذي يعترف به p=none فعلياً؟ أقل مما يُتهم به عادة. بحسب شروط المواصفة نفسها، إنها وضع المراقبة: صاحب المجال يجمع التقارير الإجمالية و"لا يعبّر عن أي تفضيل للتعامل مع الرسائل التي تفشل في التحقق من DMARC"، بينما يمكن لمستقبِل يطبّق DMARC أن "لا يزال" يتحقق من استخدام المجال. ما لا تفعله هو إيقاف أي شيء على الطرف المستقبِل. مرشح البريء العشوائي لدى مزودك الخاص، وتصنيف السمعة، وفحوصات عناوين URL وتحليل المرفقات، كل هذه آليات منفصلة تعمل بغض النظر عما نشره المرسل. رسالة مزيفة تصل إلى مجال p=none لا يتم ترقيتها إلى صندوق الوارد الخاص بك من خلال السجل؛ يتم ببساطة تسليمها إلى المستقبِل دون تفضيل معلن، والمستقبِل هو من يقرر.

يسير نصف سوء الفهم الآخر في الاتجاه الآخر. DMARC لا يقرأ الجزء الخطير من رسالة بريد إلكتروني احتيالية. تحدد مواصفتها الخاصة ما هو مقصود أن يكون خارج النطاق، و"تحليل المحتوى" موجود في تلك القائمة، بتلك الكلمات. كما أنها تنص على أن DMARC "لا تعالج استخدام أسماء النطاقات المتشابهة بصرياً أو إساءة استخدام اسم العرض البشري القابل للقراءة في RFC5322.From" — الحيلتان اللتان تحمل معهما معظم رسائل الانتحال بالعلامات التجارية. وفيما يتعلق بقيمة النجاح: "النجاح في DMARC وحده لا يضمن أن التسليم إلى صندوق وارد المستقبِل سيكون آمناً أو مرغوباً فيه." رسالة موثوقة بشكل صحيح من مجال قابل للتصرف تجتاز DMARC بنجاح. DMARC يجيب على سؤال من كان مصرحاً له باستخدام المجال في رأس From:. لا شيء أكثر.

هنا تأتي قواعد المرسلين بكميات كبيرة لعام 2024، التي يتم الإبلاغ عنها بشكل روتيني بطريقة خاطئة، بما في ذلك في النسخة الأولى من هذه المقالة. تتطلب إرشادات المرسلين من Google أن يقوم مرسلو 5,000 رسالة أو أكثر يومياً إلى حسابات Gmail بـ "إعداد مصادقة بريد DMARC لنطاق الإرسال الخاص بك"، ثم تقول، في النفس ذاته: "يمكن تعيين سياسة إنفاذ DMARC الخاصة بك إلى none." في Sender Hub الخاص بـ Yahoo، والذي يجب قراءته بشكل منفصل بدلاً من افتراض أنه ينسخ Google، تُصاغ المتطلبات كـ "نشر سياسة DMARC صحيحة بـ p=none على الأقل - يجب أن تنجح DMARC"، ولا تنشر أي حد أدنى للحجم الرقمي على الإطلاق. دخلت كلا مجموعتي المتطلبات حيز التنفيذ من فبراير 2024. لا أحد منهما يفرض على أحد الابتعاد عن p=none. ما يفرضه كلاهما فعلياً هو مصادقة متسقة: تتطلب Google أن "يكون المجال في رأس From: للمرسل متوافقاً إما مع مجال SPF أو مجال DKIM"، وتقول Yahoo أن المحاذاة المريحة مقبولة. المحاذاة، وليس الشدة، هي البوابة.

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

لا تحتاج إلى طرفية للبحث. أدوات البحث المجانية — فاحص المجال من dmarcian و DMARC check من MXToolbox — تجلب السجل وتطبع السياسة لك. افعلها لبنكك وموفر الرواتب الخاص بك والخط الجوي الذي تطير معه. فقط اقرأ الإجابة لما هي عليه: بيان نية من صاحب المجال، مدخل واحد بين عديد من المدخلات في قرار يتخذه موفر البريد الخاص بك بمفرده، عن نوع واحد محدد من الانتحال. هذا شيء مفيد حقاً أن تكون قادراً على قراءته في عشر ثوانٍ. وليس حكماً حول ما إذا كانت الرسالة التالية التي تدّعي أنها من تلك العلامة التجارية آمنة أم لا.

تصحيح، 20 أكتوبر 2026. وصفت نسخة سابقة من هذه المقالة p=none بأنها توصل الرسائل المزيفة إلى صندوق الوارد و p=reject بأنها الإعداد الوحيد الذي يمنع رسالة مزيفة، وقالت أن قواعد المرسلين بكميات كبيرة من Google و Yahoo لعام 2024 فرضت على المرسلين الابتعاد عن p=none، وأوردت رقماً بحوالي واحد من ثلاثة نطاقات في الإنفاذ. تم تصحيح وصف السياسة مقابل RFC 9989؛ Google و Yahoo فعلاً يقبلان p=none، كما هو مقتبس أعلاه من توثيقهما الخاص؛ وتم حذف رقم الإنفاذ لأن التقرير الأساسي لا ينشر عينته أو مقامه. تنص المقالة الآن أيضاً على ما لا تفحصه DMARC.