قم بتأكيد نشر نظام إدارة المحتوى (CMS) قبل اختيار التعليمات
يقوم نظام إدارة المحتوى (CMS) على النحو الأمثل بإنشاء رسائل التطبيق، لكن وسيلة النقل التي تم تكوينها ترسلها. ابدأ بتسجيل إصدار CMS ونموذج الاستضافة والبيئة وتكامل البريد الذي يتعامل مع سير العمل المتأثر. لا يمكن افتراض مشاركة نظام إدارة المحتوى (CMS) الذي يعمل على DXP، والتثبيت المستضاف ذاتيًا، والتطبيق مع مرحل الطرف الثالث الخاص به. SPF أو DKIM إعدادات. تعتبر حملة Optimizely منتجًا منفصلاً ويجب عدم استعارة سجلات مجال البريد التسويقي الخاصة بها لإشعارات نظام إدارة المحتوى (CMS).
تم تسمية صفحة خادم البريد الإلكتروني DXP للطرف الأول التي تم استردادها لهذا الدليل باسم DXP لـ CMS 12 وCommerce 14. وهي توثق السحابة البريد الإلكتروني للمعاملات الخدمة وتكوين SMTP المدعوم من SendGrid وعملية مصادقة المجال المدعومة بالدعم. تستخدم هذه المقالة هذا المسار كفرع التنفيذ الملموس. تتطلب قابلية التطبيق على إصدار CMS آخر أو طبقة استضافة أو تكامل مخصص الوثائق الحالية المقابلة وأدلة النشر. تعد تسمية الكتالوج العامة Optimizely CMS أوسع من نطاق التكوين المحدد هنا. تكوين خادم البريد الإلكتروني DXP
قبل تحرير التكوين، قم بتسمية مالك التطبيق ومشغل النشر ومسؤول البريد ومالك DNS . وافق على سير العمل الذي سيثبت النجاح: إشعار المشروع، أو رسالة الموافقة على المحتوى، أو بريد إلكتروني آخر للتطبيق تم تكوينه بشكل صريح. استخدم محتوى اصطناعيًا ومستلمًا خاضعًا للرقابة. لا تعد النشرة الإخبارية التسويقية بديلاً مناسبًا لاختبار إشعارات نظام إدارة المحتوى (CMS) لأن كلا المنتجين يحملان نفس اسم البائع.
تتبع الرسالة من حدث التطبيق للترحيل
قم بتقسيم المسار إلى إنشاء الحدث وإرسال التطبيق وإرسال SMTP وتسليم الموفر ومصادقة المتلقي. سجل الأدلة المتوفرة في كل مرحلة. إذا لم يصدر التطبيق إشعارًا أو يرسله مطلقًا، فلن يتمكن تحرير نظام التعرف على SPF من إنشائه. إذا رفض SMTP بيانات الاعتماد، فهذا يعني أن الرسالة لم تصل بعد إلى المرحلة التي يقوم فيها المستلم بتقييمها DMARC.
تصف وثائق مشاريع CMS 13 الخاصة بـ Optimizely بشكل منفصل إرسال الإشعارات وتقول إنه يجب تكوين إعدادات SMTP لإشعارات البريد الإلكتروني. وهذا يدعم التحقق من مرحلة التشغيل والإرسال عندما يكون التثبيت الفعلي هو CMS 13؛ ولا يثبت أن نشر CMS 12 له إعدادات افتراضية متطابقة للمهمة أو أن مثال DXP SMTP ينطبق دون تغيير. قم بمطابقة تعليمات التكوين مع الإصدار المثبت بدلاً من خلط مقتطفات الإصدار. إشعارات المشروع CMS 13
بالنسبة لكل بيئة، قم بالتمييز بين تكوين وقت التشغيل الفعال والملف المصدر الذي قد يتم تجاوزه أثناء النشر. يمكن أن يتواجد النجاح المرحلي مع فشل الإنتاج الناتج عن إعداد مفقود أو عنوان "من" مختلف. جمع الإعدادات المعقمة وسجلات التطبيق من خلال العملية الهندسية العادية. لا تكشف عن بيانات اعتماد SMTP أو مفاتيح API أو أسرار الإنتاج غير ذات الصلة في حزمة الأدلة.
قم بتكوين نقل DXP الموثق من خلال النشر الخاضع للتحكم
يقول دليل DXP أن تكوين البريد الإلكتروني لا يتم تطبيقه تلقائيًا من خلال تحويلات التكوين القياسية. وهو يصف الحصول على بيانات اعتماد خدمة البريد الإلكتروني من خلال بوابة إدارة DXP وتوفير إعدادات SMTP للتطبيق. يتضمن مثاله إعدادات هوية إشعارات التطبيق بالإضافة إلى إعدادات النقل. استخدم آلية التكوين المدعومة للإصدار والبيئة المنشورين، وراجع القيم الفعالة الناتجة. تكوين خادم البريد الإلكتروني DXP
التعامل مع إنشاء بيانات الاعتماد وتخزينها وتدويرها كعملية أمنية منفصلة يمكن التحكم فيها. لا يتطلب هذا الدليل بيانات اعتماد جديدة إذا كانت بيانات اعتماد العمل المعتمدة موجودة بالفعل. لا تلصق سرًا أبدًا في مقالة عامة أو مثال مستودع أو سجل DNS أو لقطة شاشة للدعم. قم بالرجوع إلى المتجر السري المعتمد والمشغل المسؤول بدلاً من ذلك. تأكد من أن سجلات النشر والإبلاغ عن الأخطاء لا تطبع بيانات الاعتماد عند الاختبار.
خدمة DXP الموثقة مخصصة للاتصال الآلي بموقع المعاملات. يوجه الدليل العملاء الذين يحتاجون إلى إمكانات SendGrid الأخرى، مثل استخدام قالب HTML المخصص الخاص بهم، نحو حساب مشترك بشكل منفصل أو موفر SMTP آخر. تأكد من الاستخدام المقصود بدلاً من افتراض أن الوصول إلى DXP SMTP هو وصول غير مقيد إلى حساب SendGrid المُدار بواسطة العميل. الحساب المنفصل له ملكيته الخاصة وإجراءات مصادقة المجال.
طلب المصادقة لكل مجال الإرسال
للحصول على مسار DXP الموثق، اتصل بـ Optimizely مع مجال الإرسال للحصول على المساعدة في تنشيط مصادقة المرسل. يقول الدليل نفسه أنه يجب طلب DKIM لكل مجال إرسال بريد ويتطلب سجلات DNS إضافية. احصل على مجموعة السجلات الدقيقة وخطة التنشيط للبيئة قبل نشر أي شيء. لا عالمية محدد, CNAME يمكن اشتقاق الهدف أو المفتاح الخاص من اسم المنتج. مجال DXP وتكوين DKIM
قم بإدراج كل مجال مرئي من النطاق الذي تستخدمه الإشعارات ذات الصلة. إذا كانت التطبيقات متعددة المواقع أو مسارات العمل التي تم تكوينها بشكل منفصل تستخدم مجالات مختلفة، فاطلب من الدعم تكوين المصادقة الذي يغطي كل منها. لا تفترض أن التحقق من نطاق الشركة الأساسي يؤدي تلقائيًا إلى تنشيط كل نطاق فرعي أو علامة تجارية بديلة. سجل من يجب عليه تأكيد التنشيط من جانب المرسل بعد نشر DNS .
تتضمن صفحة DXP نموذجًا لسياسات نظام التعرف SPF . تعامل معها كأمثلة توثيقية، وليست وصفات كاملة لمجال الإنتاج. حدد مالك المغلف الفعلي، واحتفظ بالمرسلين المعتمدين الآخرين واحتفظ بسياسة نظام التعرف SPF واحدة صالحة هناك. تقييم حدود البحث العودي قبل دمج الترخيص. إذا كان النقل الذي تم تكوينه يختلف عن خدمة DXP الموثقة، فاحصل على الإرشادات الحالية الخاصة بهذا النقل بدلاً من ذلك. SPF RFC 7208
قم بنشر كل سجل DKIM متوفر لدى المالك المحدد بالنوع المقدم. احتفظ بالمحددات النشطة أثناء عملية النقل المخطط لها، وحل تعارضات CNAME قبل الحفظ، واحتفظ بالمفاتيح الخاصة خارج DNS . الاستعلام عن الخوادم المعتمدة للتحقق من الاسم والقيمة الناتجة؛ معاينة محرر DNS ليست كافية. يدعم السجل العام التحقق من الصحة فقط عندما تستخدم الرسالة الصادرة الفعلية هوية التوقيع المقابلة لها. DKIM RFC 6376
حافظ على تنسيق هوية المرسل وسياسة DMARC
قم بالموافقة على العنوان المرئي المقصود قبل الاختبار. لا يثبت اسم مضيف SMTP الصحيح وبيانات الاعتماد العاملة أن التطبيق يستخدم المجال المعتمد. قم بتسجيل هوية الإشعارات الفعالة وأي تجاوز على مستوى التطبيق بشكل منفصل عن تكوين النقل. قم بمراجعة معالجة الرد حتى لا يتم توجيه المستلمين إلى صندوق بريد غير مراقب دون اتخاذ قرار تجاري.
افحص سياسة DMARC الحالية للنطاق المرئي واحتفظ بالتنفيذ المعتمد لها، تنسيق وتكوين التقارير. ينجح DMARC عندما تتم محاذاة هوية SPF أو DKIM واحدة على الأقل ضمن الوضع القابل للتطبيق. يمكن لمجال التوقيع المملوك للموفر اجتياز التحقق من صحة التشفير دون التوافق مع المجال المرئي للمؤسسة. لا تستجيب بإضعاف سياسة النطاق بالكامل قبل فحص مسار مصادقة المرسل المدعوم. DMARC RFC 9989
يعد اتصال التطبيق ومصادقة الموفر ووضع البريد الوارد بمثابة نتائج قبول منفصلة. سجل CMS الذي يشير إلى أنه تم إرسال رسالة ليس إيصالًا من صندوق البريد النهائي. قد تستمر تصفية الرسالة المستلمة التي تم تمرير DMARC لأسباب أخرى. احتفظ بهذه الفروق في تقرير التغيير حتى لا تخفي طبقة واحدة ناجحة مشكلة لم يتم حلها في مكان آخر.
ورقة عمل مسار CMS وDXP القابلة لإعادة الاستخدام
أكمل نسخة منفصلة لكل بيئة نشر وهوية إرسال مختلفة ماديًا.
- إصدار CMS ونموذج الاستضافة والمشروع والبيئة: ______.
- سير العمل الدقيق والمشغل الاصطناعي والمستلم المتوقع: ______.
- مصدر التكوين ومراجعة النشر وإعدادات وقت التشغيل الفعالة: ______.
- مزود النقل وصاحب الحساب والمرجع السري المعتمد فقط: ______.
- مرئي من واسم العرض ووجهة الرد وتوقع المغلف: ______.
- حالة دعم تؤكد إمكانية تطبيق DXP وكل مجال إرسال: ______.
- مالكو DNS المُصدرون وأنواعهم وقيمهم ومتطلبات التنشيط: ______.
- سياسات SPF و DMARC الحالية ومجموعة التغييرات المعتمدة: ______.
- الإجابات الرسمية وأوقات الاستعلام وحالة التحقق من المزود: ______.
- الإرسال وتقديم SMTP وأدلة تسليم الموفر: ______.
- الرسالة المستلمة من، والمغلف، وجميع أزواج DKIM d=/s= والنتائج الموثوقة: ______.
- نشر التراجع وخطة استعادة DNS والقبول البشري: معلق.
التشخيص الخيالي لفشل إشعار الإنتاج
هذا المثال خيالي. نجح الفريق في اختبار إشعار الموافقة في المرحلة المرحلية ونشر التطبيق. تستخدم رسائل الإنتاج مجالًا مرئيًا مختلفًا من. نجح إرسال SMTP ، ولكن أبلغ مستلم مستقل عن توقيع موفر صالح لا يتوافق مع مجال الإنتاج هذا. يقترح الفريق نسخ هدف DKIM للحملة إلى DNS لأنه ينتمي أيضًا إلى Optimizely.
يقارن التشخيص المقترح هوية الإنتاج الفعالة بالمجالات التي يغطيها طلب دعم DXP. في هذا السيناريو، تم تضمين الهوية المرحلية فقط. تتمثل الخطة التصحيحية في طلب تكوين المصادقة المدعوم لمجال إرسال الإنتاج ونشر السجلات الصادرة وإعادة اختبار سير عمل الموافقة الفعلي. لن يؤدي استعارة سجل الحملة إلى إثبات أن موقع DXP يستخدمه. هذا مثال عملي، وليس اختبارًا مباشرًا أو تأكيدًا حول أي عملية نشر للعميل.
استرداد في الطبقة التي تغيرت
إذا توقف التطبيق عن إرسال الرسائل، فقم بمقارنة إعدادات النشر والنقل قبل التراجع عن DNS . إذا فشل التحقق من النطاق، فقارن المالكين الذين أصدروا الدعم بالإجابات الموثوقة. إذا مرت المصادقة ولكن فشل التسليم، فافحص استجابات الموفر والمستلم دون توسيع أذونات المرسل دون داع. احتفظ بالأدلة قبل إعادة المحاولة حتى يمكن التعرف على الإشعارات المكررة.
يجب أن يؤدي التراجع إلى استعادة النشر المتأثر بشكل ضيق أو تغيير DNS ، وليس تدوير كل بيانات الاعتماد أو إعادة تعيين المنطقة بأكملها. يتم إيقاف المحددات التي تم استبدالها فقط بعد أن يؤكد مالك البريد أنه لا يوجد طريق نشط أو في قائمة الانتظار يحتاج إليها. تم إنشاء فرع DXP الموثق، ولكن تظل قابلية تطبيق إصدار CMS الأوسع والإعدادات الخاصة بالمستأجر والقيم الصادرة عن الدعم و DNS المباشر والرسائل المستلمة والمراجعة المرئية وموافقة الشركات الصغيرة والمتوسطة البشرية معلقة. لم يتم تغيير أي تكوين للتطبيق أو بيانات الاعتماد أو سجل DNS أو سير العمل المباشر لهذا الدليل.
احتفظ بأمان النقل بعيدًا عن الأمثلة المنسوخة
تمزج الصفحة العامة أمثلة لملفات التكوين وتتضمن إعداد تعليمات برمجية معطل لـ SSL. لا توافق هذه المقالة على هذا الإعداد أو على مقتطف الإصدار غير المتطابق. اطلب من مالك النشر تأكيد النقل المدعوم وسلوك TLS لوقت التشغيل الفعلي دون الكشف عن بيانات الاعتماد. في الحالة الخيالية، لا يحدد توقيع الموفر وحده نتيجة نظام التعرف على SPF غير المحددة.
قبول رسالة منفصلة عن طرح السياسة
يمكن لنتيجة SPF المتوافقة أن تلبي تقييم الرسالة، ولكنها لا تبرر وحدها نقل النطاق بأكمله للرفض. RFC 9989 يتطلب القسم 7.4 DKIM صالحًا لنشر النطاقات p=reject ويحذر من إمكانية التشغيل التفاعلي للبريد غير المباشر. قم بجرد جميع المرسلين الشرعيين والطرق غير المباشرة قبل أن يوافق مالك السياسة على التنفيذ. لم يتم تنفيذ أي تغيير DNS أو عملية مستأجر أو اختبار الرسالة المستلمة لهذه المقالة.