DMARC fail: فحص الترويسات والمحاذاة وSPF

تعني DMARC fail عدم وجود مصادقة ناجحة ومحاذية لنطاق From. تطلب p=reject الرفض، وتطلب p=quarantine معاملة مشبوهة. قد يطبق المستقبِل استثناءات، ولا يضمن ذلك مجلد بريد مزعج معينا. افحص الإعداد وأسباب التسليم الأخرى أيضا. راجع بريد الشركات الصغيرة للسياق الأشمل.

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

يوفر الدليل جدول فرز وخطوات تحقيق وأمثلة إعداد. لا يصلح تغيير DNS واحد كل حالات الفشل تلقائيا.

ما معنى DMARC fail؟

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

ينجح البريد عندما تنجح SPF أو DKIM مع محاذاة النطاق لنطاق RFC5322 From. راجع RFC 7489. لا يثبت ذلك سلامة المحتوى.

الخطوة 1: فحص المحاذاة أولا

قد يصادق المزود نطاقه بنجاح دون محاذاة لنطاقك الظاهر. تحقق من النطاق الذي نجح، لا من النتيجة وحدها.

مثال:

Header From: support@yourdomain.com
Return-Path: bounces.vendor.net
DKIM: d=vendor.net

قد تظهر spf=pass وdkim=pass ويفشل DMARC لأن vendor.net لا يحاذي yourdomain.com، ولا توجد مصادقة ناجحة ومحاذية أخرى.

تحقق لدى التسويق وCRM والدعم وSMTP البديل من مصادقة النطاق وReturn-Path أو نطاق ارتداد مخصص وDKIM مناسب. تخصيص الروابط أو نطاق التتبع لا يغير نطاق المغلف تلقائيا.

أمثلة توضيحية؛ استخدم قيم المزود الفعلية وفعّل الإعداد واختبره:

Type: CNAME
Host: bounces
Value: yourvendor.example.net

Type: CNAME
Host: k1._domainkey
Value: dkim1.yourvendor.example.net

Type: CNAME
Host: k2._domainkey
Value: dkim2.yourvendor.example.net

قد يساعد TrekMail على تجميع إعدادات النطاق. راجع إضافة نطاق وسجلات DNS المطلوبة. استخدم SPF واحدا لكل نطاق مغلف معني، ولا تضف كل خدمة آليا إلى السجل نفسه.

الخطوة 2: التحقيق في الترويسات المستلمة

افتح مصدر الرسالة وابحث عن Authentication-Results وReturn-Path ونطاقات DKIM d=. ثق بنتائج بنية الاستقبال الموثوقة فقط، لا بالترويسات العشوائية التي تحملها الرسالة.

ترتيب الفحص:

1. حدد نطاق From الظاهر.
2. افحص نتيجة SPF.
3. حدد نطاق المغلف الذي قيّمته SPF.
4. افحص نتيجة DKIM.
5. حدد d= في التوقيع الصالح الذي تم تقييمه.
6. قارن النطاقين مع From بحسب النمط المختار.

مثال ترويسة للفشل:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sendgrid.net header.s=s1;
  spf=pass smtp.mailfrom=bounces.sendgrid.net;
  dmarc=fail (p=reject) header.from=yourdomain.com

اقرأه كما يلي:

تنجح SPF لنطاق ارتداد تحت sendgrid.net. لا تثبت header.i عند sendgrid.net نطاق توقيع DKIM؛ تحقق من d= في التوقيع. نطاق From هو yourdomain.com. يشير الفشل هنا إلى غياب مصادقة ناجحة ومحاذية.

كرر التحقيق لكل تدفق؛ قد تختلف الرسائل المعاملاتية والتسويق والدعم والعناوين البديلة. راجع إعداد البريد على نطاقي.

الخطوة 3: التحقيق في إعادة التوجيه منفصلة

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

لا تحكم من فشل SPF وحده في Google Groups أو Outlook أو مسارات الجامعات. قد ينجح DMARC بفضل DKIM صالح ومحاذ، لذا اختبر المسار الحقيقي.

يشرح RFC 7960 حفظ مرسل المغلف أو إعادة كتابته. قد يفشل SPF عند الحفظ، ولا تضمن إعادة الكتابة، ومنها SRS، محاذاة From الأصلي. راجع RFC 7960.

زيادة تفويضات SPF عشوائيا ليست حلا عاما. قيّم الآتي:

1. اضبط DKIM واختبره في التدفقات المدعومة.
2. قيّم المحاذاة المرنة للنطاق التنظيمي، واختر الصارمة لحاجة مدروسة فقط.
3. حقق في تعديلات القوائم التي تفسد التوقيع؛ قد تدعم ARC استثناء محليا، لا نجاح DMARC مضمونا.

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

الخطوة 4: التحقيق في SPF PermError

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

مثال SPF موسع:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mail.zendesk.com include:sendgrid.net include:servers.mcsv.net ~all

لا تثبت القائمة الظاهرة صحة التقييم؛ افحص includes المتداخلة وredirects على المسار الفعلي.

استعلم عن القيم المنشورة:

dig +short txt yourdomain.com
nslookup -type=txt yourdomain.com

الاستعلام وحده لا يثبت PermError. حتى المزود الذي لم تستخدمه منذ ستة أشهر لا تحذفه قبل التأكد من غياب تدفقات تحتاج إليه. قد يكون التقسيم مناسبا:

marketing.yourdomain.com
support.yourdomain.com
billing.yourdomain.com

ينطبق حد SPF مستقل على نطاق المغلف المستخدم فعليا بعد تفعيل إعداد المزود. نشر DNS لنطاق فرعي وحده لا يغير مسار الإرسال. اختبر التفويض ومحاذاة From بعد التغيير.

تتناول مراجعة حالة DNS في TrekMail سجلات SPF المكررة والتحقق من القيم.

الخطوة 5: التحقيق في احتمال الإساءة

ليس كل فشل بحاجة إلى تعديل DNS. قد يكون إرسالا غير مصرح أو خطأ في مسار مشروع؛ الفشل ليس تصنيفا تلقائيا للانتحال.

IP مجهول مع فشل SPF وDKIM يستدعي التحقيق، لا السماح أو الحظر الأعمى. راجع المصادر والمرحلّات وإعادة التوجيه. تطلب p=quarantine وp=reject معالجة عند الفشل مع بقاء قرار محلي للمستقبِل.

قرر بناء على الأدلة:

1. حقق في IP والمزود المجهولين بحصر المصادر والسجلات والاختبارات.
2. أكد المرسل الفعلي ومصادقة النطاق للبريد المشروع.
3. فعّل DKIM واختبره إن كان مدعوما ومفقودا.
4. افحص القيود قبل نقل تدفق إلى نطاق فرعي أو استبدال الأداة، واختبر المغلف الفعلي والمحاذاة.

قد تؤثر سياسة التقييد المنطبقة في أخطائك مهما كانت نيتك، مع احتمال استثناءات محلية. راجع إرشادات Google لمصادقة المرسلين.

أنماط شائعة بحسب المصدر

نوع النظام قرينة توجه التحقيق، لا دليل كاف لتحديد السبب.

إدارة الفشل عبر نطاقات كثيرة

تحتاج Google Workspace وcPanel وSendGrid وإعادة توجيه Gmail لدى العملاء إلى إعدادات حالية خاصة بكل حالة. يزيد DNS غير الواضح صعوبة التحقيق المتكرر.

قد تساعد بيئة مشتركة في متابعة حالة النطاق والتوجيه وSMTP وسجلات المصادقة. اللوحة ليست دليلا على نتائج جميع الرسائل الفعلية.

السعر الابتدائي المدفوع المذكور لـ TrekMail هو $3.50 شهريا، مع تجربة مجانية موصوفة لمدة 14 يوما وخيار مجاني يستخدم SMTP يوفره المستخدم. النطاقات والصناديق وcatch-all والتوجيه وترحيل IMAP وAPI والمساعدة في الإعداد خاضعة لشروط الخطط الحالية. ينسخ IMAP الرسائل المدعومة؛ MX وبيانات التطبيقات يحتاجان إلى عمل مستقل.

مع نطاقات عملاء كثيرة، راجع استضافة البريد متعدد النطاقات وقارن العمليات والتكاليف الفعلية.

قائمة تحقيق مختصرة

ابدأ برسالة محددة ونتائج موثوقة، وقارن نطاقات المصادقة مع From ثم أصلح المشكلة المثبتة.

1. افحص Authentication-Results الموثوقة في الرسالة.
2. حدد نتيجة SPF ونطاق المغلف.
3. حدد نتيجة DKIM ونطاق d= الصالح.
4. قارن مع Header From.
5. أصلح المحاذاة إن لم تحاذ أي آلية ناجحة.
6. اختبر DKIM الصالح والمحاذ وحفظ البيانات الموقعة عند التوجيه.
7. حقق في تقييم SPF وتقسيم المغلف الفعلي عند الحاجة.
8. حقق في المصادر المجهولة بالسجلات والاختبارات، ولا تصنفها من الفشل وحده.

ترتيب واضح يساعد على اختيار تعديلات تستند إلى الأدلة.

الخلاصة: إصلاح السبب المثبت

قد تنتج DMARC fail عن محاذاة خاطئة أو DKIM لم يحفظ عند التوجيه أو SPF PermError أو إرسال غير مصرح. لا يثبت الفشل وحده الإساءة ولا يتنبأ بالتسليم.

أصلح السبب المدروس بدلا من إضافة سجلات عشوائية. قد يقدم TrekMail مساحة مشتركة ونطاقات متعددة وSMTP خاصا في Nano أو مدارًا وترحيل IMAP بحسب الخطة. تحقق من الخيارات الحالية على TrekMail أو قارن الخطط في https://trekmail.net/pricing، واستمر في اختبار التدفقات المشروعة النادرة.