قم بتأكيد منتج GoodData ومساره بالضبط
يُطلق على إجراء الطرف الأول الذي يدعم هذا الدليل اسم GoodData Legacy Growth, Configure DKIM للبريد الإلكتروني الصادر. يتعلق الأمر بالبريد الصادر ذي العلامات البيضاء ويتطلب العمل من جانب العميل وGoodData. لا تقم بتطبيقه تلقائيًا على GoodData Cloud الحالية أو خطة أخرى أو خدمة إعلام مختلفة.
ابدأ بتأكيد المنتج والمجال ذي العلامة البيضاء والمقصود من العناوين وسير عمل الرسائل الفعلية مع مالك الحساب. حدد مسؤول DNS ومالك دعم GoodData الذي يتعامل مع تكوين التسمية البيضاء. لا يعد عنوان URL المخصص للتطبيق أو سمة العلامة التجارية دليلاً على توقيع البريد الإلكتروني الصادر بنفس المجال.
تتمثل مهمة القارئ في إنشاء ترتيب توقيع مدعوم ثم اختبار البريد المقصود. لا تبرر علامة الموفر الواسعة للكتالوج الادعاء بأن كل منتج من منتجات GoodData يدعم نفس الشيء محددأو عملية الترحيل أو إدارة المفاتيح. إذا كان النطاق القديم الموثق لا يتطابق مع المستأجر الخاص بك، فاحصل على إجراء الطرف الأول المطابق قبل تغيير DNS .
اختر ترتيب المفاتيح المدعوم
تصف وثائق النمو القديم استخدام مفتاح خاص محدد، مع مفتاح فريد تم إنشاؤه بواسطة GoodData كبديل، أو استخدام مفتاح GoodData المشترك. في مسار المفتاح المشترك، يوفر الدعم سجل DNS الذي يحتوي على المفتاح العام. في مسار المفتاح المحدد، تقوم الأطراف بتنسيق المحدد والمجال مع تكوين التوقيع. لا يتم توفير محدد عام أو قيمة مفتاح عام للعملاء لنسخها من هذا الدليل.
تفضل الترتيب الذي يناسب سياسة ملكية مفتاح التوقيع الخاصة بالمؤسسة ويقلل من التعرض غير الضروري. وضح من يقوم بإنشاء المفتاح ومن يمكنه استخدامه وكيفية تنسيق التناوب وكيف ستتم إزالة سلطة التوقيع الخاصة بالموفر عند إيقاف الخدمة. يمكن أن يكون سجل DNS العام مرئيًا على نطاق واسع؛ لا يمكن التعامل مع المفتاح الخاص بنفس الطريقة.
تصف وثائق الموفر النقل المشفر عند استخدام المفتاح الخاص الذي يوفره العميل. لا تلصق مفتاحًا خاصًا في الدردشة أو تعليق دعم عادي أو مستند عام أو DNS . اطلب من مالك الأمان المعتمد التحقق من المستلم المقصود وعملية النقل الآمنة. لا يزال طلب أو قبول البديل الذي أنشأه الموفر يتطلب فهم من يملك مادة التوقيع الخاصة ويتحكم فيها.
نشر مواد التحقق العامة فقط
احصل على نوع السجل الدقيق والمالك الكامل والمحدد والقيمة العامة من الإعداد المدعوم. قارنها بمجال التوقيع المعتمد. قم بتسجيل تسمية محرر DNS المطلوبة بشكل منفصل لأن حقل الاسم النسبي قد يقوم بإلحاق المنطقة تلقائيًا. تحقق مما إذا كان المحدد الموجود ينتمي بالفعل إلى خدمة بريد أخرى قبل إجراء التغيير.
A توقيع DKIM باستخدام d=example.com و s=analytics1 يبحثان عن مفتاحهما في analytics1._domainkey.example.com . هذا مثال على بناء الاسم الاصطناعي، وليس الإعداد الافتراضي لـ GoodData. لن يتحقق المفتاح المنشور بشكل صحيح ضمن محدد أو مجال مختلف من هذا التوقيع. الحفاظ على القيمة العامة الكاملة وحدود السجل عندما يمثل المحرر فترة طويلة سجل TXT كسلاسل متعددة.
بعد النشر، استعلم عن DNS الرسمي للمالك الدقيق. احتفظ بالإجابات وتأكد من أن التفويض النشط يخدم السجل الذي قمت بتحريره. ثم اطلب من مالك الدعم إكمال التكوين من جانب GoodData. يعد نشر DNS دون تفعيل التوقيع نصف المهمة فقط.
حافظ على تمييز عامل الحماية من SPF الاختياري عن المحاذاة
include:relays.gooddata.com كخيار اختياري SPF بالإضافة إلى ترخيص مرحلات البريد الخاصة بها. تأكد من أن هذا هو المسار المناسب قبل استخدامه. لا تقم بإضافته فقط بسبب وجود سير عمل GoodData غير ذي صلة في المؤسسة، ولا تقم بإنشاء سياسة SPF ثانية في نفس المالك.
قم بمراجعة أي تحديث ضروري SPF ككل: احتفظ بالمرسلين المعتمدين الحاليين، وتحقق من تبعيات بحث DNS الخاصة بالسياسة وتأكد من سلوكها النهائي. تجنَّب نسخ عناوين IP للإرسال إلى القائمة المسموح بها الثابتة بدون خطة صيانة صريحة. إن هدف الترخيص الذي يديره الموفر والقائمة المجمدة للإجابات الحالية لهما عواقب تشغيلية مختلفة.
نجاح SPF في حد ذاته لا يثبت DMARC تنسيق. الهوية التي تم تقييمها هي مرسل المغلف اِختِصاص. إذا كانت الرسالة تستخدم مظروفًا مملوكًا للموفر أثناء إظهار المجال الخاص بك في "من"، فإن مرور نظام التعرف على هوية المرسل SPF الخاص بنطاق الموفر هذا لا يتوافق مع المجال الخاص بك. يمكن لتوقيع DKIM المتوافق مع "من" المرئي أن يوفر المسار المطلوب.
اختبر رسالة حقيقية ذات علامة بيضاء
قم بتشغيل سير عمل كل مادة داخل النطاق إلى صندوق بريد اختباري معتمد ومتحكم فيه. احتفظ بالرسالة الأولية المستلمة ولاحظ سير العمل وتكوين المرسل ووقت الاختبار. سجل من وهوية المغلف المرئية وكل نطاق توقيع DKIM ومحدد ونتائج مصادقة المتلقي الموثوق به. لا تستنتج هذه القيم من عنوان URL ذو العلامة البيضاء أو العرض الموقع وحده.
مثال للقبول الاصطناعي: من reports@example.com ، يتم التحقق من توقيع DKIM للرسالة باستخدام d=example.com ويقوم المتلقي بتقييم DMARC بنجاح على هذا المسار المحاذي. حتى إذا كان نظام التعرف على هوية SPF يمرر فقط لنطاق مغلف غير ذي صلة، DKIM المحاذاة تمامًا يمكن أن توفر مسار DMARC . إذا كان التوقيع يستخدم نطاقًا مختلفًا غير ذي صلة بدلاً من ذلك، فإن مرور DKIM وحده لا يكفي لدعم استنتاج القبول هذا.
كرر العينة بعد تدوير المفتاح أو تغيير في نقل البريد. إذا كان التوقيع المتوقع غائبًا، فتحقق من التنشيط من جانب GoodData وسير العمل الفعلي قبل إضافة المزيد من السجلات. إذا كان التوقيع موجودًا ولكنه غير صالح، فقم بمقارنة المحدد والمجال والمفتاح العام وأي تعديل للرسالة. إذا نجحت المصادقة ولكن التسليم كان سيئًا، فتحقق من عوامل المتلقي والسمعة الأخرى بشكل منفصل.
خطة التناوب والتقاعد والتعافي
احتفظ بمجموعة سجلات التغيير المسبق والمالك الموثق لكل جزء من ترتيبات التوقيع. قم بتنسيق الوقت الذي يبدأ فيه الموفر في التوقيع باستخدام محدد جديد والوقت الذي يصبح فيه المفتاح العام متاحًا. لا تفترض أن حذف سجل واحد يؤدي إلى إبطال كل الإمكانيات أو أن حذف مفتاح قديم على الفور يعد أمرًا آمنًا للبريد المرسل بالفعل الذي لا يزال قيد التسليم.
عند إيقاف التكامل، تأكد من أنه لا يوجد سير عمل لا يزال بحاجة إليه قبل إزالة المحددات أو أذونات نظام التعرف على هوية SPF . التوفيق بين الاحتفاظ بالمفتاح الخاص والوصول إلى التوقيع من جانب الموفر ضمن عملية الأمان الخاصة بالمؤسسة. إذا كان المفتاح قد تم كشفه، فاستخدم عملية الحادث والتناوب بدلاً من التعامل مع المشكلة على أنها تأخير عادي في ذاكرة التخزين المؤقت DNS .
هذا دليل وثائقي لمنتج قديم يحمل علامة محددة. الأمثلة اصطناعية. لم يتم الوصول إلى أو اختبار أي مفتاح خاص أو تكوين مستأجر أو تغيير DNS أو تبادل الدعم أو تسليم رسالة GoodData. يبقى التحقق من الإنتاج وأي قرار أوسع نطاقًا للمنتج مع مالكي الحساب والأمان.
استخدم دفتر الأستاذ التنشيط قبل استدعاء المسار كاملاً
تفترض الحالة المكتوبة GD-01 أن المستأجر قد تم تأكيد النمو القديم، وأن المصدر المعتمد هو reports@example.com والمحدد التوضيحي المتفق عليه هو analytics1. يمتلك مالك DNS مفتاحًا عامًا منصوصًا عليه في analytics1._domainkey.example.com ، بينما يظل تنشيط التوقيع من جانب الموفر غير مؤكد. لا يمكن DNS وحده إغلاق المهمة. اطلب من مالك العلامة البيضاء الحصول على تأكيد لتكوين التوقيع المدعوم ثم فحص الإشعار المعتمد غير الضار. سيوفر تمرير DKIM الافتراضي الموثوق به لاحقًا مع d=example.com, s=analytics1 محاذاة دقيقة، ولكن حتى يتوفر هذا الدليل، تظل نتيجة الرسالة غير معروفة. لم يتم استخدام أي مفتاح خاص أو طلب دعم أو بحث DNS أو إجراء المستأجر هنا.
الحفاظ على حدود التنفيذ
RFC 9989 يتطلب القسم 7.4 DKIM صالحًا، وليس نظام التعرف على SPF وحده، لنشر النطاقات p=reject، ويحذر من إمكانية التشغيل التفاعلي للبريد غير المباشر والقائمة البريدية. إن نجاح اختبار واحد للرسائل المباشرة لا يشكل دليلاً على أن كل طريق مشروع جاهز لسياسة أقوى. احتفظ بالحماية المعتمدة الحالية أثناء تشخيص الفجوة الفعلية؛ أي تغيير في السياسة يحتاج إلى قرار خاص به.