حدد ما إذا كان Openprovider يخدم المنطقة النشطة
يتعلق هذا الدليل بنشر سجلات المصادقة في Openprovider DNS . إنه ليس دليل تكوين لصندوق بريد Openprovider المنفصل أو إعادة توجيه المنتجات. يمكن تسجيل المجال الخاص بك في Openprovider بينما يقوم Microsoft 365 أو خدمة الحملة أو موفر آخر بإرسال البريد الخاص به. يقدم المرسل تعليمات المصادقة الخاصة به؛ يقوم مشغل DNS المعتمد بنشر السجلات المعتمدة. أبقِ هذه الأدوار منفصلة عند إسناد العمل.
Openprovider يدعم نفسه خوادم الأسماء وخوادم الأسماء الخارجية. يوضح دليل خادم الأسماء الخاص به أنه يجب تكوين المناطق المستضافة خارجيًا لدى موفر DNS الخارجي، بينما تتم إدارة المناطق المستضافة بواسطة Openprovider من خلال إدارة DNS ونظرة عامة على مناطق DNS . ابدأ بالتفويض العام الفعلي والمنطقة المحددة قيد التغيير. المجال المسجل والمنطقة المرئية في الحساب لا يكفيان لإنشاء السلطة. فتح إرشادات خادم الأسماء
لا تقم بتغيير خوادم الأسماء لمجرد إنشاء SPF المحرر متاح. هذه عملية ترحيل منفصلة يمكن أن تؤثر على موقع الويب والبريد الوارد ورموز التحقق المميزة و DNSSEC. إذا كان الموفر الخارجي موثوقًا، فقم بتسليم تغييرات السجل المعتمدة إلى مسؤول ذلك الموفر. إذا كان Openprovider موثوقًا، فتأكد من أنك تقوم بتحرير المنطقة المباشرة بدلاً من القالب المخصص للاستخدام المستقبلي.
تجميع تغييرات السجل من خدمة الإرسال
اطلب ترخيص نظام التعرف على هوية المرسل SPF الحالي الصادر عن المرسل، DKIM المالكين والقيم، وأي تعليمات خاصة بالمغلفات المخصصة، والمجال الدقيق الذي ينطبق عليه كل منها. تجنب السجل العالمي المسمى بإعداد Openprovider SPF : لا يصبح مضيف DNS مرسل بريد معتمدًا بمجرد استضافة المنطقة. ينطبق نفس التمييز على DKIM . تنص مقالة DKIM الخاصة بـ Openprovider على أن خادم البريد المرسل يحدد محتوى السجل ويقوم الموفر أو مهندس النظام بتزويده. منشور Openprovider DKIM
قم بتصدير مجموعات السجلات المتأثرة الكاملة أو الاحتفاظ بها بطريقة أخرى، بما في ذلك أسماء المالكين وأنواعهم وTTLs والقيم. احتفظ برموز TXT غير المرتبطة سليمة. قم بتسجيل كل إجراء مقترح كإضافة أو استبدال أو سحب مع مالك الخدمة والسبب. أ محدد الذي يبدو قديمًا قد يستمر في التحقق من صحة البريد في قائمة الانتظار أو دعم تطبيق آخر. لا تسمح تعليمات الخدمة الجديدة بحذف مفتاح الخدمة القديمة.
افصل المالك المقصود المؤهل بالكامل عن مدخلات المحرر. بالنسبة إلى DKIM ، تعد تسميات المحدد و_ _domainkey ضرورية؛ فهي غير قابلة للتبديل مع قمة المجال. ل DMARC، حدد مالك _dmarc المناسب. بالنسبة لنظام التعرف على SPF ، حدد مجال مغلف SMTP الفعلي. لا يقوم دليل سجلات DNS المسترجعة بتأسيس اتفاقية عالمية حالية لإدخال القمة. تأكيد معالجة الواجهة الحالية للمالك الجذر واللاحقات الملحقة قبل الحفظ؛ لا تفترض وجود حقل فارغ أو قبول @ في كل وضع إدخال. اتفاقيات سجل DNS Openprovider
نشر نظام التعرف على SPF كسياسة واحدة بتنسيق TXT الذي تم التحقق منه
يستخدم دليل SPF الخاص بـ Openprovider سجلات TXT ويوجه مستخدميه على وجه التحديد إلى تغليف المحتوى بعلامات اقتباس مستقيمة. اتبع اصطلاح الإدخال الموثق للمحرر الحالي، ثم افحص إجابة TXT المنشورة للتحقق من تفسير التنسيق بشكل صحيح. علامات الاقتباس المتعرجة المنسوخة من معالج النصوص ليست متكافئة. لا تقم بإضافة طبقات الاقتباس بشكل متكرر عندما يعرض المحلل بالفعل سلاسل مع علامات الاقتباس. منشور Openprovider SPF
دلالات البروتوكول هي معيار القبول. يجب أن تكون هناك سياسة نظام SPF مرشحة واحدة لدى المالك الذي تم تقييمه. قد يحتوي سجل TXT على سلاسل أحرف متعددة تم ضمها لمعالجة نظام التعرف SPF ، لذا فإن تقسيم العرض لا يمثل بالضرورة سياسات متعددة. وعلى العكس من ذلك، لا يعد السجلان المنفصلان اللذان يبدأان بعلامة إصدار نظام التعرف على هوية SPF طريقة صالحة لاستيعاب مرسلين اثنين. الحفاظ على المساحات المطلوبة وتسلسل الآلية الكامل في القيمة المعاد بناؤها. SPF RFC 7208
تحتوي مقالة SPF العامة الخاصة بالموفر على لغة مبسطة حول طول TXT ، بينما يصف دليل سجلات DNS الخاص به بوضوح تقسيم قيمة TXT كبيرة إلى سلاسل أصغر داخل سجل واحد. يجب ألا يتم التعامل مع حد سلسلة الأحرف على أنه حد إجمالي للسجل. قم بتأكيد معالجة المحرر الحالي وتحقق من الإجابة المعاد بناؤها. دليل تسجيل TXT الخاص بـ Openprovider إذا تم رفض قيمة طويلة، فاحصل على إرشادات الموفر؛ لا تقم بتقصير مفتاح عام أو تقسيم سياسة نظام SPF إلى سجلات مستقلة.
قم بتقييم حدود البحث المتكرر لنظام التعرف على هوية المرسل SPF قبل حفظ السياسة المدمجة. لا يزال من الممكن أن تتجاوز السياسة القصيرة بصريًا الحد الأقصى من خلال السياسات المضمنة. لا تستبدل الآليات التي يحتفظ بها الموفر بلقطة من عناوين IP الحالية ما لم تتم الموافقة على نموذج الصيانة هذا ودعمه بشكل متعمد. تغييرات التسوية الثابتة التي يجب أن تتبع تغييرات البنية التحتية المستقبلية.
حافظ على أنواع سجلات DKIM وملكية المحدد سليمة
توفر بعض خدمات الإرسال مفتاحًا عامًا TXT ؛ آخرون يزودون أ CNAME الاسم المستعار. انشر النوع المتوفر لدى مالك المحدد المتوفر. لا تضع هدف CNAME في حقل TXT أو تنشر المفتاح في القمة. يستمد المتلقي عملية البحث من نطاق توقيع الرسالة ومحددها، ولهذا السبب لا يساعد السجل ذو المظهر المعقول لدى مالك مختلف. DKIM RFC 6376
يقوم Openprovider بتوثيق الأخطاء عندما يقوم CNAME بمشاركة مالكه مع بيانات السجل العادية الأخرى. إذا أبلغ المحرر عن تكرار أو تعارض CNAME ، فافحص مجموعة السجلات الكاملة لهذا المالك بالضبط. لا تقم بحذف سجل TXT المتعارض قبل تحديد المرسل الذي يملكه. اطلب من المرسل الجديد محددًا مدعومًا غير متعارض أو خطط لتدوير متحكم فيه. الصراع هو مسألة ملكية الثقة، وليس مجرد مشكلة التحقق من صحة المدخلات. توجيهات تعارض OpenProvider CNAME
لا يتسبب المفتاح العام أو سجل التفويض في بدء خدمة الإرسال في التوقيع. أكمل أي تنشيط من جانب المرسل بشكل منفصل وتحقق من التوقيع على رسالة حقيقية. لا تقم مطلقًا بنشر المفاتيح الخاصة أو بيانات اعتماد API أو كلمات مرور SMTP في المنطقة أو ورقة العمل.
تمييز دليل DMARC عن الوفد المستضاف
يصف تكامل EasyDMARC الخاص بـ Openprovider مسارين للإدارة: سياسة مستضافة يتم الوصول إليها من خلال اسم مستعار CNAME وسياسة TXT يتم صيانتها يدويًا. وهو يحذر من أن هدف التفويض الموضح في المثال ليس هو القيمة المطلوب استخدامها؛ توفر لوحة التحكم الهدف الفعلي. كما يصف أيضًا إنشاء CNAME تلقائيًا في عملية شراء أو تنشيط مؤهلة باستخدام خوادم أسماء Openprovider. لذلك قم بفحص مالك _dmarc الموجود قبل إضافة أي شيء يدويًا. إدارة EasyDMARC مفتوحة المزود
اختر نموذجًا إداريًا واحدًا معتمدًا. مع التفويض المستضاف، قد تتغير سياسة التشغيل في الخدمة المستضافة دون إجراء تعديل مناظر في منطقة Openprovider. قم بتعيين مالك لهذه الخدمة واحتفظ بإعدادات السياسة المعتمدة الخاصة بها. باستخدام TXT اليدوي، يجب أن تنعكس التغييرات في القيمة المنشورة. تجنب ترك سياسة TXT و CNAME لنفس المالك، ولا تستبدل وجهات التقارير الحالية لمجرد اتباع معالج التكامل.
يقوم DMARC بتقييم النطاق المرئي من مقابل تمرير هويات SPF أو DKIM المحاذاة. النشر هو جزء من هذه العملية. فإنه لا يثبت محاذاة المرسلين في المجال. حافظ على اختلاف سلوك المستلم عن السياسة المطلوبة واحتفظ بمخزون المرسلين على مستوى النطاق قبل تشديد التنفيذ. DMARC RFC 9989
ورقة عمل النشر Openprovider القابلة لإعادة الاستخدام
أنشئ صفًا واحدًا لكل مالك تم تغييره واحتفظ بسجل التغيير المشترك للمجال.
- المجال وخوادم الأسماء الرسمية ومعرف المنطقة المباشرة: ______.
- مسؤول DNS ومسؤول المرسل والموافق على التغيير: ______.
- إرسال الخدمة وأدلة تكوينها الحالية: ______.
- المقصود من المالك المؤهل بالكامل ومدخل مضيف المحرر المنفصل: ______.
- نوع السجل والقيمة المعتمدة الكاملة وTTL: ______.
- مجموعة السجلات السابقة والتبعيات التي يجب أن تظل موجودة: ______.
- تم تقييم مالك المغلف بنظام التعرف على هوية المرسل SPF والتحقق من السياسة المتكررة: ______.
- ملكية محدد DKIM ومراجعة التعارض وتنشيط المرسل: ______.
- دليل DMARC TXT أو خيار CNAME المستضاف ومالك السياسة: ______.
- الإجابة الرسمية بعد التغيير والمقارنة العودية: ______.
- مرجع الرسالة المستلمة، من، المظروف، التوقيعات والنتائج الموثوقة: ______.
- خطوات التراجع وإعادة اختبار المالك والفحص البصري والقبول البشري: معلقة.
تشخيص خيالي لاصطدام محدد
هذا المثال خيالي. يضيف البائع خدمة تسويق جديدة إلى المجال الذي يستضيف Openprovider DNS الخاص به. تطلب الخدمة الجديدة CNAME لدى محدد يحمل بالفعل مفتاح TXT لمرسل الفاتورة. يرفض Openprovider التغيير باعتباره تعارضًا. يقترح البائع إزالة TXT لأن دليل الإعداد الجديد ينص على أن المحدد مطلوب.
يحدد التحقيق الآمن مرسل الفاتورة ويؤكد أنه لا يزال يوقع الرسائل الصادرة باستخدام هذا المحدد. الاسترداد المقترح هو طلب محدد مدعوم مختلف من خدمة التسويق أو تنسيق عملية نقل رئيسية تم التحقق منها مع كلا المالكين. ليس من الضروري حذف مفتاح الفاتورة بشكل أعمى. بعد الموافقة على التغيير، سيتم اختبار الفاتورة والرسائل التسويقية المنفصلة. لا يتم تمثيل أي منطقة فعلية أو مرسل أو اختبار ناجح في هذا السيناريو.
أغلق باستخدام DNS وأدلة الرسالة
استعلم عن المالكين الدقيقين على خوادم الأسماء الرسمية بعد حفظ الردود والحفاظ عليها. قارن الإجابة العودية بشكل منفصل، مع التعرف على التخزين المؤقت. ثم اطلب من كل مرسل متأثر إنتاج رسالة يتم التحكم فيها لصندوق بريد مستقل وتسجيل نتائج المستلم الموثوق به. لا يمكن لمدقق DNS فقط التأكد من المحدد الذي يستخدمه المرسل بالفعل أو ما إذا كانت هوية المرور الخاصة به تتم محاذاتها.
إذا كان الاسترداد ضروريًا، فقم باستعادة مجموعة السجلات السابقة المتأثرة فقط وكرر اختبارات سير العمل ذات الصلة. احتفظ بدليل إعدادات السياسة المستضافة بالإضافة إلى قيم DNS ، لأن الأولى يمكن أن تتغير بشكل مستقل. يظل الوصول إلى الحساب الحالي ولقطات شاشة الواجهة والتقاطات الرسمية قبل وبعد وأدلة الرسائل المستلمة وموافقة الشركات الصغيرة والمتوسطة البشرية في انتظار هذا الدليل. لم يتم إجراء أي تعديلات DNS أو اختبارات مباشرة.
احتفظ بالسجلات العامة منفصلة عن عمليات التشفير
لا يؤدي نشر المفتاح العام إلى تشفير نص البريد الإلكتروني أو إنشاء توقيع أو إثبات أن الرسالة بأكملها آمنة. استخدم معيار DKIM لتوقيع دلالات بدلاً من شرح التشفير المبسط لمقالة الموفر. تحقق من المحتوى الموقع الفعلي ونتيجة جهاز الاستقبال بعد إكمال مشغل المرسل التنشيط.
قبول رسالة منفصلة عن طرح السياسة
يمكن لنتيجة SPF المتوافقة أن تلبي تقييم الرسالة، ولكنها لا تبرر وحدها نقل النطاق بأكمله للرفض. RFC 9989 يتطلب القسم 7.4 DKIM صالحًا لنشر النطاقات p=reject ويحذر من إمكانية التشغيل التفاعلي للبريد غير المباشر. قم بجرد جميع المرسلين الشرعيين والطرق غير المباشرة قبل أن يوافق مالك السياسة على التنفيذ. لم يتم تنفيذ أي تغيير DNS أو عملية مستأجر أو اختبار الرسالة المستلمة لهذه المقالة.