الإجابة المختصرة
كيف أضبط DMARC لنطاقي؟
انشر سجل TXT على _dmarc.yourdomain يقرأ: v=DMARC1; p=none; rua=mailto:you@yourdomain، واقرأ التقارير المجمّعة لنحو شهر، ثم ارفع السياسة إلى quarantine وأخيراً reject. DMARC معرّف بموجب RFC 9989 منذ مايو 2026. Postelva تستضيف السجل في محرر DNS المجاني لديها.
السياسات الثلاث لـ DMARC وما تفعله كل واحدة
| السياسة | السجل | الأثر على رسالة تفشل في DMARC | متى تُستخدم |
|---|---|---|---|
| مراقبة (Monitor) | v=DMARC1; p=none; rua=mailto:[email protected] | تُسلَّم كالمعتاد؛ وتُرسل إليك التقارير | الأسابيع الأولى، لرؤية كل مُرسِل |
| حجر صحي (Quarantine) | v=DMARC1; p=quarantine; rua=mailto:[email protected] | تُعامل كمشبوهة، وغالباً تُرسل إلى الرسائل المزعجة | بعد أن ينجح SPF وDKIM في كل بريدك المشروع |
| رفض (Reject) | v=DMARC1; p=reject; rua=mailto:[email protected] | يرفضها خادم المستقبِل | حين تُظهر التقارير ألا فشل مشروع متبقٍ |
إعداد DMARC في ست خطوات
تأكد من SPF وDKIM أولاً
يحتاج DMARC إلى أن ينجح واحد منهما على الأقل وأن يطابق نطاق From لديك. انشر الاثنين قبل DMARC، باتباع الأدلة الخاصة بـ SPF وDKIM.
اختر صندوق بريد للتقارير
أنشئ عنواناً مثل dmarc@yourdomain. تقول RFC 9989 إن على المالك إعداد صندوق بريد لاستقبال التقارير المجمّعة وتحليلها.
انشر سجل المراقبة
أضف سجل TXT باسم المضيف _dmarc والقيمة v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.
اقرأ التقارير لنحو شهر
تصل التقارير مرة في اليوم تقريباً من المستقبِلين الذين يرسلونها. ابحث عن بريد مشروع يفشل في محاذاة SPF وDKIM، وأصلح هؤلاء المُرسِلين.
انتقل إلى quarantine
غيّر p=none إلى p=quarantine. أبقِه لفترة مماثلة، وقارن كيف تعاملت الرسائل في التقارير.
انتقل إلى reject، أو توقف عند quarantine
غيّر إلى p=reject حين تكون التقارير نظيفة. إذا كنت تنشر في قوائم بريدية من هذا النطاق، فابقَ على quarantine.
; stage 1: monitor
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
; stage 2: quarantine
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
; stage 3: reject
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"ماذا يحتوي سجل DMARC؟
سجل DMARC هو سجل TXT على _dmarc.yourdomain يبدأ بـ v=DMARC1 ويسرد وسوماً مفصولة بفواصل منقوطة. وسم الإصدار يأتي أولاً وهو حساس لحالة الأحرف. تعرّف RFC 9989 هذه الوسوم: p (سياسة النطاق)، وsp (سياسة النطاقات الفرعية الموجودة)، وnp (سياسة النطاقات الفرعية غير الموجودة)، وadkim وaspf (المحاذاة، وr للمرنة أو s للصارمة، والمرنة افتراضياً)، وrua (عناوين التقارير المجمّعة)، وruf (عناوين تقارير الفشل)، وfo (خيارات الفشل)، وt (وضع الاختبار، y أو n)، وpsd.
إذا غابت p، يعامل المستقبِل السياسة كأنها none. وإذا غابت sp، فإن السياسة p تشمل النطاقات الفرعية. وإذا غابت rua، فلا تُنتج أي تقارير مجمّعة. لذلك يتكون سجل مفيد في حده الأدنى من ثلاثة أجزاء: الإصدار، وسياسة، وعنوان تقرير.
وسم pct الذي ما زالت أدلة كثيرة قديمة تعرضه أزالته RFC 9989، لأنه نادراً ما كان يُطبَّق بدقة إلا عند 0 و100. ويحل محله الوسم t: t=y يتصرف مثل pct=0، وt=n مثل pct=100، وn هو الافتراضي. احذف pct من السجلات القديمة. الخلفية الأوسع في SPF وDKIM وDMARC معاً.
ماذا تعني المحاذاة في DMARC؟
تعني المحاذاة أن النطاق الذي توثّقه SPF أو DKIM يطابق النطاق الظاهر في عنوان From. في الوضع المرن، وهو الافتراضي، يكفي أن يكون الاثنان على النطاق التنظيمي نفسه، فـ mail.example.com يتوافق مع example.com. وفي الوضع الصارم يجب أن يكونا متطابقين. تشير RFC 9989 إلى أن أغلب مالكي النطاقات يجدون المحاذاة المرنة كافية.
تنجح الرسالة في DMARC حين ينجح SPF أو DKIM وتكون محاذاة. يكفي أيٌّ منهما. ويوقّع مزوّد صندوق بريد مثل Proton Mail أو Fastmail باسم نطاقك عبر سجلات DKIM من نوع CNAME، فتتحقق المحاذاة دون جهد إضافي. والفخ هو خدمة طرف ثالث توقّع بنطاقها هي: ينجح DKIM لديها لكنه لا يتطابق حتى تضبط نطاق توقيع مخصصاً لها.
تجد RFC 9989 النطاق التنظيمي عبر مسار شجرة DNS، بحد أقصى ثمانية استعلامات، بدلاً من قائمة اللاحقات العامة. بالنسبة إلى نطاق عادي على .com أو .me لا يغيّر هذا أي شيء عليك فعله.
إلى متى ينبغي أن أبقى على p=none؟
ابقَ على p=none لشهر على الأقل، ثم على p=quarantine لفترة مماثلة، قبل p=reject. هذا هو الترتيب الذي تنصح به RFC 9989 في إرشادات النشر، وهو يتطابق مع صفحات مساعدة المزوّدين. يبدأ Mailbox.org سجله النموذجي بـ p=none ويحذّر من أن سياسة صارمة تُفرض مبكراً قد ترتد بريداً مشروعاً. وينصح Proton بـ p=quarantine والانتقال إلى p=reject بعد أن ينجح البريد المشروع.
بحسب قراءة Postelva بتاريخ 12 نوفمبر 2026 لإرشادات DMARC لدى المزوّدين الثلاثة الذين ينشرونها (Proton Mail وMailbox.org وMailfence)، يبدأ اثنان منهم بـ p=none، ويوصي واحد بـ p=quarantine.
هناك تحذيران لـ p=reject. تقول RFC 9989 إن النطاق الذي يستخدمه لا يجب أن يعتمد على SPF وحده، ويجب أن يوقّع بـ DKIM، لأن SPF ينكسر عند التحويل. وتقول أيضاً إن النطاقات التي يرسل مستخدموها إلى القوائم البريدية لا ينبغي أن تنشر p=reject على الإطلاق. فالقوائم كثيراً ما تعدّل الرسائل، وهذا يكسر التوقيع.
أين تذهب تقارير DMARC وماذا تُظهر؟
تذهب التقارير المجمّعة إلى عنوان mailto: الموجود في rua، عادة مرة في اليوم من كل مستقبِل، وتسرد المصادر التي أرسلت بريداً بنطاقك في سطر From. تشترط RFC 9989 أن يدعم المستقبِلون عناوين mailto: وتوصي بإرسال التقارير المجمّعة على الأقل كل 24 ساعة. ويُعرَّف الإبلاغ المجمّع في RFC 9990.
تقارير الفشل، التي يُطلب بـ ruf، هي نسخ لكل رسالة. كثير من المستقبِلين يحجبونها أو يحجبون أجزاء منها حماية للخصوصية، لذلك لا تعتمد عليها. وإذا كان عنوان rua خارج نطاقك، فيجب على مالك ذلك النطاق الآخر أن يفوّضه بسجل TXT على yourdomain._report._dmarc.otherdomain يحتوي v=DMARC1;، وهي قاعدة توقف إساءة استخدام صناديق البريد الخاصة بأطراف ثالثة. بالنسبة إلى نطاق شخصي صغير، تكون قائمة المصادر قصيرة: مزوّدك، ولا شيء آخر تقريباً.
لقراءة ما ينشره DNS لديك قبل كل مرحلة وبعدها، استخدم الأوامر الخاصة بفحص سجلات MX وSPF وDKIM وDMARC.
هل يحتاج نطاقي الشخصي إلى DMARC؟
نعم، لأي نطاق يرسل بريداً: يكلّف سجل TXT واحد، ويحجب الرسائل المزوّرة التي تستخدم اسمك. تشترط Google وجود DMARC، وتكفي فيه سياسة none، للمُرسِلين الذين يتجاوزون 5,000 رسالة في اليوم إلى حسابات Gmail، وتطبّق Microsoft العتبة نفسها على Outlook.com. صندوق البريد الشخصي يقع بعيداً جداً عن هذه الحدود. ومع ذلك يخبر السجل المستقبِلين بما تريد أن يفعلوه بالتزوير.
بالنسبة إلى نطاق لا يرسل أي شيء، اضبط p=reject فوراً مع SPF -all وMX فارغ. تقدّم Postelva قالب «بلا بريد» لهذه الحالة. أما النطاق الذي له صندوق بريد، فابدأ بـ none. والجانب النقلي من الحماية نفسها، أي التشفير بين الخوادم، مشروح في كيف تُعدّ MTA-STS وTLS-RPT.
تعريف يمكن الاستشهاد به: DMARC هو سياسة DNS تخبر المستقبِلين بما يفعلونه بالرسائل التي لا تتطابق نتائج SPF وDKIM فيها مع نطاق From، وأين يرسلون التقارير عنها.
أسئلة حول إعداد DMARC
هل تشترط RFC 9989 استخدام p=reject؟
لا. يحدد المعيار ثلاث سياسات ويترك الاختيار لمالك النطاق. وينصح بمسار تدريجي، ويحذّر من p=reject للنطاقات التي ينشر مستخدموها في القوائم البريدية.
هل تغيّر RFC 9989 سجل DMARC الحالي لديّ؟
ما زالت السجلات تبدأ بـ v=DMARC1، فالسجل العامل يبقى عاملاً. أُسقط وسم ri، وأُزيل pct، وأُضيفت t وnp وpsd.
ماذا يحدث إذا نشرت p=reject مبكراً جداً؟
البريد المشروع الذي يفشل في المحاذاة، مثل أداة نشرات منسية، يرفضه المستقبِلون. وتقارير p=none موجودة لاكتشاف هؤلاء المُرسِلين أولاً.
هل يمكنني استخدام صندوق بريد مجاني للتقارير؟
نعم، أي صندوق بريد تقرؤه. عنوان منفصل أو اسم مستعار يُبقي ملفات التقارير اليومية خارج صندوق الوارد الرئيسي.
كم عدد سجلات DMARC التي يمكن أن يملكها النطاق؟
سجل واحد لكل اسم، على _dmarc.yourdomain. ويمكن للنطاقات الفرعية أن تملك سجلها الخاص، أو أن ترث سياسة النطاق الأب عبر sp.
في الخلاصة
- DMARC سجل TXT على _dmarc.yourdomain يبدأ بـ v=DMARC1.
- RFC 9989 (مايو 2026) هي المواصفة الحالية؛ وهي تُلغي RFC 7489 وتزيل pct.
- ابدأ بـ p=none مع عنوان rua، واقرأ التقارير لنحو شهر.
- ثم p=quarantine لفترة مماثلة، ثم p=reject.
- تنجح الرسالة حين ينجح SPF أو DKIM ويتطابق مع نطاق From؛ والمحاذاة المرنة هي الافتراضي.
- النطاق الذي يستخدم p=reject لا يجب أن يعتمد على SPF وحده، ولا ينبغي استخدامه مع القوائم البريدية.
- Postelva تستضيف السجل في DNS مجاني؛ و.com يكلّف 12.49 US$/سنة كل عام.
المصادر (6)
- RFC 9989, Domain-based Message Authentication, Reporting, and Conformance (DMARC) — RFC Editor (قُرئت 2026-11-12)
- RFC 7489, DMARC (ملغاة) — RFC Editor (قُرئت 2026-11-12)
- SPF وDKIM وDMARC لنطاق مخصص — Mailbox.org (قُرئت 2026-11-12)
- نطاق مخصص ومكافحة الانتحال — Proton (قُرئت 2026-11-12)
- إرشادات مُرسِلي البريد الإلكتروني — Google Workspace Admin Help (قُرئت 2026-11-12)
- تعزيز أمن البريد الإلكتروني: متطلبات جديدة للمُرسِلين بكميات كبيرة — Microsoft Tech Community (قُرئت 2026-11-12)