تضبط قاعدة لإعادة التوجيه، وترسل رسالة اختبار، فتصل بنجاح. ثم تتابع عملك.
بعد ذلك يقول عميل إنه لم يتلق ردك. لا تظهر رسالة ارتداد ولا إشعار بعدم التسليم. لم تصل الرسالة في مكان ما بين الخوادم، دون إشعار ظاهر لك.
هذا ما قد يحدث عند إعادة توجيه البريد إلى عنوان آخر: يفتح خادمك اتصال SMTP جديدا بالوجهة. وتفحص الوجهة SPF باستخدام عنوان IP لخادمك، لا عنوان المرسل الأصلي. إذا لم يكن هذا العنوان مصرحا به لنطاق مرسل المغلف، فقد يفشل SPF. وإذا لم يبق توقيع DKIM صالح ومتوافق مع نطاق المرسل الظاهر، فقد يفشل DMARC أيضا. تطلب سياسة p=reject الرفض، لكن المعالجة الفعلية ووجود ارتداد يعتمدان على سياسة المستلم ومسار الرسالة.
ليس السبب بالضرورة خطأ كتابيا في الإعدادات. قد يتعارض أسلوب إعادة التوجيه مع آليات المصادقة الحديثة. يغطي الدليل الشامل لإعداد إعادة توجيه البريد وإصلاحها السيناريوهات المختلفة. ويركز هذا المقال على المصادقة: أنماط الفشل، ورموز الأخطاء، والحلول المناسبة.
لماذا قد تفشل المصادقة عند إعادة التوجيه إلى عنوان آخر
يستخدم خادم الاستلام عنوان IP لخادم إعادة التوجيه عند فحص SPF. وللبريد طبقات هوية مختلفة قد تفقد توافق النطاقات أثناء التوجيه. يتحقق SPF من هوية المغلف، بينما يتطلب DMARC نجاح SPF أو DKIM مع توافق النطاق مع نطاق From: الظاهر. وتحدد سياسة المستلم كيفية التعامل مع الفشل.
| الطبقة | RFC | معناها | آلية التحقق |
|---|---|---|---|
| المغلف (P1) | RFC 5321 | عنوان MAIL FROM في جلسة SMTP، وهو وجهة الارتداد التي تسجل في Return-Path | SPF |
| الترويسة (P2) | RFC 5322 | حقل From: الذي يراه المستلم في برنامج البريد | DKIM؛ ويتحقق DMARC من توافق النطاقات |
المسار كالتالي: يرسل الخادم A إلى خادم إعادة التوجيه B، الذي يفتح اتصال TCP جديدا بالوجهة C. ترى C عنوان IP الخاص بخادم B. ويسأل SPF نظام DNS لنطاق المغلف: "هل يحق لهذا العنوان إرسال البريد باسم نطاقك؟" إذا بقي مرسل المغلف الأصلي ولم يكن B مصرحا به، فقد يفشل SPF. ليس الفشل حتميا في كل عملية توجيه.
يكفي لنجاح DMARC نجاح SPF أو DKIM مع توافق النطاق. لذلك يمكن لتوقيع DKIM أصلي صالح ومتوافق أن يسمح بمرور الرسالة المعاد توجيهها. قد تبطل تغييرات المحتوى الموقع أو الترويسات الموقعة التوقيع، بحسب أسلوب توحيد الصيغة ونطاق التوقيع. إذا لم تنجح أي مصادقة متوافقة، يفشل DMARC. وتطلب p=reject الرفض دون ضمان طريقة المعالجة النهائية.
ثلاثة أنماط فشل يجب معرفتها
قد تظهر مشكلات مختلفة عند إعادة توجيه البريد. لكل نمط أدناه سبب وإعدادات يجب فحصها وحل مناسب. تختلف رموز الأخطاء الفعلية بحسب البيئة، لكن تمييز النمط يساعدك على تضييق نطاق التشخيص.
1. حظر الإرسال في Microsoft 365 (550 5.7.520)
قد يحظر Microsoft 365 إعادة التوجيه التلقائي إلى الخارج افتراضيا للحد من تسريب البيانات. فإذا أنشأت قاعدة صندوق بريد توجه الرسائل خارج المؤسسة، فقد يمنعها Exchange Online قبل مغادرتها. تحقق من السياسة الفعلية المطبقة على المستخدم المعني.
550 5.7.520 Access denied, Your organization does not allow external forwarding.
هذا حظر تفرضه السياسة، لا خطأ في البروتوكول. يمكن للمسؤول المخول مراجعة ما يلي:
- افتح Microsoft 365 Defender Portal.
- انتقل إلى Email & collaboration → Policies & rules → Threat policies → Anti-spam.
- عدل Outbound spam filter policy ذات النطاق المحدود بالمستخدمين أو المجموعات المصرح لهم.
- اضبط Automatic forwarding لهذا النطاق فقط على On - Forwarding is enabled إذا كانت الموافقة تسمح بذلك.
التفعيل العام يزيد المخاطر عند اختراق حساب. احصر السماح في الحسابات المعتمدة، وطبق المصادقة متعددة العوامل، وراقب حجم البريد الصادر بعد التغيير. راجع أيضا أي قواعد أخرى قد تمنع إعادة التوجيه.
2. غياب نتيجة مصادقة متوافقة لنجاح DMARC
قد يصعب ملاحظة هذه المشكلة. يمكن أن يفشل SPF عند تغير عنوان IP، لكن توقيع DKIM صالح ومتوافق مع نطاق المرسل الظاهر قد يتيح نجاح DMARC. أما التغييرات في الجزء الموقع من المحتوى أو في الترويسات الموقعة التي لا يستوعبها توحيد الصيغة فقد تبطل DKIM.
من التغييرات الشائعة التي قد تكسر DKIM:
- إضافة برنامج مكافحة الفيروسات تذييلا: "تم الفحص بواسطة [اسم المنتج]"
- إضافة بوابة الوجهة وسوما للموضوع:
[EXT]أو[EXTERNAL]، إذا كان حقل Subject موقعا - إدراج لافتات تحذير "مرسل خارجي" في محتوى HTML
- إعادة كتابة الترويسات الموقعة أو إضافة تذييل إلغاء الاشتراك بواسطة برنامج القوائم البريدية
إذا لم ينجح SPF ولا DKIM مع توافق النطاق، تكون نتيجة DMARC (RFC 7489) هي FAIL. تطلب p=reject الرفض، لكن المستلم يحدد المعالجة الفعلية. قد ينتج عن رفض SMTP إشعار بعدم التسليم، وقد تتم معالجة أخرى دون إشعار ظاهر. افحص السجلات ونتائج المصادقة بدلا من افتراض حذف صامت حتمي.
3. حلقات التوجيه (554 5.4.14)
تنشأ الحلقة حين تتبادل الخوادم الرسالة مرارا حتى بلوغ حد القفزات أو حد آخر. قد تظهر إشعارات عدم التسليم، لكن ليس بالضرورة فورا. ويمكن للحلقات أن تثقل طوابير البريد وتؤخر تسليم رسائل أخرى.
من الأسباب الشائعة:
- يوجه المستخدم A إلى B، ولدى B قاعدة تعيد التوجيه إلى A.
- يوجه A إلى B، ثم يدخل رد الغياب التلقائي من B في مسار التوجيه مجددا. يعتمد التكرار على القواعد والحماية من الحلقات؛ والردود التلقائية السليمة تحد عادة من التكرار.
- يوجه عنوان شامل إلى صندوق بريد، ثم يوجه الصندوق إلى عنوان غير موجود في النطاق نفسه.
554 5.4.14 Hop count exceeded - possible mail loop
تحقق دائما من سلسلة التوجيه كاملة، بما فيها الردود التلقائية ووجهات العنوان الشامل، قبل تشغيل إعادة التوجيه في بيئة الإنتاج.
أدوات المعالجة: SRS وARC
يمكن لـ SRS وARC تقليل مشكلات المصادقة، لكنهما لا يضمنان التسليم. يعيد SRS كتابة مرسل المغلف بحيث يمكن لـ SPF النجاح عند صحة DNS والسماح بعنوان IP الصادر. ويسجل ARC نتائج المصادقة السابقة التي قد يثق بها المستلم وفق تقديره عند فشل DMARC. يتطلب كلاهما دعما على مستوى الخادم، وليس مجرد قاعدة في برنامج البريد.
SRS: مخطط إعادة كتابة المرسل
يعيد SRS كتابة مرسل المغلف (P1) إلى نطاق تتحكم فيه. بدلا من الإبقاء على alice@bank.com كمرسل مغلف قد لا يكون خادمك مخولا بالإرسال لنطاقه، يمكن لخادم إعادة التوجيه تغيير Return-Path إلى:
SRS0=Hash=Timestamp=bank.com=alice@your-forwarding-domain.com
يفحص SPF الآن نطاقك. إذا سمح سجل SPF بعنوان IP الصادر واكتملت بقية الفحوص بنجاح، يمكن أن ينجح SPF. لكن هذا لا يحقق تلقائيا التوافق مع نطاق From: الأصلي الظاهر.
تساعد قيمة التجزئة والطابع الزمني في التحقق من مسار الارتداد. إذا وصل إشعار عدم تسليم إلى عنوان SRS، يمكن لخادمك التحقق من العنوان وفك ترميزه وإرسال الإشعار إلى Alice. لهذه العناوين صلاحية وغرض محدودان. إدارة الأسرار والتحقق مهمان، لكنهما لا يغنيان عن قيود الترحيل والحماية الأخرى من إساءة الاستخدام.
ARC: سلسلة الاستلام الموثقة
قد يتيح SRS نجاح SPF، لكنه لا يصلح تلقائيا توافق المغلف والترويسة الظاهرة. ولا يصلح ARC (RFC 8617) هذا التوافق أيضا. يضيف خادم إعادة التوجيه معلومات موقعة عن حالة المصادقة التي رصدها عند استلام الرسالة.
قد يستخدم Google وMicrosoft سلاسل ARC الصالحة من الوسطاء الموثوقين في قرار التسليم. لا تضمن سلسلة صالحة وسمعة جيدة وصول البريد إلى Gmail أو Outlook. يحدد المستلم من يثق به وكيف يتعامل مع فشل DMARC.
فكر في ARC كسجل لمسار معالجة الرسالة. يضيف كل وسيط مشارك إفادة موقعة عن المصادقة التي رصدها. ويمكن للمستلم التالي التحقق من السلسلة واختيار الثقة بها عندما لا ينجح فحص DMARC المعتاد.
قد يطبق Gmail وMicrosoft 365 أختام ARC في المسارات المدعومة، لذا افحص الترويسات في مسارك الفعلي. في غياب ARC لا يوجد هذا السجل، لكن DKIM الأصلي الصالح والمتوافق قد يظل كافيا لنجاح DMARC. غياب ARC لا يعني تلقائيا فشل DMARC.
التنفيذ: مساران
يمكنك إدارة مصادقة التوجيه على خادم البريد الخاص بك، أو اختيار بنية مدارة تدعم الآليات المطلوبة لمسارك. في الحالتين يجب التحقق من الإعدادات الفعلية ونتائج الاختبار؛ لا يلغي أي خيار جميع مخاطر التسليم.
الخيار A: Postfix + postsrsd (إدارة ذاتية)
على خادم Linux يعمل بـ Postfix، يمكن استخدام postsrsd لإعادة كتابة المغلف. يستخدم المثال التالي جداول TCP القديمة. تستخدم الإصدارات الرئيسية الأحدث جداول socketmap غير المتوافقة مع هذا الإعداد. راجع وثائق الإصدار المثبت لديك قبل تطبيقه:
# /etc/postfix/main.cf
sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient
مسؤولياتك في هذا المسار:
- إدارة أسرار SRS. قد يتيح تسرب المفاتيح تزوير عناوين SRS وإساءة استخدام مسارات الارتداد؛ وتظل قيود الترحيل ضرورية.
- وضع استثناءات مناسبة للنطاقات المحلية والبريد غير المعاد توجيهه، حتى لا تعطل إعادة الكتابة المسارات الداخلية.
- مراقبة سمعة عنوان IP الصادر، التي تؤثر في التسليم مع المصادقة والمحتوى وسياسة المستلم.
- إعداد توقيع ARC بشكل مستقل؛ فلا يوفره postsrsd وحده.
قد يعمل هذا المسار جيدا، لكنه يحتاج إلى صيانة مستمرة. ويمكن لمنصة متخصصة أن تتولى بعض العمل بحسب وظائفها والمسار الذي تدعمه.
الخيار B: TrekMail (إعادة توجيه مدارة)
عند اختيار TrekMail، تحقق من دعم المسار المطلوب لإعادة كتابة SRS تلقائيا، وتوقيع ARC، ومرحلات SMTP المدارة. قد تختلف الوظائف بحسب الخطة والإعدادات. يمكن للبنية المدارة تقليل الصيانة، لكنها لا تضمن التسليم أو سمعة محددة.
| الإمكانية | Postfix مستضاف ذاتيا | TrekMail |
|---|---|---|
| إعادة كتابة المغلف عبر SRS | تثبيت postsrsd وإعداده | تحقق من الدعم في مسارك |
| توقيع ARC | يتطلب إعدادا إضافيا | تحقق من توفره في الخطة المدفوعة |
| إعداد SPF/DKIM/DMARC | تعديل DNS يدويا لكل نطاق | تحقق من أدوات الإعداد الإرشادي |
| سمعة الإرسال | سجل عنوان IP الخاص بك | تحقق من مرحلات SMTP المدارة وشروطها (Starter+) |
| إدارة قواعد نطاقات متعددة | إعدادات لكل خادم | تحقق من لوحة التحكم وحدود النطاقات |
للمؤسسين المستقلين: إذا كنت تدفع $6 شهريا لكل صندوق لمجرد توجيه info@yourdomain.com إلى بريدك الشخصي، فقارن أيضا الخيارات ذات السعر الثابت. سعر Starter المذكور هنا، $3.50 شهريا لما يصل إلى 50 نطاقا دون رسوم لكل مستخدم، مرجع وليس وعدا بالشروط الحالية. تحقق من السعر وصلاحيات التوجيه والحدود. راجع كيفية عمل إعادة توجيه صناديق البريد في TrekMail.
للوكالات التي تدير DNS لعدة عملاء: قد يستهلك تشخيص SPF في مسارات التوجيه وقتا كبيرا. ويمكن للوحة مركزية تبسيط الإدارة إذا كانت الوظائف المطلوبة متاحة. يشرح دليل إعادة التوجيه عبر الأسماء المستعارة الفروق عند الاختيار بينها وبين قواعد صناديق البريد الكاملة.
قائمة تحقق قبل إعادة التوجيه إلى عنوان آخر
راجع النقاط الأربع قبل تشغيل قاعدة فعلية. تساعد على الحد من المشكلات السابقة، لكنها لا تستبدل اختبارات التسليم ومراقبة السجلات والتحقق من سياسة المستلم.
- يعمل SRS حيث يلزم. افحص ترويسة
Return-Pathفي رسالة اختبار وصلت. في مسار يستخدم SRS يجب أن ينتمي العنوان المعاد كتابته إلى نطاق التوجيه. تحقق أيضا من نتيجة SPF الفعلية. - احفظ المحتوى الموقع. تجنب تذييلات مكافحة الفيروسات ووسوم الموضوع واللافتات التي قد تكسر DKIM. لا توقف الفحص الأمني؛ احتفظ بحماية مكافئة دون تعديل الرسالة الموقعة. ليس كل تعديل مبطلا للتوقيع؛ يتوقف ذلك على توحيد الصيغة والحقول الموقعة.
- تحقق من الحماية من الحلقات. راجع قواعد التوجيه العكسي والمسارات الشاملة والردود التلقائية. اختبر منع التكرار بدلا من افتراض أن كل رد غياب يسبب حلقة.
- راجع سياسة الإرسال في M365. في Exchange Online اسمح بـ "Automatic Forwarding" فقط للمستخدمين أو المجموعات المعتمدة عبر سياسة محدودة النطاق في بوابة Defender. تحقق من السياسة الفعلية وأي حظر إضافي.
متى يكون عدم إعادة التوجيه أفضل
ليست إعادة التوجيه دائما الخيار المناسب. إذا أردت جمع بريد عدة نطاقات في صندوق محلي واحد، فقد يتيح الاسم المستعار للنطاق تجنب قفزة توجيه إضافية. لكن إذا كان الاسم المستعار يوجه إلى الخارج، تبقى أسئلة المصادقة نفسها؛ افحص المسار الحقيقي.
توضح مقارنة الاسم المستعار للنطاق وصندوق البريد متى تختار كل حل. عند الانتقال من مزود سابق، قد تنقل أداة ترحيل IMAP في TrekMail البريد الموجود مباشرة إذا كانت متاحة لحسابك. لكنها لا تضبط تلقائيا مسار الرسائل الجديدة أثناء الانتقال.
الخلاصة
عند إعادة التوجيه يرى SPF عنوان IP لخادم التوجيه. إذا لم يسمح به نطاق المغلف الأصلي، فقد يفشل SPF. يمكن لـ DKIM الأصلي الصالح والمتوافق أن يبقي DMARC ناجحا؛ وإلا فقد يفشل. أما الرفض والارتداد والمعالجة الأخرى فتتوقف على المستلم والمسار.
تعمل أدوات المعالجة على مستوى الخادم: يعيد SRS كتابة مرسل المغلف ويمكن أن يساعد SPF على النجاح لنطاقك، ويوفر ARC سجلا موقعا يستخدمه المستلم وفق تقديره. لا يضمن أي منهما توافق النطاقات أو التسليم. يمكنك إعدادهما بنفسك أو التحقق من دعم منصة مدارة.
لتقليل إدارة مفاتيح SRS وإعداد ARC وسمعة الإرسال، تحقق مما يقدمه TrekMail لمسارك. يجب مقارنة سعر Starter المذكور، $3.50 شهريا لما يصل إلى 50 نطاقا بسعر ثابت ودون رسوم لكل مستخدم، بالشروط الحالية. عرض جميع الخطط.