مخطط إعادة كتابة المرسل SRS: الدور والحدود

تضبط إعادة توجيه من contact@your-agency.com → you@gmail.com، وتختبرها فتعمل. بعد أسبوعين، لا تصل رسالة تتضمن عقدًا من عميل مؤسسي، ولا تجدها في البريد المزعج. تفحص السجلات فتجد: 550 5.7.1 Unauthenticated email. أو يظهر 550 5.7.520 Access denied، الذي قد يدل في Microsoft 365 على قيد يمنع إعادة التوجيه الخارجي الصادر. يحتاج كل خطأ إلى تشخيص مستقل. وغياب الرسالة لا يعني أنه لم يحدث رفض SMTP أو إشعار بتعذر التسليم.

من التدابير الممكنة لمشكلات SPF الناتجة عن إعادة التوجيه مخطط إعادة كتابة المرسل SRS. قد يفشل SPF من دون إعادة كتابة إذا لم يسمح نطاق مرسل المغلف الأصلي للخادم الوسيط بالإرسال. وفي 2026، لا تعني متطلبات Google وYahoo أن جميع المرسلين ملزمون عمومًا بسياسة DMARC p=reject (متطلبات Google لمرسلي البريد الإلكتروني). قد تؤدي السياسات الصارمة إلى الرفض عند غياب مصادقة متوافقة مع نطاق المرسل الظاهر. يشرح هذا الدليل عمل SRS على مستوى البروتوكول وحدوده والتدابير المكمّلة له.

لفهم الصورة كاملة، ابدأ بدليل إعداد إعادة توجيه البريد ومعالجة المشكلات الشائعة.

ما هو مخطط إعادة كتابة المرسل (SRS)؟

يعيد مخطط إعادة كتابة المرسل SRS صياغة مرسل المغلف، وقد يمنع فشل SPF الناتج عن إعادة التوجيه. قبل أن يمرر خادمك الرسالة، يستبدل عنوان مغلف SMTP (MAIL FROM) بعنوان على نطاق إعادة التوجيه الخاص بك. لا يظهر هذا العنوان عادةً بوصفه المرسل في الواجهة، لكنه قابل للفحص في الترويسات الخام. يتحقق المستلم بعدها من SPF لنطاقك. وقد ينجح الفحص إذا كان سجل DNS يسمح بمسار الإرسال الفعلي وكانت بقية الإعدادات صحيحة. من دون إعادة الكتابة، قد لا يسمح النطاق الأصلي لخادمك بالإرسال. لكن فشل SPF وحده لا يثبت انتحال الهوية ولا يعني تلقائيًا فشل DMARC.

مستويان لهوية مرسل البريد

يسهل تشخيص SRS عندما تميّز بين هويتين مختلفتين للمرسل. يفحص SPF مستوى المغلف. ويتحقق DMARC من أن مصادقة صالحة واحدة على الأقل، عبر SPF أو DKIM، تتوافق مع نطاق From الظاهر. وقد تغيّر إعادة التوجيه هذه العلاقات.

يشارك المغلف في نقل SMTP ويحدد مسار إرجاع إشعارات تعذر التسليم؛ ويفحص SPF نطاق مرسله. أما From في الترويسة فيظهر في برنامج البريد ويوفر النطاق المرجعي لفحص توافق DMARC. عندما تنشئ إعادة التوجيه اتصال SMTP جديدًا، قد لا يشمل تفويض SPF الأصلي الخادم الجديد. يمكن أن يساعد SRS في هذا الفحص، لكنه لا يحل جميع مشكلات المصادقة.

محطة جديدة: لماذا قد يفشل SPF عند إعادة التوجيه

عند إعادة توجيه الرسالة، يفتح خادمك اتصال SMTP جديدًا مع الوجهة، مضيفًا محطة إلى المسار. يظل مرسل المغلف alice@bank.com، لكن عنوان IP للاتصال يصبح عنوانك. يفحص SPF هذا العنوان وفق سجل bank.com. إذا لم يكن مخوّلًا، يفشل SPF. وإذا نشر bank.com سياسة DMARC p=reject، فقد يرفض المستلم الرسالة عند غياب توقيع DKIM صالح ومتوافق أيضًا. قد يظهر خطأ SMTP أو إشعار بتعذر التسليم؛ فالرفض ليس صامتًا دائمًا.

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

كيف يعيد مخطط إعادة كتابة المرسل (SRS) صياغة المغلف

يستبدل SRS عنوان المغلف MAIL FROM بعنوان على نطاق إعادة التوجيه قبل فتح اتصال SMTP الجديد. قد يتيح ذلك نجاح SPF لهذا النطاق. وتبقى ترويسة From: التي يراها المستلم كما حددها المرسل الأصلي.

# WITHOUT SRS - SPF fails downstream
Return-Path: <alice@bank.com>
Received-SPF: fail (IP not authorized for bank.com)

# WITH SRS - SPF passes on your domain
Return-Path: <SRS0=4fac=PM=bank.com=alice@your-domain.com>
Received-SPF: pass (IP authorized for your-domain.com)

في المثال، يفحص خادم الوجهة SPF في your-domain.com، الذي يسمح لخادمك بالإرسال. ينجح SPF تحت هذا الشرط. ويستمر المستلم في رؤية From: alice@bank.com. أتاح SRS فحص SPF المباشر، لكن التوافق مع نطاق From الأصلي يحتاج إلى تقييم منفصل.

فهم صيغة عنوان SRS

قد يبدو عنوان SRS في Return-Path معقدًا، لكن لكل جزء وظيفة. يساعد فهم بنيته في التعرف على إعادة الكتابة الظاهرة والتحقيق في الأخطاء بصورة أدق.

مثال: SRS0=4fac=PM=bank.com=alice@your-domain.com

العقبة الثانية: لا يحقق SRS توافق نطاق SPF

ثمة فرق مهم: قد يتيح SRS نجاح فحص SPF، لكنه لا يحقق تلقائيًا توافق نطاق SPF مع From الظاهر. يحتاج DMARC إلى SPF أو DKIM صالح ومتوافق. لذلك قد تستمر الرسائل المعاد توجيهها في الفشل حتى مع إعداد SRS بصورة صحيحة.

يتطلب DMARC توافق نطاق اجتاز المصادقة مع نطاق الترويسة الظاهرة From:. في المثال مع تفعيل SRS:

• فحص SPF: PASS - عنوان IP الخاص بك مخوّل من نطاق المغلف your-domain.com
• توافق نطاق SPF: FAIL - المغلف your-domain.com ≠ الترويسة bank.com

عند غياب توافق SPF، يعتمد نجاح DMARC على توقيع DKIM صالح ومتوافق. إذا وقّع المرسل الأصلي بهذه الطريقة وبقيت الأجزاء الموقعة سليمة وفق قواعد توحيد الصيغة المستخدمة، فقد ينجح DMARC عبر DKIM. قد تبطل تنبيهات مثل “External Email”، أو تذييلات برامج مكافحة الفيروسات، أو تحويلات MIME من ترميز 8 بت إلى 7 بت توقيع DKIM عندما تغيّر محتوى موقّعًا.

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

ARC كإضافة إلى مخطط إعادة كتابة المرسل SRS

يكمّل ARC (Authenticated Received Chain، RFC 8617) عمل SRS. بينما يعيد SRS كتابة المغلف لفحص SPF، يستطيع الوسيط استخدام ARC لتوثيق نتائج المصادقة التي رصدها فعلًا بتوقيعات. يحصل المستلم التالي على معلومات عن الفحوص السابقة. لا يعني ذلك أن جميعها نجحت أو أن الرسالة خالية من البريد المزعج.

يضيف ARC ثلاث ترويسات: ARC-Authentication-Results وARC-Message-Signature وARC-Seal. يمكن للنتائج توثيق المصادقة السابقة. لكن توقيع الرسالة حساس للتعديلات في المحتوى الموقّع، ولا يصمد أمام كل تغيير في متن الرسالة. كما لا يصلح ARC توقيع DKIM غير صالح ولا يعيد توافق نطاقات DMARC.

القيد المهم: يقرر المستلم ما إذا كان يثق بجهة توقيع ARC والسلسلة. في Microsoft 365، يمكن لمسؤول مخوّل إعداد جهات توقيع ARC موثوقة عبر PowerShell باستخدام Set-ArcConfig، عندما تدعم إعدادات المستأجر الحالية ذلك وتتطلبه. ليست هذه خطوة يدوية واجبة في كل بيئة. ولا يمكن فرض ثقة Gmail يدويًا أيضًا.

في بيئات الإنتاج، يمكن أن يتكامل SRS وARC: يساعد SRS فحص SPF للمغلف الجديد، ويقدم ARC سياقًا لقرار المستلم. ليسا إلزاميين في كل إعداد، ولا يضمنان معًا تسليمًا موثوقًا إلى جميع المزودين الكبار.

تشخيص مشكلات SRS: قائمة تحقق

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

1. افحص ترويسة Return-Path

أرسل رسالة اختبار من حساب خارجي عبر إعادة التوجيه، ثم افحص الترويسات الخام في الوجهة النهائية. النتائج التالية مثال، وليست تشخيصًا يعتمد على العنوان وحده.

# SRS inactive - SPF will fail
Return-Path: <original-sender@external.com>
Authentication-Results: spf=fail (IP not authorized for external.com)

# SRS active - SPF passes on your domain
Return-Path: <SRS0=xxxx=yy=external.com=sender@your-domain.com>
Authentication-Results: spf=pass (IP authorized for your-domain.com)

2. افحص قيود الإرسال الصادر في Microsoft 365

إذا كنت تعيد توجيه الرسائل من Microsoft 365 إلى الخارج وينطبق قيد السياسة التالي، تُحظر الرسائل قبل مغادرة المستأجر. لا يصلح SRS على خادم لاحق هذا الحظر.

550 5.7.520 Access denied, Your organization does not allow external forwarding.

راجع سياسة تصفية البريد المزعج الصادر في بوابة Defender. لا تغيّرها إلا بتفويض من المؤسسة ومع تدابير حماية مناسبة. لا يعالج SRS على خادم الاستقبال هذا القيد، ولا ينبغي استخدامه لتجاوزه.

3. افحص حلقات التوجيه

إذا أعاد A التوجيه إلى B ثم أعاد B التوجيه إلى A، فقد يتكرر الإرسال بحسب القواعد والحماية من الحلقات. ابحث في السجلات عن مؤشرات مثل هذه:

554 5.4.14 Hop count exceeded
5.4.6 Routing loop detected

بدل إعادة التوجيه، استضف صناديق بريد فعلية

قد يكون إعداد postsrsd وإدارة مفاتيح HMAC والتحقيق في فشل توافق نطاقات DMARC جزءًا من العبء التشغيلي لإعادة توجيه البريد المهني إلى صناديق شخصية تجنبًا للرسوم لكل صندوق. يعالج SRS مشكلة في هذه البنية. ويمكن لصندوق يستقبل البريد مباشرة الاستغناء عن محطة إعادة التوجيه الإضافية.

بدل إعادة توجيه contact@client-domain.com إلى Gmail وإدارة إعداد SRS، يمكنك استضافة contact@client-domain.com كصندوق IMAP فعلي لدى TrekMail. يمكنك الوصول عبر برنامج بريد متوافق، بما في ذلك تطبيق Gmail عندما يدعم التكامل المطلوب عبر IMAP. ويحدث التسليم مباشرة إلى الصندوق. تستغني عن محطة إعادة التوجيه عبر SMTP وإعادة كتابة المغلف الخاصة بها، لا عن جميع مشكلات المصادقة. قارن النهجين في دليل إعادة توجيه بريد النطاق إلى Gmail أو في المقارنة بين الاسم المستعار وصندوق البريد.

هل تدير عدة نطاقات لعملاء؟ بدل التحقيق في SRS على كل خادم، يمكنك إدارة النطاقات مركزيًا لدى TrekMail بصناديق منفصلة. يعتمد الفصل والتوافر ووقت الإعداد على التهيئة والمزايا الحالية؛ ولا يُضمن الإعداد خلال دقائق أو العزل الأمني المطلق. يشرح دليل استضافة البريد لعدة نطاقات الإدارة المركزية والعمل المرتبط بها.

تبدأ خطط TrekMail الموصوفة من $3.50 شهريًا مع تجربة مجانية لمدة 14 يومًا. تحقق من الأسعار والحدود وشروط التجربة الحالية. أنشئ صناديق بريد فعلية لتجنب العبء الإضافي لإعادة التوجيه.