التعريف
DMARC (Domain-based Message Authentication, Reporting, and Conformance) آلية قابلة للتوسع لمصادقة البريد الإلكتروني، تتيح لمالك النطاق نشر سياسة قابلة للقراءة الآلية في DNS تُعلن ما يجب على خوادم البريد المستلمة فعله عندما تفشل رسالة واردة في فحوصات محاذاة SPF أو DKIM، وتمكّن تلك الخوادم من إرسال تقارير منظمة إلى مالك النطاق. قيم سياسة DMARC الثلاث — none وquarantine وreject — تمنح مالكي النطاقات تحكمًا متدرجًا في كيفية تعامل البنية المستقبلة العالمية مع البريد غير المُصادَق عليه الذي يدّعي أنه من نطاقهم.
طُوّر DMARC تعاونيًا من قبل مجموعة من المشاركين في الصناعة بمن فيهم PayPal وGoogle وMicrosoft وYahoo وReturnPath وأصحاب مصلحة آخرون في النظام البيئي للبريد، ونُشر أول مرة كـIETF RFC 7489 في مارس 2015. تصون المواصفة مجموعة عمل DMARC.org. توسع وتنسق معيارَين سابقَين للمصادقة: SPF (RFC 7208) وDKIM (RFC 6376)، اللذين تستخدمهما كإشارات إدخال دون أن تستبدلهما.
كيف يعمل
تُنشر سياسة DMARC كسجل DNS TXT في _dmarc.<النطاق>. مثال نموذجي: v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; adkim=s; aspf=s. الوسوم الرئيسية:
v=DMARC1— معرّف الإصدارp=— السياسة:none(مراقبة فقط)، أوquarantine(التسليم إلى البريد العشوائي/غير المرغوب)، أوreject(التخلص من الرسالة كليًا)rua=— وجهة URI لتقرير التجميع؛ تتلقى ملخصات XML يومية لنتائج المصادقة من مزودي صناديق البريد المشاركينruf=— وجهة URI للتقرير الجنائي؛ تتلقى تقارير على مستوى الرسالة معدّلة لإخفاء البيانات الحساسةpct=— النسبة المئوية للرسائل التي تنطبق عليها السياسة (يسمح بنشر مرحلي)adkim=وaspf=— وضع المحاذاة:s(صارم، يتطلب تطابقًا تامًا للنطاق) أوr(متساهل، يسمح بمطابقة النطاق الفرعي)
الابتكار الجوهري الذي يقدمه DMARC هو محاذاة المعرّف. لا يُعتبر اجتياز SPF أو DKIM متوافقًا مع DMARC إلا إذا كان النطاق المُصادَق عليه متوائمًا مع نطاق رأس RFC5322.From — عنوان “From:” الذي يراه مستخدمو البريد. يُغلق هذا الفجوة التي يتركها عمل SPF وDKIM المستقل: قد تجتاز رسالة SPF على نطاق مختلف (مرسِل المظروف) وتجتاز DKIM لنطاق توقيع طرف ثالث، ومع ذلك تكون احتيالية إذا كان رأس From يعرض نطاقًا مختلفًا. يتطلب DMARC أن ينتج SPF أو DKIM على الأقل اجتيازًا متوائمًا.
تُسلَّم تقارير التجميع (RUA) عادة كملفات XML مضغوطة، خلال 24 ساعة من نهاية فترة التقرير، من مزودي صناديق البريد بمن فيهم Google (Gmail) وMicrosoft (Outlook/Exchange Online Protection) وYahoo Mail وApple iCloud Mail وComcast وآخرين. تحتوي هذه التقارير على عدد الرسائل لكل IP مصدر، ونتائج SPF، ونتائج DKIM، وتصرّف DMARC. توفر أدوات مثل DMARCIAN وValimail وPostmark DMARC Digests وGoogle Postmaster Tools لوحات تحكم تحلل هذه التقارير وتمثلها بصريًا.
أين تصادفها
يُصادف DMARC أينما حدث إرسال بريد بحجم مرتفع أو رهان عالٍ. منذ فبراير 2024، تطلب كل من Google وYahoo من مرسلي أكثر من 5,000 رسالة يوميًا إلى عناوين Gmail أو Yahoo Mail أن يكون لديهم سجل DMARC منشور بحد أدنى p=none — تغيير سياسي صناعي مهم جعل DMARC إلزاميًا فعليًا للمرسلين بكميات كبيرة. أعلنت Microsoft عن متطلبات مماثلة لصناديق بريد المستهلكين على Outlook.com في 2025.
بالنسبة لمنصات المسابقات التي ترسل أصوات تأكيد عبر البريد على نطاق واسع، يخدم DMARC دورين. أولًا، يحمي سمعة نطاق الإرسال بتعليمات الخوادم المستلمة برفض الرسائل المزورة — فيمنع طرفًا ثالثًا من انتحال عنوان From الخاص بمنصة المسابقة في حملات تصيّد، مما قد يضر بمكانة قابلية التسليم للنطاق. ثانيًا، توفر تقارير DMARC التجميعية قناة مراقبة تشغيلية: يستطيع مالك النطاق رؤية نسبة الرسائل الصادرة التي تجتاز SPF وDKIM عبر مزودي صناديق البريد المشاركين، ووضع علامة على أي تكوين خاطئ في البنية قبل أن يتسبب في إخفاقات بالجملة في رسائل تأكيد المسابقة.
ينشر مزودو خدمات البريد بمن فيهم SendGrid وMailgun وAmazon SES وPostmark وSparkPost إرشادات لتهيئة DMARC مع بنية الإرسال الخاصة بهم. أدوات تشخيص DNS بما فيها MXToolbox DMARC Lookup وDMARC Inspector من DMARCIAN ومدقق سجلات EasyDMARC تتيح لمالكي النطاقات التحقق من السياسات المنشورة.
أمثلة عملية
تبدأ شركة مسابقات بإرسال رسائل تأكيد باستخدام نطاق فرعي جديد confirm.votes.example.com. النطاق الأم votes.example.com لديه p=reject في سجل DMARC. ولأن سجلات SPF وDKIM للنطاق الفرعي الجديد لم تُهيأ بعد، تفشل رسائل التأكيد في محاذاة DMARC وتُرفض من قبل Gmail. يشخّص المدير المشكلة عبر بيانات تقرير التجميع التي تُظهر فشل DMARC بنسبة 100% على النطاق الفرعي، ويضيف سجلات DNS المناسبة من نوع SPF include ومُحدّد DKIM، ويعيد ضبط سياسة النطاق الفرعي لـDMARC (sp=none) مؤقتًا أثناء النشر.
تجري علامة تجارية مسابقة لتقديم الصور بجوائز إجمالية 50,000 دولار. يحاول مزور إرسال رسائل تصيد باستخدام نطاق المسابقة كعنوان From، موجّهًا الناخبين إلى صفحة تأكيد مزيفة لجمع بيانات اعتماد البريد. ولأن سياسة DMARC للنطاق p=reject، يتجاهل Gmail وOutlook وYahoo Mail جميعًا الرسائل الاحتيالية قبل التسليم، فتحمي كلًا من المشاركين وسمعة المرسل للعلامة التجارية.
مفاهيم ذات صلة
يعتمد DMARC على كل من سجل SPF و**DKIM** كمدخلات للمصادقة — يتطلب اجتياز DMARC أن يكون أحدهما على الأقل متوائمًا مع نطاق رأس From. في عمليات المسابقات، تأثير SPF وDKIM وDMARC المركّب على وضع البريد في صندوق الوارد هو العامل التقني الأساسي الذي يحدد ما إذا كانت رسائل تأكيد الصوت بالبريد ستصل إلى صناديق الناخبين. معيار BIMI الذي يسمح بعرض شعار العلامة في عملاء صناديق البريد كمؤشر ثقة يتطلب سياسة DMARC p=quarantine أو p=reject كشرط مسبق.
