ما هو DMARC؟
DMARC (مصادقة الرسائل المستندة إلى النطاق والإبلاغ والامتثال) هو بروتوكول لمصادقة البريد الإلكتروني يتحقق من توافق نطاق موثّق عبر SPF أو DKIM مع النطاق الموجود في عنوان From لرسالة بريد إلكتروني. يمكن لمالك النطاق نشر تفضيل المعالجة المطلوب للرسائل التي تفشل في التحقق من DMARC، وطلب تقارير تجميعية أو تقارير فشل خاصة بالرسائل.
لماذا يُعد DMARC ضروريًا
تعمل SPF وDKIM على مصادقة معرّفات الإرسال. لكنها لا تتحقق بمفردها من توافق المعرّف الموثّق مع النطاق الوارد في عنوان From، ولا تحدد تفضيل مالك النطاق لمعالجة الرسائل الفاشلة.
يحل DMARC هذه المشكلة من خلال:
- تحديد تفضيل المعالجة: none أو quarantine أو reject للرسائل التي تفشل في DMARC
- التحقق من التوافق: يجب أن يتوافق معرّف موثّق واحد على الأقل عبر SPF أو DKIM مع نطاق From
- طلب التقارير: توفر تقارير الفشل التجميعية والخاصة بالرسائل رؤية حول نتائج المصادقة المرصودة
كيف يعمل DMARC
1. ينشر المرسل سياسة DMARC في DNS (سجل TXT في _dmarc.domain.com)
2. يُرسل البريد الإلكتروني مع From: [email protected]
3. يتحقق المستلم من SPF وDKIM
4. يتحقق المستلم من التوافق: هل يتوافق النطاق الموثّق مع ترويسة From؟
5. قرار المعالجة: يأخذ المستلم السياسة المطلوبة والإشارات الأخرى في الاعتبار
6. قد تُرسل التقارير: قد ترسل الجهات المستلمة المشاركة تقارير الفشل التجميعية أو الخاصة بالرسائل عند طلبها
توافق DMARC
يتطلب DMARC التوافق: يجب أن يتوافق النطاق الوارد في ترويسة From مع معرّف موثّق واحد على الأقل وفق وضع التوافق المرن أو الصارم المحدد في السجل:
- توافق SPF: نطاق MAIL FROM الذي تم التحقق منه عبر SPF، أو نطاق HELO عندما يكون MAIL FROM فارغًا
- توافق DKIM: نطاق d= في توقيع DKIM صالح
من دون التوافق، يمكن أن ينجح SPF أو DKIM بينما يفشل DMARC. يعالج DMARC مباشرةً أشكالًا محددة من انتحال الهوية التي تستخدم نطاق From نفسه. ولا يكتشف النطاقات المشابهة بصريًا أو إساءة استخدام اسم المرسل المعروض.
تنسيق سجل DMARC
سجلات DMARC هي سجلات TXT في _dmarc.yourdomain.com:
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
وسوم DMARC
| الوسم | مطلوب | الوصف | المثال |
|---|---|---|---|
| v | نعم | الإصدار | v=DMARC1 |
| p | موصى به (اختياري) | تفضيل المعالجة المطلوب للبريد الذي يفشل في التحقق من DMARC | p=none/quarantine/reject |
| rua | لا | معرّف URI للتقرير التجميعي | rua=mailto:[email protected] |
| ruf | لا | معرّف URI لتقرير الفشل الخاص بالرسائل | ruf=mailto:[email protected] |
| t | لا | وضع اختبار السياسة | t=y أو t=n |
| sp | لا | السياسة المطلوبة للنطاقات الفرعية الموجودة | sp=reject |
| np | لا | السياسة المطلوبة للنطاقات الفرعية غير الموجودة | np=reject |
| adkim | لا | وضع توافق DKIM | adkim=s (صارم) أو adkim=r (مرن) |
| aspf | لا | وضع توافق SPF | aspf=s أو aspf=r |
وسم pct تاريخي. لم يعد معيار DMARC الحالي يستخدمه لتطبيق سياسة على نسبة مئوية من الرسائل الفاشلة. يوصى بوسم p لكنه اختياري، ويُعامَل السجل الصالح الذي لا يتضمنه على أنه p=none.
سياسات DMARC
p=none: لا يعبّر عن أي تفضيل لمعالجة الرسائل الفاشلة. يستخدمه مالكو النطاقات عادةً أثناء مراجعة التقارير.v=DMARC1; p=none; rua=mailto:[email protected]
p=quarantine: يطلب من المستلمين التعامل مع الرسائل التي تفشل في DMARC على أنها مشبوهة.
v=DMARC1; p=quarantine; rua=mailto:[email protected]
p=reject: يطلب من المستلمين رفض الرسائل التي تفشل في DMARC. يأخذ المستلمون هذا التفضيل مع الإشارات الأخرى في الاعتبار، لذلك لا يضمن الرفض.
v=DMARC1; p=reject; rua=mailto:[email protected]
مسار تطبيق DMARC
المرحلة 1: المراقبة (p=none)
ابدأ بالمراقبة لفهم منظومة البريد الإلكتروني لديك:
v=DMARC1; p=none; rua=mailto:[email protected]
حلّل التقارير لتحديد:
- خدمات الإرسال الشرعية التي تفتقد إلى SPF أو DKIM
- المرسلين غير المصرح لهم (الانتحال)
- مشكلات التوافق
المرحلة 2: الحجر (p=quarantine)
بعد مصادقة المصادر الشرعية:
v=DMARC1; p=quarantine; rua=mailto:[email protected]
راجع التقارير وتأكد من مصادقة البريد الشرعي قبل اختيار سياسة أكثر صرامة. لا يحدد معيار DMARC الحالي عملية نشر تدريجية بالنسبة المئوية.
المرحلة 3: الرفض (p=reject)
اطلب رفض الرسائل التي تفشل في DMARC:
v=DMARC1; p=reject; rua=mailto:[email protected]
تقارير DMARC
التقارير التجميعية (rua)
يوصى بأن ترسل الجهات المستلمة تقارير XML تجميعية يوميًا أو بوتيرة أكثر تكرارًا. تلخص التقارير تدفقات الرسائل المرصودة، لذلك يعتمد توفرها وتغطيتها على الجهات المستلمة التي ترسل التقارير:
- حجم البريد الإلكتروني
- معدلات نجاح أو فشل SPF وDKIM وDMARC
- عناوين IP المُرسِلة
- مؤسسات المستلمين
تقارير الفشل (ruf)
قد تتضمن التقارير الخاصة بالرسائل ترويسات الرسالة أو محتواها. لا ترسلها جميع الجهات المستلمة، وغالبًا ما يعود ذلك إلى مخاوف الخصوصية:
- تفاصيل فشل المصادقة
معالجة التقارير
تقارير DMARC التجميعية بصيغة XML وقد يصعب قراءتها. استخدم خدمات مثل:
- DMARC Analyzer
- Dmarcian
- Valimail
- Postmark DMARC
التحقق من DMARC
تبلغ تكلفة واجهة DomScan API لمصادقة البريد الإلكتروني، التي تتطلب المصادقة، 3 أرصدة لكل نطاق، وتعيد سجل DMARC والوسوم التي تم تحليلها.
dig _dmarc.example.com TXT
curl -H "X-API-Key: $DOMSCAN_API_KEY" "https://domscan.net/v1/email-auth?domain=example.com"
# Check dmarc.record and dmarc.tags in the JSON response
مشكلات DMARC الشائعة
عدم تلقي التقارير: تأكد من أن عنوان rua قادر على استقبال رسائل بريد إلكتروني كبيرة، إذ إن بعض الموفرين يرشحونها. فشل البريد الشرعي: تحقق من إعداد SPF وDKIM لجميع خدمات الإرسال، وتأكد من التوافق. فشل خدمات الجهات الخارجية: تتطلب خدمات كثيرة إعداد DKIM مخصصًا لتحقيق توافق DMARC.يضيف DMARC التوافق وتفضيل المعالجة المطلوب وإعداد التقارير إلى SPF وDKIM. راجع مصادر الإرسال والتقارير قبل طلب معالجة أكثر صرامة.