إعادة توجيه البريد لا تعمل: التشخيص في 6 خطوات

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

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

راجع القائمة قبل تعديل DNS. يشرح دليل إعداد توجيه البريد وإصلاحه طبقة SPF ودور SRS وARC. نركز هنا على تشخيص المشكلة الحالية.

لماذا قد لا يظهر خطأ عند تعطل التوجيه؟

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

اقرأ الترويسات والإشعارات والسجلات المتاحة. القاعدة النشطة لا تثبت وصول الرسالة. تقدم الخطوات الست التالية ترتيبا عمليا للفحص. تعديل DNS قبل فحص الرسائل المزعجة قد يهدر مثلا 45 دقيقة.

فرز خلال 60 ثانية: حدد العرض أولا

خصص، كإرشاد عملي، 60 ثانية لتصنيف العرض قبل تعديل الإعدادات. الأنماط الأربعة التالية نقاط بدء للتحقيق وليست تشخيصا قاطعا.

قائمة فحص تعطل توجيه البريد

ابدأ بالخطوة 1 والخطوة 2. قد يوفر مجلد الرسائل المزعجة أو إشعار الارتداد دليلا مفيدا، بدلا من قضاء مثلا 45 دقيقة بتعديل DNS غير المتسبب بالمشكلة. تابع حتى تحدد العطل ببيانات فعلية.

الخطوة 1: افحص مجلد الرسائل المزعجة بالوجهة

فحص أولي  |  العرض: لا بريد ولا ارتداد

قد توجد الرسالة في المزعج. عند التوجيه من client@gmail.com إلى you@outlook.com قد يرى الخادم النهائي عنوان IP لم يسمح به SPF لهوية مرسل الظرف الأصلي. تعتمد النتيجة أيضا على DKIM وDMARC وسياسة المستلم.

الإجراء: ادخل الصندوق النهائي وافحص المجلد المزعج.

المتابعة: صنف الرسالة المكتشفة بأنها غير مزعجة حيث يناسب. راجع Sender Rewriting Scheme (SRS) لإعادة كتابة مرسل الظرف. يساعد SPF للهوية الجديدة، لكنه لا يضمن محاذاة DMARC مع From الأصلي أو التسليم. قد يكفي توقيع DKIM صالح ومحاذ بقي سليما لنجاح DMARC دون SRS.

الخطوة 2: اقرأ إشعار الارتداد ورموز NDR

اقرأ الخطأ المتاح  |  العرض: يتلقى المرسل إشعار تعذر التسليم

اقرأ رمز SMTP والتفسير الكامل، لا العنوان وحده. يوفران دليلا ملموسا، لكن لبعض الرموز أسباب متعددة.

الخطوة 3: افحص محاذاة DMARC

مراجعة المصادقة لـGmail وYahoo وOutlook  |  العرض: غياب التسليم أو الرفض

لا يرجع كل عطل إلى DMARC. حتى مع p=reject، فالقول إن التوجيه دون SRS أو ARC يفشل 100% من الوقت غير صحيح. قد ينجح DMARC إذا بقي توقيع DKIM صالحا ومحاذيا لنطاق From الظاهر. يجب أن ينجح SPF أو DKIM وأن يكون نطاق الآلية الناجحة محاذيا.

استعلم عن سياسة النطاق الأصلي من الطرفية:

dig _dmarc.originalsender.com TXT +short

وجود p=reject طلب سياسة لا دليل رفض هذه الرسالة. يستخدم SPF هوية الظرف وDKIM نطاق التوقيع. يقارن DMARC كل آلية بنطاق From الظاهر، ولا يقارن مرسل الظرف بتوقيع DKIM مباشرة.

المتابعة: راجع الترحيل الداعم لـSRS وARC حيث يناسب. يحفظ ARC النتائج السابقة في سلسلة موقعة، ويقرر المستلم الثقة بالسلسلة المتحقق منها. لا يضمن نجاح DMARC أو التسليم. تحويلات cPanel على الخادم، وتختلف قواعد Gmail وOutlook بحسب التنفيذ. افحص قدرات خادم التوجيه الفعلي.

الخطوة 4: راجع سياسة التوجيه الخارجي في Microsoft 365

فحص سياسة Office 365  |  العرض: إشعار 550 5.7.520 NDR

قد يحظر Microsoft 365 التوجيه التلقائي الخارجي بالسياسة. لا تتجاوز قاعدة المستخدم سياسة المؤسسة المطبقة. على مسؤول مخول مراجعة الحاجة والموافقة على استثناء ضيق؛ لا تفعل التوجيه لكل المؤسسة دون تقييم.

1. افتح كمسؤول مخول Microsoft 365 Defender
2. راجع Email & collaboration → Policies & rules → Threat policies → Anti-spam؛ قد تتغير أسماء الواجهة
3. افحص Anti-spam outbound policy (Default) والسياسة المحددة المطبقة فعليا
4. افتح عند السماح Edit protection settings
5. راجع Automatic forwarding rules واختر بعد الموافقة وللنطاق المناسب فقط On - Forwarding is enabled

قد يكون الخيار معطلا بسبب صلاحيات أو سياسة. اطلب من مسؤول المؤسسة التحقيق؛ لا تلغي إعدادات المستخدم سياسة المنظمة.

الخطوة 5: افحص حلقات المسارات

تحقيق المسار  |  العرض: خطأ 5.4.14 أو نسخ متعددة

تنشأ حلقة حين يرسل الخادم A إلى B ويعيد B إلى A. قد توقفها حدود القفزات. مثالها catch-all للنطاق A إلى B، بينما يعيد B عناوين معينة إلى A. قد تكون للنسخ المتكررة أسباب أخرى أيضا.

افحص الترويسات التالية في الرسائل المتأخرة أو المتكررة:

• X-Loop
• X-MS-Exchange-Inbox-Rules-Loop
• Delivered-To مع تكرار العنوان نفسه

يساعد دليل catch-all للنطاق على تصميم المسارات. قد تمر السلسلة بأسماء مستعارة، لكنها يجب أن تكون محدودة وتصل إلى صندوق نهائي دون حلقة.

الخطوة 6: تحقق من وجهة Gmail

فحص التفعيل  |  العرض: القاعدة موجودة ولا توجيه

في Gmail الشخصي قد ينقص تأكيد الوجهة. تحقق من اكتمال التحقق ومن تفعيل التوجيه فعلا بعده. وجود القاعدة وحده لا يثبت نشاط التوجيه.

الإجراء: ابحث بالوجهة عن رسالة تأكيد Gmail Team وفي المزعج أيضا. تحقق من المرسل والوجهة المطلوبة قبل فتح رابط التأكيد. عند الحاجة اطلب التحقق مجددا عبر إعدادات Gmail → التوجيه وPOP/IMAP ثم راجع تفعيل التوجيه.

قراءة الترويسات لتشخيص مشاكل التوجيه

رسالة المزعج وصلت بالفعل، وتصنيفها لا يثبت فشل المصادقة. اقرأ Authentication-Results الصادر عن خادم استقبال موثوق مع المسارات والسجلات. لا يظهر كل خطأ توجيه في هذه الترويسة.

عرض الترويسات:

• Gmail: افتح الرسالة → قائمة النقاط الثلاث → عرض الأصل
• Outlook: ملف → خصائص → ترويسات الإنترنت؛ تحقق من مسار إصدارك

مقطع توضيحي لـSRS وARC، لا صيغة ARC كاملة أو معيارية. افحص ترويسات ARC والتحقق الفعلي؛ لا يثبت هذا المقطع وحده صحة السلسلة:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sender.com;
  spf=pass (google.com: domain of SRS0=ABCD=XY=sender.com@forwarder.com
            designates 1.2.3.4 as permitted sender)
  dmarc=pass (p=REJECT) dis=NONE header.from=sender.com
  arc=pass (i=1 spf=pass dkim=pass)

البادئة SRS0= في Return-Path قرينة لإعادة كتابة SRS لا إثبات سلامة الإعداد كله. غيابها لا ينفي كل أشكال إعادة الظرف ولا يثبت فشل DMARC. افحص الترويسات والخادم. قواعد Google المشددة منذ 2024 للإرسال إلى Gmail الشخصي لا تطبق بشكل مماثل على كل خدمة أو نطاق تجاري.

عندما يصبح تعطل التوجيه مشكلة عمل

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

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

قلل التحقيق المتكرر

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

إدارة منفصلة: قواعد Gmail أو cPanel وفحص SPF لكل نطاق ومراجعة سياسة M365 ومتابعة التغييرات.

نموذج TrekMail الموصوف: مسارات مركزية مع SRS وARC على مستوى MTA حيث تدعم. تحقق من كل مسار؛ يظل القبول بقرار المستلم.

يصف TrekMail توجيها عبر Postfix مع إعادة الظرف بـSRS وتوقيع ARC. يجب أن يبقى المحتوى المغطى بتوقيع DKIM سليما لنجاح التحقق؛ يحفظ ARC النتائج السابقة ولا يستبدل التوقيع الأصلي. افحص الدعم والمعالجة الحالية لكل مسار. قد تطبق Gmail وOutlook وYahoo ترشيحا إضافيا.

قد يقلل التحكم المركزي لوكالة تدير عشرات النطاقات عبء التحقيق في 30 لوحة منفصلة. اضبط وافحص مسار كل نطاق وصلاحياته. يساعد دليل إدارة بريد العملاء على تفادي حلقات A→B→A المذكورة في الخطوة 5.

يذكر الوصف التاريخي Pro بسعر $10 شهريا (100 نطاق، 50GB) وAgency بسعر $23.25 شهريا (1,000+ نطاق)، وتجربة 14 يوما. تحقق من وظائف SRS/ARC الحالية والحدود وطلب البطاقة وتغطية التجربة: قارن الخطط عبر trekmail.net/pricing.

أدر مشاكل التوجيه المتكررة بصورة منهجية. راجع دعم TrekMail لـSRS وARC وإمكاناته الحالية.