ابدأ بـ مرسل المغلف وكذلك العنوان المرئي من. يضع مرجع TurboSMTP ملف SPF إذن على مجال عنوان المغلف. يثبت تسجيل الدخول الناجح SMTP الإذن بإرسال البريد إلى المرحل؛ لا يثبت أن المستلم سيقوم بمصادقة المجال الذي اخترته.
نشر سجلات مصادقة التتابع المعمول بها
يتضمن المثال الرسمي include:spf.turbo-smtp.com. قم بدمج هذه الآلية في سياسة نظام SPF الوحيدة الموجودة حيثما ينطبق ذلك، قبل آليتها النهائية. لا تقم بنسخ المثال a أو mx أو ?all إلى سياسة محددة دون تحديد ما إذا كانت هذه التفويضات ودلالات الفشل مقصودة أم لا.
يوفر المرجع مفتاح TXT العام لـ Turbo-smtp. _domainkey . انسخ المفتاح الكامل الحالي من المرجع الرسمي أو التكوين المؤكد من قبل موفر الخدمة، وليس مفتاحًا تم اختراعه من محدد اسم. تأكد من أن التوقيع الصادر الفعلي يستخدم هذا المحدد ومجال التوقيع المتوقع. تحتوي الصفحة على جملة غير متناسقة في محتواها DMARC القسم: ينتمي DMARC إلى _dmarc .<domain>، كما يظهر الجدول الخاص به، وليس إلى محدد DKIM . اتبع معيار DMARC لاسم المالك هذا. مرجع تكوين TurboSMTP
لا تستبدل سياسة التنفيذ الحالية بسياسة الصفحة p=none مثال فقط لإكمال الإعداد. لغة التسليم الخاصة بالمورد ليست ضمانًا للبريد الوارد. إذا كشف حسابك عن قيم مصادقة مختلفة، فقم بحل الاختلاف مع الدعم واحتفظ بالتعليمات الخاصة بالحساب قبل تغيير DNS .
تحقق من DNS ونتيجة الاستلام الحقيقية
قبل تغيير تكوين مرسل ترحيل SMTP ، قم بتصدير قيم DNS الموجودة، وقم بتسجيل الفرق المعتمد وقم بتسمية مالك التراجع. تأكد مما إذا كان محرر DNS يتوقع تسمية نسبية أو اسمًا مؤهلاً بالكامل؛ مضاعفة لاحقة المجال يخلق سجل التي لن يجدها أي مدقق مقصود. الاستعلام عن اسم المالك الفعلي بعد الحفظ، بما في ذلك أي CNAME الهدف، بدلاً من الاعتماد على شعار نجاح المحرر.
يجب أن يظل SPF بمثابة سياسة واحدة في المجال ذي الصلة وأن يظل ضمن حدود مصطلح الاستعلام عن نظام أسماء النطاقات (DNS). RFC 7208. لا يتم إنشاء إضافة التضمين في حد ذاته تنسيق. تحت RFC 9989، يتم تمرير DMARC عند نجاح SPF واحد على الأقل أو DKIM تتم محاذاة النتيجة مع المجال المرئي من ضمن الوضع القابل للتطبيق. لا تطلب محاذاة كلا الآليتين كشرط يفرضه المعيار، ولا تخطئ في اعتبار تصريح مرور نطاق الموفر بمثابة مرور نطاق العميل المتوافق.
أرسل رسالة مرسلة من خلال نفس بيانات اعتماد SMTP والتطبيق المستخدم في الإنتاج إلى صندوق بريد تتحكم فيه. احفظ نتائج المصادقة الموثوقة لنظام الاستقبال، المرئية من، وهوية المغلف، وقيم DKIM d= وs=، والطابع الزمني، وحالة الموفر. يُظهر بحث DNS فقط المفتاح المتاح؛ RFC 6376 يقوم التحقق أيضًا بتقييم التوقيع على الرسالة المستلمة. استخدم محتوى غير حساس وتجنب تعريض رسائل العملاء الكاملة للمدققين العامين.
استخدم قرار القبول والتراجع المحدود
حالة القبول التوضيحية هي رسالة من alerts@example.com تحتوي على توقيع صالح باستخدام d=example.com. تدعم مطابقة النطاق الدقيقة محاذاة DKIM في أي من الوضعين. التوقيع الصالح الذي يستخدم d=vendor.example.net فقط لا يتوافق مع example.com ؛ وبدون محاذاة نظام التعرف على هوية المرسل SPF ، تفشل هذه العينة في اختبار قبول DMARC . هذه أمثلة منطقية، وليست نتائج TurboSMTP التي تمت ملاحظتها.
إذا فشل الاختبار، فافصل DNS المفقود، والمحدد الخاطئ، وتكوين الموفر غير النشط، والتوجيه غير المتوقع، وتعديل الرسالة قبل إجراء تغيير آخر. أعد اختبار سير العمل نفسه بعد كل تصحيح تمت الموافقة عليه. لا تقم بإضعاف سياسة DMARC للنطاق بأكمله لإخفاء مشكلة مرسل واحد. عندما تكون هناك حاجة إلى التراجع، قم باستعادة التوجيه السابق المعتمد أو تكوين المرسل والاحتفاظ بالسجلات الرئيسية بينما لا تزال الرسائل الموقعة في قائمة الانتظار بحاجة إليها. احتفظ بأدلة الاختبار والاستثناءات التي لم يتم حلها مع مخزون النطاق. لم يتم إجراء أي وصول للمستأجر أو تغيير DNS أو إرسال حقيقي أثناء إعداد هذا الدليل.
افصل السياسة في غير محلها عن التوقيع العامل
تفترض الحالة المكتوبة TS-01 وجود رسالة تم استلامها قبل أن يكون تحرير DNS الخاطئ من alerts@example.org وممر DKIM موثوق به مع d=example.org, s=turbo-smtp. يوفر هذا محاذاة DKIM الدقيقة. وبشكل منفصل، قام أحد المسؤولين عن طريق الخطأ بوضع قيمة DMARC TXT على turbo-smtp._domainkey.example.org ؛ السياسة الفعلية في _dmarc.example.org غير معروفة. هذه القيمة التي تم وضعها في غير محلها ليست سياسة DMARC قابلة للاستخدام لدى مالك الاكتشاف المطلوب، كما أن خلطها مع البيانات الرئيسية يستدعي التحقيق. يجب على مالك DNS الحفاظ على المفتاح العام الصحيح والتوفيق بين السياسة المقصودة على _dmarc.example.org دون استبدال التنفيذ الحالي. لا تؤكد نتيجة التوقيع الافتراضي صحة تغيير DNS الخاطئ. لم يتم فحص أو تغيير أي رسالة أو مفتاح أو منطقة.
الحفاظ على حدود التنفيذ
RFC 9989 يتطلب القسم 7.4 DKIM صالحًا، وليس نظام التعرف على SPF وحده، لنشر النطاقات p=reject، ويحذر من إمكانية التشغيل التفاعلي للبريد غير المباشر والقائمة البريدية. إن نجاح اختبار واحد للرسائل المباشرة لا يشكل دليلاً على أن كل طريق مشروع جاهز لسياسة أقوى. احتفظ بالحماية المعتمدة الحالية أثناء تشخيص الفجوة الفعلية؛ أي تغيير في السياسة يحتاج إلى قرار خاص به.