كيفية إعداد DMARC والتحقق من مصادر البريد

إذا كنت تبحث عن كيفية إعداد DMARC، فلا تبدأ مباشرة بـ p=reject. ابدأ عادة بالمراقبة، وتحقق من نجاح SPF أو DKIM مع المحاذاة لكل مصدر مشروع، ثم قيّم تشديد السياسة تدريجيا. يساعد ذلك على إدارة مخاطر الانتحال دون إغفال الفواتير وإعادة تعيين كلمات المرور وخدمات SaaS المنسية.

الواقع ليس بسيطا دائما. قد يستخدم النطاق Microsoft 365، بينما ترسل الفوترة عبر تطبيق خارجي والتسويق عبر منصة أخرى، وما زالت آلة تصوير ترسل المستندات الممسوحة. قد يؤدي نسيان مصدر عند التقييد إلى تعطيل عمل مشروع. راجع أيضا إعداد البريد على نطاقي ودليل بريد العمل.

هذا دليل عملي: اجمع البيانات، وافحص المصادر، وأصلح المحاذاة، ثم قيّم السياسة. المراقبة خطوة أولى وليست دليلا على أن كل انتقال لاحق آمن.

ما الذي يفعله DMARC؟

ينشر DMARC عبر DNS طلب المعالجة للرسائل التي تظهر نطاقك في From ولا تستوفي شروط المصادقة والمحاذاة. يبنى على SPF وDKIM، ويكفي نجاح إحدى الآليتين مع محاذاة النطاق لنطاق From الظاهر.

DMARC اختصار لـ Domain-based Message Authentication, Reporting, and Conformance. يتيح نشر طلب سياسة وطلب تقارير عن تدفقات البريد المرصودة. المواصفة الأساسية هي RFC 7489.

تذكر القواعد التالية:

• نجاح SPF دون محاذاة لا يكفي، لكن نجاح DKIM المحاذي قد يجعل DMARC ينجح.
• نجاح DKIM دون محاذاة لا يكفي، لكن نجاح SPF المحاذي قد يجعل DMARC ينجح.
• ينجح DMARC إذا حققت SPF أو DKIM النجاح والمحاذاة معا.

تطلب Google من المرسلين بكميات كبيرة SPF وDKIM وسجل DMARC بسياسة لا تقل عن p=none، مع شروط المحاذاة المعنية. لا تنطبق كل متطلبات الإرسال الكثيف تلقائيا على كل مرسل. راجع الأسئلة الشائعة لإرشادات مرسلي Google.

ما الذي تتحقق منه قبل DMARC؟

افحص بيئة الإرسال أولا. قد تكشف التقييمات أخطاء SPF أو غياب DKIM أو استخدام نطاق المزود دون محاذاة. تطبيق التقييد دون اختبار قد يؤثر في رسائل مشروعة.

تحقق من ثلاثة أمور:

1. SPF: استخدم سجلا واحدا لكل نطاق مغلف فعلي، والتزم بحد 10 آليات ومعدلات تستدعي DNS، بما في ذلك التقييم المتداخل، لا عدد جميع استعلامات DNS.
2. DKIM: فعّله حيث يكون مدعوما، واستخدم مفاتيح بطول 2048 بت إذا كان المزود يدعمها.
3. حصر المصادر: راجع البريد وCRM والفوترة والدعم والنماذج والماسحات والتسويق.

في TrekMail، ابدأ بـ سجلات DNS المطلوبة وإضافة نطاق. قد تكشف الفحوص سجلات مفقودة أو مكررة، لكنها لا تغني عن اختبار مصادقة رسائل فعلية.

يرسل تطبيق الفواتير من billing@yourdomain.com، لكنه يوقع بنطاق المزود ويستخدم return-path الخاص به. قد تنجح SPF وDKIM للمزود، بينما يفشل DMARC لنطاق From لديك لعدم وجود مصادقة ناجحة ومحاذية.

هذا يفسر أثر تغيير السياسة دون اختبار. نشر سياسة المراقبة نفسه لا يسبب فشل المصادقة.

الخطوة 1: نشر سجل للمراقبة فقط

ابدأ عادة بـ p=none. لا تطلب هذه السياسة الحجر أو الرفض بسبب DMARC، ويمكنك طلب التقارير. وصول التقارير غير مضمون، وتبقى التصفية المحلية ممكنة.

أنشئ TXT في _dmarc.yourdomain.com بهذه القيمة:

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

القيمة نفسها بصيغة ملف المنطقة، وليست سجلا إضافيا ينشر معها:

_dmarc  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

يتبع ذلك مثال RFC 7489. استخدم عنوان تقارير مخصصا أو عنوانا بديلا يتابعه مسؤول؛ التقارير التجميعية بصيغة XML وقد تتراكم. راع الخصوصية والوصول والتفويض عبر DNS عند استخدام وجهة خارجية.

تحقق من السجل بعد نشره واختبر المصادر الفعلية أينما تدير DNS. قد يفيد دليل وصول الرسائل إلى البريد المزعج في تحقيقات إعادة التوجيه. الحالة الخضراء في اللوحة لا تثبت صحة كل تدفق.

الخطوة 2: قراءة التقارير والتحقيق في المصادر

التقارير تساعد على التحقيق، لكنها لا تحصر كل البريد ولا تصنف تلقائيا ما هو مشروع أو ضار. استكمل بيانات المستقبِلين المشاركين بالسجلات والاختبارات.

قد تعرض التقارير:

• عناوين IP المرصودة للإرسال
• نتائج مصادقة SPF
• نتائج مصادقة DKIM
• نتائج تقييم DMARC التي تراعي المحاذاة مع From
• المعالجة التي أبلغ عنها المستقبِل

ميز بين المصادر التي تحققت منها والتدفقات التي تحتاج إلى تحقيق.

أصلح أخطاء المصادر المشروعة المثبتة. أما IP غير المعروف فقد يكون خادم إعادة توجيه أو مرحلا مشتركا، فلا يعد دليلا على الإساءة. ونجاح المصادقة لا يثبت سلامة المحتوى.

الجدول توضيحي، ولا يصف كل إعداد افتراضي لدى كل مزود:

عند إدارة نطاقات كثيرة، يحتاج كل SaaS جديد إلى مراجعة المصادقة والتشغيل. قد تساعد استضافة البريد متعدد النطاقات على التنظيم، لكنها لا تضمن توفير التكاليف أو تقليل طلبات الدعم.

الخطوة 3: إصلاح المحاذاة لا المصادقة وحدها

نجاح SPF أو DKIM وحده لا يكفي. يجب أن يطابق نطاق المصادقة الناجحة نطاق From، أو يشترك معه في النطاق التنظيمي نفسه عند المحاذاة المرنة.

يعرّف RFC 7489 المحاذاة المرنة باشتراك نطاق مصادقة SPF أو توقيع DKIM مع RFC5322.From في النطاق التنظيمي نفسه. تكفي مصادقة ناجحة ومحاذية واحدة لـ DMARC، مع فائدة إعداد الآليتين حيث تكونان مدعومتين.

معالجات شائعة:

• منصات التسويق: إعداد توقيع DKIM لنطاقك حيث يكون مدعوما.
• الرسائل المرتدة: إعداد return-path مخصص أو نطاق ارتداد مناسب إذا دعمه المزود.
• Microsoft 365: تفعيل DKIM لنطاقك واختباره قبل التقييد.
• إرسال TrekMail المدار: نشر قيم SPF وDKIM المناسبة لإعدادك الفعلي.

اتبع مزود الإرسال الصادر الفعلي. قد يقدم TrekMail مساعدة في DNS وخيارات SMTP الخاص بالمستخدم في Nano أو SMTP المدار ضمن الخطط المدفوعة. يبقى فصل الصناديق عن الإرسال وإدارة الموارد خاضعين للخطة وإعداداتها.

توصف Nano باستخدام SMTP يوفره المستخدم، والخطط المدفوعة باستخدام SMTP المدار. السعر الابتدائي المذكور $3.50 شهريا، مع عرض تجربة مجانية لمدة 14 يوما للخطط المدفوعة وخيار Nano مجاني دون بطاقة. تحقق من الأسعار وشروط التجربة والميزات الحالية في أسعار TrekMail.

الخطوة 4: تقييم quarantine

بعد مراجعة المصادر المشروعة يمكنك تقييم quarantine. هذه سياسة تقييد فعليا، تطلب معالجة الرسائل الفاشلة باعتبارها مشبوهة. لا تضمن مجلد بريد مزعج معينا أو إمكانية الاستعادة أو مرحلة وسطى آمنة لكل نطاق.

استبدل قيمة السجل الحالي إذا كان ذلك مناسبا:

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

لماذا قد يفيد الحجر قبل الرفض؟

• يطلب معالجة أشد لرسائل DMARC الفاشلة.
• قد يكون أقل أثرا من الرفض، لكن البريد المشروع قد يتأثر أيضا.
• يمكن التحقيق في الأثر مع مراقبة وخطة للتراجع.

راقب مدة تغطي التدفقات المعنية. قد يكون أسبوعان إرشادا أوليا، لكن حتى 30 يوما لا تثبت اكتمال التغطية. اختبر الإرسال النادر والشهري والفصلي على حدة.

قد يظهر لاحقا ملحق WordPress أو بيئة CRM تجريبية أو آلة قديمة أو مزود يرسل دوريا. لا تعتمد على فترة هادئة من التقارير وحدها.

الخطوة 5: تقييم reject بعد تحقق كاف

تطلب p=reject رفض الرسائل الفاشلة في DMARC. قد تحد من انتحال النطاق مباشرة، لكنها لا تمنع كل أشكال الانتحال ولا تضمن الوصول إلى الوارد.

قد يحل سجل نهائي مناسب محل السجل الحالي:

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

يصف RFC 7489 طلب الرفض مع p=reject. قد يطبق المستقبِلون استثناءات محلية؛ ليس ذلك ضمانا لحظر كل رسالة.

قبل الانتقال، تحقق من الآتي:

• نجاح إرسال مزود الصناديق الفعلي ومحاذاته
• نجاح مصادر التسويق والرسائل المعاملاتية ومحاذاتها
• مراجعة تقارير الفترات المعنية، لا بضعة أسابيع هادئة فقط
• فهم الأخطاء المتبقية واختبار التدفقات النادرة المهمة

واصل متابعة التقارير والسجلات والتغييرات. DMARC جزء من إدارة التغيير المستمرة.

أخطاء شائعة تؤثر في البريد

تحقق من المصادر المفقودة وSPF المكرر وDKIM غير المختبر وإعدادات المزود غير المحاذية. لا يسبب نشر سياسة المراقبة فشل المصادقة بنفسه، لكن التقييد المتسرع قد يزيد الأثر.

• تطبيق التقييد قبل اختبار DKIM والمسارات
• نشر سجلات SPF متعددة بدلا من سجل مناسب واحد
• افتراض أن نجاح SPF يعني نجاح DMARC
• نسيان مزودي الإرسال منخفض الحجم
• الانتقال مباشرة من غياب DMARC إلى p=reject
• إرسال التقارير إلى وجهة لا يتابعها أحد

قد يفشل SPF عند إعادة التوجيه بينما ينجح DMARC بفضل DKIM صالح ومحاذ إذا حفظت البيانات الموقعة وفق قواعد الصياغة القياسية. راجع إعادة توجيه العناوين البديلة وبريد العمل الآمن.

قائمة مختصرة لإعداد DMARC

تساعد القائمة على تنظيم القرار، لكنها لا تضمن أن تطبيق السياسة آمن بعد مدة ثابتة.

1. احصر مصادر الإرسال التي تستخدم نطاقك.
2. استخدم SPF صالحا واحدا لكل نطاق مغلف معني ضمن حدود التقييم.
3. فعّل DKIM واختبره حيث يكون مدعوما.
4. انشر سياسة مراقبة مثل v=DMARC1; p=none; rua=mailto:....
5. حقق في التقارير بالاستعانة بالسجلات وبيانات المصادر.
6. أصلح أخطاء المصادقة وتحقق من المحاذاة للمصادر المشروعة.
7. قيّم p=quarantine وآثارها.
8. تابع البيانات والتدفقات المهمة.
9. قيّم p=reject مع اختبارات وخطة للتراجع.

الخلاصة: إعداد DMARC بصورة مدروسة

ابدأ عادة بـ p=none، واحصر المصادر وأصلح المصادقة والمحاذاة. قيّم بعدها p=quarantine ثم p=reject إذا كان مناسبا. تدير هذه الخطوات المخاطر، لكنها لا تضمن التسليم أو الحماية الكاملة من الانتحال.

عند إدارة عشرات أو مئات النطاقات، قد تفيد بيئة أكثر اتساقا. يمكن أن يقدم TrekMail نطاقات خاصة وصناديق IMAP وcatch-all وإعادة توجيه وترحيلا وSMTP خاصا أو مدارًا بحسب الخطة. ينسخ IMAP الرسائل المدعومة؛ انتقال MX وبيانات التطبيقات الأخرى يحتاجان إلى عمل مستقل. قارن التكاليف والحدود لبيئتك.

هذه هي كيفية إعداد DMARC عمليا: تحقق أولا، واختبر المحاذاة، وقيّم السياسة بناء على أكثر من التقارير وحدها.