DMARC ‏p=none مقابل quarantine مقابل reject: دليل عملي للمشغّلين

المفاضلة الأساسية

اختيار سياسة DMARC هو اختيار بين الرؤية والتطبيق الصارم. يوفّر p=none المراقبة دون التأثير في التسليم. ويرسل p=quarantine البريد المشبوه إلى مجلد البريد المزعج. أما p=reject فيحجب البريد غير الموثَّق بالكامل. المسار الأكثر أمانًا هو الطرح على مراحل: ابدأ بـ none لتحديد كل المُرسِلين المشروعين، ثم انتقل إلى quarantine لاختبار الأثر، وأخيرًا اصل إلى reject لتأمين نطاقك بالكامل ضد الانتحال.

لماذا تهم السياسة طابور الحوادث

بصفتك مهندسًا مسؤولًا عن قابلية التسليم، فهدفك الأول أن يصل البريد المعاملاتي المشروع إلى المستلِم مع منع المهاجمين من استخدام نطاقك. إذا انتقلت مباشرة إلى p=reject دون مرحلة مراقبة، فمن المرجح أن تتسبب في حادثة عالية الأولوية عندما يتوقف نظام قديم منسي أو أداة تسويق تابعة لجهة خارجية فجأة عن تسليم البريد.

يعتمد DMARC (Domain-based Message Authentication, Reporting, and Conformance) على محاذاة SPF وDKIM. وإذا أخفقت الرسالة في كليهما، فإن الوسم p= يخبر خادم البريد المستقبِل بالضبط بما يفعله بتلك الرسالة.

مستويات السياسة الثلاثة

1. p=none (وضع المراقبة)

في هذا الوضع لا يتخذ المستقبِل أي إجراء بشأن الرسالة مهما كانت نتائج المصادقة. وهو مخصص لجمع البيانات فقط.

متى تستخدمه:

• عند الإعداد الأولي لـ DMARC.
• عندما لا تكون متأكدًا من كل الخدمات التي ترسل البريد نيابةً عنك.
• أثناء الترحيل إلى واجهة API جديدة للبريد الإلكتروني.

الحمولة (payload):

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;

المفاضلة: لا توجد أي حماية من الانتحال. لا يزال بإمكان المهاجمين إرسال بريد بهوية نطاقك، لكنك سترى ذلك في تقارير RUA (التجميعية).

2. p=quarantine (تطبيق مخفَّف)

تُعامَل الرسائل التي تخفق في DMARC على أنها مشبوهة. ستنقلها معظم الجهات المستقبِلة إلى مجلد البريد المزعج أو البريد غير الهام.

متى تستخدمه:

• بعد أن تحلل تقارير p=none وتتحقق من محاذاة كل المسارات المشروعة.
• كهامش أمان قبل الانتقال إلى الرفض الكامل.

الحمولة (payload):

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com;

المفاضلة: تقلل من ظهور البريد المنتحَل لكنها لا تقضي عليه. وقد تظل بعض الرسائل المشروعة تصل إلى البريد المزعج إذا دُوِّرت مفاتيح DKIM بطريقة خاطئة أو بلغت سجلات SPF حد 10 استعلامات DNS.

3. p=reject (تطبيق كامل)

هذا هو المعيار الذهبي لأمان النطاق. سيرفض الخادم المستقبِل قبول الرسالة صراحةً إذا أخفقت في DMARC.

متى تستخدمه:

• عندما تُظهر مراقبتك محاذاة بنسبة 99.9% لكل الحركة المشروعة.
• عندما يفوق خطر انتحال النطاق خطر إخفاقات التسليم العارضة.

الحمولة (payload):

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com;

المفاضلة: لا توجد شبكة أمان. إذا أُعدّ نظام حيوي إعدادًا خاطئًا، ضاعت الرسالة. سترى هذه الإخفاقات في تقارير RUA، لكن المستخدم لا يتلقى الرسالة أبدًا.

قائمة تحقق المشغّل للطرح

لا تنقل السياسات بناءً على انطباع. انقلها بناءً على البيانات في تقاريرك التجميعية. استخدم أداة مثل SendHQ Email DNS Checker للتحقق من انتشار سجلاتك بشكل صحيح قبل كل انتقال.

المرحلة 1: الاستكشاف (p=none)

1. انشر p=none مع عنوان rua.
2. انتظر من 7 إلى 14 يومًا لالتقاط دورة عمل كاملة من الرسائل (بما فيها التقارير الأسبوعية).
3. حلّل التقارير بحثًا عن الحركة «غير المحاذاة».
4. حدّد المُرسِلين المشروعين من الجهات الخارجية (مثل Zendesk وSalesforce وShopify).
5. اضبط DKIM لكل مُرسِل تحدده. هذه أكثر الطرق موثوقية لضمان المحاذاة.

المرحلة 2: الاختبار (p=quarantine)

1. حدّث السياسة إلى p=quarantine.
2. راقب تذاكر الدعم بحثًا عن عبارات مثل «لم تصلني الرسالة» أو «الرسالة في البريد المزعج».
3. افحص تقارير RUA بحثًا عن أي قفزات جديدة في الإخفاقات.
4. إذا حدثت إخفاقات، فأصلح المصادقة وابقَ عند quarantine أسبوعًا آخر.

المرحلة 3: التقوية (p=reject)

1. حدّث السياسة إلى p=reject.
2. تحقق من أن مساراتك المعاملاتية الأكثر حساسية (إعادة تعيين كلمات المرور والفواتير) ما زالت تُسلَّم.
3. واصل المراقبة. DMARC ليس إعدادًا «تضبطه وتنساه».

التعامل مع البريد بوصفه أثرًا جانبيًا

بالنسبة إلى مهندسي المنتجات الذين يبنون وكلاء ذكاء اصطناعي أو سير عمل آلية، فإرسال البريد أثر جانبي خارجي. ويعني ذلك أنه قد يخفق لأسباب خارجة عن منطق تطبيقك (مشكلات DNS أو رفض DMARC أو حدود المعدّل).

عدم التكرار والموافقة

عندما يطلق وكيل ذكاء اصطناعي إرسال بريد، يجب أن تمنع تكرار الإرسال عند إعادة المحاولة. استخدم مفتاح عدم التكرار (idempotency key) في طلبات API حتى لا تؤدي مهلة الشبكة إلى وصول الرسالة نفسها إلى العميل خمس مرات.

وعلاوة على ذلك، لا ينبغي أن يملك الوكلاء إذنًا مستقلًا بإرسال رسائل عالية الحساسية. طبّق طابور موافقات للمحتوى الذي يولّده الوكلاء لضمان توافق عنوان «From» والمحتوى مع علامتك التجارية وسياسات المصادقة لديك.

تكلفة بنية التسليم التحتية

يؤثر اختيارك لمزوّد الإرسال في طريقة إدارتك لـ DMARC. بعض المزوّدين يجعلون إعداد DKIM بسيطًا، بينما يتطلب غيرهم إدخالات DNS يدوية لكل نطاق فرعي.

عند تقييم التكاليف، انظر إلى إجمالي تكلفة الملكية. على سبيل المثال، يكلّف إرسال 50,000 رسالة نحو 5 USD على Amazon SES بنظام a la carte (بسعر 0.10 USD لكل 1,000 رسالة)، بينما تكلّف باقات Postmark نحو 66 USD للحجم نفسه (15 USD لأول 10,000 رسالة، إضافةً إلى رسوم زيادة تتراوح بين 1.20 و1.80 USD لكل 1,000).

ومن الخيارات الأخرى Resend، التي تقدّم باقة مجانية بواقع 3,000 رسالة شهريًا (بحد أقصى 100 يوميًا)، أو Mailgun بدءًا من 15 USD شهريًا لكل 10,000 رسالة. وتعتمد SendGrid الآن فترة تجريبية مدتها 60 يومًا لباقتها المجانية، مع بدء Essentials من 19.95 USD شهريًا.

أيًّا كان المزوّد، تبقى سياسة DMARC الدرع الأساسي لنطاقك. وإذا كنت تستخدم مزوّدًا يدعم SPF فقط، فإن خطر إخفاق التسليم يزداد عند الانتقال إلى p=reject لأن SPF ينكسر أثناء إعادة توجيه البريد. وDKIM هو الوسيلة الوحيدة للحفاظ على المحاذاة عبر إعادة التوجيه.

أنماط الإخفاق الشائعة

فخ إعادة التوجيه

يرسل المستخدم A رسالة إلى المستخدم B. لدى المستخدم B إعادة توجيه تلقائية إلى المستخدم C. غالبًا ما يغيّر خادم إعادة التوجيه مُرسِل الظرف (envelope sender) إلى نطاقه هو لتجنب تصنيفه كبريد مزعج. وهذا يكسر محاذاة SPF. وإذا كنت تستخدم p=reject دون توقيع DKIM، فلن يرى المستخدم C الرسالة أبدًا.

حد استعلامات DNS

تقتصر سجلات SPF على 10 استعلامات DNS. وإذا أضفت مزوّدين كثيرين إلى سجل SPF، فسيُعيد المستقبِل permerror. وهذا يسبب إخفاق DMARC. لحل ذلك، استخدم مزوّدًا يشجع المصادقة التي تبدأ بـ DKIM أو استخدم تسطيح SPF (SPF flattening).

مشكلة «تقنية المعلومات الخفية» (Shadow IT)

كثيرًا ما تشترك فرق التسويق في أدوات جديدة (مثل خدمة نشرات بريدية جديدة) دون إبلاغ فريق الهندسة. فترسل بريدًا من نطاقك، فيخفق في DMARC، ويُرفَض. ولهذا تُعدّ مرحلة p=none غير قابلة للتفاوض.

جدول ملخص للمشغّلين

السياسة | الإجراء | المخاطرة | الرؤية | الاستخدام الموصى به

p=none | لا شيء | منخفضة | عالية | الاستكشاف والتدقيق

p=quarantine | مجلد البريد المزعج | متوسطة | عالية | الاختبار والانتقال

p=reject | محجوب | عالية | متوسطة | أمان كامل في بيئة الإنتاج

لمزيد من التعمق في التنفيذ التقني لهذه السجلات، راجع دليلنا حول DKIM وSPF وDMARC.

إدارة هذه السجلات يدويًا مرهقة. تبسّط SendHQ ذلك بتوفير إرسال معاملاتي عبر نطاقات موثَّقة وأدوات تضمن أن تكون بنيتك التحتية جاهزة للوكلاء.

اعرف المزيد على https://sendhq.cc.