أعط كل وجهة نظر مراقبة سؤالا دقيقا
تجيب مراقبة صحة المجال ومراقبة مصادقة الرسائل على أسئلة ذات صلة ولكن مختلفة. يمكن للأول فحص ما إذا كانت تبعيات DNS المحددة موجودة أم لا، وتحليلها وتبقى متسقة مع التكوين المقصود. أما الثاني فيفحص ما حدث عندما واجهت رسائل معينة أجهزة استقبال معينة. إن تسمية كلا وجهتي النظر بـ "سلامة البريد الإلكتروني" دون تحديد الأدلة الخاصة بهما يجعل من السهل إساءة فهم لوحة المعلومات المطمئنة.
هذا نموذج مراقبة مقترح، وليس عرضًا توضيحيًا لمنتج EmailAuth . لم يتم الاستعلام عن أي مجال، ولم يتم جمع أي رسالة أو تقرير، ولم يتم نشر أي جهاز مراقبة. تمت مراجعة المراجع في 8 نوفمبر 2026، بما في ذلك مايو 2026 DMARC تحديد. لا يزال دعم الموفر الفعلي وإصدارات المُقيِّم وحركة العملاء وسلوك التنبيه غير مؤكد.
حدد ما يمكن أن يلاحظه فحص المجال
يمكن أن يحتفظ فحص المجال بالاسم الدقيق الذي تم الاستعلام عنه ونوع السجل والإجابة ووقت التجميع وميزة الحل. وقد يكتشف سياسة مفقودة، أو بناء جملة مشوه، أو تفويض غير متوقع، أو تغيير من خط أساس معتمد. وتعتمد ثقتها على طريقة الجمع واكتمالها. قد تعكس الإجابة العودية التخزين المؤقت؛ قد تعكس قائمة مستوى التحكم الخاص بالموفر تكوينًا معلقًا بدلاً من النشر العام الحالي.
للحصول على تمييز ملموس للمزود، يقول Route 53 أن عملية القائمة الخاصة به يمكنها إرجاع السجلات في انتظار التوزيع على خوادم DNS . لذلك، لا ينبغي دمج مخزون واجهة برمجة التطبيقات (API) ومراقبة DNS الرسمية في حقيقة واحدة ذات طابع زمني. استخدم تسميات منفصلة واحتفظ بالخلاف للتحقيق فيه. RFC 1034 يشرح السلطة والتخزين المؤقت، في حين أن مرجع Route 53 API يصف سلوك طائرة التحكم.
تعتمد عمليات التحقق من المجال أيضًا على النطاق المتوفر. أ DKIM يتطلب البحث عن المفتاح أ محدد; فحص المحفظة الذي يعرف أن محددًا واحدًا لا يمكنه إنشاء تغطية لكل تطبيق. صالحة سجل SPF لا يخبر الشاشة بالخادم الذي أرسل الرسالة بالفعل. يجب أن يذكر عرض التكوين هذه القيود بجوار نتيجته، بدلاً من إخفائها خلف تسمية سليمة.
اتبع هويات الرسالة الفعلية
SPF يقوم بتقييم مضيف الإرسال مقابل هوية SMTP . يقوم التحقق DKIM بتقييم التوقيع ومجال التوقيع الخاص به. يقوم DMARC بعد ذلك بربط المصادقة الأساسية الناجحة بنطاق مؤلف الرسالة. لا يجبر إعداد DNS ذو المظهر الصحيح تطبيق الإرسال على اختيار الهوية المقصودة أو إرفاق التوقيع المقصود. RFC 7208, RFC 6376 و RFC 9989 وصف أدوار البروتوكول هذه.
لنفترض مرسلًا وهميًا يستخدم نطاق مغلف محاذيًا ولكنه يرسل من عنوان IP لا تسمح به سياسة نظام التعرف SPF الخاص به. لنفترض أن توقيع DKIM الخاص به معطل. مفتاح SPF و DKIM المنشور للنطاق و سجلات DMARC يمكن أن تكون جميعها صحيحة من الناحية النحوية، إلا أن هذه الرسالة لن تحتوي على آلية تمرير محاذية. وهذا سيناريو توضيحي، وليس فشلًا تم التقاطه أو ادعاء بأن جهاز استقبال معين رفضه.
سيكون الدليل التالي عبارة عن عينة رسالة معتمدة وتقييم جهاز استقبال موثوق به، مقترنًا بملاحظات التكوين والطوابع الزمنية ذات الصلة. ان Authentication-Results يكون ذا معنى فقط ضمن حدود الثقة المناسبة. يمكن للمرسل إدراج رأس مسمى بشكل مشابه؛ مجرد العثور على النص لا يؤكد صحة التأكيد. RFC 8601.
استخدم التقارير دون التظاهر بأنها تغطي كل شيء
DMARC تقارير مجمعة توفير ملاحظات المتلقي على مدى فترة التقارير، بما في ذلك معلومات المصدر، وأعداد الرسائل والنتائج المتعلقة بالمصادقة. يمكنهم الكشف عن التدفق الفاشل الذي لا يستطيع مدقق السجل الثابت رؤيته. فهي ليست نسخة مستمرة لجميع رسائل البريد، ولا يعد التقرير الغائب دليلاً على عدم وجود حركة مرور أو نجاح عالمي. تؤثر المشاركة وتسليم التقارير واكتمال المعالجة على السكان الذين تمت ملاحظتهم. RFC 9990.
قم بتخزين تنظيم التقارير والفاصل الزمني ووقت الوصول وحالة المعالجة بشكل منفصل. يمكن للتقرير المتأخر أن يصف حالة سابقة. يمكن أن يؤدي فشل المحلل اللغوي أو مهمة الاستيعاب القديمة إلى جعل فجوة المراقبة تبدو وكأنها تحسن إذا قامت لوحة المعلومات فقط بإزالة البيانات المفقودة. قم بالتوفيق بين المصادر المتوقعة حيثما أمكن ذلك، ولكن تجنب اختراع مجموعة مستقبلية متوقعة لم تقم المنظمة بتأسيسها من قبل.
تصميم تنبيهات لفئات الفشل المميزة
يجب أن يوضح تنبيه التكوين المقترح ما الذي تغير، وأين تمت ملاحظته، وما إذا كانت إعادة المحاولة قد أكدت الملاحظة. يجب أن يحدد تنبيه الرسالة التدفق المتأثر والمحتوى المرصود، مع سياق هوية كافٍ للتمييز بين فشل المصادقة ومرسل غير معروف ولكنه عابر. يجب أن يحدد تنبيه التغطية الأدلة القديمة أو المفقودة أو غير المعالجة. وهذه قرارات تشغيلية منفصلة حتى لو ظهرت في تقرير واحد.
قم بتعيين الحدود مع صاحب العمل. قد يكون عدد صغير من رسائل إعادة تعيين كلمة المرور الفاشلة أكثر أهمية من تدفق تسويقي أكبر بكثير ومنخفض القيمة. سجل المقام والنافذة الزمنية خلف كل نسبة مئوية. لا تقدم درجة التكوين الخضراء كضمان للتسليم، أو تفسر نتيجة DMARC الناجحة كدليل على موافقة العميل أو أمان الرسالة أو وضع البريد الوارد.
الارتباط قبل تغيير أي شيء
عندما تختلف وجهات النظر، قم بمحاذاة أوقات المراقبة الخاصة بها وقارن بين هويات المؤلف والمغلف والتوقيع الفعلي. تحقق مما إذا تم تغيير المرسل، أو تدوير المحدد، أو تعديل المسار للمحتوى الموقع، أو احتفاظ المحلل بإجابة قديمة. الحفاظ على التفسيرات المتنافسة حتى تفصل الأدلة بينها. قد يكون التصعيد الصحيح لمالك التطبيق بدلاً من مشغل DNS .
بالنسبة للمرسل الخيالي غير الموقع، فإن إضافة مفتاح عام آخر لن يؤدي إلى تمكين تسجيل الدخول في التطبيق. يجب أن يستهدف الإصلاح المقترح السبب الذي تم التحقق منه وأن يكون له موافقته الخاصة ومعايير التراجع وأدلة ما بعد التغيير. لا يسمح تنبيه المراقبة ولا فرضية المحلل بتحرير DNS أو إجراء بيانات الاعتماد أو الكشف الخارجي أو رسالة الاختبار.
أبقِ العرض التوضيحي وإصدار الأدلة منفصلين
تظل بوابة الكتالوج مفتوحة: قارن تكوين DNS سليمًا مع مرسل حقيقي فاشل والأدلة التي يكشفها كل عرض. تشرح الحالة الخيالية أعلاه سبب أهمية هذه المقارنة ولكنها لا ترضي كلمة "حقيقي". سيتطلب الأمر مثالًا تشغيليًا معتمدًا ويتم التعامل معه بأمان مع التكوين المترابط وأدلة المتلقي. ولم يتم الحصول على مثل هذه الأدلة هنا. لا تزال المراجعة الفنية البشرية والفحص المستقل والتحقق من صحة التنفيذ الحالي وموافقة نشر المالك معلقة.