لماذا لا تنتقل محفظة العملاء إلى reject دفعة واحدة
يمكن إدارة نطاق واحد بالنظر، أما المحفظة فلا: لكل عميل أدوات لا تعرفها الوكالة دائمًا بالكامل. والدافع غالبًا خارجي. ففي 1 فبراير 2024 بدأ Gmail يطلب SPF وDKIM وDMARC من المرسِلين الذين يتجاوزون 5000 رسالة يوميًا، ويضع Yahoo شرطًا مشابهًا، وتطبّق Outlook.com قواعد مماثلة على الأحجام الكبيرة. وعند Gmail وYahoo معًا يكون الحد الأدنى سجل DMARC منشورًا بسياسة p=none: فهذه الشروط لا تطلب منك الانتقال إلى reject. ما يدفع إلى ذلك هو انتحال الهوية: عميل يُستخدم اسمه لإرسال فواتير مزيفة، أو تصل فواتيره الحقيقية إلى البريد غير المرغوب.
والخطر ذو اتجاهين. فسياسة reject المنشورة مبكرًا ترفض بريدًا شرعيًا، وأنت من سيتصل به العميل. ويوصي معيار DMARCbis (RFC 9989، الصادر في مايو 2026 والذي يحل محل RFC 7489) بتدرّج: p=none شهرًا على الأقل، ثم p=quarantine لمدة مماثلة مع مقارنة النتائج. تجد تعريف السياسات الثلاث في دليلنا عن DMARC p=quarantine، وما يغيّره المعيار الجديد في DMARCbis. هنا نعالج العمل الخاص بالمحفظة: الجرد والجدول الزمني والتواصل.
نشر p=none مع عنوان للتقارير، عميلًا بعد عميل
لكل نطاق، أول كتابة هي سجل TXT على _dmarc.your-domain.com: v=DMARC1; p=none; rua=mailto:[email protected]. لا يغيّر p=none شيئًا في التسليم؛ بل يطلب من المستقبِلين إرسال تقارير مجمّعة إليك، ملف XML مضغوط لكل مستقبِل في اليوم. وإذا جمعتَ تقارير جميع عملائك في عنوان تابع للوكالة، مثل [email protected]، فإن نطاق هذا العنوان يختلف عن نطاق العميل، وعلى المستقبِل أن يتحقق من موافقتك. يتيح معيار التقارير (RFC 9990) لذلك سجل TXT على client-example.com._report._dmarc.agency-example.com يتضمن على الأقل v=DMARC1. ودونه يتجاهل المستقبِل العنوان فلا تتلقى شيئًا. أما السجل العام *._report._dmarc.agency-example.com فيأذن بجميع النطاقات دفعة واحدة.
يمنح التجميع رؤية شاملة لكنه يخلط العملاء في صندوق واحد. وعنوان لكل عميل، أو فرز حسب نطاق الحقل header_from، يجنّبك قراءة تقارير عميل أثناء البحث عن تقارير آخر.
قراءة سطر من التقرير: الحقول المهمة
- source_ip — العنوان الذي سلّم الرسالة؛ يكشف البحث العكسي أو ترويسة
Receivedفي رسالة اختبار المزوّد الذي يقف خلفه. - count — عدد الرسائل في السطر؛ وهو يرتّب العمل، فنعالج الأحجام الكبيرة أولًا.
- disposition — ما طبّقه المستقبِل:
noneأوquarantineأوreject. مع p=none تكون كلهاnone؛ ويصبح العمود مفيدًا في المراحل التالية. - dkim وspf — النتيجة المقيَّمة لأغراض DMARC، أي مع المحاذاة. وDKIM صالح لكنه غير محاذٍ يظهر
fail. - header_from — النطاق الظاهر في حقل From، وهو ما تحميه DMARC.
- envelope_from — نطاق المظروف (Return-Path) الذي تحاذي SPF عليه؛ ووجود نطاق مزوّد هنا يفسّر فشل SPF.
- أسطر بلا مالك — عنوان IP مجهول بقيمة
countكبيرة هو إما أداة منسية عند العميل وإما انتحال: نسأل العميل قبل الحكم.
المحاذاة: لماذا تفشل أداة تجتاز SPF وDKIM
تشترط DMARC أن يكون SPF أو DKIM محاذيًا للنطاق الظاهر في حقل From. تحاذي SPF نطاق المظروف (Return-Path) لا From؛ وتحاذي DKIM نطاق d= في التوقيع. فخدمة نشرات بريدية ترسل بـ Return-Path خاص بها وتوقّع بـ d= خاص بها تجتاز SPF وDKIM من جهتها، وتفشل في DMARC عند عميلك، لأن أيًا من النطاقين ليس نطاق From. افتراضيًا تكون المحاذاة relaxed (aspf وadkim قيمتهما r): يكفي نطاق فرعي من النطاق التنظيمي نفسه. وفي الوضع strict (s) يجب أن يتطابق النطاق تمامًا. أبقِ relaxed ما لم تكن لديك حاجة محددة.
الحل هو نفسه تقريبًا دائمًا: اجعل الأداة توقّع بنطاق العميل عبر نشر سجلات CNAME الخاصة بـ DKIM التي يقدمها المزوّد. تكفي محاذاة واحدة، فلا ضرر من Return-Path الخاص بالمزوّد إذا كان DKIM محاذيًا. وعند إضافة include: في SPF، احسب العدد: يحدّ RFC 7208 التقييم بـ 10 استعلامات DNS، وما فوق ذلك تكون النتيجة خطأً دائمًا (permerror).
مصفوفة المرسِلين من الأطراف الثالثة الواجب محاذاتهم
مرّر الجدول أفقيًا
| المرسِل | ما يقدمه المزوّد | ما يُنشر عند العميل |
|---|---|---|
| نشرة بريدية، إرسال جماعي | مفتاح DKIM ونطاق الإرسال | CNAME لـ DKIM؛ يُنصح بنطاق فرعي مخصص للإرسال |
| CRM، أتمتة التسويق | توقيع DKIM باسم العميل | CNAME لـ DKIM؛ و`include:` في SPF فقط إذا طلبه المزوّد |
| الفوترة، الدفع الإلكتروني | الإرسال من خوادمه | CNAME لـ DKIM الخاص بالمزوّد؛ وإلا الإرسال من نطاق فرعي مخصص للإرسال |
| مكتب المساعدة، التذاكر | عنوان إرسال يلزم التحقق منه | CNAME لـ DKIM والتحقق من نطاق الإرسال |
| البريد الرئيسي | سجلات SPF وDKIM موثقة | `include:` في SPF ومفتاح DKIM الخاص بمزوّد البريد |
| موقع الويب (نماذج، متجر) | الإرسال من خادم الموقع أو عبر مرحِّل | SMTP موثَّق بنطاق العميل |
الجدول الزمني النموذجي لنطاق واحد، مرحلةً بمرحلة
الأسبوع 0: نشر p=none
سجّل النطاق ثم انشر
v=DMARC1; p=none; rua=mailto:[email protected]. تحقق بالأمرdig +short TXT _dmarc.your-domain.com. تصل التقارير الأولى خلال 24 إلى 48 ساعة.الأسابيع 1 إلى 4: المراقبة والمراجعة أسبوعيًا
يوصي المعيار بشهر على الأقل من p=none. كل أسبوع، جمّع الأسطر حسب المزوّد واملأ جدول المتابعة: المرسِل، والحجم، ومحاذٍ أم لا، وشرعي أم لا.
تصحيح كل مرسِل شرعي غير محاذٍ
انشر سجلات CNAME لـ DKIM الخاصة بالمزوّد، وأرسل رسالة اختبار إلى صندوق Gmail وتأكد من
dmarc=passفي الترويسة. الأداة المهجورة لا تُصحَّح: تُسجَّل على أنها مما يجب رفضه.الأسابيع 5 إلى 8: تفعيل quarantine
استبدل السجل بـ
v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:[email protected]، لمدة مماثلة للمرحلة السابقة. تذهب حالات الفشل إلى البريد غير المرغوب بدل أن تُرفض: ويُظهر عمودdispositionفي التقارير ما كان سيضيع.عدم الاعتماد على pct كشبكة أمان
ألغى RFC 9989 الوسم
pctلعدم موثوقيته خارج القيمتين 0 و100، وأضافt=yلطلب عدم تطبيق السياسة. دعم Gmail وYahoo وMicrosoft للوسمtغير موثّق حتى الآن: لا تبنِ مرحلة عليه.الأسابيع 9 إلى 12: الانتقال إلى reject
إذا لم تكشف quarantine عن أي مرسِل شرعي يفشل، فانشر
v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:[email protected]. نبّه العميل في اليوم السابق، وراقب التقارير يوميًا طوال أسبوع.مواصلة المراجعة بعد reject
كل أداة جديدة يعتمدها العميل تصبح مرسِلًا يجب محاذاته. أدرج ذلك في عقد المتابعة: تُعلَن كل أداة إرسال جديدة قبل تشغيلها، ثم تُضاف إلى جدول المتابعة.
النطاقات الفرعية: sp وnp ونطاق فرعي مخصص للإرسال
النطاق الفرعي الذي لا سجل خاصًا به يرث سياسة النطاق التنظيمي. يحدد الوسم sp سياسة النطاقات الفرعية الموجودة، ويحدد np سياسة النطاقات الفرعية غير الموجودة؛ وفي غياب np يُرجَع إلى sp ثم إلى p (RFC 9989، تعريف الوسوم). وفي سجل منشور على نطاق فرعي يُتجاهل sp. والوسم np حديث: فالمستقبِل الذي لا يعرفه يتجاهله ويطبّق sp.
الاستخدام المعتاد هو النطاقات الفرعية المزيفة. فمحتال يكتب من invoice.client-example.com، وهو نطاق فرعي غير موجود، يوقفه np=reject دون أي خطر على البريد الحقيقي، إذ لا يخرج منه شيء شرعي. وللأدوات الخارجية، فضّل نطاقًا فرعيًا مخصصًا للإرسال، مثل news.your-domain.com: تكون الأداة محاذاة فيه بوضع relaxed، ولا تزدحم مفاتيحها وSPF الخاص بها في النطاق الرئيسي، ويمكنك تشديد النطاق الرئيسي دون انتظار ذلك التدفق. وسجل _dmarc خاص بالنطاق الفرعي يتيح حتى جدولًا زمنيًا مستقلًا.
التدفقات التي تتعطل: القوائم البريدية وإعادة التوجيه والأسماء المستعارة
بعض الرسائل الشرعية تفشل في DMARC بحكم بنيتها، لأن وسيطًا يعيد إرسالها مع الإبقاء على From الأصلي. فالقائمة التي تضيف تذييلًا تُبطل توقيع DKIM؛ وإعادة التوجيه تُبطل SPF لأن عنوان IP الذي يسلّم الرسالة لم يعد العنوان الذي يأذن به النطاق. ويقول المعيار ذلك صراحة (RFC 9989، قسم التشغيل البيني): قد لا يتوافق p=reject مع هذه التدفقات غير المباشرة، وينبغي ألا تنشره النطاقات التي يكتب مستخدموها في القوائم البريدية. ويُذكر ARC (RFC 8617) محاولةً للحل، لكن لم تنتشر أي طريقة على نطاق واسع. ويطلب المعيار أيضًا من المستقبِلين ألا يرفضوا بناءً على p=reject وحده، وأن يعاملوا الرسالة، في غياب تحليل آخر، كما لو كانت quarantine: فلا يُطبَّق reject حرفيًا دائمًا، وهذا ليس سببًا لتجاهله.
يمكن رصد هذه الحالات قبل التحويل. ابحث في التقارير عن أسطر يعود عنوان IP فيها إلى مرحِّل قائمة أو خدمة إعادة توجيه، ويفشل فيها spf وdkim، وقيمة count فيها منخفضة لكنها منتظمة. ثم اسأل العميل: أسماء مستعارة لخريجين، جمعية، عنوان يعيد التوجيه إلى صندوق شخصي. وفي نطاق تُستخدم عناوينه للكتابة في قوائم عامة، ابقَ على quarantine: إنه خيار يمكن الدفاع عنه، ويُسجَّل في جدول المتابعة.
أثبت النتيجة قبل تنبيه العميل
أرسل رسالة اختبار من كل أداة إلى صندوق Gmail، وافتح «إظهار الأصل» وابحث عن السطر Authentication-Results: يجب أن يتضمن dmarc=pass header.from=your-domain.com. بعد الانتقال إلى reject، يحمل رفض SMTP رمزًا من الصيغة 5.7.x ونصًا خاصًا بالمستقبِل. احتفظ بلقطة لرسالة الرفض وبالسطر المقابل في تقرير rua: فهي تُري العميل أن الأداة المعيبة كانت محددة ومُبلَّغًا عنها، لا مكتشفة بعد وقوع المشكلة.
الرسالة التي تُرسَل إلى العميل قبل كل مرحلة
لا يحتاج العميل إلى فهم DMARC، لكن عليه أن يعرف ما الذي يتغير ومتى وما المطلوب منه. تكفي أربع جمل.
الموضوع: حماية نطاقك من انتحال البريد الإلكتروني
مرحبًا، نعزّز حماية نطاقك your-domain.com من انتحال عناوينك. ابتداءً من [التاريخ]، ستوضع في البريد غير المرغوب الرسائل التي تبدو صادرة من نطاقك دون توثيق، ثم تُرفض ابتداءً من [التاريخ التالي]. لكي لا نفقد أي رسالة شرعية، هل يمكنك أن تزوّدنا قبل [التاريخ] بكل الأدوات التي ترسل بريدًا باسمك (نشرة بريدية، فوترة، CRM، دعم، موقع)؟ يبقى خطر على القوائم البريدية وإعادة توجيه العناوين: أخبرنا إن كنت تستخدم شيئًا منها.
احتفظ بالرد في ملف العميل: فهو يحدد من صرّح بأي الأدوات وفي أي تاريخ.
جدول متابعة المحفظة
مرّر الجدول أفقيًا
| النطاق | السياسة الحالية والمرحلة التالية | المرسِلون المعتمدون وحالة العميل |
|---|---|---|
| client-a-example.com | p=none، وquarantine عند الأسبوع 4 | البريد والنشرة معتمدان؛ الفوترة قيد التأكيد |
| client-b-example.com | p=quarantine، وreject عند الأسبوع 8 | أربعة مرسِلين محاذون؛ لا فشل شرعي في التقارير |
| client-c-example.com | p=reject، ومراجعة أسبوعية | أضاف العميل CRM، وDKIM قيد النشر |
| client-d-example.com | p=quarantine، دون reject مخطط | العناوين مستخدمة في قوائم؛ القرار مسجَّل |
| client-e-example.com | p=none، دون مرحلة مخططة | العميل لا يرد؛ يلزم جدولة تذكير |
استكشاف الأخطاء: خمس حالات فشل شائعة في المحفظة
في المحفظة تتكرر الحوادث الخمس نفسها. وهذه هي مع سببها والإجراء الذي يحلّها.
الأعراض والحلول
- لا يصل أي تقرير — عنوان
ruaعلى نطاق مختلف عن نطاق العميل وسجل التفويض_report._dmarcغير موجود: انشره، وإلا يتجاهل المستقبِل العنوان. - أداة تجتاز SPF وDKIM لكنها تفشل في DMARC — Return-Path و
d=الخاصان بها هما للمزوّد: انشر سجلات CNAME لـ DKIM باسم العميل لمحاذاة DKIM. - SPF في حالة permerror — أكثر من 10 استعلامات DNS (RFC 7208): احذف سجلات
include:الخاصة بالأدوات المهجورة أو انقل الأداة إلى نطاق فرعي مخصص للإرسال. - أداة جديدة تُرفض بعد reject — اعتمدها العميل دون إخبارك: عُد إلى quarantine ريثما تحاذي الأداة، بدل تخفيف المحاذاة.
- العميل لا يرد — ابقَ على p=none أو quarantine، وسجّل التذكير وتاريخه في جدول المتابعة؛ فنشر reject دون جرد يحمّلك مسؤولية.
الوثائق الرسمية
RFC 9989، معيار DMARCbis (الوسوم والنطاقات الفرعية والتشغيل البيني): https://www.rfc-editor.org/rfc/rfc9989.html
RFC 9990، تقارير DMARC المجمّعة (الوجهات الخارجية): https://www.rfc-editor.org/rfc/rfc9990.html
RFC 7208، معيار SPF (حد 10 استعلامات DNS): https://www.rfc-editor.org/rfc/rfc7208.html
RFC 8617، معيار ARC: https://www.rfc-editor.org/rfc/rfc8617.html
متطلبات Gmail للمرسِلين بكميات كبيرة: https://support.google.com/a/answer/81126
أفضل ممارسات Yahoo للمرسِلين: https://senders.yahooinc.com/best-practices/
متطلبات Outlook للأحجام الكبيرة: https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730
