لماذا هبطت الرسالة التي أعدتَ توجيهها إلى نفسك في مجلد الرسائل غير المرغوبة

عندما تعيّن إعادة توجيه تلقائية من حسابك القديم إلى الجديد، ستختفي بعض تلك الرسائل بهدوء إلى مجلد الرسائل غير المرغوبة — ليس لأن مزود الخدمة معطّل، بل لأن إعادة التوجيه تعيد كتابة معرّف المُرسل دون إعادة كتابة الإثبات التشفيري. يفحص SPF الخادم الخاطئ، ويتحول حكم DMARC إلى فشل، والرسالة المشروعة التي أرسلتها لنفسك تُوضع في الحجر. للحل اسم: ARC، المعرّف في RFC 8617 منذ عام 2019.

لماذا يجعل التوجيه رسائلي تفشل في SPF؟

لأن SPF يفحص آخر خادم أعاد نقل الرسالة، وإعادة التوجيه تغيّر ذلك الخادم. SPF — Sender Policy Framework — سجل DNS يسرد عناوين IP التي يُسمح لها بإرسال بريد لنطاق معين. عندما يُرسل لك bank.com إيصال استقبال، يفحص الخادم المستقبل: هل وصل هذا من عنوان IP مُصرّح به من bank.com؟ نعم. نجح.

الآن أعد توجيه ذلك الإيصال من Gmail إلى عنوانك الجديد. خوادم Google تعيد نقله إلى الأمام. يشغّل الخادم المستقبل النهائي فحص SPF ويسأل: هل Google مُصرّح لها بالإرسال نيابةً عن bank.com؟ لا، ليست كذلك. SPF يفشل. توثيق Google Workspace الخاص يشرح هذا بوضوح — الرسائل المُعاد توجيهها تفشل في SPF لأن خادم التوجيه ليس في سجل SPF للنطاق الأصلي. لم يحدث انتحال هوية. الفحص ينظر إلى القفزة الخاطئة فحسب.

فلماذا يُرسلها ذلك إلى الرسائل غير المرغوبة؟

DMARC. كان فشل SPF وحده قابلاً للبقاء في السابق؛ DMARC حوّله إلى حكم. DMARC يربط SPF و DKIM معاً ويخبر المستقبلين ماذا يفعلون عندما يفشل كلاهما: لا شيء، أو الحجر، أو الرفض. بحلول عام 2024، لم يكن أمام المُرسلين الكبار خيار — بدأت Google و Yahoo في المطالبة بـ DMARC من أي شخص يُرسل أكثر من 5,000 رسالة يومياً إلى مستخدميهما.

DKIM، العمود الآخر، توقيع مدمج في الرسالة. من الناحية النظرية، يصمد أمام إعادة التوجيه، لأنه يوقّع المحتوى وليس المسار. من الناحية العملية، أي شيء يلمس الرسالة يكسره. قائمة بريدية تُضيف تذييراً مثل "أنت مشترك، إلغاء الاشتراك هنا"، أو خادم يُعيد كتابة سطر الموضوع، أو حتى تغيير في طريقة التفاف السطر — التوقيع لم يعد متطابقاً، و DKIM يفشل أيضاً. الآن العمودان معاً صارا في الأسفل، DMARC يقول فشل، وإيصالك الخاص في مجلد المحذوفات.

ما هو ARC وهل يُصلح هذا فعلاً؟

ARC — Authenticated Received Chain, RFC 8617 — يسمح لمُعيد توجيه صادق أن يشهد بأن البريد اجتاز المصادقة قبل أن يلمسه. خادم التوجيه يختم الرسالة بسجل مختوم يقول "عندما وصلت إليّ، كان SPF و DKIM صالحين — ثق بكلامي للقفزة التي لا تستطيع التحقق منها." المستقبل النهائي، إن ثق بذلك مُعيد التوجيه، يستطيع تجاوز فشل DMARC والتسليم.

المشكلة في "إن ثق". ARC ليست كلمة مرور؛ إنها نظام سمعة. يزن المستقبل ما إذا كان ختم ARC مشغلاً معروفاً وحسن التصرف. Google تختم رؤوس ARC وتحترمها من المُرسلين الذين تثق فيهم، وهذا هو السبب في أن إعادة التوجيه من Gmail إلى Gmail عادةً ما تصمد بينما إعادة التوجيه عبر بعض مرحل جامعي قديم لا تصمد.

إذا كنت تشغّل إعادة التوجيه بنفسك، فإن حركتين ملموستين تساعدان. استخدم Server-Side Redirect / SRS-style rewriting إن عرضها مزودك، والتي تعيد كتابة مُرسل الغلاف بحيث تفحص SPF خادمك بدلاً من النطاق الأصلي. وفضّل إعادة التوجيه بين مزودي خدمة يدعم كلاهما ARC. إذا كنت تدمج الحسابات وتريد من الوجهة أن تتعامل ببساطة مع فوضى المصادقة نيابةً عنك، فهذا بالضبط نوع السباكة المدمجة التي منصة البريد الإلكتروني المدعومة بالذكاء الاصطناعي مبنية لاستيعابه.

متى يجب أن أتوقف عن لوم مزود الخدمة؟

عندما يكون النمط "فشل البريد المُعاد توجيهه فقط"، فإن مزود الخدمة يؤدي عمله بشكل صحيح — البروتوكول هو المشكلة. إليك المؤشر: افتح رؤوس الرسالة المفقودة وابحث عن السطر Authentication-Results. إذا رأيت spf=fail إلى جانب عنوان IP مُرسل ينتمي إلى مُعيد توجيه وليس المُرسل الأصلي، فهذا يعني أن SPF يفحص القفزة الخاطئة. إذا ظهر dkim=fail على بريد مرّ عبر قائمة أو مرحل يُعدّل الرسائل، فهذا توقيع مشوّه وليس تزييف.

الحقيقة غير المريحة هي أن المصادقة في البريد الإلكتروني تم لصقها، طبقة فوق طبقة، على مدى عقدين على نظام لم يفترض أبداً أن أحداً قد يكذب. SPF جاء في 2006، DKIM في 2007، DMARC في 2015، ARC في 2019 — كل واحد يُصلح ثقباً فتحه السابق. التوجيه هو اللحام حيث يحتك الأربعة معاً، وصندوق بريدك هو المكان الذي تشعر فيه بالاحتكاك.

@@END@@