اضبط SPF وDKIM وDMARC حول كل نظام مخوّل بالإرسال باسم نطاقك. بريد الموظفين مسار واحد فقط؛ فقد يرسل الموقع وCRM ونظام الدعم ومنصة الحملات بصورة مستقلة. افحص رسائلها الفعلية والنطاقات المصادَق عليها والمحاذاة قبل تغيير سياسة النطاق أو اعتماد مثال إعداد عام.
تنتج المراجعة المفيدة جردًا للمرسلين وأدلة رسائل ومسؤولًا محددًا لكل تصحيح. لا تكفي علامة نجاح في لوحة DNS إذا ظل الموقع يرسل بهوية غير مرتبطة بنطاقه الظاهر. وبالمثل، لا تعني نتيجة DMARC الناجحة وعدًا بأن يضع المستلم الرسالة في صندوق الوارد.
ابدأ بالأشخاص الذين يشغّلون كل نظام. اسأل عن عنوان From الظاهر ومزوّد الإرسال ومن يستطيع تعديل هذا الإعداد. ضم المرسلين غير المتكررين مثل أدوات الفوترة؛ فقد لا تكشف تقارير أسبوع هادئ عن نظام لا يرسل إلا مرة كل شهر أو عند حدث نادر.
استخدم ورقة العمل الأصلية التالية قبل طلب تغييرات DNS. سجّل نطاق مرسل الغلاف ونطاق توقيع DKIM من رسائل مستلمة تمثل المسار وإعدادات المزوّد، بدل افتراض تطابقهما مع العنوان الذي يظهر للمستلم. احفظ تفاصيل الرسائل داخل سجل مشروع ذي صلاحيات مناسبة للأشخاص المعنيين فقط.
| مسار الإرسال | مسؤول العمل | الهوية والأدلة المطلوب تسجيلها |
|---|---|---|
| بريد الموظفين | مسؤول البريد | From الظاهر ونطاق الغلاف وتوقيع DKIM ونتائج الاستقبال |
| رسائل الموقع | مسؤول صيانة الموقع | مزوّد النماذج والرسائل التشغيلية والمرسل المضبوط ومثال مستلم |
| CRM أو نظام الدعم | مالك النظام | سلوك العنوان المشترك وربط الإرسال وهوية التوقيع |
| الحملات التسويقية | مسؤول الحملات | نطاق الإرسال ومصادقة المزوّد وأدلة حملة تمثل المسار |
| المالية والأدوات الأخرى | فريق العمليات المعني | المرسلون غير المتكررين وتوثيق المزوّد وموعد التحقق |
| منصة المصدر المراد إيقافها | مسؤول الترحيل | الإرسال المخوّل المتبقي ودليل انتهاء الحاجة قبل إزالة التفويض |
مصدر الإرسال المجهول بند يحتاج تحقيقًا. قد يكون ربطًا مشروعًا أغفله الجرد، أو استخدامًا غير مخوّل. لا تمنح الإذن لكل مصدر لمجرد ظهوره في تقرير. حدّد النظام ومسؤوله أولًا، ثم قرّر هل يحتاج إلى إعداد صحيح أم إلى إنهاء المسار ومنع استخدامه.
يفحص SPF هل خادم الإرسال مخوّل للنطاق الجاري تقييمه، وعادةً يكون نطاق مرسل الغلاف. وقد يختلف هذا عن عنوان From الظاهر. ويتحقق DKIM من توقيع يغطي أجزاء محددة من الرسالة بمفتاح مرتبط بنطاق التوقيع. أما DMARC فيفحص محاذاة هوية مصادَق عليها بنجاح مع نطاق From الظاهر.
يميّز دليل إعداد DMARC من Microsoft بين مرسل الغلاف والمرسل الظاهر ونطاق توقيع DKIM. يمكن أن تنجح الرسالة في DMARC عبر SPF محاذٍ أو DKIM محاذٍ. راجع الآليتين في إعداد المرسل، ولا تعتبر نجاح رسالة واحدة إثباتًا لصحة جميع مسارات الإرسال الأخرى.
يتضح الفرق في الأمثلة التالية. تستخدم الحالات الأصلية نطاقات محجوزة للتوضيح ونتائج اختبار مفترضة. ليست ترويسات ملتقطة أو أدلة من شركة حقيقية. استخدمنا نطاقات متطابقة تمامًا حتى لا يعتمد تفسير المثال على خلاف حول حدود النطاق التنظيمي أو على إعداد نطاق فرعي معين.
| الحالة التوضيحية | نطاق From الظاهر | نتيجة المصادقة | تفسير DMARC |
|---|---|---|---|
| رسالة موظف | example.com | ينجح SPF للنطاق example.com وينجح DKIM للنطاق نفسه | توجد هوية مصادَق عليها ومحاذية |
| CRM بهويات المزوّد | example.com | ينجح SPF وDKIM للنطاق vendor.example.net فقط | الفحوص ناجحة لكنها غير محاذية، فلا تنتج نجاح DMARC |
| حملة بتوقيع النطاق | example.com | ينجح SPF للنطاق vendor.example.net وينجح DKIM للنطاق example.com | يمكن أن ينتج النجاح من DKIM المحاذي |
| رسالة معاد توجيهها بتوقيع سليم | example.com | يفشل SPF ويظل DKIM ناجحًا للنطاق example.com | يمكن أن ينتج النجاح من DKIM المحاذي |
يفترض مثال إعادة التوجيه بقاء التوقيع صالحًا. قد يغيّر وسيط المحتوى أو يعالج الرسالة بطريقة أخرى؛ لذا اختبر مسارات إعادة التوجيه والقوائم البريدية المهمة، ولا تفترض أن المثال يصف كل مسار. وتبقى أحكام المصادقة أو الترشيح الأخرى لدى المستقبِل منفصلة عن نتيجة DMARC المحددة.
حلّ RFC 9989، المنشور في مايو 2026، محل RFC 7489 وRFC 9091. أزال الوسم القديم pct وحدّث اكتشاف النطاق التنظيمي. لا تستخدم وصفة تطبيق تدريجي بنسب مئوية من دليل قديم باعتبارها إرشاد البروتوكول الحالي. تحقّق مما يدعمه المزوّدون الفعليون قبل تطبيق أمثلة الإعداد.
ينص المعيار أيضًا على ألا يعتمد المرسلون الذين يستخدمون p=reject على SPF وحده، وأن يضيفوا توقيعات DKIM صالحة. يختلف هذا المتطلب على المرسل عن قاعدة نجاح الرسالة المفردة أعلاه. اجمع المعيار الحالي وتطبيق المزوّد الموثق ونتائج الرسائل المرصودة في المراجعة نفسها.
عمليًا، ميّز المحاذاة المرنة التي تعتمد اشتراك النطاق التنظيمي عن المحاذاة الصارمة التي تتطلب تطابق النطاقين. لا يكفي تشابه نهاية الاسمين لإثبات الحد التنظيمي. إذا اعتمد الإعداد على نطاقات فرعية، فتحقّق من سلوك الاكتشاف والمحاذاة المعني، ولا تختزل القاعدة في آخر جزأين من الاسم.
راجع السجل القائم قبل إضافة أي شيء. تذكر إرشادات تشخيص SPF من Google تعدد سجلات SPF وغياب مرسلين خارجيين وزيادة استعلامات DNS ضمن المشكلات الشائعة. احتفظ بسياسة SPF واحدة لكل نطاق يجري تقييمه، وتحقّق من الصياغة وسلوك الاستعلامات بعد تضمين المزوّدين المخولين.
لا يعني ذلك أن النطاق لا يستطيع امتلاك أكثر من سجل TXT واحد بأي غرض. قد تستخدم سجلات التحقق وخدمات أخرى النوع نفسه. حدّد سياسة SPF المعنية، وتجنب حذف سجلات غير مرتبطة بها، واحتفظ بالإعداد السابق في سجل التغيير. فقد يغفل مثال المزوّد المنسوخ خدمة أخرى ترسل بصورة مشروعة.
في DKIM، تحقّق من معلومات المفتاح المنشورة ومن إعداد التوقيع في خدمة الإرسال معًا. افحص رسالة مستلمة لمعرفة النطاق الذي وقّعها وهل نجح التحقق. نشر سجل DNS وحده لا يثبت أن المزوّد يوقّع الرسائل بتلك الهوية. نسّق تغييرات المفاتيح وفق العملية التي يوثقها المزوّد المعني.
وفي DMARC، سجّل النطاق والسياسة الحالية ووجهة التقارير وإعداد المحاذاة. تأكّد من سيطرة المؤسسة على DNS المعني وإمكان استقبال التقارير ومراجعتها. الوصول إلى حساب مسجل النطاق لا يعني بالضرورة الوصول إلى مستضيف DNS المعتمد، وقد يحتاج التغيير مسؤولًا آخر ضمن الفريق أو المزوّدين.
عند التطبيق الجديد، ابدأ بخطة لحصر الإرسال المشروع ومراجعة المصادقة قبل تشديد المعالجة. توصي إرشادات إعداد DMARC من Google بحصر خدمات الإرسال الخارجية ومراقبة التقارير. قيّم أمثلة المزوّد بجانب المعيار الحالي، ولا تنسخ وصفة أقدم تعتمد نسبة تطبيق السياسة دون مراجعة دعمها وسلوكها.
إذا كانت السياسة مطبقة بالفعل، حافظ على الحالة القائمة أثناء التحقيق ما لم يوافق المسؤول على تغيير محدد. قد يضعف التحويل العام إلى وضع المراقبة حماية موجودة دون معالجة السبب. عرّف المشكلة والنتيجة المطلوبة أولًا، بدل استخدام إعادة الضبط خطوة افتراضية في كل تدقيق.
يضم سجل التغيير المفيد أربعة أجزاء:
- الدليل: مسار الإرسال والوقت ونتائج المصادقة المعنية والفشل المرصود.
- التصحيح المقترح: إعداد المزوّد أو DNS المتأثر، مع مسؤوله والأثر المتوقع.
- التحقق: الرسائل والتقارير وردود الاستقبال التي ستُفحص بعد التغيير.
- المتابعة: المرسلون غير المحسومين وموعد المراجعة وشروط إبقاء التغيير أو الرجوع عنه.
تساعد تقارير DMARC على كشف استخدام النطاق، لكنها ليست جردًا كاملًا لكل رسالة أو قرار مستلم. راجع فترة التقرير وتغطيته المتاحة وجدول الإرسال الفعلي. أعطِ المرسلين المشروعين غير المحسومين إجراءات ومسؤولين محددين، ولا تجعل التقرير الخالي دليلًا على اكتمال الإعداد وصحة كل المسارات.
حدّث جرد المرسلين عند إضافة ربط للموقع أو تغيير CRM أو بدء خدمة حملات أو ترحيل بريد الموظفين. أزل تفويض مصدر قديم عندما يتحقق المسؤول من انتهاء عمله المشروع، وفق خطة الانتقال المتفق عليها. لا تجعل تغيير منصة الموظفين سببًا لحذف تفويض نظام آخر ما زال يعمل.
استخدم قائمة ترحيل بريد الشركة لربط مراجعة المصادقة بقبول الصناديق والوصول المشترك. وللعمل على قواعد جمهور الحملات وردود المستلمين وتشخيص موضع الرسائل، انتقل إلى قائمة قابلية تسليم البريد التي تفصل تلك الأدلة عن مجرد نجاح فحص النطاق والسجلات المنشورة.
يمكن أن تحدد خدمة بريد الشركات من تكنوستاك نطاق المراجعة بين الأنظمة وتسليم التشغيل. وتشمل باقات الاستضافة المُدارة أصلًا فحوص SPF وDKIM وDMARC المعلنة وفق إعدادات مزوّد البريد. راجع هذا البند المشمول أولًا، ثم اتفق على أي إعداد إضافي للمرسلين أو عمل ترحيل مطلوب.
