تظهر بلاغات فشل DMARC أحياناً بعد أن تظن أنك أنهيت الإعداد الأصعب. نشرت SPF وDKIM، ثم انتقلت بسياسة DMARC إلى p=quarantine أو p=reject. لكن رسالة حقيقية يعاد توجيهها فلا تصل. قد لا تكون انتحالاً أو رسالة مزعجة؛ ربما سلكت مساراً أخل بالمصادقة. السياسة تطلب معاملة معينة، لكن جهة الاستقبال تقرر الإجراء الفعلي.
هذه هي صعوبة فشل DMARC أثناء إعادة التوجيه. تكون الرسالة مشروعة، إلا أن المرحلة الوسيطة تغير سياق التسليم بحيث لا يرى المستلم النهائي مؤشرات الثقة الأصلية. إذا تعاملت مع SPF وDKIM كخانتين اكتمل ضبطهما، فقد تبدو المشكلة عشوائية. فحص المسار والنطاقات يساعد على كشف نمطها واختيار معالجة مناسبة.
إذا احتجت إلى أساس الإعداد الأوسع، فابدأ بدليل البريد الإلكتروني للأعمال. وإذا كنت تستخدم إعادة التوجيه بالفعل، فاقرأ أيضاً دليل إعادة توجيه البريد.
ما المعنى الفعلي لفشل DMARC؟
يعني فشل DMARC أن الرسالة لم تحقق نجاح SPF المتطابق مع نطاق From الظاهر، ولا نجاح DKIM المتطابق معه. اجتياز المصادقة وحده لا يكفي: يراجع DMARC العلاقة بين نطاق المصادقة والنطاق الذي يراه المستلم وفق نمط التطابق المختار.
يعتمد DMARC على SPF وDKIM. ووفق المبدأ الأساسي الموضح في المواصفة السابقة RFC 7489، تنجح الرسالة إذا تحقق أحد الشرطين التاليين:
- نجاح SPF مع تطابق نطاقه مع نطاق Header From.
- نجاح DKIM مع تطابق نطاقه مع نطاق Header From.
يبدو ذلك بسيطاً، لكن تفسير فشل DMARC يتعقد عندما تختلط مفاهيم مختلفة:
- المصادقة: هل نجح SPF أو DKIM؟
- تطابق النطاقات: هل يطابق نطاق الفحص الناجح نطاق Header From؟
- سلامة الرسالة بعد إعادة التوجيه: هل بقيت البيانات الموقعة صالحة عبر المرحلة الوسيطة؟
قد ينجح SPF وتظهر نتيجة فشل DMARC. وقد ينجح DKIM وتظهر نتيجة فشل DMARC. إذا لم تتطابق أي هوية ناجحة مع النطاق الظاهر، فلن ينجح DMARC.
لماذا تسبب إعادة التوجيه فشل DMARC كثيراً؟
قد تسبب إعادة التوجيه فشل DMARC لأنها تغير المسار وأحياناً المحتوى. يعتمد SPF على مصدر الاتصال، بينما يعتمد DKIM على سلامة البيانات الموقعة. قد تفقد الرسالة مسار مصادقة بسبب التوجيه، ثم تفقد الآخر بسبب تعديلها.
هذا مسار شائع:
- يرسل المرسل البريد من
sender.com. - يستقبله صندوق بريد أو بوابة وسيطة.
- يعيد النظام توجيهه تلقائياً إلى Gmail أو Outlook أو وجهة أخرى.
عندئذ يرى المستلم النهائي عنوان IP لخادم إعادة التوجيه بوصفه عميل SMTP، وليس عنوان المرسل الأصلي.
هنا قد تبدأ مشكلة فشل DMARC.
يتأثر SPF أولاً
يُعرّف SPF في RFC 7208. وهو يتحقق مما إذا كان عنوان IP المتصل مصرحاً له بالإرسال لنطاق مرسل المغلف.
بعد إعادة التوجيه، يصبح عنوان الاتصال هو عنوان الخادم الوسيط. إذا لم يسمح له نطاق المغلف الأصلي، يفشل SPF. يمكن لـ SRS إعادة كتابة مرسل المغلف إلى نطاق الوسيط لكي ينجح SPF لهذا النطاق، لكن ذلك لا يعيد تلقائياً التطابق مع نطاق From الأصلي.
المسار الأصلي: يرسل
sender.comمن IP A وينجح SPF.
المسار المعاد توجيهه: يرسل الوسيط من IP B. يقارن المستلمsender.comمع IP B، ويفشل SPF إذا لم يكن العنوان مصرحاً به.
هذا الفشل وحده لا يضمن فشل DMARC. إذا بقي توقيع DKIM صالحاً ومتطابقاً، يظل DMARC ناجحاً. لهذا يستحق DKIM عناية خاصة في المسارات غير المباشرة.
يمكن لـ DKIM الحفاظ على مسار المصادقة
يوقع DKIM، الموضح في RFC 6376، ترويسات محددة ومتن الرسالة. لا يفحص عنوان IP الذي يعيد توجيهها، ولذلك يمكنه توفير نجاح DMARC عند فقدان SPF.
لكن ذلك يحتاج إلى تحقق الشرطين:
- بقاء التوقيع صالحاً بعد إعادة التوجيه.
- تطابق نطاق
d=مع نطاق From الظاهر.
إذا غاب أحدهما ولم يوجد مسار مصادقة متطابق آخر، فقد يحدث فشل DMARC.
قد تعدل أنظمة إعادة التوجيه الرسائل بطرق تبطل التوقيع:
- إضافة
[EXTERNAL]إلى الموضوع - إلحاق إخلاء مسؤولية أو تذييل قانوني
- إعادة كتابة حدود MIME
- تغيير التفاف السطور أو المسافات البيضاء
تسمح قواعد التطبيع المرن في DKIM ببعض التغييرات، لا بكل تغيير. يعتمد الأثر على الحقول الموقعة والتعديل الفعلي. لذلك لا يثبت فشل DMARC بعد إعادة التوجيه وجود انتحال؛ افحص أولاً ما إذا كان التنفيذ قد غير رسالة مشروعة.
مشكلة تطابق النطاقات من دون إعادة توجيه
لا يتطلب فشل DMARC إعادة توجيه. قد يصادق مرسل SaaS بنطاقه الخاص بينما يعرض From نطاق شركتك. تكون الرسالة حقيقية، لكن DMARC يفشل إذا لم يوجد SPF أو DKIM ناجح ومتطابق.
هذه مشكلة إعداد يسهل إغفالها أثناء التشغيل.
مثال:
- From:
billing@yourcompany.com - Return-Path:
bounce.vendor-mail.com - DKIM:
d=vendor-mail.com
قد ينجح SPF للنطاق vendor-mail.com، وقد ينجح DKIM للنطاق vendor-mail.com. ومع ذلك يظهر فشل DMARC لأن أياً من الهويتين لا يطابق yourcompany.com.
عالج ذلك بإعداد مصادقة نطاق مخصص. يفضل أن يوقع مزود الإرسال بـ DKIM صالح ومتطابق مع نطاقك. ويمكن لنجاح SPF على نطاق مغلف متطابق توفير مسار DMARC أيضاً، لكن إعادة التوجيه قد تفقدك هذا المسار، لذا راجع DKIM.
إذا كنت تعيد النظر في إعداد يعتمد بكثرة على الأسماء المستعارة، فاقرأ الاسم المستعار للنطاق مقابل صندوق البريد. المسارات غير الواضحة تجعل تشخيص مشكلات المصادقة أصعب.
تشخيص فشل DMARC من الترويسات
في كثير من حالات فشل DMARC، تعطي قراءة الترويسات اتجاه التشخيص أسرع من التخمين. ابدأ بترويسة Authentication-Results التي أضافها خادم الاستقبال الموثوق، ولا تثق تلقائياً في ترويسة بالاسم نفسه مصدرها مجهول. قارن بعدها نتائج SPF وDKIM ونطاقات التطابق.
اطلب الترويسات الكاملة من المستلم، وابحث عن نتيجة مثل:
Authentication-Results: mx.google.com;
spf=fail smtp.mailfrom=sender.com;
dkim=pass header.i=@sender.com header.s=mail;
dmarc=pass header.from=sender.comهنا فشل SPF بينما نجح DKIM وDMARC. قد يفسر ذلك إعادة التوجيه، لكن النتيجة وحدها لا تثبت المسار. لا توجد مشكلة DMARC في هذا الفحص؛ افحص أي مشكلة تسليم أخرى بصورة مستقلة.
أما هذه النتيجة فتحتاج إلى متابعة:
Authentication-Results: mx.google.com;
spf=fail smtp.mailfrom=sender.com;
dkim=fail header.i=@sender.com;
dmarc=fail header.from=sender.comقد يكون هذا فشل DMARC بسبب إعادة التوجيه. يمكن لتغير المسار تفسير SPF، لكن تشخيص DKIM يحتاج إلى مراجعة تعديل المحتوى وصحة التوقيع ونشر المفتاح ونتيجة المصادقة الأصلية. لا تستبعد أسباباً أخرى بالترويسات وحدها.
| نتيجة الترويسة | المعنى الشائع | الإجراء |
|---|---|---|
spf=fail، dkim=pass، dmarc=pass | قد تظهر في إعادة توجيه طبيعية | لا يلزم إصلاح DMARC لهذه النتيجة؛ واصل المراقبة. |
spf=fail، dkim=fail، dmarc=fail | إعادة توجيه مع تعديل محتوى أو DKIM غير صالح محتمل | راجع التوقيع والمفاتيح والتطبيع والتعديلات الوسيطة. |
dkim=pass مع نطاق d= غير متطابق | مشكلة تطابق محتملة لدى مزود الإرسال أو المرحل | أعد DKIM متطابقاً، وراجع مسار SPF أيضاً. |
spf=permerror | سجل SPF معقد أو متعدد أو غير صحيح محتمل | صحح الصياغة والمصادر الزائدة، واستخدم نطاقات فرعية مناسبة، وراجع صيانة flattening. |
arc=pass | اجتازت سلسلة ARC التحقق؛ الثقة بها قرار مستقل للمستلم | قيّم الوسيط وقرار الاستقبال النهائي. |
تقليل فشل DMARC في البريد المعاد توجيهه
لن تمنع المستلمين من إعادة التوجيه. يمكنك تقليل فشل DMARC بتصميم يستوعبه: DKIM صالح ومتطابق، وSPF قابل للإدارة، ومسار يحافظ على البيانات الموقعة قدر الإمكان. لا يضمن أي إعداد سلوك كل وسيط أو مستلم.
1. اجعل DKIM جزءاً ثابتاً من كل مسارات الإرسال
إذا أردت الحفاظ على مصادقة الرسائل المشروعة بعد إعادة التوجيه، فوقع كل تدفقات البريد الصادر، لا النشرات أو الدعم وحدهما. راجع الفوترة وإشعارات التطبيقات والخدمات الأخرى. DKIM مسار مهم لذلك، مع أن الإرسال المباشر يمكنه اجتياز DMARC عبر SPF متطابق أيضاً.
يجب أن يتطابق نطاق التوقيع مع From الظاهر. إذا كانت الرسالة من yourdomain.com، فوقع باستخدام yourdomain.com أو نطاق فرعي يحقق نمط التطابق المختار. يعتمد التطابق المرن على النطاق التنظيمي، بينما يحتاج الصارم إلى تطابق كامل للنطاق.
في TrekMail، ابدأ بقيم سجلات DNS المطلوبة. عالج تحذيرات حالة DNS قبل اختبار المسارات المعقدة؛ لون الحالة وحده ليس دليلاً على التسليم.
2. استخدم تطبيع DKIM المرن حيث يناسب
التطبيع من نوع simple أكثر حساسية لبعض تغييرات التنسيق الصغيرة. يستطيع التطبيع المرن من نوع relaxed استيعاب تطبيع معين للترويسات والمسافات، وقد يقلل بعض حالات فشل DMARC. لكنه لا يجعل تعديل المحتوى آمناً على نحو عام.
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail;
c=relaxed/relaxed; h=from:to:subject:date:message-id; ...إضافة تذييل إلى المتن قد تبطل التوقيع رغم ذلك. اختبر المسار الحقيقي؛ لا يعالج التطبيع المرن إلا التغييرات التي تسمح بها قواعده.
3. راجع تطابق نطاقات الموردين
إذا وقع CRM أو مكتب الدعم أو أداة النشرات باستخدام d=vendor.com، فتحقق من وجود توقيع DKIM آخر صالح ومتطابق أو نجاح SPF متطابق. من دون هذا المسار قد يحدث فشل DMARC حتى قبل إعادة التوجيه. أعد مصادقة مناسبة لنطاقك. لنطاق return-path المخصص وDKIM المخصص وظيفتان مختلفتان؛ لا يفرض DMARC كليهما دائماً، لكن الاعتماد على SPF وحده معرض لأثر إعادة التوجيه.
4. أبق SPF ضمن حدود التقييم
لا يفشل SPF مع إعادة التوجيه وحدها، بل قد يفشل حين تتراكم الخدمات القديمة وعمليات include المتداخلة. يحدد RFC 7208 عدد الآليات والمعدِّلات التي تستدعي استعلامات DNS أثناء التقييم بحد أقصى 10، مع احتساب العناصر المتداخلة المعنية. تجاوز الحد قد يعطي permerror فلا يوفر SPF مسار نجاح DMARC.
dig +short TXT example.com
dig +short TXT _dmarc.example.comإذا جمعت Google وMicrosoft وMailgun وSendGrid وZendesk وخوادم قديمة في سجل واحد، فاحصر الخدمات النشطة. أزل المصادر غير المستخدمة وانقل ما يناسب إلى نطاقات فرعية. وقد تحتاج تقنية flattening إلى صيانة عند تغير عناوين مزود الخدمة.
5. افهم دور SRS وARC وحدودهما
يعيد SRS كتابة مرسل المغلف لكي ينجح SPF لنطاق خادم إعادة التوجيه، لكنه لا يستعيد تلقائياً تطابق From الأصلي. يستطيع ARC حفظ نتائج مصادقة سابقة في سلسلة قابلة للتحقق. قد يأخذ المستلم النهائي بها إذا وثق في الوسيط. لا يحل أي منهما محل DKIM مضبوط، ولا يضمن نجاح DMARC أو وصول الرسالة.
تميز إرشادات Google الحالية بين البريد المباشر والمعاد توجيهه، وتوصي بخدمات إعادة التوجيه التي تضيف ARC. هذا لا يلغي الشروط التقنية لـ تطابق DMARC. في 2025 و2026 يظل البريد غير المباشر مجالاً يستحق الاختبار؛ تحقق من نطاق قواعد المزود الحالية.
إذا كنت تدير صناديق كثيرة معاد توجيهها، فراجع وظائف المنصة والمسار الفعلي. وفق العرض الحالي، يدعم TrekMail إعادة توجيه الصناديق وإرشادات DNS. تساعد وثائق استخدام SMTP الخاص بك على مراجعة مسؤوليات التطابق؛ اختبر مجموعة الخدمات التي تختارها.
النهج القديم والجديد لإدارة نطاقات كثيرة
قد يؤدي التعامل مع فشل DMARC بإضافة أدوات باستمرار إلى فقدان معرفة النظام الذي يوقع الرسائل. النهج الأفضل يوضح استضافة الصناديق والإرسال وحالة DNS لكي تظهر المشكلات ويمكن تشخيصها. المقارنة التالية تصف خيارات تشغيلية، لا عيوباً لازمة لكل نموذج تسعير.
| النهج القديم | النهج الجديد |
|---|---|
| قد يدفع التسعير حسب المستخدم إلى أسماء مستعارة ومسارات توجيه معقدة | قد يتيح نموذج متعدد النطاقات برسوم ثابتة صناديق فعلية ضمن شروط الخطة |
| سجل SPF ضخم لكل خدمة أضيفت سابقاً | DNS منظم ومصادر include أقل ونطاقات فرعية عند الحاجة |
| مزود الإرسال يوقع بنطاق المورد فقط | لكل تدفق مشروع مسار مصادقة متطابق مناسب |
| غياب الرؤية حتى يشكو المستخدمون | فحوص DNS قد تكشف مشكلات الإعداد مبكراً |
| نقل الصناديق بتصدير يدوي وافتراضات | ترحيل IMAP قد يقلل النسخ اليدوي؛ DNS والمصادقة يحتاجان إلى مراجعة منفصلة |
هذا هو الجانب العملي في TrekMail: بحسب الشروط الحالية يمكنك استضافة صناديق نطاقات متعددة مركزياً ومشاركة التخزين واختيار SMTP مُدار أو مزودك الخاص. راجع نماذج التشغيل في استضافة البريد لنطاقات متعددة ونقل الصناديق في imapsync.
ماذا تفعل عند وصول بلاغ فشل DMARC؟
عند وصول بلاغ فشل DMARC، لا تعد السياسة تلقائياً من reject إلى none. أثبت أولاً إن كانت المشكلة إعادة توجيه أو DKIM غير صالح أو غياب التطابق. احصر المصادر المشروعة واختبر الإصلاح؛ إذا لزم تغيير السياسة، فليكن مضبوطاً مع مراقبة وخطة رجوع.
- احصل على الترويسات الكاملة من المستلم.
- تحقق مما إذا كان SPF قد فشل لأن عنوان الاتصال يعود لوسيط معروف يعيد التوجيه.
- راجع نجاح DKIM أو فشله ونطاق
d=الذي وقع الرسالة. - تحقق من تطابق نطاق التوقيع مع From الظاهر.
- ابحث عن
arc=passوقيّم السلسلة إذا مرت الرسالة بوسيط موثوق. - راجع SPF لكثرة استعلامات DNS أو مصادر include قديمة.
إذا كنت تستخدم TrekMail، فابدأ من إضافة نطاق لمراجعة السجلات، ومن لا أستقبل رسائل البريد إذا كانت المشكلة رسالة مفقودة بلا ارتداد واضح. تقارير DMARC مفيدة كمصدر إضافي، لكنها لا تغطي جميع المستلمين.
الخلاصة: فشل DMARC يستدعي فحص التصميم
تكرار فشل DMARC لا يعني أن البريد غير قابل للإصلاح. ربما تعتمد على SPF كثيراً، أو لا يتطابق DKIM أو لا يصح، أو يعدل وسيط الرسالة. ولا تستبعد الانتحال أو مصادر غير مصرح بها من دون تحقيق.
المعالجة غالباً عمل أساسي منظم: إعداد مصادقة متطابقة، والحفاظ على صلاحية DKIM، وإدارة تعقيد SPF، واختبار إعادة التوجيه. اجعل ذلك جزءاً من التشغيل المستمر.
وفق العرض الحالي، يتيح TrekMail استضافة متعددة النطاقات برسوم ثابتة وتخزيناً مشتركاً وترحيل IMAP وcatch-all وإرسالاً مرناً ضمن شروط الخطط. ينقل IMAP بيانات الصناديق، لا DNS أو التطبيقات أو السمعة، ولا يضمن غياب الانقطاع. تبدأ الخطط المدفوعة حالياً من $3.50 شهرياً بالفوترة السنوية، وقد تتوفر تجربة مجانية لمدة 14 يوماً. Nano مجاني بحسب شروطه من دون بطاقة. تحقق من الأسعار الحالية أو زر TrekMail.
باختصار، إذا كانت إعادة التوجيه ضمن بيئتك، فضع فشل DMARC في خطة الاختبار، لا في قائمة الحالات التي تتجاهلها. المسارات المختبرة والمسؤوليات الواضحة قد تجعل تشغيل البريد أكثر متانة، لكنها لا تضمن التسليم.
