حدد Netcore CE أو Netcore Email API أولاً
لا تكفي تسمية حساب Netcore لاختيار وصفة DNS . تنشر Netcore تعليمات منفصلة لإعداد المجال لمنصة Customer Engagement (CE) وEmail API الخاصة بها. تحدد صفحة تسجيل الدخول للمنتج واجهة برمجة تطبيقات البريد الإلكتروني على أنها Pepipost سابقًا. قم بتسجيل المنتج أو المستأجر أو الحساب الفرعي الذي يرسل الرسالة وما إذا كان التطبيق يستخدم SMTP أو تكامل واجهة برمجة التطبيقات (API) أو حملة CE. لا تقم بتطبيق مقالة Pepipost قديمة على شاشة CE لمجرد أن كلاهما يحمل اسم Netcore. تسجيل الدخول إلى منتج Netcore, إعداد المجال CE, التحقق من واجهة برمجة تطبيقات البريد الإلكتروني.
قم بجرد التدفقات الحقيقية التي تواجه العملاء قبل إضافة مجال إرسال. قد يكون للإيصال ورابط تسجيل الدخول والحملة التسويقية أصحاب تطبيقات ومجالات مختلفة. لكل منها، احتفظ بالرسالة الأساسية أو فشل الإرسال، والمرسل الذي تم تكوينه، وحالة المجال الحالية ومن يتحكم في DNS الموثوق. تصف الخطوات أدناه الفروع الموثقة؛ أسماء المضيفين والقيم التي تم إنشاؤها بواسطة الحساب لها الأولوية على الأمثلة.
واجهة برمجة تطبيقات البريد الإلكتروني: فصل التحقق من DNS عن الموافقة
يصف دليل إعداد Email API المحتفظ به نشر لوحة المعلومات المتوفرة SPF TXT وفريدة من نوعها DKIM سجل TXT، ثم استخدم التحقق من سجلات DNS . إذا كانت هناك سياسة موجودة بالفعل لدى مالك SPF ، فقم بدمج التفويض المطلوب في تلك السياسة بدلاً من إضافة مرشح آخر سجل SPF. لا تقم بلصق نموذج نهج كامل على أذونات المرسلين الشرعيين الآخرين. بعد التحقق من DNS ، يدخل النطاق في عملية موافقة يمكن أن تتضمن عمليات فحص تلقائية ومراجعة يدوية. لا يثبت سجل DNS الذي تم التحقق منه في حد ذاته أن المجال معتمد للإرسال. التحقق من نطاق واجهة برمجة تطبيقات البريد الإلكتروني والموافقة عليه.
احتفظ بالنتيجتين في حقول ورقة عمل منفصلة. إذا كان DNS صحيحًا ولكن الموافقة لا تزال معلقة، فتحقق من حالة مراجعة الحساب ومعلومات العمل المطلوبة. يمكن أن تؤدي تعديلات DNS المتكررة إلى حجب تكوين العمل دون معالجة الموافقة. وعلى العكس من ذلك، لا يثبت الحساب النشط أن مجال المرسل المحدد أو الحساب الفرعي جاهز.
يصف دليل Netcore التوضيحي أيضًا قيمة SPF المنقحة التي يجب على المشغل نشرها عند اكتشاف سياسة موجودة. قارن هذه القيمة المقترحة بالسجل المعتمد الحالي: ربما قام فريق آخر بتغيير DNS منذ أن قرأته لوحة المعلومات لأول مرة. الحفاظ على الأذونات المتعمدة وتقييم مسار البحث الكامل. بالنسبة إلى DKIM ، استخدم اسم المضيف والقيمة المرتبطة بالمجال المحدد. يمكن للمحددات المنفصلة أن تخدم خدمات مختلفة، ولكن قيمًا متعارضة في خدمة واحدة محدد لا يتم حلها عن طريق تكديس المفاتيح التعسفية. شرح البريد الإلكتروني API SPF و DKIM, قواعد معالجة SPF.
CE: تحقق من كل صف DNS تم إنشاؤه
تحدد وثائق CE الإعدادات → مجال البريد الإلكتروني → إضافة مجال. بعد الدخول إلى المجال، توفر شاشة تكوين DNS غرض كل سجل ونوعه واسم المضيف والقيمة والحالة. يمكن أن تتضمن أنواع السجلات TXT ، CNAME و MX ؛ انسخ الصفوف المتوفرة بالفعل للمستأجر بدلاً من فرض نموذج TXT ثنائي واجهة برمجة تطبيقات البريد الإلكتروني. يقول الدليل أنه يجب تكوين جميع السجلات التي تم إنشاؤها والتحقق منها. استخدم التحقق، ثم أكمل التدفق عند نجاحه. CE إضافة مجال البريد الإلكتروني.
يميز دليل CE نفسه بين النجاح والمعلق والخطأ والترحيل. "في انتظار" و"خطأ" لا يسمحان بالإرسال. ويحذر أيضًا من أن تعديل اسم المضيف بعد التحقق يجعل النطاق غير نشط ويتطلب إعادة التحقق من جميع السجلات. تعامل مع تعديلات اسم المضيف باعتبارها تغييرًا خاضعًا للرقابة مع وجود خطر الانقطاع. يعد توفر إعدادات تنزيل DNS مفيدًا في تسليم الأدلة؛ فهو ليس دليلاً على نشر السجلات أو أن المتلقي قد قام بتوثيق الرسالة.
لا تقم بإعادة تعيين الوارد العادي للمنظمة سجلات MX لمجرد أن الصف الذي تم إنشاؤه يستخدم MX . حدد أولاً المالك الدقيق والغرض الذي أظهره المستأجر. يمكن أن يكون للنطاق الفرعي للإرسال أو الارتداد تكوين DNS خاص به. لا يبرر النص العام الذي تمت مراجعته اسم مضيف CE العالمي أو هدف MX أو محدد DKIM .
المظروف المخصص: النشر والتفعيل هما خطوتان مختلفتان
تقوم Netcore Email API بتوثيق نموذج مخصص بشكل منفصل Return-Path عملية. وهو يصف اختيار نطاق فرعي، ونشر تعيين CNAME المقدم ومطالبة فريق التسليم بتمكين المغلف المخصص/ Return-Path و DKIM للحساب. تعني هذه العملية الموثقة أن CNAME المنشور وحده ليس دليلاً على أن الرسائل قد غيرت هويتها. قم بتأكيد تعليمات المستأجر الحالية وحالة التنشيط قبل الاعتماد على هذا الخيار. تحتفظ المقالة بتسمية عصر Pepipost، لذا لا تقم بتعميم هدفها أو عملية الدعم الخاصة بها على CE. Return-Path المخصص لواجهة برمجة تطبيقات البريد الإلكتروني.
قرر سبب الحاجة إلى المغلف المخصص. يمكنه توفير مسار SPF محاذٍ فقط إذا كان نطاق المغلف الفعلي يلبي المجال من تنسيق المتطلبات ويمر SPF . يمكن للنطاق الفرعي ذي الصلة أن يلبي المحاذاة المريحة، بينما تتطلب المحاذاة الصارمة مساواة تامة في المجال. تم التحقق منها، الانحياز توقيع DKIM قد تزود بالفعل DMARC طريق. لا تقم بإزالة سجلات DNS التي يطلبها الموفر لمجرد أن DMARC يحتاج إلى آلية تمرير واحدة محاذية فقط. قواعد محاذاة DMARC.
املأ ورقة عمل Netcore الخاصة بالمنتج
استخدم نسخة واحدة لكل مستأجر/حساب فرعي ومجال الإرسال. انسخ كل صف DNS تم إنشاؤه إلى إدخال مرقم منفصل بدلاً من طي عدة أغراض في غرض واحد.
- المنتج: CE / واجهة برمجة تطبيقات البريد الإلكتروني. المستأجر/الحساب الفرعي: ______. التطبيق أو الحملة: ______.
- المقصود من المجال: ______. المرسل الحالي المكون: ______. سلطة ومشغل DNS : ______.
- رقم الصف الذي تم إنشاؤه: ______. غاية: ______. مالك: ______. يكتب: ______. دليل القيمة الدقيقة: ______. النتيجة الرسمية وتوقيت UTC: ______.
- أذونات نظام التعرف على SPF الحالية التي تم الاحتفاظ بها: ______. التقييم الكامل لبحث DNS: ______.
- حالة DNS للمجال: ______. حالة الموافقة على واجهة برمجة التطبيقات (API)، إن وجدت: ______. تاريخ الإثبات: ______.
- تغيير اسم المضيف CE المخطط لها؟ ______. صاحب إعادة التحقق والانقطاع: ______.
- مطلوب مغلف مخصص؟ ______. مالك النشر: ______. تأكيد تفعيل الموفر: ______. هوية المغلف المستلم: ______.
- اختبار سير العمل ومعرف الرسالة: ______. من المجال: ______. نطاق/نتيجة SPF : ______. كل DKIM
d=/s=/ نتيجة: ______. - نتيجة DMARC لجهاز الاستقبال: ______. وضع المحاذاة ومسار المرور: ______.
- فحص التعامل مع الارتداد: ______. مسار التراجع: ______. الموافقة على الإصدار: ______.
قاعدة التشخيص: يعد فقدان البيانات الموثوقة مشكلة تتعلق بالنشر؛ تعتبر موافقة API المعلقة مشكلة تتعلق بالموافقة على الخدمة؛ مظروف مختلف بعد النشر يمثل مشكلة في التنشيط أو التوجيه. قم بتعيين الفشل إلى المالك الصحيح قبل إجراء تغيير آخر.
التشخيص العملي الخيالي: DNS الذي تم التحقق منه، والمظروف القديم
مثال تدريبي خيالي، وليس نتيجة اختبار Netcore. يرسل التطبيق إيصالات من receipts.example. قام مالكه بنشر سجل DKIM الخاص بالحساب وطلب مظروفًا مخصصًا على bounce.receipts.example. لا تزال الرسالة المستلمة تستخدم مظروف خدمة غير ذي صلة، ولكن يمر DKIM معه d=receipts.example. يُبلغ المتلقي الموثوق به عن مرور DMARC .
تشرح ورقة العمل كلتا النتيجتين: يوفر DKIM مسار المرور المحاذي؛ لا يزال تغيير المغلف المخصص غير مثبت. يتحقق المسؤول من حدوث تنشيط الموفر وما إذا كان التطبيق يستخدم المستأجر المقصود. إضافة المزيد من أذونات SPF إلى receipts.example لن يغير المغلف المملوك للخدمة في تلك الرسالة. بعد تأكيد التنشيط، يجب أن يُظهر الإيصال الجديد المغلف المتوقع ومعالجة الارتداد الناجحة.
في حالة CE الخيالية الثانية، يتم تحرير اسم المضيف الذي تم التحقق منه أثناء إطلاق الحملة ويصبح النطاق غير نشط. الرد الصحيح هو إكمال عملية إعادة التحقق المطلوبة ومواصلة إيقاف الإرسال مؤقتًا حتى تسمح CE بذلك. ستعالج تذكرة الموافقة على واجهة برمجة تطبيقات البريد الإلكتروني سير عمل المنتج الخاطئ.
القبول والاسترداد
استعلم عن مالكي السجلات بالضبط في DNS المعتمد، ثم قارن النتائج المتكررة مع الطوابع الزمنية. فحص التوقيعات المستلمة وكذلك لوحة القيادة. يثبت مفتاح DKIM المنشور توفره، وليس أن التطبيق يستخدم هذا المفتاح؛ يُثبت إرسال واجهة برمجة التطبيقات (API) الناجح قبول الخدمة، وليس وضع البريد الوارد. استخدم معاملة ومستلمًا خاضعين للرقابة، دون وجود رموز إعادة تعيين حقيقية أو بيانات العميل في حزمة المراجعة. التحقق DKIM.
احفظ إعدادات DNS والتطبيق التي تم تغييرها مسبقًا. إذا فشل المسار الجديد، فأوقف المرسل المتأثر مؤقتًا، واستعد التكوين الذي تم تغييره فقط واختبر رسالة جديدة. تحقق من عمليات الإرسال في قائمة الانتظار قبل تبديل وسائل النقل لتجنب التكرارات. احتفظ بالمجالات والحملات غير ذات الصلة خارج نطاق التغيير.
لم يتم اختبار أي مستأجر Netcore مباشر أو تغيير DNS أو رسالة مستلمة لهذه المخطوطة. أوراق العمل والأمثلة هي مواد تحضيرية. يظل قابلية تطبيق المنتج/المستأجر الحالي وأدلة التنشيط والموافقة DNS المعتمد واختبارات الرسائل المباشرة والمراجعة المرئية وموافقة الشركات الصغيرة والمتوسطة البشرية مطلوبة قبل الإصدار.