تحت RFC 9989 §5.4, a DMARC المرور لا يضمن وضع البريد الوارد. يقوم بإنشاء نتيجة مصادقة مجال محاذية للرسالة. لا يزال بإمكان خدمة الاستقبال رفض الرسالة لسبب آخر، أو قبولها في الرسائل غير المرغوب فيها، أو وضعها في البريد الوارد، أو تطبيق معالجة خاصة بالمستخدم لاحقًا.
هذه الحدود مهمة لأن التشخيص الخاطئ يخلق التغيير الخاطئ. لا يستطيع DNS إصلاح الموافقة السيئة أو الشكاوى المستمرة أو المحتوى غير المرغوب فيه. وعلى العكس من ذلك، لا يعمل عمل السمعة على إصلاح مسار المصادقة غير المحاذي.
فصل مراحل التسليم
استخدم أربعة قياسات مختلفة:
- المرحلة: التوثيق؛ السؤال: هل SPF أو DKIM تم اجتيازه، وهل تمت محاذاة هوية مرور واحدة على الأقل مع من؟
- المرحلة: القبول؛ سؤال: هل قبل الخادم المتلقي الرسالة أثناء SMTP ؟
- المرحلة: التنسيب. سؤال: بعد القبول أين وضع المتلقي الرسالة أو كشفها؟
- المرحلة: الخطوبة؛ سؤال: ماذا فعل المتلقي، وما مدى موثوقية هذا القياس؟
تم تحديد إكمال SMTP موجب بعد نهاية البيانات في RFC 5321 §4.2.5. يمكن للرسالة اجتياز المصادقة وفشل القبول. يمكن قبوله ووضعه في البريد العشوائي. يمكنه الوصول إلى البريد الوارد وعدم تلقي أي مشاركة مفيدة. لا تصف جميع النتائج الأربع بأنها إمكانية التسليم.
قراءة جدول تشخيصي خيالي
الحالات التالية اصطناعية. وهي توضح كيفية اختيار التحقيق التالي دون المطالبة بالأداء الملحوظ.
- الملاحظة: DMARC ؛ الحالة أ: النجاح؛ الحالة ب: تمرير؛ الحالة ج: فشل
- الملاحظة: SMTP ؛ الحالة أ: مقبولة؛ الحالة ب: مقبولة؛ الحالة ج: تم الرفض من خلال الاستجابة المتعلقة بالمصادقة
- الملاحظة: التنسيب؛ الحالة أ: البريد العشوائي؛ الحالة ب: البريد الوارد؛ الحالة ج: لا تتوفر نسخة تم تسليمها
- الملاحظة: الشكاوى أو إشارات المتلقي؛ الحالة أ: الشكاوى المرتفعة؛ الحالة ب: عادية للفوج المحدد؛ الحالة ج: لا تنطبق على الرسالة المرفوضة
- الملاحظة: التركيز التالي؛ الحالة أ: الموافقة والتوقعات والسمعة والمحتوى وأنماط الإرسال؛ الحالة ب: مواصلة مراقبة حركة المرور المماثلة؛ الحالة ج: سلسلة الهوية والتوقيع ومسار نظام التعرف على هوية SPF واستجابة الموفر
في الحالة أ، لا يؤدي تغيير DMARC من لا شيء إلى رفض إلى معالجة سبب عدم رغبة الرسائل التي تمت مصادقتها. التحقيق في مصدر القائمة والقمع والتكرار والمحتوى وتعليقات المزود. في الحالة ج، لا يمكن أن يبدأ اختبار البريد الوارد حتى يتم فهم الرفض المتعلق بالمصادقة.
استخدم المصادقة كشرط أساسي، وليس كاختصار للسمعة
يقوم موفرو صندوق البريد بنشر المتطلبات والتوصيات للمرسلين، مثل إرشادات Google لمستلمي Gmail الشخصيين. يمكن أن تتضمن هذه المتطلبات SPF ، DKIM ، DMARC ، DNS الصالح، وممارسات النقل، وضوابط الشكاوى، وسهولة إلغاء الاشتراك في حركة المرور المعمول بها. إن تلبية أحد المتطلبات لا يعني التنازل عن المتطلبات الأخرى.
تعد المصادقة ذات قيمة لأنها تنشئ هوية مجال مستقرة وتساعد المستلمين في تحديد البريد. ولا يشتري السمعة أو يثبت موافقة المتلقي أو يضمن معاملة تفضيلية. قرارات السمعة والتصنيف خاصة بالمستقبل ويمكن أن تختلف حسب تدفق حركة المرور والمستلم والوقت.
لا تستنتج العلاقة السببية من تغيير DNS المتزامن وتغيير الموضع. يمكن لبرنامج الإرسال تغيير الحجم والجمهور والمحتوى والبنية التحتية في نفس الوقت. سجل التدخلات وقارن بين المجموعات المماثلة قبل التوصل إلى نتيجة.
التشخيص مع الأدلة من المتلقي ذي الصلة
ابدأ باستجابة SMTP الفعلية ونتائج المصادقة الموثوقة ضمن الحدود المحددة بواسطة RFC 8601 §7.1. إذا تم رفض الرسالة، فيمكن أن يحدد الرمز والنص المصاحب فئة ما، لكن الرمز وحده لا يمثل تشخيصًا كاملاً. هناك حاجة إلى وثائق الموفر وسجلات الإرسال لتفسيرها.
إذا تم قبول الرسالة، فاستخدم القياس عن بعد للموفر المتوفر، واختبار البذور مع القيود المذكورة، وتقارير المستلمين، وبيانات الحملة الخاضعة للرقابة. يعد صندوق البريد الاختباري دليلاً على صندوق البريد والرسالة، وليس توقعًا عالميًا لكل مستلم.
للمصادقة، سجل من، هوية SPF التي تم تقييمها، كل DKIM d= domain، تنسيق والسياسة المعمول بها. بالنسبة لصحة البرنامج، قم بتسجيل تدفق حركة المرور والحجم ومعلومات الشكوى وسلوك المنع وأصل القائمة وتغييرات المحتوى والتوقيت.
تعامل مع مقاييس المشاركة بعناية
معدل الفتح ليس وكيلًا مستقلاً يمكن الاعتماد عليه لوضع البريد الوارد أو الاهتمام البشري. حماية خصوصية البريد من Apple يقوم بتنزيل المحتوى عن بعد في الخلفية بغض النظر عن المشاركة. إرشادات التتبع المفتوحة لـ Mailchimp يوثق أيضًا صور التتبع المحظورة وقيود تنسيق العميل. يمكن أن تتضمن النقرات أيضًا فحصًا أمنيًا آليًا، كما هو موضح في إرشادات نشاط الروبوت الخاصة بـ Mailchimp.
تحديد السكان وطريقة القياس. اجمع بين استجابات التسليم والشكاوى وسلوك إلغاء الاشتراك وأدلة المزود ونتائج الأعمال. تجنب المطالبة بالتحسين من مقياس واحد بدون خط أساس قابل للمقارنة وشرح للتغييرات المربكة.
تجنب تغييرات DNS التي تستهدف المشكلة الخاطئة
لا تقم بإضافة تضمين SPF آخر لأن الحملة التي تمت مصادقتها تصل إلى البريد العشوائي. لا تضعف المحاذاة لمطاردة التنسيب. لا تنشر مكررة سجلات SPF. لا تنتقل إلى الرفض فقط بسبب وصول رسالة اختبار إلى البريد الوارد.
يجب أن تحل تغييرات DNS مشكلة الهوية أو السياسة المثبتة. يجب أن تحل تغييرات ممارسات الإرسال مشاكل الموافقة أو التردد أو المحتوى أو التجزئة أو السمعة. في بعض الأحيان تكون هناك حاجة إلى كلا مساري العمل، لكن يجب أن يحتفظا بمالكين وأدلة منفصلين.
بناء سجل تشخيصي مشترك
يحتوي سجل الحالة المفيد على:
- المرسل الدقيق، من المجال ودفق حركة المرور؛
- رسالة تمثيلية ونتائج مصادقة موثوقة؛
- استجابة SMTP والطابع الزمني؛
- التنسيب الملحوظ مع الطريقة والقيود؛
- الشكوى والقمع والأدلة المتلقية المتاحة لتلك المجموعة؛
- التغييرات الفنية والبرنامجية الأخيرة؛
- الفرضية والمالك والتدخل وتاريخ المراجعة.
يحول هذا التنسيق السؤال "هل قام DMARC بإصلاح إمكانية التسليم؟" في أسئلة قابلة للاختبار. هل تحسنت المصادقة؟ هل تغير القبول؟ هل تغير موضع البريد المماثل؟ هل تحسنت استجابة المستلم دون تغيير الجمهور؟
للحصول على إثبات الهوية، استخدم دليل سلسلة هوية البريد الإلكتروني. للحصول على خط أساس للرصد، تابع مع دليل سياسة مراقبة DMARC.
احتفظ بالنتيجة ضمن الأدلة
بالنسبة للحالة أ، احتفظ بملاحظة المصادقة ولكن البريد العشوائي وتحقق من أدلة الشكوى المذكورة؛ بالنسبة للحالة C، احتفظ بالرفض الفعلي قبل التحقق من وضع البريد الوارد. قارن بين نفس طريقة القياس والفوج عبر التغييرات. لا تعتبر عمليات الفتح أو النقرات التلقائية دليلاً على عمل بشري. هذه الحالات خيالية، وليست قياسات حملة أو وعود بالتحسين.