محاذاة DMARC: التحقق من SPF وDKIM وFrom

قد تغفل الفرق محاذاة DMARC بعد نشر SPF وDKIM وسجل DMARC. إذا استمر تصنيف البريد كمزعج أو رفضه، فافحص المحاذاة والأسباب الأخرى؛ ليست المحاذاة التفسير الوحيد. راجع أيضا دليل بريد العمل.

نجاح المصادقة وحده لا يكفي. يجب أن يحاذي نطاق SPF أو DKIM الناجح نطاق From الظاهر. يفشل DMARC إن لم توجد مصادقة ناجحة ومحاذية، لكن ذلك لا يثبت الانتحال. قد تسبب الخدمات الخارجية وCRM والدعم وإعادة التوجيه والإعدادات الناقصة النتيجة نفسها.

يشرح الدليل المحاذاة وحدود SPF والترويسات المعنية واختبار مسارات الإرسال وإعادة التوجيه الفعلية.

ما هي محاذاة DMARC؟

تقارن نطاق المصادقة في SPF أو DKIM بنطاق From الظاهر. ينجح DMARC إذا نجحت SPF مع المحاذاة أو نجحت DKIM مع المحاذاة. يكفي نجاح محاذ واحد، ويفشل دون ذلك.

هذه قاعدة RFC 7489. لا يستبدل DMARC المصادقة، بل يربط نجاحها بالنطاق الذي يراه المستقبِل في From.

الفحوص الأساسية:

نجاح SPF أو DKIM دون المحاذاة لا يكفي. المطلوب نجاح آلية محاذية.

DMARC pass = (SPF pass + SPF aligned) OR (DKIM pass + DKIM aligned)

لماذا تنجح SPF ولا تتحقق المحاذاة؟

قد ينتمي Return-Path للمزود، فيكون IP مصرحا له وتنجح SPF دون محاذاة لنطاقك. يمكن أن يحدث ذلك مع SendGrid أو Mailchimp أو HubSpot أو Shopify. وقد ينجح DMARC رغم ذلك إن نجحت DKIM المحاذية.

يدير المزودون الارتدادات وقوائم منع الإرسال والتتبع، ولذلك تستخدم بعض إعداداتهم Return-Path بنطاق المزود.

From الظاهر: billing@example.com
Return-Path: bounces+123@sendgrid.net

قد تنجح SPF بسبب تفويض IP لنطاق sendgrid.net. لكنه لا يوفر محاذاة SPF لأن sendgrid.net لا يحاذي example.com.

اضبط نطاق ارتداد مخصصا أو Return-Path مخصصا حيث يدعمه المزود. تخصيص الروابط ونطاق التتبع ليسا تلقائيا الوظيفة نفسها؛ تحقق من مرسل المغلف الفعلي.

bounces.example.com.   CNAME   u1234.wl.sendgrid.net.

بعد تفعيل المزود والاختبار، يمكن استخدام bounces.example.com في المغلف. يحاذي ذلك example.com في الوضع المرن. نشر CNAME وحده لا يثبت تفعيل الإعداد.

تغير إعادة التوجيه الخادم المتصل وقد تفشل SPF الأصلية. راجع إعادة توجيه بريد النطاق إلى Gmail وإعادة توجيه العناوين البديلة. قد تكفي SPF في المسار المباشر إن نجحت وحاذت، لكن اختبر المسارات الأخرى منفصلة.

لماذا تهم محاذاة DKIM؟

قد يصمد DKIM عند إعادة التوجيه إذا بقي التوقيع صالحا ومحاذيا وحفظت البيانات الموقعة وفق الصياغة القياسية. لا يضمن كل مسار إعادة توجيه ذلك.

لذلك يعد DKIM المحاذي خيارا تشغيليا مهما، لكنه ليس شرطا بروتوكوليا لـ DMARC إذا نجحت SPF المحاذية. توقيع المزود لا يحقق تلقائيا محاذاة نطاقك.

From الظاهر: newsletter@example.com
توقيع DKIM: d=mailchimpapp.net

قد ينجح DKIM دون محاذاة. يفشل DMARC فقط إن لم توجد أيضا SPF ناجحة ومحاذية.

فعّل مصادقة النطاق لدى المرسل الفعلي: انشر سجلات DKIM المطلوبة وتحقق من تفعيل المزود للتوقيع الصحيح.

s1._domainkey.example.com.   CNAME   s1.domainkey.u1234.vendor.net.
s2._domainkey.example.com.   CNAME   s2.domainkey.u1234.vendor.net.

قد يوقع الإعداد الفعال بـ d=example.com أو نطاق مناسب مثل d=mail.example.com. يدعم ذلك DMARC عند فشل SPF فقط إن بقي التوقيع صالحا واستوفى نمط المحاذاة المختار.

تطلب Google من المرسلين بكميات كبيرة محاذاة From عبر SPF أو DKIM مع متطلبات المصادقة المعنية. تحقق من فئتك والنتائج الفعلية؛ لا يتنبأ خطأ المحاذاة وحده بكل حالات التصفية أو التقييد.

المحاذاة المرنة والصارمة

تقارن المرنة النطاقات التنظيمية، وتتطلب الصارمة تطابق النطاق تماما. المرنة هي الافتراضية، لكن الاختيار المناسب يعتمد على المصادر ومتطلبات الإدارة.

تضبط aspf محاذاة SPF وadkim محاذاة DKIM.

مثال:

_dmarc.example.com. TXT "v=DMARC1; p=none; aspf=r; adkim=r; rua=mailto:dmarc@example.com"

مع المحاذاة الصارمة لا يحاذي التوقيع بنطاق mail.example.com عنوان From في example.com. هذا اختلاف في شروط النمط، لا دليل على الإساءة.

اختر الصارمة لحاجة مدروسة ومع رقابة كافية على المصادر. وإلا فقيّم المرنة واختبر المسارات المهمة.

التحقيق في محاذاة DMARC

افحص Authentication-Results المستلمة وDKIM d= وSPF smtp.mailfrom ونتيجة dmarc المرتبطة بـ header.from. ثق فقط بنتائج أضافتها بنية الاستقبال الموثوقة، لا بترويسات عشوائية ضمن الرسالة.

تساعد هذه النتائج على تحديد الخلل. لا تثبت header.i في المثال التالي نطاق توقيع DKIM؛ تعتمد DMARC على d= في التوقيع الذي تم تقييمه.

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sendgrid.net header.s=s1;
  spf=pass smtp.mailfrom=bounces+123@sendgrid.net;
  dmarc=fail header.from=example.com

افحص بالترتيب:

1. راجع header.from لمعرفة نطاق المرسل الظاهر.
2. راجع smtp.mailfrom؛ نطاق مزود غير محاذ لا يحقق محاذاة SPF.
3. ليست header.i معيار DMARC؛ تحقق من d= في التوقيع الصالح.
4. إذا لم تحاذ أي مصادقة ناجحة، يفشل DMARC ولو نجحت SPF وDKIM منفصلتين.

افحص DNS أيضا:

dig +short TXT _dmarc.example.com
dig +short TXT example.com
dig +short CNAME s1._domainkey.example.com

قد يكون فشل SPF في إعادة التوجيه من خصائص المسار. يساعد DKIM الصالح والمحاذ، لكن نجاح DKIM وحده لا يكفي، وDNS لا يثبت نتائج كل الرسائل الفعلية.

للإعداد الجديد راجع دليل إعداد النطاق وإنشاء بريد على نطاقك. استخدم SPF واحدا مناسبا واختبر DKIM وDMARC. لا تحذف MX أو سجلات قديمة إلا بعد التحقق من استخدامها.

أنماط فشل المحاذاة الشائعة

حقق في الإرسال الخارجي وإعادة التوجيه والنطاقات الفرعية المختلفة والسجلات المكررة أو القديمة. النمط قرينة، لا بديل عن الفحص.

حالات متكررة:

1. نطاق ارتداد للمزود: تنجح SPF دون محاذاة، وقد تدعم DKIM نجاح DMARC.
2. توقيع المزود: تنجح DKIM دون محاذاة، وقد تدعم SPF نجاح DMARC.
3. إعادة التوجيه: قد تفشل SPF، وتساعد DKIM إن بقيت صالحة ومحاذية.
4. نمط صارم غير مقصود: لا تحاذي النطاقات الفرعية المختلفة.
5. سجلات قديمة: تحقق من المسارات والتوقيع الفعلي؛ DNS لا يفعّل تلقائيا جهة توقيع خاطئة.

عند ظهور 4.7.32 أو رد Gmail مشابه يتعلق بمحاذاة From، افحص نتائج المصادقة والمتطلبات المعنية. راجع إرشادات مرسلي Google.

إدارة المحاذاة مع TrekMail

قد يجمع TrekMail الصناديق وحالة DNS وخيارات الإرسال. يساعد ذلك على تنظيم تحقيق موزع بين خمس لوحات، لكنه لا يغني عن حصر المصادر والاختبارات.

مقارنة إدارية:

إدارة متفرقة أم مترابطة

قد يتوفر SMTP المدار وفقا للخطة المدفوعة. ومع SMTP الخاص بك تربط مزودا فعليا مثل SES أو SendGrid أو Mailgun وتتحقق من متطلباته. في الحالتين تحتاج إلى DNS مناسب ونجاح محاذ فعلي، لا حالة خضراء فقط.

مراجع مفيدة:

يشرح وصول رسائلي إلى البريد المزعج نتائج إعادة التوجيه. وتوضح إعدادات IMAP & SMTP إعداد العملاء. نجاح تسجيل الدخول لا يعني نجاح DMARC للبريد الصادر.

السعر الابتدائي المذكور لـ Starter هو $3.50 شهريا. التجربة المجانية الموصوفة للخطط المدفوعة مدتها 14 يوما، وتتطلب بطاقة ائتمان لبدئها. توصف Nano بأنها مجانية مع SMTP يوفره المستخدم وحتى 10 نطاقات و5 GB من المساحة المشتركة. تحقق من الأسعار والميزات والشروط الحالية في أسعار TrekMail. ينسخ ترحيل IMAP الرسائل المدعومة، لا MX أو كل بيانات التطبيقات تلقائيا.

قائمة التحقق النهائية للمحاذاة

احرص على SPF أو DKIM ناجح ومحاذ لكل مصدر مشروع، وكليهما حيث يمكن. يدعم ذلك إدارة المخاطر دون ضمان سلامة التقييد أو بقاء كل مسار إعادة توجيه أو التسليم.

1. احصر البريد وCRM والفوترة والدعم والمتجر والنماذج والتسويق.
2. تحقق من نطاق From الظاهر لكل مصدر.
3. تحقق من تفويض SPF ومحاذاة Return-Path.
4. اضبط توقيع DKIM المناسب واختبره.
5. استخدم aspf=r وadkim=r ما لم تتطلب احتياجاتك المدروسة نمطا آخر.
6. اختبر Gmail والمستقبِلين المعنيين، وافحص Authentication-Results الموثوقة.
7. احتفظ عادة بـ p=none إلى أن تحقق بما يكفي في المصادر والمسارات المهمة؛ التصفية المحلية ممكنة.
8. قيّم التقييد بتقارير جزئية وسجلات واختبارات وخطة للتراجع. الفشل ليس تصنيفا تلقائيا للانتحال؛ اختبر التدفقات النادرة أيضا.

تربط المحاذاة المصادقة بالنطاق الظاهر، لا بسلامة المحتوى أو شرعية مؤكدة. قارن خيارات إدارة النطاقات والتكاليف الحالية على TrekMail.