يمكن أن تمر رسالة DMARC ولا تزال تفشل في تلبية متطلبات المرسل الخاصة بموفر صندوق البريد. وهذا ليس بالضرورة تناقضا. يجيب DMARC على سؤال هوية محدد؛ قد يحتاج المستقبل أيضًا إلى آليات فعالة ونقل آمن وبناء رسالة مناسب وسلوك إرسال مسؤول.
ابدأ بقرار البروتوكول
مراجع: RFC 9989 §4.1, RFC 9989 §4.4, RFC 9989 §4.10, RFC 9989 §5.3.5.
RFC 9989، الذي تم نشره في مايو 2026، يلغي طلبات RFC القديمة 7489 و9091. وبموجب القسم 4.1، يتم تمرير DMARC عند وجود سجل سياسة لمجال المؤلف ومحاذاة هذا المجال مع معرف تمت مصادقته من الرسالة. يبقى مبدأ التمرير الانحيازي: يجب أن تمر آلية مصادقة مدعومة واحدة على الأقل تنسيق إلى المجال المرئي من. ل SPF ضمن DMARC ، الهوية ذات الصلة هي SMTP البريد من المجال تحت RFC 9989 §4.4.2؛ ولا تُعد نتيجة نظام التعرف على هوية المرسل ( SPF المستندة إلى HELO بديلاً عن هوية DMARC تلك. ل DKIM، فهو المجال d= للتوقيع الصالح. الآلية الناجحة دون المحاذاة المطلوبة لا تساهم في تمرير DMARC . RFC 9989 الأقسام 3.2.10 و4.1-4.3.
المحاذاة لها أوضاع صارمة ومريحة. Strict يقارن المجالات القابلة للتطبيق تمامًا؛ يستخدم الاسترخاء علاقتهم بالمجال التنظيمي. RFC 9989 القسم 4.10 يحدد مسيرة شجرة DNS الاكتشاف بدلاً من نهج قائمة اللواحق العامة القديمة. تحقق من الإصدار الذي تم تنفيذه بواسطة المتلقي أو المُقيم قبل افتراض سلوك الاكتشاف الخاص به. لا تقم بتنفيذ محاذاة مريحة عن طريق التحقق مما إذا كانت سلسلة مجال واحدة تنتهي بسلسلة أخرى فقط. يمكن أن تؤدي اللاحقة المخادعة أو الحساب غير الصحيح للمجال التنظيمي إلى نتيجة خاطئة.
أضف متطلبات الموفر كطبقة منفصلة
تتطلب إرشادات الدعم الكبير الحجم للمستهلك من Microsoft اجتياز كل من نظام التعرف على هوية المرسل SPF و DKIM ، بالإضافة إلى DMARC . تتطلب متطلبات Yahoo المجمعة كلا الآليتين وتمرير DMARC . هذه هي البوابات التشغيلية بالإضافة إلى منطق الآلية المحاذية للبروتوكول. قم بمراجعة المصدر الحالي للوجهة بدلاً من استنتاج قاعدة عالمية من موفر واحد. دعم مايكروسوفت و متطلبات Yahoo.
أنشئ عمودًا واحدًا لنتيجة DMARC وأعمدة منفصلة للمصادقة المطلوبة و DNS والنقل والتنسيق وعناصر التحكم في إلغاء الاشتراك. إن وجود مؤشر أخضر عام بدون تلك الأعمدة يجعل من الصعب معرفة ما إذا كان البرنامج يقوم بتقييم البروتوكول أو قائمة مراجعة الموفر أو بناء جملة DNS المنشور فقط.
استخدم جدول الحقيقة لتوضيح الفرق
مراجع: RFC 9989 §5.3.5.
تشتمل حزمة المراجعة الخاصة على تركيبات صناعية مكونة من حالتين. أولاً، يمر كل من نظام التعرف على SPF و DKIM ولكن لا تتم محاذاة أي منهما: يفشل DMARC . ثانيًا، يفشل SPF أثناء تمرير DKIM ومحاذاته: يمرر DMARC . لا يزال من الممكن أن تفشل الحالة الثانية في بوابة الموفر التي تتطلب بشكل مستقل نجاح نظام التعرف على هوية المرسل SPF .
هذه المدخلات عبارة عن قيم منطقية بسيطة عن عمد، وليست تطبيقًا لاكتشاف DNS Tree Walk، أو الاكتشاف القديم القائم على اللاحقة العامة، أو تقييم نظام التعرف على هوية SPF ، أو تشفير DKIM . تفترض كلتا الحالتين وجود سجل سياسة DMARC قابل للتطبيق. إنهم يجعلون التمييز المنطقي قابلاً للتكرار دون التظاهر باختبار مقدم الخدمة. في التحقيق الحقيقي، استبدل كل قيمة منطقية بنتيجة ملحوظة موثوقة وهويتها المقيَّمة.
لا تخلط بين النشر والتقييم
مراجع: RFC 9989 §5.4.
نشر p=none ينشئ سياسة مراقبة مطلوبة، وليس نتيجة ناجحة لمصادقة الرسالة. لا يؤدي نشر مفتاح DKIM العام إلى تسجيل البريد الصادر. إضافة ان سجل SPF لا يثبت الاتصال الفعلي باستخدام عنوان معتمد. تحتاج كل قطعة أثرية للتكوين إلى ملاحظة مقابلة من مسار الإرسال المقصود.
وبالمثل، الانتقال من p=none إلى p=reject لا إصلاح المحاذاة. يقوم بتغيير المعالجة المطلوبة لمالك المجال في حالات الفشل. جرد المسارات المشروعة قبل تغيير الإنفاذ، والحفاظ على خطة التراجع وتقييم التأثير على التدفقات غير المباشرة. لا يزال المتلقي يطبق سياسة التصرف المحلية الخاصة به؛ ولا يعد إجراء DMARC المطلوب ضمانًا للتسليم.
بناء سجل إغلاق مفيد
مراجع: RFC 8601 §5.
بالنسبة لكل عينة تم فحصها، احتفظ بـ "من" ومرسل المغلف وعنوان IP المتصل وموقّع DKIM و محددونتائج الآلية ووضع المحاذاة واستجابة الاستلام النهائية. حدد المصدر الموثوق لتلك النتائج. لا تقبل الرؤوس المنسوخة بشكل عشوائي باعتبارها موثوقة لمجرد أنها تحتوي على كلمة "تمرير".
قم بإغلاق نتيجة البروتوكول ونتائج امتثال الموفر بشكل منفصل. وهذا يجعل من الممكن القول بدقة أن DMARC قد تم اجتيازه بينما بقي متطلب آخر دون حل، وتعيين التصحيح إلى المالك الصحيح دون إضعاف الضوابط غير ذات الصلة.