اختر مسار Postmark والهويات
يغطي هذا الدليل الرسائل الصادرة التي تم إرسالها فعليًا إلى Postmark ، وليس موقع ويب يستخدم Postmark فقط للمعالجة الواردة. قم بتسجيل التطبيق وخادم Postmark ودفق الرسائل والمجال المقصود ومسؤول DNS . يجب اختبار الإيصال المُرسل بواسطة تطبيق مختلف بشكل منفصل حتى عندما تبدو علامته التجارية متطابقة. قبل تغيير DNS ، احفظ السجلات الموجودة والرسالة الأساسية من سير العمل الدقيق.
يوفر سير عمل التحقق من مجال Postmark أ DKIM سجل TXT والعرف Return-Path CNAME. يسمح النطاق الذي تم التحقق منه بالإرسال من العناوين عبر هذا النطاق، لذا يجب أن يكون التحقق من النطاق مملوكًا للفريق المخول بتمثيله. استخدم القيم المعروضة للمجال الخاص بك، وليس القيم من مستأجر مختلف. التحقق من نطاق Postmark.
تمكين التوقيع قبل تغيير السياسة
افتح توقيعات المرسل، واختر المجال وأدخل إعدادات DNS . انسخ اسم مضيف DKIM وقيمته إلى سجل TXT لدى موفر DNS المعتمد. تحقق مما إذا كان محرر DNS يقوم بإلحاق اسم المنطقة؛ ستؤدي اللاحقة المكررة إلى وضع المفتاح في المكان الخطأ. ارجع إلى Postmark وتحقق من السجل. يقوم Postmark بتوثيق الشيكات التلقائية خلال 48 ساعة والتحكم اليدوي في التحقق. يبدأ التوقيع بعد التحقق. إعداد DKIM.
لا تعامل الحالة الخضراء كاختبار القبول النهائي. ويثبت أن الموفر وجدت سجل، لا يعني ذلك أن تطبيق الإنتاج الخاص بك استخدم عنوان "من" المقصود أو أن بوابة لاحقة احتفظت بالتوقيع. قم بجدولة إرسال متحكم فيه بعد التحقق والحفاظ على الرسالة الأصلية للمستلم، بما في ذلك جميع توقيعات DKIM .
أضف Return-Path المدعوم بشكل منفصل
استخدم اسم مضيف Return-Path المعروض في نفس إعدادات النطاق وهدف CNAME الخاص به، والموثق كـ pm.mtasv.net . قم بحجز اسم مضيف غير مستخدم لهذا الغرض. لا تضع SPF سجل TXT جنبًا إلى جنب مع CNAME بنفس اسم المالك، ولا تستبدل سجلاتك العليا بالسجل المرتد CNAME . تُظهر وثائق Postmark اختلافًا في تهجئة اسم المضيف الافتراضي، لذا فإن قيمة الحساب المباشر لها الأولوية على المثال المنسوخ. التحقق من المجال.
لا يتطلب Postmark وضعه في قمة العميل سجل SPF. يتبع فحص نظام التعرف على SPF نطاق المغلف الفعلي. لا يمكن لإضافة تضمين قمة تحويل Return-Path المملوك للموفر إلى مسار مملوك للعميل. Return-Path المخصص الموثق هو نطاق فرعي؛ ينصح Postmark بتخفيف عامل الحماية من SPF تنسيق لهذا الطريق. لم يتم إصلاح متطلبات SPF الصارمة عن طريق إضافة المزيد من التضمينات. احتفظ بالسياسة المعتمدة للنطاق واستخدم مسار DKIM متوافقًا تم التحقق منه حيثما كان ذلك مناسبًا. إرشادات Postmark SPF.
إثبات نتيجة الطلب
ما يلي هو تصميم قبول اصطناعي، وليس تسليمًا ملتقطًا. استبدل كل مثال بالقيمة المرصودة واحتفظ بالطابع الزمني للاختبار ومعرف الرسالة.
- الدليل: مرئي من؛ القيمة التوضيحية: receipts@example.com ؛ سؤال القبول: هل هذه هي هوية الطلب المعتمدة؟
- الدليل: مجال المغلف؛ القيمة التوضيحية: pm-bounces.example.com ؛ سؤال القبول: هل تم تنشيط Return-Path المخصص لهذه الرسالة؟
- الدليل: مجال توقيع DKIM ؛ القيمة التوضيحية: example.com ؛ سؤال القبول: هل قام المستلم الموثوق بالتحقق من صحة هذا التوقيع؟
- شهادة: DMARC; القيمة التوضيحية: تمرير؛ سؤال القبول: ما هي طريقة التمرير المحاذية التي أنتجت هذه النتيجة؟
- ra من نطاق example.com والنطاق الفرعي المرتد أسفله، يمكن أن تعمل محاذاة SPF المريحة بينما لا تعمل محاذاة SPF الصارمة. مرور المجال الدقيق توقيع DKIM لا يزال بإمكانه تلبية DMARC . تقييم التوقيع المرصود، وليس الوعد بتوقيع كل رسالة. محاذاة DMARC.
اختبر إيصالًا حقيقيًا وحدث إعادة تعيين كلمة المرور من خلال مسارات التطبيق الخاصة بكل منهما. قارن التدفقات وتكوين المرسل. إذا نجح أحدهما وفشل الآخر، فتحقق من المسار المتباين قبل تغيير DNS المشترك. لا تقم بإعادة إرسال الإيصالات المالية الحقيقية للعملاء كاختبار.
التشخيص والتعافي
في حالة غياب DKIM ، تأكد من أن مجال التطبيق من يطابق المجال الذي تم التحقق منه وأن التوقيع نشط. إذا كان التوقيع موجودًا لكنه فشل، فاحفظ سبب المستلم وتحقق من السبب الدقيق محدد البحث وأي ترحيل لتعديل المحتوى. إذا نجح نظام التعرف على هوية SPF ولكن لم تتم محاذاته، فافحص تنشيط Return-Path بدلاً من إضافة أذونات القمة. إذا فشل التحقق DNS ، فقم بمقارنة الإجابات الموثوقة وإكمال اسم المضيف ونوع السجل مع قيم الحساب.
قم بإيقاف تشغيل دفق التطبيق المتأثر مؤقتًا فقط في حالة فشل القبول. قم باستعادة السجل المحفوظ أو إعداد المرسل من خلال مالك التغيير، ثم أعد اختبار حدث متحكم فيه. لا تقم بإزالة محدد قديم بينما قد يظل البريد في قائمة الانتظار في حاجة إليه. يتم إيقاف التفويض المرتد غير المستخدم وتسجيل السجلات فقط بعد التأكد من عدم مشاركة أي تطبيق Postmark آخر لها. هذه المخطوطة مبنية على التوثيق؛ لم يتم اختبار أي مستأجر أو تغيير DNS أو التسليم المباشر.
قارن النتائج الصارمة والمريحة بشكل واضح
بالنسبة للحالة المكتوبة PM-01، افترض receipts@example.com ، البريد من bounce@pm-bounces.example.com وممر SPF موثوق به لـ pm-bounces.example.com . في ظل المحاذاة المريحة العادية لنفس المجال التنظيمي، تتم محاذاة مسار نظام التعرف على هوية SPF هذا؛ مع aspf=s لا يتطابق تمامًا example.com . افترض بشكل منفصل أن التوقيع المار d=example.com, s=demo1: يتوافق هذا المسار تمامًا ويمكن أن يلبي DMARC حتى في حالة نظام التعرف على هوية المرسل (SPF) الصارم. إذا أصبح DKIM غير معروف بدلاً من المرور، فلا تحتفظ بالتمرير بناءً على الفرضية السابقة. هذه مدخلات منصوص عليها، وليست تسليمًا Postmark تم التقاطه أو نصيحة لإضعاف السياسة.
الحفاظ على حدود التنفيذ
يتطلب القسم 7.4 RFC 9989 DKIM صالحًا، وليس نظام التعرف على SPF وحده، للنطاقات التي تنشر p=reject, ويحذر من إمكانية التشغيل التفاعلي للبريد غير المباشر والقائمة البريدية. إن نجاح اختبار واحد للرسائل المباشرة لا يشكل دليلاً على أن كل طريق مشروع جاهز لسياسة أقوى. احتفظ بالحماية المعتمدة الحالية أثناء تشخيص الفجوة الفعلية؛ أي تغيير في السياسة يحتاج إلى قرار خاص به.