يغير اسم النطاق المستعار كيفية استخدام العنوان أو استلامه داخل الخدمة. وهو لا يحدد في حد ذاته المجال الموضوع في الخارج توقيع DKIM. قبل استخدام اسم مستعار لبريد العميل، افحص الرسالة المرسلة عبر المسار المقصود وحدد الهوية التي توقعها الخدمة.
الاسم المستعار هو أيضًا مصطلح منتج مثقل. ويمكنه وصف عنوان صندوق بريد بديل أو مجال مرتبط بالمستأجر أو هوية المرسل على مستوى التطبيق. ينطبق سير العمل هذا على الرسالة الناتجة وأدلة DNS . راجع الوثائق الحالية لميزة الاسم المستعار المحددة قبل افتراض أنها تدعم الإرسال أو المجال المخصص DKIM.
فصل تكوين الاستلام عن هوية الإرسال
حدد أولاً الغرض من الاسم المستعار. العنوان الذي يتلقى الرسائل في صندوق بريد موجود قد لا يتم ترخيصه مطلقًا للاستخدام الخارجي. إذا كان الإرسال مدعومًا، فحدد ما إذا كانت الخدمة تحتفظ بالاسم المستعار في "من"، أو تعيد كتابته إلى العنوان الأساسي أو تقوم بتوجيهه عبر مرسل مختلف.
قم بتسجيل عنوان "من" المرئي بعد التسليم، وليس فقط العنوان المحدد في نافذة الإنشاء. قم أيضًا بتسجيل أي حقل مرسل وهوية المغلف، ولكن لا تخلط بينهما وبين مجال DKIM 'sd. RFC 6376 §3.5 يحدد مجال التوقيع d، والذي يختلف عن عنوان مؤلف الرسالة. RFC 9989 §4.4 يستخدم مجال المؤلف والمعرفات الموثقة لـ تنسيق.
قراءة كل توقيع على رسالة تسيطر عليها
أرسل اختبارًا من الاسم المستعار باستخدام نفس العميل أو واجهة برمجة التطبيقات أو مسار صندوق البريد المفوض كإنتاج. تصدير الرسالة المستلمة دون تحريرها. حدد كل DKIM-Signature وقيمتي d وs ونتائج المتلقي الموثوق به. يمكن للخدمة إضافة كل من توقيع الموفر وتوقيع مجال العميل؛ قد لا تكون الأداة الأولى التي تعرضها الأداة هي ذات الصلة DMARC.
لكل توقيع تمرير، قم بتقييم التوافق مع المجال المستلم. يحتاج الوضع الصارم إلى تطابق تام للنطاق ضمنه RFC 9989 §3.2.10. الوضع المريح يسمح بنفس الشيء المجال التنظيمي تحت RFC 9989 §4.10.2. لا يتوافق المجالان المسجلان المتميزان ببساطة لأن أحدهما اسم مستعار للآخر في بوابة الإدارة.
استخدم ورقة عمل هوية صغيرة
حالة توضيحية، مع افتراض نطاقات تنظيمية مميزة وسياسة DMARC سارية: العنوان الأساسي هو person@company.example ، بينما الاسم المستعار الصادر هو person@newbrand.example . يرى المتلقي من في newbrand.example وتوقيع مرور مع d=company.example. هذا التوقيع لا يتوافق مع newbrand.example . إذا كان توقيع تمرير آخر يستخدم d=newbrand.example, فإن هذا التوقيع الثاني يوفر مسار DKIM محاذيًا.
قم بتسجيل كلتا النتيجتين بدلاً من استدعاء الرسالة بأكملها بدون توقيع أو الإشارة إلى أن DKIM معطل. لا يزال التوقيع الصالح ضمن المجال الأساسي صالحًا DKIM . الخاصية المفقودة هي محاذاة الاسم المستعار. يقيم SPF بشكل منفصل قبل تعيين نتيجة DMARC الإجمالية. تعد ورقة العمل هذه مثالًا اصطناعيًا، وليست دليلاً على سلوك الاسم المستعار لأي خدمة.
اطلب العلاج المدعوم
اسأل ما إذا كان بإمكان الموفر توقيع البريد المستعار باستخدام النطاق المستعار، وما إذا كان ذلك يتطلب إضافة المجال كهوية إرسال مميزة. احصل على أسماء سجلات DNS الحالية وأنواع السجلات وقيمها. تحقق من من يتحكم في منطقة DNS وما إذا كان التغيير المقترح يتعارض مع التغيير الحالي محدد.
لا تقم بنسخ المفتاح العام للنطاق الأساسي يدويًا وتفترض أن الخدمة ستبدأ باستخدام قيمة d جديدة. لا يمكن لنشر DNS توجيه موقع عشوائي لتغيير الهوية. يجب أن يتفق تكوين الإرسال ومواد التحقق المنشورة.
احتفظ بالاسم المستعار في مراجعات دورة الحياة
كرر الاختبار للردود وعملاء الأجهزة المحمولة والرسائل التي ينشئها التطبيق عند استخدام تلك المسارات. احتفظ بخريطة من المحدد إلى الموفر مع مالك النشاط التجاري للاسم المستعار وعينة مؤرخة. عند الهجرة أو التقاعد، تأكد مما إذا كانت الهويات الأخرى لا تزال تعتمد على نفس الموفر قبل إزالة السجلات المفوضة.
يجب أن يوضح بيان الإغلاق الاسم المستعار والمسار الذي تم اختباره، والمجال d الذي تم تمريره وما إذا كان محاذيًا أم لا. إذا لم يتمكن المنتج من توفير الهوية المطلوبة، فقم بتوثيق هذا القيد واختيار تصميم إرسال مدعوم بدلاً من الإبلاغ عن الاسم المستعار على أنه مصادق عليه دون تأهيل.
سجل القرار التالي
استخدم صفًا واحدًا لكل مسار فعلي: الاسم المستعار المطلوب، المستلم من، كل زوج d/s، النتيجة الموثوقة، وضع المحاذاة، والفجوة المتبقية. يعد ممر المجال الأساسي مع اسم مستعار غير ذي صلة من DKIM صالحًا ولكنه غير محاذٍ DKIM . لا تعتبر الرسالة بأكملها فشل DMARC حتى يتم تقييم نظام التعرف على SPF والسياسة المعمول بها. لم يتم التأكيد هنا على إمكانية الاسم المستعار الخاص بالموفر أو النتيجة المباشرة.