دليل · cloudflare dmarc

كيف يطبّق فريق المنتج DMARC في Cloudflare بأمان؟

أعدّ DMARC في Cloudflare بجرد كل خدمة ترسل باستخدام نطاقات From الظاهرة لديك، والتحقق من محاذاة SPF أو DKIM على رسائل تجريبية خاضعة للتحكم، ثم إضافة سجل TXT واحد للسياسة عند الاسم _dmarc بالضبط. ابدأ بالإبلاغ، واحتفظ بحالة DNS السابقة، وتحقق من الإجابات الموثوقة والتكرارية، وراجع التقارير المجمّعة قبل طلب quarantine أو reject. يستضيف Cloudflare سياسة DNS أو يحلّلها؛ لكنه لا يجعل المُرسِل محاذيًا ولا يثبت التسليم.

افصل DNS في Cloudflare عن إعداد المُرسِل

يمكن أن يدير Cloudflare نظام DNS الموثوق بينما يتولى مزوّد آخر إرسال بريد التطبيق وتوقيعه. دوّن هذه الحدود قبل تعديل أي شيء. تنشر المنطقة (zone) سياسة DMARC في سجل TXT؛ ويتحكم كل مزوّد بريد في Return-Path ونطاق توقيع DKIM والمحدِّد (selector) والتوثيق، وأحيانًا في الإبلاغ؛ ويتحكم التطبيق في المستأجر (tenant) وفئة الرسالة والمستلِم والقالب وعنوان From الظاهر ومسار المزوّد. لا يمكن لسجل DNS صالح أن يعالج مُرسِلًا غير مصرّح به، أو توقيع DKIM مفقودًا، أو Return-Path غير محاذٍ، أو قيمة From تعبر بين المستأجرين. اجرد أنظمة الإنتاج والاختبار (staging) والدعم والفوترة والهوية والمراقبة وCRM والتسويق والبريد البشري بحسب نطاق From الظاهر. عيّن لكل منها مالكًا وجهة اتصال للتراجع، وصنّف مصادر التقارير المجهولة قبل رفع مستوى التطبيق.

استعلم عن اسم السياسة الذي تقيّمه الجهات المستقبِلة

بالنسبة إلى البريد من alerts@notify.example.test، ابدأ بسجل TXT عند _dmarc.notify.example.test. لا تنشر السياسة عن طريق الخطأ عند مضيف الموقع أو خادم البريد (mail exchanger) أو محدِّد DKIM أو اسم Return-Path. قد يختار اكتشاف DMARC الحالي سياسة النطاق التنظيمي أو نطاق اللاحقة العامة المناسبة عندما لا يملك نطاق المؤلف سجلًا صالحًا، لذلك دوّن الاسم الذي استعلمت عنه ونطاق السياسة الذي جرى اختياره. استعلم عن الإجابات الموثوقة والتكرارية الحالية قبل فتح Cloudflare. وجود عدة سجلات سياسة عند الاسم نفسه، أو صيغة وسوم غير سليمة، أو CNAME متعارض قد يجعل النتيجة غير قابلة للاستخدام. احفظ المحتوى القديم وTTL ومخرجات المحلّل والمالك والقيمة المتوقعة بعد التغيير ليكون التراجع دقيقًا بدلًا من إعادة بنائه أثناء حادثة.

أنشئ سجل TXT واحدًا تمت مراجعته في Cloudflare

افتح حساب Cloudflare والمنطقة الصحيحين، وانتقل إلى DNS Records، واختر Add record، ثم اختر TXT. استخدم _dmarc اسمًا نسبيًا لسياسة النطاق الجذر، أو التسمية _dmarc الدقيقة للنطاق الفرعي المقصود. أدخل قيمة واحدة تمت مراجعتها دون علامات اقتباس غير متسقة؛ توضح وثائق Cloudflare أنها تضيف علامات اقتباس محيطة بمحتوى TXT الجديد المحفوظ بدونها. اختر TTL يتناسب مع الطرح والاسترداد، وأضف مرجع تغيير آمنًا للخصوصية عند الحاجة، ولا تحفظ إلا بعد التحقق من المنطقة والاسم والقيمة القديمة والقيمة الجديدة. سياسات TXT هي بيانات DNS وليست مسارات ويب عبر وكيل (proxy). إذا كان شريك استضافة أو مزوّد موثوق آخر يدير المنطقة، فأجرِ التغيير هناك بدلًا من افتراض أن لوحة تحكم Cloudflare هي المرجع الموثوق.

ابنِ قيمة DMARC من قرارات صريحة

يمكن أن يبدأ سجل مرحلة المراقبة بـ v=DMARC1; p=none وعنوان URI معتمد للإبلاغ المجمّع، لكن هذا مثال وليس قيمة عامة. أبقِ الإصدار أولًا، واجعل السياسة المطلوبة مقصودة، وصرّح بكل وجهة إبلاغ. لا تراجع سياسة النطاق الفرعي أو وضع المحاذاة أو النسبة المئوية أو وسوم الإبلاغ إلا عند وجود متطلب موثّق وتفسير حالي للمعايير. لا تنسخ نموذجًا من مزوّد يحتوي على صندوق rua يخص غيرك، ولا تقفز إلى p=reject لمجرد أن الصيغة صحيحة. يعبّر السجل الصالح عن معاملة مطلوبة من الجهة المستقبِلة؛ لكنه لا يثبت أن SPF أو DKIM يصادقان، ولا أن أيًّا من المعرّفين المصادَق عليهما محاذٍ لنطاق From، ولا أنه جرى جرد كل مسارات الإرسال المشروعة، ولا أن أي رسالة وصلت إلى صندوق الوارد.

تحقق من محاذاة SPF وDKIM على رسائل حقيقية

أرسل أمثلة خاضعة للتحكم من كل مسار في التطبيق إلى مستلِمين يمكنك فحص ترويساتهم الخام. سجّل From الظاهر وSMTP MAIL FROM وعنوان IP المُرسِل ونطاق DKIM d= والمحدِّد وAuthentication-Results ومعرّف المزوّد وفئة الرسالة والبيئة والوقت. يمكن أن ينجح DMARC عبر SPF مصادَق عليه ومحاذٍ أو عبر توقيع DKIM موثَّق ومحاذٍ. يقيّم SPF هوية SMTP وقد يتغير عند إعادة التوجيه؛ أما DKIM فيتحقق من توقيع على أجزاء مختارة من المحتوى. ولا يغني أيٌّ منهما عن تفويض التطبيق. اختبر المحاذاة المرنة أو الصارمة عن قصد، بما في ذلك النطاقات الفرعية ومسارات التحويل عند الفشل. قبول API من المزوّد وقبول خادم الوجهة ونجاح DMARC والوصول إلى صندوق البريد والتفاعل كلها ملاحظات مختلفة. أبقِ هذه الحالات منفصلة حتى لا يتحول نجاح استدعاء API أو مؤشر سياسة أخضر إلى دليل تسليم أقوى.

تحقق من DNS والتقارير خارج لوحة التحكم

بعد الحفظ، استعلم عن خوادم الأسماء الموثوقة في Cloudflare وعن عدة محلّلات تكرارية مستقلة للحصول على TXT عند الاسم _dmarc بالضبط. خزّن الإجابات الخام ونطاق السياسة المختار وTTL والمحلّل والطابع الزمني ونتيجة المحلّل اللغوي. تأكد من وجود سجل واحد صالح تمامًا، وأن v=DMARC1 يأتي أولًا، وأن القيم المطلوبة صحيحة، وأن عناوين URI للإبلاغ معتمدة. كرّر ذلك بعد نافذة التخزين المؤقت المتوقعة. أرسل رسائل خاضعة للتحكم مرة أخرى وافحص ترويسات الجهة المستقبِلة. توضح Cloudflare أن DMARC Management وسيلة لعرض مصادر الإرسال ونتائج SPF وDKIM وDMARC المجمّعة، لكن التقارير ملاحظات متأخرة تقدمها الجهات المستقبِلة وليست إحصاءً حيًا كاملًا. اربطها بأدلة المزوّد. توقف عند اختلاف المحلّلات، أو غياب حركة منخفضة التكرار، أو ظهور مصادر مشروعة مجهولة، أو رسائل خاضعة للتحكم غير محاذية، أو تغيّر غير متوقع في حجم التقارير.

تعامل مع Cloudflare DMARC Management على أنه تغيير في DNS

تقول Cloudflare إن تفعيل DMARC Management قد يدعو إلى إنشاء سجل عندما لا يوجد سجل، أو إلى إضافة عنوان إبلاغ مجمّع تابع لـ Cloudflare إلى وسم rua موجود. راجع هذا التغيير المقترح كما تراجع بنية الإنتاج: صدّر القيمة السابقة، وتأكد من أن الوجهات الحالية ما زالت مقصودة، وتحقق من نطاق النطاق، واحتفظ بخطة التراجع. كما تصف وثائق التفعيل نطاقًا حاليًا يقتصر على النطاق الجذر (apex) وتنبيهًا بشأن سجل SPF خارجي. لا تفترض أن الميزة تستطيع إعادة كتابة مسار SPF مستضاف في مكان آخر بأمان. لا يثبت مصدر أو عنوان IP مدرج أي تطبيق أو مستأجر أو شخص صرّح به، وغياب صف لا يثبت أنه لا توجد حركة. استخدم العرض لجمع الأدلة مع الحفاظ على DNS الموثوق والرسائل الخام وسجلات المزوّد وتدقيق التطبيق.

ارفع مستوى التطبيق عبر أدلة على مراحل

راقب مدة كافية لتغطية كل مُرسِل مشروع وكل فئة رسائل وكل نمط أيام الأسبوع وكل مهمة دفعية وكل مسار تحويل عند الفشل وكل سير عمل منخفض التكرار. صنّف المصادر إلى مملوكة، ومزوّد معتمد، ومعاد توجيهها، ومجهولة، ومسيئة. أصلح المحاذاة للحركة المشروعة قبل طلب معاملة أشد. ينبغي أن تتضمن بوابة القرار (go/no-go) DNS صالحًا، ونجاح الرسائل الخاضعة للتحكم، وتغطية محاذية مقبولة، وعدم وجود مصادر مشروعة مجهولة، وملكية للحوادث، وجاهزية الدعم، وتراجعًا تم اختباره. ارفع السياسة فقط عبر تغيير محدود ومعتمد، وراقب إخفاقات المصادقة والأعمال معًا. تراجع أو أوقف عند رفض رسالة مشروعة، أو فقدان التقارير، أو ظهور مصادر غير متوقعة، أو تعارض المحلّلات، أو ترحيل المزوّد، أو مفاجآت وراثة النطاقات الفرعية. غيّر SPF وDKIM وDMARC كلًّا على حدة كلما أمكن حتى يبقى إسناد التراجعات واضحًا.

تجنّب أنماط الفشل الشائعة في DMARC على Cloudflare

من الإخفاقات المتكررة تعديل المنطقة الخطأ، والنشر عند اسم _dmarc خاطئ، وترك سجلي سياسة، وإضافة علامات اقتباس معطوبة، واستبدال قائمة rua المعتمدة، وافتراض أن سياسة النطاق الجذر والنطاق الفرعي متطابقتان، واستخدام p=reject قبل ظهور المُرسِلين النادرين. وثمة خطأ آخر هو اعتبار الحالة المحفوظة أو المكتشفة في لوحة التحكم دليلًا على مستوى الرسالة. استخدم فروقات دقيقة (diffs) ومستلِمين خاضعين للتحكم واستعلامات مستقلة وترويسات خام وسجلات حوادث محصورة بالمستلِم. أبقِ عناوين العملاء ونصوص الرسائل ومفاتيح API وبيانات التقارير غير المحدودة خارج التذاكر والتحليلات. إذا ظلت الإجابات الموثوقة والمخزنة مؤقتًا غير متسقة بعد المدة المخطط لها، أو غاب مُرسِل متوقع، أو فشلت رسالة حقيقية في المحاذاة، فتوقف وشخّص التفويض والتخزين المؤقت وصيغة السجل وجرد المُرسِلين وSPF وDKIM كلًّا على حدة.

كيف ينسجم SendHQ

الحد الآمن مستقل عن المزوّد: يفوّض التطبيق رسالة، ويصادق عليها مزوّد الإرسال، وتنشر Cloudflare حالة DNS أو تحللها، ويقيّم المستقبِلون الرسالة. اعتمد على الوثائق الرسمية الحالية لـ Cloudflare، ومعيار DMARC الحالي، وإجابات DNS المرصودة، وأدلة الرسائل المستلمة المضبوطة.

الأسئلة الشائعة

ما اسم Cloudflare الذي يحمل سياسة DMARC للنطاق الجذر؟

أنشئ TXT عند _dmarc للمنطقة، بحيث يُحلّ إلى _dmarc.example.com. أما لهوية From على نطاق فرعي، فقيّم نطاق المؤلف هذا وقواعد الاكتشاف الحالية.

هل ينبغي أن تتضمن قيمة TXT علامات اقتباس يدوية؟

تقول Cloudflare إن محتوى TXT الجديد المحفوظ بلا علامات اقتباس يُحاط بها تلقائيًا. تجنّب علامات الاقتباس اليدوية غير المتسقة، ثم تحقق من الإجابة الخام الموثوقة ونتيجة المحلّل اللغوي.

هل تمرّر Cloudflare سجل DMARC TXT عبر وكيل؟

لا. لا يوجد قرار وكيل HTTP في سياسة TXT هذه. انشرها في DNS الموثوق وتحقق منها من الخارج؛ أما سلوك وكيل الويب فوظيفة مختلفة.

هل يمكن أن يغيّر DMARC Management السجل؟

تذكر وثائق تفعيل Cloudflare أنها قد تعرض إضافة سجل أو وجهة rua تابعة لـ Cloudflare. راجع هذا التغيير واحتفظ بالحالة السابقة وتحقق منه وتراجع عنه بشكل صريح.

هل يرفض p=none البريد الفاشل؟

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

هل يثبت نجاح DMARC الوصول إلى صندوق الوارد؟

لا. إنه يثبت فقط أن تقييم المصادقة المحاذية المنطبق قد نجح. أما قبول المزوّد وقبول الجهة المستقبِلة ومكان الوصول في المجلدات والتفاعل فتتطلب أدلة منفصلة ومحددة النطاق.

لماذا قد ينجح SPF بينما يفشل DMARC؟

قد لا تكون هوية SMTP المصادَق عليها محاذية لنطاق From الظاهر، أو قد ينطبق خطأ تقييم آخر. افحص الهويات بدقة ونتائج الجهة المستقبِلة الخام.

هل يثبت سجل DMARC تكاملًا مع مزوّد بريد إلكتروني؟

لا. لا يثبت سجل DMARC وحده تكاملًا مع مزوّد بريد إلكتروني.

المصادر

تابع التعلّم

كيفية إجراء فحص DMARC لبريد التطبيقافحص اكتشاف سجل DMARC وصيغته ومحاذاة SPF وDKIM والسياسة والتقارير والرسائل الحقيقية للتطبيق دون الخلط بين استعلام DNS والتسليم.شرح صيغة سجل SPF لبريد التطبيقافهم صيغة SPF v=spf1 والآليات (mechanisms) والمؤهّلات (qualifiers) والمعدِّلات (modifiers) وحدود استعلامات DNS وسلوك include وredirect والتحقق ومحاذاة DMARC.كيفية فحص DKIM لبريد التطبيقافحص DKIM بمعاينة توقيع حقيقي والاستعلام عن محدِّده ونطاقه والتحقق من الرسالة وقراءة نتائج الجهة المستقبِلة واختبار المحاذاة.كيفية تقييم خدمة قابلية تسليم البريد الإلكترونيقيّم خدمات قابلية تسليم البريد الإلكتروني بحسب النطاق والأدلة والمصادقة وحلقات الملاحظات وقوائم المنع والخصوصية وقابلية النقل والملاءمة التشغيلية.