تأكد من أن TransIP موثوق
هذا دليل نشر DNS ، وليس دليل إعداد خدمة بريد TransIP. يمكن تسجيل النطاق في TransIP عندما يكون موثوقًا خوادم الأسماء في أماكن أخرى. تحقق من التفويض العام للمجال وحدد المنطقة الموثوقة قبل التحرير. لا تقم بتبديل خوادم الأسماء فقط لإتاحة الوصول إلى نموذج DNS . احصل على أسماء السجلات الدقيقة للمرسل وأنواعها وقيمها، بالإضافة إلى تصدير المنطقة الحالية ونطاق التغيير المعتمد.
أدخل الأسماء والقيم بشكل صحيح
حدد المجال في لوحة التحكم وافتح إعدادات DNS . يتطلب التحرير المخصص إيقاف تشغيل إعدادات TransIP التلقائية. يمكن أن تؤدي إعادة تمكين هذه الإعدادات إلى استبدال السجلات المخصصة وخوادم الأسماء. يستخدم حقل الاسم @ لقمة المنطقة والأسماء النسبية للنطاقات الفرعية. خارجي CNAME يحتاج الهدف إلى اسمه الكامل ونقطة زائدة. تم توثيق قواعد الواجهة هذه في مصدر لوحة تحكم TransIP أدناه.
من أجل TXT DKIM بالمفتاح، يوجه مصدر DKIM المستخدمين إلى حذف علامات الاقتباس المحيطة والخطوط المائلة العكسية غير الضرورية. استخدم المفتاح العام للمرسل، وليس عينة تم إنشاؤها مطلقًا. أ محدد على مجال فرعي للإرسال يحتاج إلى هذا النطاق الفرعي في اسم المالك النسبي. استخدم CNAME فقط عندما أصدر المرسل تفويض CNAME بالفعل. لا يؤدي نشر المفتاح إلى بدء خدمة الإرسال في التوقيع.
ورقة عمل رسم الخرائط الأصلية
ما يلي هو تدريب تخطيطي خيالي لمنطقة example.org ، وليس تكوين إنتاج. review._domainkey.news.example.org كاملة لمالك DKIM خرائط للمراجعة. _domainkey.news في حقل الاسم. أ DMARC يقوم المالك _dmarc.news.example.org بتعيين _dmarc.news. ال SPF خرائط المالك news.example.org للأخبار. قم بوضع علامة على الاسم الكامل المتوقع على بطاقة التغيير حتى يتمكن المراجع من اكتشاف لاحقة example.org.example.org غير المقصودة.
احتفظ بنظام SPF و DMARC كسياسات TXT بأسماء مالكيها الصحيحة. لا تضع سطرًا كاملاً لملف المنطقة، بما في ذلك الفئة والنوع، في حقل القيمة. عديد سجلات TXT يمكن أن تتواجد معًا لأغراض غير مرتبطة، ولكن هناك سياستان لنظام التعرف على SPF في اسم واحد تم تقييمه غير صالحتين. تتطلب قيم DKIM الطويلة معالجة دقيقة: صفحات TransIP المستردة لا تنشئ إجراءً عالميًا لتقسيم السلسلة الطويلة. إذا رفضت اللوحة القيمة الكاملة للموفر، توقف واحصل على إرشادات TransIP الحالية بدلاً من اقتطاعها.
التحقق من النشر قبل اختبار البريد
استعلم عن كل خادم موثوق لمعرفة أسماء SPF و DMARC وأسماء المحددات الكاملة. قارن القيم الكاملة، بما في ذلك سلاسل TXT المتسلسلة حيث تم إرجاعها. بالنسبة للمفتاح المفوض، تحقق من هدف CNAME وإجابة TXT النهائية. كرر ذلك من خلال محلل عودي واحتفظ بملاحظات TTL. يمكن أن يشير عرض لوحة التحكم الصحيح مع غياب الإجابة العامة إلى مرجع خاطئ أو بيانات غير محفوظة، وليس مجرد نشر بطيء.
عندها فقط قم بتشغيل رسالة يتم التحكم فيها من خلال خدمة الإرسال. يجب أن يؤدي التراجع من جانب DNS إلى استعادة السجلات التي تم تغييرها، وليس إعادة تمكين الإعدادات التلقائية أو استعادة المنطقة القديمة بالكامل دون مقارنة التغييرات غير ذات الصلة.
إثبات الهوية لدى المتلقي
استخدم صندوق بريد خارجيًا يمكن التحكم فيه وأرسله عبر سير عمل الإنتاج، مع محتوى غير ضار وبدون بيانات العملاء. احفظ الرسالة الأولية والطابع الزمني ونظام الاستقبال Authentication-Results. تجاهل تأكيدات المصادقة التي أدخلها مرسل غير موثوق به. تسجيل المجال المرئي من، Return-Path أو هوية المغلف الموثقة، وكل زوج DKIM d= وs=. اسم العرض أو عنوان الرد ليس هو هوية DMARC .
يسمح تمرير نظام التعرف على هوية SPF للخادم المتصل بهوية المغلف التي تم تقييمها. يتحقق ممر DKIM من صحة التوقيع لمجال التوقيع الخاص به. يحتاج DMARC إلى طريقة تمرير يتوافق نطاقها مع المجال المرئي من: الصارم تنسيق يتطلب نفس المجال؛ تسمح المحاذاة المريحة بإقامة علاقة المجال التنظيمي المعمول بها. يمكن أن يمر التوقيع المملوك للموفر دون المصادقة على "من" المرئي الخاص بك. تمريرة واحدة محاذاة توقيع DKIM يمكنه تلبية DMARC حتى في حالة فشل توقيع آخر. تأتي قواعد البروتوكول هذه من RFC 7208 و RFC 6376 و RFC 9989، المدرجة أدناه.
تحقق من DNS المعتمد قبل تشخيص ذاكرة التخزين المؤقت. اسأل خادمًا موثوقًا عن الاسم والنوع الدقيقين، ثم قارن بين المحلل التكراري بعد مدة تخزينه المؤقت. بالنسبة إلى DKIM ، اتبع أي CNAME لاستجابة TXT للمفتاح العام الخاص به. لا تنشر أبدًا مفتاحًا خاصًا. احتفظ بسياسة نظام التعرف على SPF واحدة عند كل اسم تم تقييمه وتحقق من الحد العشرة لمصطلح البحث عن DNS عبر التضمينات المتداخلة. لا تستبدل سياسة SPF المشتركة بمثال الموفر.
الاسترداد والقبول
قم بإيقاف سير العمل المتأثر مؤقتًا إذا أظهرت الاختبارات تراجعًا جديدًا. قارن السجل الذي تم تغييره بالنسخة المحفوظة وقم بالتراجع عن هذا التغيير فقط بعد التحقق من المرسلين الآخرين. إعادة فحص DNS وإعادة الإرسال بعد الاسترداد؛ لا يؤدي إرجاع القيمة إلى مسح كل محلل على الفور. احتفظ بسجلات التحقق من DKIM القديمة متاحة بينما قد تظل الرسائل الموقعة مسبقًا قيد النقل، ما لم يتطلب حادث أمني الإلغاء.
اقبل التغيير فقط عندما يتفق DNS وحالة التطبيق والرسالة المستلمة الحقيقية. قم بتسجيل مالك التدفق والطابع الزمني للأدلة ومشغل المراجعة التالية. لا يعد وضع البريد الوارد وحده دليلاً على المصادقة، ولا تضمن المصادقة الناجحة وضع البريد الوارد. لا تقم بتشديد سياسة DMARC الخاصة بالنطاق المشترك بناءً على قوة اختبار مقدم خدمة واحد. جرد المصادر المشروعة الأخرى أولا.
تشخيص إدخال ذو مظهر صحيح في المنطقة الخاطئة
تفترض الحالة المكتوبة TI-01 أن المجال مسجل في TransIP، لكن التفويض العام الخاص به يشير إلى مشغل DNS آخر. إدخال لوحة TransIP محفوظ للمراجعة. _domainkey.news لا ينشئ النشر في review._domainkey.news.example.org . يجب على مالك النطاق تأكيد المشغل المعتمد وترتيب السجل المعتمد هناك؛ إن تغيير خوادم الأسماء أو تمكين الإعدادات التلقائية ليس هو الاختصار التصحيحي. تظل الإجابات العامة المنبعثة d=/s= ونتائج المتلقي غير معروفة حتى يتم جمعها بشكل منفصل. هذا السيناريو منصوص عليه، وليس بحث DNS فعليًا أو إجراء اللوحة.
الحفاظ على حدود التنفيذ
يتطلب القسم 7.4 RFC 9989 DKIM صالحًا، وليس نظام التعرف على SPF وحده، للنطاقات التي تنشر p=reject, ويحذر من إمكانية التشغيل التفاعلي للبريد غير المباشر والقائمة البريدية. إن نجاح اختبار واحد للرسائل المباشرة لا يشكل دليلاً على أن كل طريق مشروع جاهز لسياسة أقوى. احتفظ بالحماية المعتمدة الحالية أثناء تشخيص الفجوة الفعلية؛ أي تغيير في السياسة يحتاج إلى قرار خاص به.