حل ملكية الحساب قبل DNS
يتعلق هذا الدليل بنطاقات المرسل في Elastic Email Marketing وEmail API، ولا يتلقى البريد من خلال منتج Inbox الخاص به. ابدأ بالحساب المقصود، ومجال الإرسال، ومالك التطبيق، ومسؤول DNS المعتمد. تأكد من الحساب الذي يمتلك المجال حاليًا قبل إنشاء خطة نشر جديدة.
رسائل البريد الإلكتروني المرنة دليل التحقق من المجال يقول أنه يمكن ربط مجال المرسل بحساب واحد فقط للتسويق عبر البريد الإلكتروني أو واجهة برمجة تطبيقات البريد الإلكتروني في المرة الواحدة. إذا كان لديه حساب آخر، قم بحل هذه الملكية أولاً. يجب ألا يقوم المسؤول بحذف مجال إنتاج من حساب قديم دون تحديد التطبيقات التي لا تزال ترسل من خلاله. عندما يكون الوصول غير متاح أو لا يمكن للحساب إزالته، اتبع دعم الموفر وعملية التحقق من الملكية.
استخدم سير عمل التحقق من الحساب
المسار الموثق هو الإعدادات > النطاقات > إدارة النطاقات > بدء التحقق. حدد التحقق من المجال، وأدخل المجال الذي تملكه، وانشر السجلات المقدمة واستخدم التحقق من السجل. في تفاصيل المجال، قم بفحص حالات السجلات الفردية بدلاً من التعامل مع إدخال القائمة الإجمالي كدليل على أن كل ميزة اختيارية تعمل.
ل SPF، يحدد المزود include:_spf.elasticemail.com. قم بدمج التفويض اللازم في سياسة SPF TXT الحالية المعمول بها بدلاً من إنشاء سياسة ثانية. قم بمراجعة السياسة بأكملها، بما في ذلك الخدمات المعتمدة الأخرى وتكلفة بحث DNS . لا تنسخ آليات a أو mx واسعة النطاق من أحد الأمثلة ما لم تتطابق مع التفويض المقصود للنطاق.
ل DKIM، استخدم الاسم والقيمة الموضحين في قسم DKIM الحالي للحساب. يقوم Elastic Email بإنشاء زوج المفاتيح ونشر المكون العام من خلال DNS الخاص بك سجل TXT. برنامج تعليمي قديم محدد أو المفتاح العام ليس بديلا. إذا أبلغت الخدمة أنه لم يتم العثور على DKIM صالح، فقارن الإجابة الموثوقة بقيمة الحساب الحالي قبل تغيير السجلات غير ذات الصلة.
تعامل مع سلوك المرسل الافتراضي باعتباره خيارًا للسياسة
يصف الموفر العلامة التجارية الاحتياطية بناءً على ما إذا كان مجال المرسل الافتراضي موجودًا ويلاحظ أن الحسابات الفرعية يمكن أن ترث استخدام مجال المرسل الافتراضي الذي تم التحقق منه للحساب الرئيسي. سجل الخيار الافتراضي الذي تم تحديده وما إذا كان هذا الميراث مناسبًا للتطبيقات التي تستخدم الحساب. التحقق من النطاق وترخيص التطبيق ليسا نفس القرار الإداري.
لا تعتمد على السلوك الاحتياطي لجعل النطاق "من" غير المعتمد مقبولاً. اطلب من كل تطبيق إنتاج استخدام هويته المعتمدة واختبار ما تم تسليمه بالفعل. يمكن للنظام الأساسي إرسال رسالة بنجاح باستخدام مجال غير متوقع، والذي يختلف من الناحية التشغيلية عن إكمال إعداد المجال المخصص المقصود.
تتبع منفصل وتوجيه البريد عن التوقيع
تكشف تفاصيل المجال أيضًا عن التتبع و MX و DMARC حالة. قم بمراجعة الغرض من كل سجل قبل النشر. تتبع CNAME مخاوف الارتباط السلوك؛ لا تعد تعليمات MX الخاصة بنطاق المرسل إذنًا شاملاً لاستبدال توجيه البريد الوارد للمؤسسة. الحفاظ على سياسة DMARC الحالية على مستوى النطاق ما لم يوافق مالكها على تغيير متعمد بناءً على جميع المرسلين الشرعيين.
تصميم الاختبار الأصلي: استخدم رسالة تطبيق غير ضارة، واختبار حساب فرعي واحد حيثما كان ذلك مناسبًا. سجل الهوية المطلوبة من، الحساب المحدد/الافتراضي، المستلم الفعلي من، مرسل المغلفومجال DKIM والمحدد ونتائج مصادقة جهاز الاستقبال. يتطلب DMARC نتيجة تمرير SPF أو DKIM تتماشى مع العنصر المرئي من. قارن الهوية المقصودة بالهوية المستلمة قبل تحديد ما إذا كان الرجوع مقبولاً أم لا.
التشخيص والاسترداد في الطبقة الفاشلة
سيناريو توضيحي: يتطابق DNS تمامًا مع مفتاح الحساب الجديد، ولكن لا يزال التطبيق القديم يقدم من خلال حساب مختلف. لن يؤدي استبدال نفس المفتاح العام بشكل متكرر إلى إصلاح عدم تطابق التوجيه. قم بتأكيد حساب التطبيق وارتباط المجال، ثم اختر مسار الترحيل أو الاستعادة المعتمد.
حفظ الإعدادات والسجلات السابقة. قم بإيقاف التطبيق المتأثر مؤقتًا أثناء مشكلة الملكية أو الهوية التي لم يتم حلها، ثم قم باستعادة آخر تكوين معتمد حيثما أمكن ذلك. أعد التحقق بعد ترحيل الحساب أو تغييرات المجال الافتراضي أو استبدال المفتاح. تمت مراجعة الوثائق في 8 نوفمبر 2026؛ لم يتم اختبار أي حساب أو سجل DNS أو رسالة مستلمة هنا.
قرر نقل الحساب قبل إعادة إنشاء المفاتيح
تفترض الحالة المكتوبة EE-01 أن receipts@example.com تنتمي إلى تطبيق استلام نشط في الحساب القديم، بينما يحاول فريق جديد التحقق من example.com في الحساب الجديد. يُبلغ الحساب الجديد عن وجود تعارض في الملكية؛ نتائج DNS والرسائل الحالية غير معروفة. يجب على مالك التطبيق جرد القديم قبل الموافقة على النقل المنسق. إن إزالة النطاق فقط لمسح تحذير "الجديد" يعرض المسار الحالي للخطر. يجب على المشغل حل مشكلة الوصول أو اتباع عملية دعم التحقق من ملكية الموفر، مع الحفاظ على التكوين الحالي الدقيق وقرار الاسترداد. لم تحدث هنا أي إزالة للحساب أو جهة اتصال للدعم أو تغيير DNS . بعد النقل المعتمد، اطلب إيصالًا مراقبًا به هوية التوقيع المقصودة والفعلية، وليس مجرد شارة تم التحقق من نطاقها.
الحفاظ على حدود التنفيذ
RFC 9989 يتطلب القسم 7.4 DKIM صالحًا، وليس نظام التعرف على SPF وحده، لنشر النطاقات p=reject، ويحذر من إمكانية التشغيل التفاعلي للبريد غير المباشر والقائمة البريدية. إن نجاح اختبار واحد للرسائل المباشرة لا يشكل دليلاً على أن كل طريق مشروع جاهز لسياسة أقوى. احتفظ بالحماية المعتمدة الحالية أثناء تشخيص الفجوة الفعلية؛ أي تغيير في السياسة يحتاج إلى قرار خاص به.