أعددت إعادة توجيه البريد الإلكتروني واختبرتها فعملت. بعد أسبوعين، لم تصل رسالة من عميل تتضمن عقدًا. ليست في مجلد البريد المزعج، ولا يوجد إشعار ظاهر بتعذر التسليم؛ اختفت ببساطة. تفحص السجلات فتجد: 550 5.7.1 Unauthenticated email from domain.com.
قد يسهم غياب مخطط إعادة كتابة المرسل أو خلل في إعداده في هذه المشكلة، لكن رمز الخطأ نفسه له أسباب أخرى أيضًا. تتحقق مصادقة البريد، ضمن ما تتحقق منه، من أن خادم الإرسال مخوّل من نطاق مرسل المغلف. وقد تؤدي إعادة التوجيه إلى فشل هذا التحقق على مستوى البروتوكول. يساعد مخطط إعادة كتابة المرسل في معالجة ذلك، لكنه ليس حلًا كاملًا بمفرده حتى في 2026. وفهم حدوده لا يقل أهمية عن فهم ما يفعله.
يوضح هذا الدليل وظيفة مخطط إعادة كتابة المرسل، وحدوده، وكيفية بناء سلسلة إعادة توجيه تعمل بصورة سليمة. إذا كنت تبحث أيضًا عن أسباب أوسع لمشكلات التسليم، مثل سجلات MX الخاطئة أو إعدادات catch-all غير الصحيحة أو تغييرات DNS التي أثرت في المسارات، فابدأ بقراءة دليل إعداد إعادة توجيه البريد وإصلاحها.
لماذا قد يفشل SPF عند إعادة توجيه البريد
عند إعادة التوجيه، يرسل الخادم الوسيط الرسالة من عنوان IP الخاص به، بينما قد يبقى مرسل المغلف على النطاق الأصلي. إذا لم يسمح سجل SPF لهذا النطاق بعنوان IP الوسيط، يفشل SPF. ومع سياسة DMARC p=reject، قد يرفض الخادم المستقبل الرسالة إذا لم يتوفر أيضًا توقيع DKIM صالح ومتوافق مع النطاق الظاهر للمرسل. يُبلّغ رفض SMTP إلى خادم إعادة التوجيه، وقد ينتج عنه إشعار بتعذر التسليم. ومع ذلك، قد لا يرى المستلم سوى غياب الرسالة من صندوقه دون تنبيه ظاهر.
لا ينتقل البريد عبر قناة واحدة متصلة، بل عبر سلسلة من اتصالات SMTP، مع مصافحة TCP جديدة في كل محطة. إليك مثالًا لمسار قد يحدث فيه الفشل:
- يرسل
alice@client.comرسالة إلىcontact@your-agency.com - يقبل خادمك الرسالة، لأن سجل SPF في
client.comيسمح بعنوان IP لخادم إرسال Alice - يفتح خادمك اتصال SMTP جديدًا مع Gmail لإعادة توجيه الرسالة
- يرى Gmail أن الاتصال يأتي من عنوان IP الخاص بك
- يبقى مرسل المغلف
alice@client.com - يفحص Gmail سجل SPF في
client.com، ولا يجد عنوان IP الخاص بك ضمن العناوين المسموح بها - يفشل SPF. إذا كان
client.comيستخدمp=rejectولم يوجد توقيع DKIM صالح ومتوافق مع نطاق المرسل الظاهر، فقد يرفض Gmail الرسالة
تتناول RFC 7208، مواصفة SPF، هذه المشكلة المعروفة في إعادة التوجيه صراحةً. لا يحافظ SPF وحده على التفويض الأصلي عبر اتصال جديد. لذلك يمكن معالجة أحد جوانب المشكلة بتعديل مرسل المغلف.
هويتا المرسل: المغلف والترويسة
للبريد الإلكتروني مستويان من هوية المرسل. يُستخدم مرسل المغلف (RFC 5321، MAIL FROM، P1) للتحقق من SPF وتوجيه إشعارات تعذر التسليم. وهو مخصص أساسًا للخوادم، لكنه قابل للفحص أيضًا في Return-Path ضمن الترويسات الخام. أما From في الترويسة (RFC 5322، P2) فهو المرسل الذي يظهر في Gmail أو Outlook. قد تفصل إعادة التوجيه بين هاتين الهويتين. يعمل مخطط إعادة كتابة المرسل على مستوى المغلف دون تغيير المرسل الظاهر.
| المستوى | الاسم التقني | RFC | الغرض | من يراه |
|---|---|---|---|---|
| مرسل المغلف | MAIL FROM / Return-Path | RFC 5321 (P1) | فحص SPF وتوجيه إشعارات تعذر التسليم | الخوادم أساسًا؛ ويمكن فحصه في الترويسات الخام |
| From في الترويسة | ترويسة From: | RFC 5322 (P2) | عرض المرسل في برامج البريد | المستخدمون النهائيون |
عند إعادة توجيه البريد، يبقى From في الترويسة alice@client.com. ينشئ خادمك معاملة SMTP جديدة، ويُقيّم SPF بناءً على مرسل المغلف في هذه المحطة. إذا لم يكن خادم الإرسال الجديد مخوّلًا من هذا النطاق، تنشأ المشكلة الموضحة.
ما الذي يفعله مخطط إعادة كتابة المرسل فعليًا
يعيد مخطط إعادة كتابة المرسل صياغة عنوان مرسل المغلف (P1) قبل أن يفتح الخادم الوسيط اتصال SMTP الجديد. ويبقى From في الترويسة، الذي يراه المستخدم، دون تغيير. يستطيع النطاق الجديد للمغلف السماح للخادم الوسيط بالإرسال عبر SPF. وهكذا قد ينجح SPF في الوجهة إذا كان الإعداد صحيحًا، لكن ذلك لا يضمن التسليم أو توافق DMARC مع نطاق From الأصلي.
التشبيه بالبريد التقليدي: من دون مخطط إعادة كتابة المرسل، تستلم خطاب Alice، وتضعه في حقيبة بريد جديدة مع إبقاء عنوان الإرجاع الخاص بها. يرى الطرف الآخر أنك أنت من يوصل الخطاب، لكن عنوان الإرجاع يوحي بأنه أُرسل من Alice، وقد يؤدي ذلك إلى رفضه. مع مخطط إعادة كتابة المرسل، تستبدل عنوان الإرجاع بعنوانك. يصبح مسار الإرجاع متوافقًا معك بوصفك الوسيط. وإذا وجب إرجاع الحقيبة، تصل إليك ثم تعيد توجيهها إلى Alice.
| المكوّن | قبل إعادة التوجيه | بعد إعادة الكتابة بواسطة SRS |
|---|---|---|
| From في الترويسة (P2) | alice@client.com | alice@client.com (دون تغيير) |
| مرسل المغلف (P1) | alice@client.com | SRS0=4fac=PM=client.com=alice@your-agency.com |
| عنوان IP المرسل | خادمك | خادمك |
| نتيجة SPF في المثال | FAIL | PASS |
فهم صيغة عنوان SRS
عندما يكون مخطط إعادة كتابة المرسل نشطًا، يحوّل مرسل المغلف إلى عنوان مرمّز قبل إعادة التوجيه. يجب إعداد نطاق هذا العنوان بما يلائم مسار الإرسال الفعلي. تتضمن الصيغة قيمة تحقق تشفيرية للتحقق، وطابعًا زمنيًا لتحديد مدة الصلاحية، وعنوان المرسل الأصلي لإعادة توجيه إشعارات تعذر التسليم. ليست هذه رموزًا عشوائية، بل بيانات منظّمة. وتعتمد الحماية الفعلية على التنفيذ المستخدم.
مثال على عنوان أُعيدت كتابته بواسطة SRS:
SRS0=4fac=PM=client.com=alice@your-agency.com- SRS0: أول إعادة توجيه. قد يظهر
SRS1عند إعادة توجيه الرسالة لاحقًا، مما يحد من نمو العنوان في التطبيقات التي تدعم هذا السلوك - 4fac: مثال لقيمة تحقق HMAC-SHA1 في هذا التنفيذ؛ وتعتمد الخوارزمية والطول على التنفيذ. تُستخدم للتحقق من إشعارات تعذر التسليم الواردة؛ ويمكن رفض القيم غير الصحيحة للحد من استغلال خادمك في إساءة استخدام الرسائل المرتدة، أو backscatter
- PM: طابع زمني. قد تكون نافذة الصلاحية القابلة للضبط مثلًا 7-21 يومًا. يمكن رفض العناوين المنتهية، لكن ذلك ليس ضمانًا عامًا ضد هجمات إعادة الاستخدام
- client.com=alice: المرسل الأصلي بصيغة مرمّزة، ويُستخدم لإرجاع إشعارات تعذر التسليم إلى العنوان الصحيح
متى تحتاج إلى مخطط إعادة كتابة المرسل
يكون مخطط إعادة كتابة المرسل مهمًا عندما تعيد توجيه البريد تلقائيًا بين نطاقات ولا يسمح سجل SPF للمرسل الأصلي بعنوان IP الوسيط. تجعل سياسات DMARC الصارمة بنية إعادة التوجيه التي تفتقر إلى تدابير مصادقة مناسبة أكثر عرضة للمشكلات. يعالج SRS فحص SPF لنطاق المغلف المعاد كتابته، لا جميع مشكلات التسليم.
نطاق خاص يُعاد توجيهه إلى Gmail شخصي. تمتلك cool-startup.com وتعيد توجيه كل البريد إلى founder@gmail.com. قد يساعد SRS في فحص SPF هنا. من دون إعادة الكتابة، قد يفشل SPF لرسائل البنوك والجهات الحكومية وغيرها من المرسلين ذوي سياسات DMARC الصارمة. وقد يظل نجاح DMARC ممكنًا إذا بقي توقيع DKIM صالح ومتوافق مع نطاق المرسل الظاهر.
مزود خدمات مُدارة أو وكالة تستخدم عنقود بريد مشتركًا. تستضيف 200 نطاق لعملاء ينشئون باستمرار تحويلات إلى مزوديهم، مثل Comcast وAT&T وOutlook. قد يُنسب البريد المزعج الذي تعيد توجيهه إلى عنوان IP المرسل الخاص بك، حتى لو لم تنشئه. يمكن أن تضر مشكلات تفويض SPF والإرسال غير المرغوب فيه بالسمعة وتسهم في الإدراج لدى Spamhaus، وفي سيناريو غير مواتٍ قد يحدث ذلك خلال أسابيع قليلة. لكنه ليس أمرًا حتميًا، ولا خطرًا يزيله SRS وحده.
Microsoft 365 مع موصّل صادر. يستطيع M365 تطبيق SRS داخليًا على مسارات الإرسال المدعومة. عند تمرير الرسائل عبر موصّل صادر، تحقق مما إذا كانت إعادة الكتابة تحدث قبل التسليم إليه. اضبط SenderRewritingEnabled فقط إذا كان الإصدار والموصّل يدعمان ذلك وكان التغيير مصرحًا به. افحص أيضًا سياسة تصفية البريد المزعج الصادر بحثًا عن حظر إعادة التوجيه الخارجي بالرمز 5.7.520: يتعلق هذا بسياسة، وليس دليلًا على فشل SRS.
لماذا لا يكفي مخطط إعادة كتابة المرسل وحده
قد يتيح مخطط إعادة كتابة المرسل نجاح SPF لنطاق المغلف الجديد، لكنه لا يحقق تلقائيًا توافق نطاقات DMARC مع From الأصلي. يتطلب DMARC مصادقة صالحة ومتوافقة عبر SPF أو DKIM. يغيّر SRS نطاق المغلف إلى نطاق الوسيط، لكنه يبقي From في الترويسة على نطاق المرسل الأصلي. إذا لم تتوافق هذه النطاقات، يجب أن يبقى توقيع DKIM صالح ومتوافق حتى ينجح DMARC.
قد تبطل خوادم إعادة التوجيه توقيعات DKIM إذا غيّرت أجزاء موقّعة بطريقة لا تستوعبها قواعد توحيد الصيغة المستخدمة:
- قد تؤدي إضافة
[EXTERNAL]إلى الموضوع إلى إبطال DKIM إذا كانت هذه الترويسة موقّعة - قد تغيّر إضافة تذييل، مثل إشعار فحص الفيروسات أو رابط إلغاء الاشتراك، قيمة تجزئة جسم الرسالة الموقّع وتبطل DKIM
- قد تؤدي إعادة كتابة MIME، مثل تحويل الترميز من 8 بت إلى 7 بت، إلى تغيير محتوى موقّع وإبطال DKIM
في حالة الفشل، لا يتوافق SPF مع نطاق From الأصلي، وتبطل التعديلات DKIM، فيفشل DMARC. قد يرفض المستلم الرسالة وفق سياسته، وقد يحدث رفض SMTP أو يصدر إشعار بتعذر التسليم.
من التدابير المكمّلة ARC (Authenticated Received Chain، RFC 8617). يتيح للوسيط توثيق نتائج المصادقة التي رصدها فعلًا في سلسلة موقّعة. وتُضاف ثلاث ترويسات:
ARC-Authentication-Results: يسجل نتائج SPF وDKIM وDMARC الفعلية عند الاستلام، ولا يعني أن جميعها نجحتARC-Message-Signature: يوقّع أجزاء من الرسالة في حالتها وقت إنشاء توقيع ARC، وليس بالضرورة حالتها الأصلية عند الاستلامARC-Seal: توقيع تشفيري يربط مجموعة ARC بالسلسلة
يمكن لمستلم مثل Gmail تقييم ARC عندما تفشل فحوص المصادقة الحالية لرسالة معاد توجيهها. ويقرر المستلم ما إذا كان يقبل السلسلة ويثق بها عند اتخاذ قرار التسليم. لا يصلح ARC توافق نطاقات DMARC. ولا يمكنك فرض هذه الثقة أو ضمانها بمجرد بناء سمعة للنطاق بمرور الوقت.
كيفية التحقق من عمل مخطط إعادة كتابة المرسل
أرسل رسالة اختبار من حساب خارجي إلى عنوان إعادة التوجيه، وافحص الترويسات الخام في الوجهة. تبيّن ترويسة Return-Path ما إذا كانت إعادة الكتابة بواسطة SRS ظاهرة في هذه الرسالة أو بقي عنوان المرسل الأصلي. افحص نتائج المصادقة أيضًا.
الخطوة 1: فحص Return-Path في الوجهة
# SRS inactive - SPF is almost certainly failing:
Return-Path: <original-sender@protonmail.com>
# SRS active:
Return-Path: <SRS0=xxxx=yy=protonmail.com=sender@your-domain.com>الخطوة 2: فحص DNS لنطاق SRS
# Check SPF on your forwarding domain:
dig TXT your-domain.com | grep spf
# Check MX - bounces need a place to go:
dig MX your-domain.comيحتاج نطاق SRS إلى تفويض SPF مناسب ومسار يمكن الوصول إليه لاستلام إشعارات تعذر التسليم. افحص إعداد MX لهذا الغرض. لا يعني غياب سجل MX أن المسار غير متاح تلقائيًا؛ ففي بعض الظروف يمكن التسليم ضمنيًا عبر سجلات A أو AAAA. المهم أن يعمل مسار الإرجاع الفعلي، وقد تسهم مشكلاته في رفض الرسائل.
الخطوة 3: فحص سجل البريد في Linux
grep "srs_forward" /var/log/mail.logقد تشير رسائل مثل hash mismatch أو timestamp expired إلى عدم تزامن مفاتيح PostSRSd أو تبديل المفاتيح أو تأخر الرسائل أو تلف العنوان أو محاولة إعادة استخدام. وهي لا تثبت وجود هجوم. لا يتضمن Postfix دعم SRS أصليًا؛ ويُعد PostSRSd أحد خيارات التكامل، مع ضرورة فحص الإصدار والإعدادات. اضبط SRS_EXCLUDE_DOMAINS بما يلائم نطاقاتك المحلية وقواعد التوجيه، لتجنب إعادة كتابة الرسائل الداخلية دون حاجة. لا يؤدي غياب استثناء بالضرورة إلى حلقة، لكنه قد يصعّب التشخيص.
البديل الأبسط: التوقف عن إعادة التوجيه
يعالج مخطط إعادة كتابة المرسل مشكلة تنشأ من اتصال SMTP الجديد أثناء إعادة التوجيه. ويمكن لصندوق بريد IMAP فعلي على نطاقك الاستغناء عن هذه الخطوة الإضافية. تصل الرسالة مباشرة إلى الصندوق، ثم يفتحها البرنامج عبر IMAP. يزيل ذلك مشكلات المصادقة الناتجة عن خطوة إعادة التوجيه هذه، لكنه لا يزيل جميع مخاطر SPF أو DKIM أو DMARC. ولا يضمن IMAP مصادقة من طرف إلى طرف.
تشيع إعادة التوجيه لأن أحدًا لا يرغب في دفع رسوم لكل مستخدم مقابل صندوق يستقبل خمس رسائل شهريًا. لذلك يكون SRS أحيانًا جزءًا من حل لمشكلة تسعير، وليس لمسألة تقنية فقط.
يطرح نموذج TrekMail الموصوف نهجًا آخر: تبدأ الخطط من $3.50 شهريًا وتشمل عدة نطاقات مع مساحة تخزين مشتركة بسعر ثابت، دون رسوم لكل مستخدم. تحقق من الأسعار والحدود والمزايا الحالية للخطة المختارة. يمكنك تشغيل sales@yourdomain.com كصندوق IMAP فعلي والوصول إلى رسائله عبر برامج أو تكاملات مدعومة. يعتمد الربط مع Gmail أو Outlook على الدعم المتاح. من دون إعادة توجيه خارجية، تستغني عن إعداد SRS وARC الخاص بهذه الخطوة، بينما تبقى بقية اعتبارات مصادقة البريد مهمة.
للبيئات التي تخدم عدة عملاء، يشرح دليل استضافة البريد لعدة نطاقات كيفية إدارة عشرات النطاقات مركزيًا وتقليل العمل الإداري المتكرر لكل نطاق. وإذا كنت تستخدم إعدادًا هجينًا يجمع صناديق فعلية وتحويلات قديمة، فإن دليل إعادة توجيه الأسماء المستعارة للبريد يوضح إعداد مسار يتضمن SRS.
سواء أبقيت إعادة التوجيه أو انتقلت إلى صناديق فعلية، افهم وظيفة مخطط إعادة كتابة المرسل، وتحقق من تطبيقه، وأضف ARC حيث يتوفر الدعم وتكون له فائدة. قد تتسبب بنية إعادة توجيه غير مكتملة في فقد رسائل مشروعة. وهذه مخاطرة تجارية، لا مجرد تفصيل تقني.
ابدأ بإنشاء حساب TrekMail مجاني، وتحقق من الشروط الحالية للعرض الموصوف دون بطاقة ودون انتهاء الفترة التجريبية. يمكنك بذلك تجربة البريد لعدة نطاقات دون التعقيد الإضافي لإعادة التوجيه.
