قم باختيار المنتج وخدمة التوصيل أولاً
"المرسل بواسطة Sitecore" ليس وصفًا كافيًا للمسار. يجوز للمؤسسة نفسها استخدام Email Experience Manager مع EXM Delivery Cloud، أو EXM مع SMTP مخصص، أو منتج Sitecore Send المنفصل. تغطي هذه المسودة تلك الفروع الموثقة، باستخدام وثائق EXM 10.4 للأمثلة التي تم إصدارها. تأكد من المنتج والإصدار الفعليين قبل اعتماد أي إجراء. يظل نطاق الكتالوج الواسع معلقًا حتى يتم قبول هذا التحديد.
قم بتسجيل مالك الحملة ومجال الإرسال والمنتج والحساب أو البيئة وطريق التسليم. إذا كانت عملية الترحيل جارية، فقم بتسجيل المسارات القديمة والجديدة بشكل منفصل. لا ينبغي افتراض أن المجال الذي تم التحقق من صحته في أحد المنتجات قد تم تكوينه في منتج آخر. يجب أن تحدد عملية الطرح بالضبط مسارات العمل التي ستغطيها الأدلة الخاصة بها.
اتبع فرع EXM Delivery Cloud عند تطبيقه
ال دليل المجال EXM 10.4 يصف إضافة مجال مرسل يتم التحكم فيه ضمن المسؤول، خدمة تسليم البريد الإلكتروني، المجالات. إظهار التفاصيل يفضح المطلوب DKIM معلومة. تقول أن Delivery Cloud تستخدم مجال مغلف مشترك يديره الموفر SPF، لذا فهو لا يتطلب إعدادًا منفصلاً لنظام SPF لكل مجال إرسال مرئي.
استخدم فقط النطاق الذي تمتلكه المؤسسة والمصرح باستخدامه. احصل على السجل العام الصادر بالضبط وقارنه بالمنطقة الرسمية. لا تستبدل أ محدد من مثيل Sitecore مختلف. إذا أظهر التحقق تحذيرًا، فاحتفظ بهذه الحالة وتحقق من المالك المنشور، واكتب وقيمته قبل المتابعة.
يوصي دليل EXM أيضًا بالنمو التدريجي للجمهور من خلال القوائم التي تم الاشتراك فيها والمحافظة عليها. سمعة الخطة تسخين بشكل منفصل عن قبول DNS ؛ لم يتم إنشاء جدول حجم عالمي بواسطة هذا الدليل.
خطط للتغيير مع مالك الحملة. المجال الذي يظهر كما تم تكوينه في التطبيق هو ملاحظة وسيطة؛ يجب أن تظل الحملة النهائية تحمل الهوية المقصودة وأن تنتج نتيجة متوافقة. لا تفسر نظام التعرف على هوية المرسل SPF الذي يديره الموفر كدليل على محاذاة النطاق المرئي من خلال نظام التعرف على هوية SPF . يحدد المغلف والتوقيع الفعلي هذه الإجابة.
تعيين ملكية المتلقين للمعلومات لـ SMTP المخصص
ال مقارنة التسليم EXM يقوم بتعيين إدارة المصادقة لـ SMTP المخصص لنظام الإرسال المحدد للعميل. لا يقوم سير عمل مجال Delivery Cloud بتكوين مفاتيح الترحيل أو DNS أو عناصر التحكم في السمعة. هذه حدود مسؤولية، وليست ادعاءً بأن خدمات SMTP لا يمكنها دعم DKIM .
حدد مشغل الترحيل وتعليمات الطرف الأول الحالية الخاصة به. قم بتسجيل النظام الذي يطبق التوقيع النهائي، ومجال المغلف الذي يستخدمه، وما إذا كان بإمكان بوابة أخرى تعديل الرسالة بعد ذلك. إذا كانت المؤسسة تقوم بتشغيل الترحيل، فقم بتعيين مسؤول يمكنه التحقق من عناصر التحكم هذه. إذا قام مزود آخر بتشغيله، فاحصل على السجلات الصحيحة الخاصة بالحساب هناك.
احتفظ بمصادقة التتابع وتشفير النقل و DMARC متفرق. لا يؤدي الاتصال الآمن بالمرحل إلى إنشاء توقيع مجال العميل على جهاز الاستقبال النهائي. وبالمثل، فإن إرسال SMTP الناجح لا يُظهر القبول إلا في تلك المرحلة. أعد اختبار المسار الكامل عندما يتغير تعديل محتوى الترحيل أو البوابة أو المصب.
استخدم سير عمل المرسل Sitecore Send بشكل منفصل
دليل DNS الخاص بـ Sitecore Send يوجه المستخدمين إلى المزيد، والإعدادات، والمرسلين، مع معلومات السجل في علامتي التبويب SPF و DKIM وإجراء التحقق من سجلات DNS . وهو يصف التحقق المدمج من SPF و DKIM و DMARC ، بما في ذلك عمليات التحقق من النطاق الأصلي وحالة التحقق لمدة 48 ساعة. هذه هي سلوكيات التحقق من التطبيق.
انسخ القيم الخاصة بالمرسل والمجال الفعليين، وليس القيم من شاشة مجال EXM. قم بمراجعة سياسة DMARC الحالية قبل تغييرها لتلبية مطالبة التطبيق. قد يكون للنطاق بالفعل وجهة إعداد تقارير وإعدادات تنفيذ و تنسيق وضع. الحفاظ على تلك القرارات ما لم تغيرها مراجعة معتمدة منفصلة.
تعامل مع قاعدة التحقق من المجال الأصلي للموفر بعناية. وهذا لا يعني أن SMTP SPF يرث تلقائيًا سجلًا أصليًا عشوائيًا. لا تثبت حالة التحقق المخزنة مؤقتًا أيضًا أن الرسالة المستلمة حديثًا تتم مصادقتها بعد تحرير DNS خارجي. سجل كلاً من وقت التحقق من التطبيق وملاحظة الرسالة اللاحقة.
قم بمراجعة تغييرات DNS كمجموعة واحدة يتم التحكم فيها
قم بإعداد ورقة تغيير تحتوي على النطاق والمالك ونوع السجل والقيمة العامة والحساب المصدر والمشغل المسؤول. قم بتصدير السجلات الموجودة وحل تعارضات المحدد قبل النشر. إذا قامت واجهة DNS بإلحاق المجال تلقائيًا، فقم بتأكيد المالك المؤهل بالكامل الناتج. احتفظ بالمفاتيح الخاصة وبيانات اعتماد الترحيل خارج الورقة.
بالنسبة لأي تغيير في SPF يديره العميل، RFC 7208 يوفر قواعد التقييم والحد من البحث. الحفاظ على المرسلين المعتمدين الآخرين ومراجعة السياسة الكاملة. لا تقم بإضافة سياسة ثانية أو تضمين موفر غير ذي صلة لمجرد أن قائمة التحقق القديمة تتوقع خطوة Sitecore SPF .
بالنسبة إلى DKIM ، احتفظ بكل مجال توقيع ومحدد تمت ملاحظته. RFC 6376 يشرح تلك المجالات. يجب أن يتوافق DNS العام مع التوقيع المستخدم بالفعل، وليس فقط مع المحدد الذي يتوقعه المسؤول. تتطلب التوقيعات المتعددة نتائج منفصلة بدلاً من إدخال "تمكين DKIM " غير متمايز.
اختبر مسارًا حقيقيًا للحملة بمحتوى غير ضار
استخدم حملة خاضعة للرقابة أو سير عمل اختباري مدعوم يمارس مسار التسليم الفعلي. سجل ما إذا كان يطابق إرسال الإنتاج، لأن المعاينة أو إشعار التطبيق قد يستخدم مسارًا آخر. تجنب إرسال الإنتاج على نطاق واسع أثناء عدم التحقق من الهوية. احتفظ بمعرف الرسالة ووقت الإرسال حتى يمكن ربط أحداث المزود وأدلة المتلقي.
التقط مجال المغلف المرئي من والرد عليه وجميع هويات DKIM ونتائج جهاز الاستقبال الموثوق به. RFC 9989 يحدد متطلبات المحاذاة. حدد آلية التمرير التي تتم محاذاتها ولماذا. يمكن لمغلف موفر غير ذي صلة تمرير نظام التعرف على هوية المرسل SPF بينما تعتمد هوية العميل على DKIM المحاذاة.
تحقق من الفشل في سياق فرعه. في Delivery Cloud، قارن المجال الذي تم تكوينه وتفاصيل التوقيع الصادرة. باستخدام SMTP المخصص، قم بإشراك مالك التتابع النهائي. في Sitecore Send، قارن قيم المرسل وحالة التحقق مع DNS الحالي. لا تنتقل بين هذه الإجراءات حتى يتم إنشاء المسار نفسه.
استخدم ورقة عمل قرار المنتج والطريق
تبدأ ورقة عمل المنتج والتسليم الخاصة بـ Sitecore (إنشاء سجل مراجعة منفصل باستخدام الحقول الموضحة هنا) باختيار فرع إلزامي. ثم يسجل مصدر المجال وحالة التحقق والملكية النهائية وهويات الحملة النهائية. قم بوضع علامة على الفروع غير المستخدمة خارج النطاق بدلاً من التعامل مع كل ميزة Sitecore محتملة كجزء من عملية نشر واحدة.
يجب أن يربط سجل القبول أربع ملاحظات: المنتج المحدد، وطريق التسليم النشط، DNS الداعم، والنتيجة النهائية للمستلم. إذا كان أحد المفقودين، فاذكر الدليل المفقود وصاحبه المسؤول عنه. لا يمكن لشارة المنتج أن تملأ حقل الرسالة المستلمة.
حالة تشخيصية خيالية تتضمن ترحيل التتابع
حالة مكتوبة خيالية فقط: SC-02 يفترض أن الحملة المقصودة هي news@museum.example . بعد التغيير من EXM Delivery Cloud إلى SMTP المخصص، تحتوي الرسالة النهائية على d=relay.example, وهو مجال غير ذي صلة؛ نتيجة المغلف/ SPF وأي توقيعات أخرى غير معروفة. لم تتم محاذاة هذا التوقيع، لكن الحقائق المقدمة لا تشكل حكم DMARC كاملاً. يجب على مالك الترحيل توثيق تكوين توقيع نطاق العميل المدعوم وجمع الأدلة من الحملة الفعلية. لا يمكن للتحقق السحابي للتسليم القديم إغلاق المسار الجديد. لم يتم اختبار أي مستأجر أو مرحل أو DNS أو رسالة.
استرداد المسار الذي تم تغييره فقط
احتفظ بالمسار القديم المعتمد متاحًا أثناء الترحيل المخطط له حيثما أمكن ذلك، مع وجود ضوابط واضحة ضد عمليات الإرسال المكررة. تنسيق التراجع مع جدولة الحملة والرسائل الموضوعة في قائمة الانتظار. لا تحذف المفاتيح العامة القديمة حتى يؤكد المالك أن البريد المتبقي لم يعد يعتمد عليها. الحفاظ على متطلبات المنع والتعامل مع الارتداد عند تقييم مسار التسليم البديل.
أعد الاختبار بعد ترحيل المنتج وترحيل التغييرات وإضافات مجال المرسل وتعديلات DNS الخارجية. تظل هذه مسودة وثائقية غير منشورة. يظل نطاق المنتج الأصلي الدقيق والسجلات الصادرة عن الحساب DNS المباشر وأدلة الرسائل المستلمة والمراجعة المرئية وموافقة الشركات الصغيرة والمتوسطة البشرية معلقة.
افصل رسالة المرور عن جاهزية التنفيذ
RFC 9989 يتطلب القسم 7.4 DKIM صالحًا لنشر المجال p=reject ويحذر بشأن إمكانية التشغيل التفاعلي للبريد غير المباشر. لا تبرر نتيجة SPF المفردة في حد ذاتها طرح سياسة الرفض. قم بمراجعة جميع المسارات الشرعية وملكية السياسة بشكل منفصل عن إعداد الموفر هذا.