قم بتعيين مسارات البريد السريع قبل تحرير DNS
يمكن أن يكون مجال الرسالة الإخبارية جاهزًا بينما تستمر رسالة المعاملات في استخدام إعداد مصادقة مختلف. ابدأ بسرد وظائف البريد السريع التي تستخدمها المؤسسة فعليًا: المراسلات البريدية، والرسائل المرتبطة بنماذج الاشتراك، وبريد المعاملات. لكل منها سجل حسابها والمقصود من العنوان وصندوق البريد والرد وصاحب العمل. ويجب أن يغطي اختبار القبول هذه المسارات بشكل فردي.
البريد السريع دليل DKIM للمعاملات يقول صراحة النشرة DKIM لا ينطبق تلقائيًا على رسائل المعاملات. هذه هي حدود التكوين الرئيسية في هذا الدليل. لا تستخدم حملة ناجحة كدليل على مصادقة استلام الطلب أو التأكيد أو سير عمل المعاملات الأخرى.
اختر مجال المرسل الذي تتحكم فيه المؤسسة. قم بتأكيد الوصول إلى DNS المعتمد الخاص به وحدد كل من يعتمد على سجلات البريد الموجودة لديه. امنح مسؤول DNS طلب تغيير خاص بالمسار، وليس تعليمات لاستبدال تكوين البريد الإلكتروني للمنطقة بأكملها. يجب أن يوافق مالك التسويق على المرسل الذي يمكن التعرف عليه وعنوان الرد المراقب قبل الاختبار.
اختر سير عمل المصادقة المدعوم
البريد السريع تعليمات المصادقة اليدوية وصف بدءًا من إعدادات الحساب وAbsender-Einstellungen وAbsender-Authentifizierung. تستخدم العملية الموجهة Entri؛ يعرض الخيار اليدوي قيم السجل المطلوبة. حدد المجال المقصود واستخدم الإرشادات المعروضة لهذا المجال، مع قيام مسؤول DNS بمراجعة أي تغييرات مقترحة.
يصف الدليل اليدوي أربعة صفوف: DMARC, SPF ممثلة ب أ CNAMEو DKIM للمراسلات البريدية و DKIM للوظائف بما في ذلك نماذج التسجيل. احتفظ بهذا التمييز في ورقة عمل التغيير. لا تختصر المهمة في سجل DKIM عام واحد أو تستبدل تعليمات CNAME بـ سجل TXT لأن المقالة القديمة استخدمت تصميمًا آخر.
إذا كان الحساب الحالي يقدم تسميات أو أنواع سجلات مختلفة، فاحفظ التناقض واحصل على إرشادات الموفر الحالي قبل المتابعة. تحدد الوثائق العامة النمط المدعوم، وليس القيم النهائية للحساب. لا توفر هذه المقالة أي محددات أو أهداف أو مفاتيح عامة قابلة لإعادة الاستخدام. لا تمنح مساعد الإعداد وصولاً واسع النطاق DNS لمجرد تجنب فهم السجلات التي يقترح تغييرها.
النشر بدقة والحفاظ على السياسة الحالية
يسجل لكل سجل صادر صاحبه ونوعه وقيمته والغرض منه والطابع الزمني للتعليمات. تحقق مما إذا كان محرر DNS يقوم بإلحاق اسم المنطقة تلقائيًا. قارن الاسم العام الكامل بعد الحفظ، خاصة بالنسبة للنطاقات الفرعية. يمكن أن ينتج عن الحقل المعقول بصريًا لاحقة متكررة أو وضع السجل في المنطقة الخطأ.
قم بمراجعة السجلات المتعارضة قبل استبدال أي شيء. قد يكون مالك CNAME يخدم بالفعل موفرًا آخر. لا تخترع تسمية بديلة أو تزيل سجل الخدمة الأخرى بدون خطة مدعومة. تعامل مع الاسم المستعار الموجه من قبل الموفر باعتباره تبعية مستمرة لنظام DNS يديره الموفر، ويجب أن يظل غرضه ومالكه على قيد الحياة بعد عمليات تنظيف DNS المستقبلية.
البريد السريع نظرة عامة على المصادقة يصف SPF و DKIM و DMARC معًا. قم بتفسير هذا التوجيه التشغيلي باستخدام هويات البروتوكول: يقوم نظام التعرف على هوية المرسل SPF بتقييم هوية SMTP ، ويقوم DKIM بمصادقة مجال التوقيع الخاص به. عندما يجب تغيير سياسة TXT SPF ، احتفظ بسياسة واحدة لدى هذا المالك وقم بحساب التكلفة الكاملة للبحث عن DNS ضمن RFC 7208. لا تقم بإضافة الجذر الثاني سجل SPF لتقليد التعليمات المستندة إلى CNAME.
قم بفحص DMARC قبل نشر سجل آخر عند صاحبه. مثال على سياسة المراقبة ليس الإذن بتخفيض سياسة معتمدة حالية أو استبدال وجهات التقارير الخاصة بها. خطط لأي تغيير في السياسة عبر جميع المرسلين الشرعيين، وليس البريد السريع فقط. لا تنص توصية الدليل اليدوي للإعداد الأولي على ضرورة إضعاف التنفيذ الحالي للمنظمة.
قم بتكوين DKIM للمعاملات كتغيير خاص بها
بالنسبة لبريد المعاملات، المسار الموثق هو Transaktionsmails، ثم Absenderdomains verwalten. يقوم المسؤول بتحرير النطاق ذي الصلة، وإنشاء مفتاح DKIM الخاص به، ونشر سجل TXT الصادر، واستخدام إجراء التحقق والتنشيط. اتبع تعليمات المعاملات لهذا المسار بدلاً من نسخ إعدادات الرسائل الإخبارية.
احتفظ بقيمة DNS العامة منفصلة عن بيانات اعتماد التطبيق. تنتمي بيانات التحقق العامة فقط إلى ورقة عمل DNS . لا تضع كلمات مرور SMTP أو مواد التوقيع الخاصة أو أسرار واجهة برمجة التطبيقات (API) في مرفق دعم أو حزمة مراجعة. سجل من يمكنه استعادة تكوين التطبيق السابق في حالة فشل الاختبار.
يجب جدولة إجراء إنشاء المفتاح مع مالك المسار. حدد ما إذا كان المفتاح الموجود نشطًا وما يتوقعه الموفر أثناء الاستبدال قبل إنشاء مفتاح آخر. تجنب التجديد المتكرر كأسلوب لاستكشاف أخطاء DNS وإصلاحها. يمكنه تغيير القيمة العامة المتوقعة بينما لا يزال المسؤول يتحقق من صحة التغيير السابق.
قم بتأكيد كل مسار برسالة يتم التحكم فيها
بعد النشر، تحقق من DNS العام وحالة البريد السريع المقابلة. إتاحة الوقت لـ TTLs ذات الصلة وفحوصات المزود؛ يمكن أن تؤدي التعديلات المتكررة إلى حجب القيمة التي يراها المتلقي. تعد الحالة الخضراء بمثابة دليل إعداد مفيد، ولكنها لا تثبت أن المرسل أو سير العمل المختار استخدم هذا التكوين.
أرسل رسالة إخبارية غير ضارة، ومارس تدفقًا خاضعًا للرقابة لنموذج الاشتراك عند استخدامه، وقم بإجراء اختبار معاملات معتمد. استخدم عناوين الاختبار المملوكة وتجنب تسجيل مشتركين حقيقيين أو إنشاء طلبات عملاء حقيقية لمجرد جمع العناوين. حفظ معرف الرسالة، وقت UTC، من، Return-Pathوكل DKIM d= و s=, ونتائج نظام الاستلام الموثوق به.
مواصفات DKIM يحدد مجال التوقيع و محدد الحقول. قارن التوقيع الذي تمت ملاحظته بالسجل الصادر لهذا المسار. تحت RFC 9989، يجب أيضًا أن تتماشى نتيجة SPF أو DKIM الناجحة مع المجال المرئي من لـ DMARC . تحقق من تكوينها استرخاء أو صارمة تنسيق الوضع بدلاً من افتراض أن أي مجال ذي صلة كافٍ.
تقييم التنسيب بشكل منفصل. لا يزال من الممكن تصفية الرسالة التي تمت مصادقتها بسبب سياسة المستلم أو سمعته أو محتواه. إذا لم يصل الاختبار مطلقًا، فاحصل على دليل الإرسال أو الارتداد أو المنع قبل تشخيص DNS . تتطلب الرسالة المفقودة وفشل المصادقة الصريحة خطوات تالية مختلفة.
ورقة عمل قبول مسار البريد السريع
أكمل صفًا واحدًا لكل بريد ونموذج ومسار للمعاملة:
- الحساب والطريق والمالك والمقصود من العنوان: ____.
- عنوان المستلم المتحكم فيه والرد المراقب: ____.
- التعليمات الحالية ومجموعة السجلات الصادرة: ____.
- غرض التسجيل والمالك الكامل والنوع والقيمة المرجعية: ____.
- صراعات المالك الحالية والحل المعتمد: ____.
- تم الاحتفاظ بسياسة DMARC أو الموافقة على تغيير منفصل: ____.
- فحص DNS العام وحالة التطبيق ووقت التنشيط: ____.
- معرف الرسالة، وتوقيت UTC، Return-Path و DKIM d= و s=: ____.
- نتائج SPF و DKIM و DMARC الموثوقة والآلية المتوافقة: ____.
- إجراء الاسترداد والمراجع ومشغل إعادة الفحص التالي: ____.
احتفظ بالمسار معلقًا عندما يكون دليل الرأس الخاص به مفقودًا، حتى إذا كان المسار الآخر يستخدم نفس اسم العلامة التجارية. يجب أن تجعل ورقة العمل المسار غير المختبر واضحًا للشخص الذي يوافق على الإطلاق.
التشخيص الخيالي لعدم تطابق المعاملات
مثال خيالي فقط: تقوم شركة Linden Goods بتوثيق نطاق النشرة الإخبارية الخاصة بها وترى اختبارات الحملة الناجحة. لا يزال تأكيد التطبيق الخاص به يفشل DMARC . يكتشف المسؤول أن إعداد البريد فقط هو الذي اكتمل. لم يتم تكوين نطاق المعاملات وتنشيطه باستخدام سجل DKIM المنفصل الخاص به.
يكمل الفريق تدفق المعاملات المدعومة، ويتحقق من DNS ويرسل تأكيدًا جديدًا خاضعًا للرقابة. فهو يقارن مجال التوقيع الفعلي ومن المحاذاة قبل قبول المسار. لا يخفض الفريق سياسة DMARC للنطاق بالكامل لإخفاء الإعداد المفقود. لم تتم ملاحظة أي حساب Linden أو منطقة DNS أو رسالة.
أبقِ جميع مسارات الإرسال قيد المراجعة
أعد التحقق بعد تغيير مجال المرسل، أو استبدال المفتاح، أو النموذج الجديد، أو ترحيل التطبيق، أو نقل مضيف DNS. احتفظ بمخزون السجلات والرؤوس الخاصة بالمسار معًا. تدعم الوثائق العامة الحالية هذا الإجراء، بينما يظل التفتيش المباشر للمستأجر والقيم الصادرة عن الحساب واختبارات DNS والرأس والمراجعة المرئية والموافقة البشرية على الشركات الصغيرة والمتوسطة والنشر معلقة.
قم بإنهاء إعداد DKIM القابل للتطبيق قبل خطوة السياسة اليدوية
يتطلب دليل DMARC اليدوي الحالي إعداد DKIM ناجحًا قبل تلك العملية. احتفظ بإدخالات البريد ونموذج الاشتراك منفصلة عن مفتاح المعاملة المنفصل. ولا ينبغي لمؤشر وجود السياسة أن يغلق اختبار المعاملات المفقود. في الحالة الخيالية، تظل نتائج SPF و DKIM الفردية غير محددة؛ لا يقوم المثال بتأسيس فشل محدد معين أو إصلاح ناجح.
قبول رسالة منفصلة عن طرح السياسة
يمكن لنتيجة SPF المتوافقة أن تلبي تقييم الرسالة، ولكنها لا تبرر وحدها نقل النطاق بأكمله للرفض. RFC 9989 يتطلب القسم 7.4 DKIM صالحًا لنشر النطاقات p=reject ويحذر من إمكانية التشغيل التفاعلي للبريد غير المباشر. قم بجرد جميع المرسلين الشرعيين والطرق غير المباشرة قبل أن يوافق مالك السياسة على التنفيذ. لم يتم تنفيذ أي تغيير DNS أو عملية مستأجر أو اختبار الرسالة المستلمة لهذه المقالة.