إذا كنت قد أعددت DMARC على نطاقك، فربما حدقت في وسم السياسة وتساءلت عما اخترته فعلًا. p=none، p=quarantine، p=reject. تبدو متشابهة، لكنها تخبر خوادم البريد المستقبِلة بالقيام بأشياء مختلفة تمامًا مع الرسائل التي تفشل في المصادقة.
الخطأ في هذا الأمر مهم. فإذا اخترت السياسة الخاطئة مبكرًا جدًا، قد ينتهي بك الأمر بحظر نشراتك الإخبارية أو فواتيرك الخاصة. وإذا تركتها متساهلة جدًا لفترة طويلة، فأنت لا تحمي نطاقك فعليًا من التزييف. لنمر على ما تفعله كل سياسة وكيفية الانتقال بينها بأمان كجزء من إعداد DKIM SPF DMARC سليم.
تذكير سريع بما تتحقق منه DMARC فعليًا
تعمل DMARC فوق SPF وDKIM. فهي لا تقوم بالمصادقة بنفسها، بل تخبر الخوادم المستقبِلة بما يجب فعله عندما تفشل فحوصات SPF أو DKIM، وتتطلب التطابق بين النطاق الموجود في ترويسة "From" والنطاقات التي تتحقق منها تلك الفحوصات.
بدون DMARC، يمكن أن يفشل كل من SPF وDKIM بصمت وتصل الرسالة إلى صندوق بريد شخص ما مع ذلك. هذه هي الفجوة التي تسدها DMARC. إذا لم تطّلع بعد على الأساسيات، فقد تناولناها في دليل بلغة بسيطة لإعداد DKIM وSPF وDMARC لنطاقك.
السياسة الأولى: p=none
هذه هي نقطة البداية لمعظم النطاقات تقريبًا. مع p=none، أنت تخبر الخوادم المستقبِلة: "تحقق من البريد الإلكتروني مقابل سجلات SPF وDKIM الخاصة بنا، لكن لا تفعل شيئًا خاصًا إذا فشل. فقط أرسل لنا تقريرًا."
لا يتم حظر أو عزل أي شيء. يبقى تدفق بريدك كما كان قبل إضافة DMARC. القيمة هنا تكمن بالكامل في التقارير. ستبدأ بتلقي تقارير مجمّعة (عادة يوميًا، بصيغة XML) تُظهر كل خادم يرسل بريدًا باستخدام نطاقك، وما إذا كانت تلك الرسائل قد اجتازت المصادقة، ومن أين جاءت.
هذه هي مرحلة الاكتشاف. غالبًا ما ستتفاجأ بما تجده. أدوات تسويقية، تكاملات CRM قديمة، منصة نشرات إخبارية منسية، كلها ترسل بريدًا "من" نطاقك دون مصادقة صحيحة. تريد اكتشاف هذه الأمور قبل تشديد السياسة، لا بعده.
خطط للبقاء عند p=none لمدة أسبوعين إلى أربعة أسابيع على الأقل. وأطول من ذلك إذا كان نطاقك يرسل بريدًا عبر الكثير من الأدوات الخارجية.
السياسة الثانية: p=quarantine
بمجرد أن تُظهر تقاريرك أن البريد الشرعي يجتاز SPF وDKIM باستمرار، يمكنك الانتقال إلى p=quarantine. هذا يخبر الخوادم المستقبِلة بالتعامل مع الرسائل الفاشلة بحذر، عادة عبر توجيهها إلى مجلدات البريد العشوائي بدلًا من رفضها تمامًا.
العزل هو الحل الوسط. فهو يمنحك حماية حقيقية، لن تصل الرسائل المزيفة إلى صندوق الوارد الرئيسي، بينما يظل يوفر لك شبكة أمان. إذا بدأ شيء لم تلتقطه أثناء مرحلة المراقبة في الفشل، فسينتهي به المطاف في البريد العشوائي بدلًا من الاختفاء تمامًا. لا يزال بإمكانك إيجاده وتشخيص المشكلة وإصلاحها.
يمكنك أيضًا تطبيق العزل تدريجيًا باستخدام وسم pct. فضبط pct=25 يطبّق سياسة العزل على 25% فقط من الرسائل الفاشلة، مما يتيح لك الزيادة تدريجيًا ومراقبة المشاكل أثناء ذلك.
السياسة الثالثة: p=reject
هذه هي السياسة الصارمة. سترفض خوادم البريد المستقبِلة الرسائل التي تفشل في اجتياز DMARC تمامًا. لا صندوق وارد، لا مجلد بريد عشوائي، فقط رفض على مستوى الخادم.
الرفض هو ما تريده لنطاق محمي بالكامل، خاصة للنطاقات المستخدمة في المراسلات المالية، أو إعادة تعيين كلمات المرور، أو أي شيء قد يرغب المهاجمون في انتحاله. كما أن هذا ما يتوقعه معظم مزودي البريد الكبار بشكل متزايد من المرسلين الشرعيين، خاصة بعد أن شددت Gmail وYahoo متطلباتهما للمرسلين بالجملة.
لكن الرفض يجب أن يكون الخطوة الأخيرة، لا الأولى. القفز مباشرة إلى p=reject دون المرور أولًا بمرحلتي المراقبة والعزل هو أحد أكثر أخطاء DMARC شيوعًا التي نراها. فإذا لم يكن مصدر إرسال شرعي واحد فقط مُعدًا بشكل صحيح للمصادقة، تختفي تلك الرسائل. لا يصل أي إشعار ارتداد إلى المرسل، لأن الرفض يحدث في جهة الاستقبال. قد لا تدرك أن هناك خطأً حتى يخبرك عميل بأنه لم يستلم فاتورته أبدًا.
كيفية الانتقال بين السياسات بأمان
المسار العام يبدو كالتالي:
- ابدأ بـ p=none واجمع التقارير لعدة أسابيع.
- راجع كل مصدر إرسال في تلك التقارير وأصلح SPF أو DKIM لأي مصدر شرعي يفشل.
- انتقل إلى p=quarantine بقيمة pct منخفضة، ثم زدها تدريجيًا.
- بمجرد أن تبدو تقارير العزل نظيفة، انتقل إلى p=reject، مع زيادة تدريجية عبر pct أيضًا إذا أردت حذرًا إضافيًا.
قراءة التقارير المجمّعة يدويًا أمر مرهق. يستخدم معظم الناس أداة تقارير DMARC لتحليل ملفات XML إلى شيء يمكن قراءته. هذا هو العامل الأكبر في نجاح إعداد DKIM SPF DMARC فعليًا. تخطي خطوة التقارير والتخمين في طريقك نحو الرفض هو السبب الذي يجعل البريد الشرعي يختفي.
ماذا عن سياسة النطاقات الفرعية؟
تتيح لك DMARC ضبط سياسة منفصلة للنطاقات الفرعية باستخدام وسم sp. هذا أهم مما يتوقعه الناس. فإذا كان نطاقك الرئيسي يحمل سياسة رفض صارمة لكنك لم تضبط sp، فقد ترث النطاقات الفرعية وضعًا أضعف، أو قد يستهدف المهاجمون تحديدًا نطاقًا فرعيًا غير محمي لتزييف بريد لا يزال يبدو موثوقًا للمستلمين. ضبط sp=reject إلى جانب سياستك الرئيسية يسد تلك الفجوة.
التحقق من أن سياستك تعمل فعليًا
بمجرد ضبط سياسة، لا تفترض فقط أنها تؤدي عملها. أرسل رسائل اختبار من مصادر غير مصادق عليها، راجع تقارير DMARC الخاصة بك بانتظام، وراقب أي انخفاض في قابلية التسليم مباشرة بعد تغيير السياسة. لقد شرحنا هذه العملية بتفصيل أكبر في كيفية التحقق من أن إعداد DKIM SPF DMARC يعمل فعليًا بشكل صحيح.
إذا كنت تدير البريد الإلكتروني لنطاق عمل، فينبغي أن يكون مزود الاستضافة الجيد قادرًا على مساعدتك في مراجعة سجلات DNS الخاصة بك والتأكد من أن إدخالات SPF وDKIM وDMARC منسقة بشكل صحيح. خطأ إملائي واحد في سجل DMARC TXT يمكن أن يجعل السياسة بأكملها عديمة الأثر دون أي تحذير.
خلاصة القول
None وQuarantine وReject ليست ثلاث ميزات منفصلة، بل هي مراحل من نفس الرحلة. ابدأ بالمراقبة، انتقل إلى تطبيق تدريجي خفيف، ولا تُغلق الباب إلا بعد أن تتأكد من أن كل مرسل شرعي يملك مفتاحًا. إذا تسرعت، تخاطر بفقدان بريد حقيقي. وإذا تخطيت الأمر تمامًا، يبقى نطاقك مكشوفًا تمامًا للتزييف. على أي حال، الوجهة واحدة: سياسة p=reject مطبقة بالكامل، مدعومة بسجلات SPF وDKIM نظيفة عبر كل مصدر إرسال تملكه، وذلك ضمن إعداد DKIM SPF DMARC متكامل وموثوق.
