توثيق بريد العمل باستخدام SPF وDKIM وDMARC
· PoolByte
يجب أن تخرج الرسالة المرسلة من عنوان البريد الإلكتروني للشركة فعليًا من النظام المعتمد من قبل الشركة. ومع ذلك، فإن ظهور اسم العلامة التجارية في سطر العنوان لا يثبت ذلك وحده. إن نظام التعرف على هوية المرسل (SPF) وDKIM وDMARC هي طرق تحقق تكمل بعضها البعض. يُسهل الإعداد الصحيح التحقيق في مشكلات التسليم والحد من الاستخدام غير المصرح به للنطاق؛ لا يضمن وصول جميع الرسائل إلى صندوق الوارد الخاص بك.
الأمثلة في هذا الدليل هي للأغراض التعليمية فقط. استبدل example.com ونموذج معلومات المرسل باسم النطاق الخاص بك والسجلات المقدمة من مزود الخدمة الخاص بك. إذا كانت أنواع السجلات غير مألوفة بالنسبة لك، فراجع أولاً دليل سجلات DNS.
قم أولاً بإدراج جميع المرسلين
لا يجوز للشركة إرسال رسائل من تطبيق البريد الإلكتروني لموظفيها فقط. قد يستخدم أيضًا نموذج الاتصال الخاص بموقع الويب وإشعارات الطلبات وبرامج المحاسبة ومكتب الدعم ونظام التسويق نفس اسم النطاق. أولاً، قم بتدوين من يدير هذه الأنظمة، وعنوان الشاحن الظاهري، ومزود الشحن الفعلي.
على سبيل المثال، إذا كان الموظفون يستخدمون خدمة البريد الإلكتروني، ويستخدم موقع الويب حساب SMTP منفصلاً، وتستخدم الحملات منصة ثالثة، فيجب فحص جميع التدفقات الثلاثة. قد يؤثر تشغيل سياسة DMARC الصارمة من خلال اختبار إرسال الموظفين فقط على رسائل الطلب. إذا لم يعد الموفر القديم مستخدمًا، فاسأل عن سبب الاحتفاظ به في السجل؛ ينبغي مسح التراخيص غير الضرورية.
SPF: الإذن الممنوح لمصدر الإرسال
يحدد نظام التعرف على هوية المرسل (SPF) عبر DNS الأنظمة التي يمكنها إرسال الرسائل نيابة عن اسم النطاق المستخدم في إرسال SMTP. لا يجب أن يكون عنوان From الخاص بالبريد الإلكتروني الذي يظهر للمستلم هو نفس العنوان الذي يقوم نظام التعرف على هوية المرسل (SPF) بتقييمه. يعد هذا التمييز مهمًا لفهم محاذاة DMARC.
لا تنشر عدة سجلات SPF منفصلة بنفس الاسم. عند تغيير مقدم الخدمة، يتم دمج التراخيص القديمة والجديدة في سجل واحد، إذا لزم الأمر. يحدد معيار SPF العدد الإجمالي لتقييمات المصطلحات include وa وmx وptr وexists وredirect التي تتطلب بحث DNS بما يصل إلى عشرة، بما في ذلك سلاسل include التابعة. إذا تم تجاوز هذا الحد، فقد يحدث permerror؛ الحد ليس عدد كافة استعلامات DNS الفعلية. لا تتحقق بمجرد النظر إلى النص.
بالنسبة لخادم الإرسال الافتراضي، قد يبدو السجل كما يلي:
example.com TXT "v=spf1 ip4:192.0.2.10 -all"وهذا محجوز لأمثلة وثائق الملكية الفكرية؛ لا ينبغي أن يتم نسخها إلى التكوين المباشر. إذا كان مزود الخدمة الخاص بك يتطلب include، فاستخدم قيمته الحالية. لا يحل سجل SPF محل سجل MX الذي يعيد توجيه البريد الوارد.
DKIM: النظام الذي يقوم بتوقيع الرسالة
يقوم DKIM بتوقيع الرسالة المرسلة بمفتاح خاص؛ يبحث المستلم عن المفتاح العام المقابل في DNS. يجب استخدام المحدد واسم السجل وقيمة المفتاح المقدمة من قبل الموفر معًا. يكون اسم السجل عادةً بالتنسيق secici._domainkey.example.com. تتطلب بعض الخدمات الإشارة إلى CNAME إلى بنيتها التحتية بدلاً من TXT؛ اتبع تعليمات اللوحة.
لا يتم وضع المفتاح الخاص في DNS أو منشور المدونة. قد يستخدم عدة مرسلين محددات مختلفة. يعد نشر المحدد الجديد في تبادل المفاتيح والتحقق من صحته من الإرسال أسلوبًا أكثر تحكمًا من حذف المحدد القديم على الفور. بمجرد اكتمال الترحيل، أنشئ مهمة منفصلة لإزالة التفويضات القديمة.
DMARC: المحاذاة مع المرسل المرئي
يقوم DMARC بتقييم ما إذا كان نطاق المرسل الظاهري متوافقًا بشكل صحيح مع النطاق الذي تم التحقق منه بواسطة نظام التعرف على هوية المرسل (SPF) أو DKIM. ليس من الضروري أن تنجح كلتا الطريقتين في نفس الوقت؛ قد يكون نجاح SPF المحاذاة أو نجاح DKIM المحاذاة كافياً. مجرد رؤية "اجتياز" نظام التعرف على هوية المرسل (SPF) على شاشة الاختبار لا يعني أنه تم اجتياز DMARC.
من أجل إجراء الملاحظات مع التقارير أثناء التثبيت الأول، يمكن اعتبار سجل مثل ما يلي:
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]"يجب أن يعمل عنوان التقرير بالفعل. إذا كنت تستخدم نطاق تقارير مؤسسة أخرى، فراجع وثائق الخدمة لمعرفة أي تفويض إضافي مطلوب. p=none هي سياسة المراقبة؛ لا يريد DMARC رفض الرسائل الفاشلة بسبب هذه السياسة. بمجرد التحقق من المرسلين الشرعيين، يتم تقييم quarantine أو reject. تقوم أنظمة الاستقبال أيضًا بتنفيذ قراراتها الخاصة.
كيف يمكنك التحقق من التغيير؟
- احصل على نسخة مؤرخة من سجلات DNS الحالية.
- إعداد رسالة اختبارية مختلفة لكل نظام شحن.
- أرسل الرسالة إلى خدمات المستلمين المختلفة وراجع العناوين الكاملة.
- احفظ نتيجة نظام التعرف على هوية المرسل (SPF)، واسم النطاق في توقيع DKIM، ونتيجة DMARC بشكل منفصل.
- قم بالقياس مرة أخرى بعد التغيير، مع مراعاة أوقات ذاكرة التخزين المؤقت لنظام أسماء النطاقات.
- فحص المصادر غير المعروفة في التقارير؛ لا تقم بتوفير كل الموارد الفاشلة تلقائيًا.
لا تحتاج إلى إرسال بيانات أو فواتير حقيقية للعملاء للاختبار. إن كتابة اسم التدفق في سطر الموضوع، على سبيل المثال "اختبار التحقق من صحة نموذج الاتصال"، سيمنعك من الخلط بين النتائج. نظرًا لأن ملفات التقارير قد تحتوي على معلومات تشغيلية، قم بتقييد الوصول إليها وتعيين فترة للاحتفاظ بها.
الأسئلة المتداولة
إذا كان هناك ثلاثة سجلات، فلماذا ينتهي بها الأمر في مجلد البريد العشوائي؟
يتم أيضًا تقييم المحتوى وشكاوى المشتري وعادات الشحن وسمعة المرسل. على الرغم من أن المصادقة هي أساس مهم، إلا أنها ليست بديلاً عن الاتصال المعتمد والإدارة السليمة للقائمة.
هل يجب إعادة إنشاء السجلات عند نقل اسم النطاق؟
إذا كانت خدمة DNS الرسمية تتغير، فمن الضروري التحقق من سجلات MX وSPF وDKIM وDMARC الموجودة في المنطقة الجديدة. مجرد تغيير عنوان IP لخادم الويب لا يتطلب تغيير جميع سجلات البريد الإلكتروني.
ما هي المعلومات التي يجب أن أقدمها لفريق الدعم أثناء التثبيت؟
يعد اسم النطاق وخدمات الشحن المستخدمة ووقت الاختبار الفاشل والعناوين التي تم مسح البيانات الشخصية بمثابة بداية كافية. لا تشارك كلمات المرور أو المفاتيح الخاصة. يمكنك مراجعة خيارات اسم النطاق والاتصال بنا من صفحة الاتصال لتقييم التكوين.