ارتداد البريد الإلكتروني: كيف تقرأه وماذا تعني رموزه

ما هو الارتداد، واللحظتان اللتان يحدث فيهما

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

يمكن أن يُنتَج في لحظتين مختلفتين تمامًا، والتمييز بينهما هو معظم التشخيص. وهناك نتيجتان أخريان تبدوان فشلاً من موضعك، وليستا كذلك:

فعبارة «لقد ارتدت» تسمّي شيئين. أحدهما خطأ عرضه عليك برنامجك أنت، والآخر رسالة كتبتها لك آلة تخص شخصًا غريبًا، ولا يحمل تقريرًا تقرؤه سوى الثاني منهما. وبقية هذا الدليل تدور حول ذلك التقرير.

أين يكمن السبب فعلاً

تقرير التسليم رسالة من ثلاثة أجزاء، وشكله ثابت منذ RFC 3464. الجزء الأول هو الاعتذار، كتبته الآلة الأقرب إليك لإنسان يقرؤه. والثاني هو الكتلة المقروءة آليًا، وهي الجزء الوحيد الذي يحمل حقائق. والثالث هو رسالتك الأصلية، أو ترويستها فقط، حتى تستطيع معرفة أيّها فشلت.

From: Mail Delivery System <MAILER-DAEMON@mail.example.org>
To: <you@example.org>
Subject: Undelivered Mail Returned to Sender
Content-Type: multipart/report; report-type=delivery-status;
        boundary="B7F21C4"

--B7F21C4
Content-Type: text/plain; charset=us-ascii

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients.

--B7F21C4
Content-Type: message/delivery-status

Reporting-MTA: dns; mail.example.org
Arrival-Date: Tue,  8 Sep 2026 10:14:02 +0000

Final-Recipient: rfc822; sales@example.com
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.example.com
Diagnostic-Code: smtp; 550 5.1.1 <sales@example.com>: Recipient
        address rejected: User unknown in virtual mailbox table

--B7F21C4
Content-Type: text/rfc822-headers

اقرأ الجزء الأوسط بهذا الترتيب:

Final-Recipient:

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

Action:

failed ارتداد. وdelayed تحذير بأن خادمًا لا يزال يحاول ولم يتخل عن شيء بعد؛ وقد يصلك تقرير ثانٍ يقول إنها نجحت. أما relayed وdelivered فليسا فشلاً على الإطلاق، ويسهل إساءة قراءة أحدهما على أنه كذلك.

Status:

رمز الحالة الموسّع — ثلاثة أرقام، مُعدّة لتقرأها البرمجيات لا أنت. وهو الجزء القابل للمقارنة بين مزوّد وآخر، وهو ما لا تستطيعه الجمل أبدًا.

Diagnostic-Code:

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

Remote-MTA:

أيّ مضيف قاله. يستحق نظرة كلما كان الفشل متعلقًا بالتوجيه: فاسم مضيف لا تعرفه يعني عادة أن بريد النطاق يذهب إلى مكان لم تتوقعه، أو مكان كان يذهب إليه سابقًا فقط.

الجملة في أعلى التقرير تمامًا ليست دليلاً. يكتبها خادم الصادر الخاص بك، بأي صياغة يصادف أن تأتي بها برمجيته، عن فشل هو ينقله فحسب. ويمكن أن يقبع اعتذاران متطابقان فوق سطري Diagnostic-Code: لا صلة بينهما إطلاقًا، ولهذا يُساء قراءة الارتداد كثيرًا حين يُقرأ من الأعلى.

الرقمان، والرقم الذي يحسم الأمر

يُكتب الرفض على هذا النحو، وهو ثلاثة أشياء منفصلة تربط بينها مسافات:

550 5.1.1 <sales@example.com>: Recipient address rejected: User unknown

550 هو رمز الرد: ثلاثة أرقام، حدّدها بروتوكول SMTP نفسه في RFC 5321، وهو الجزء الذي يحتاجه البروتوكول ليقرر ما يفعله بعد ذلك. و5.1.1 هو رمز الحالة الموسّع من RFC 3463، أُضيف لأن ثلاثة أرقام لم تكن كافية للتعبير. وكل ما يأتي بعده نص حر، يكتبه مَن يُشغّل ذلك الخادم، ولا يُقنّنه أي شيء إطلاقًا.

يبدأ كلا الرقمين بالرقم نفسه، وذلك الرقم هو الحكم:

الرقم الثاني هو الموضوع — أي نوع من الأشياء قد اختل. وهو أسرع طريقة لتصنيف رمز لم تره من قبل قط:

ارتداد دائم (Hard bounce)

5. العنوان خاطئ، أو زال، أو مرفوض بحكم السياسة، وإعادة إرسال الرسالة نفسها لا تغيّر شيئًا. يحذف مرسِلو البريد الجماعي العنوان من القائمة عند أول ارتداد من هذا النوع، لأن الاستمرار هو ما يجعل نطاق الإرسال يُقيَّد في كل مكان دفعة واحدة.

ارتداد مؤقت (Soft bounce)

4. صندوق بريد ممتلئ، أو خادم مشغول، أو رفض مؤقت بحكم السياسة. تُعاد محاولته دون تدخل من أحد وعادة ما يصل؛ ولا تسمع به إلا إن نفدت المحاولات أولاً.

لا يرد أي من المصطلحين في أي مواصفة. إنهما اختصار صناعة الإرسال لذلك الرقم الأول، وهذا الاختصار يستحق معرفته لأن كل أداة قابلية تسليم ستُسلَّم لك يومًا ما تُقدّم تقاريرها به.

الرموز التي ستقابلها فعلاً

هناك عشرات الرموز في السجل الذي تحتفظ به IANA، ونحو دزينة منها فقط في الحياة العادية. وهذه الدزينة تغطي كل ارتداد يقرؤه أي أحد تقريبًا:

توجد رموز خارج هذه القائمة، ولكل منها معنى، لكن الرمز الذي لم تره من قبل قط يكون في الغالب .7. — سياسة أحدهم، موصوفة بكلماته هو في السطر المجاور له.

ما الذي يمكن أن يرتد وما لا يمكن عند عنوان مؤقت

لا شيء تقريبًا — وهذا يستحق التوضيح، لأن ثلاثة من الأشياء التي يصفها الناس هنا بأنها ارتداد ليست كذلك:

«المستخدم غير معروف» لا يمكن أن يحدث

يقبل الخادم كل اسم على نطاقاته العامة. anything@grabmail.io عنوان صالح قبل أن يكتبه أحد، لأنه لا توجد قائمة صناديق بريد يُقارَن بها — فرمز 5.1.1 من GrabMail شيء غير موجود أصلاً. كيف يعمل البريد المؤقت من الداخل يشرح الآلية كاملة.

انتهاء الصلاحية ليس ارتدادًا

تُحذف الرسالة بعد 5 يومًا من وصولها، وبحلول ذلك الوقت يكون خادم الإرسال قد سمع 250 منذ زمن ونسي التبادل كله. لا يُخطَر أحد، لأن شيئًا لم يفشل: فقد سُلِّمت الرسالة، ثم حُذفت لاحقًا. كم تدوم صناديق البريد المؤقتة هو الدليل الخاص بهذا النصف.

النموذج الذي يرفض العنوان ليس ارتدادًا

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

الصمت أيضًا ليس ارتدادًا

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

يبقى بعد ذلك رفض حقيقي واحد بالضبط، وهو سقف الحجم. فخادم الإرسال الذي يعلن الحجم مقدَّمًا يُصَدّ فورًا، قبل أن تُخزَّن أي بايت واحد:

>>> MAIL FROM:<news@example.com> SIZE=7602176
<<< 552 5.3.4 Message size exceeds fixed limit

أما المرسِل الذي لا يعلن الحجم فيحصل على الإجابة نفسها في نهاية الرسالة بدلاً من ذلك، حالما تُحسب البايتات له. وفي الحالتين يكون الرمز 5.3.4، ولا يُخزَّن شيء، ويُخبَر شخص حقيقي من نظام بريده هو — وهذا هو السبب الكامل للرفض عند الباب بدلاً من القبول ثم الإتلاف.

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

الارتدادات على نطاق وجّهته للتو إلى هنا

توجيه نطاق إلى صندوق catch-all هو سجل DNS واحد، وتكاد كل الارتدادات التي ينتجها تخص الساعة المحيطة بالتغيير لا الإعداد نفسه. وهناك خمس حالات، ويختلف مظهر كل منها عن الأخرى:

1. قبل وجود السجل. نطاق بلا MX وبلا سجل عنوان يُعتمد عليه بديلاً يعطي المرسِلين 5.4.4 أو 5.1.2: فلا مكان للتسليم ولا شيء يستحق إعادة المحاولة.
2. أثناء انتشار التغيير. يحتفظ المرسِلون الذين استعلموا عن السجل بالفعل بالإجابة القديمة حتى ينتهي TTL الخاص بها. والارتداد في هذه الفترة يذكر المضيف القديم في سطر Remote-MTA:، وهذا بالضبط ما يميزه عن سجل أخطأت في ضبطه.
3. بعد اكتمال الانتشار. يُقبل كل اسم على النطاق، فيتوقف «المستخدم غير معروف» عن أن يكون ممكنًا هناك أيضًا. سجل واحد، أولويته 10، يشير إلى smtp.grabmail.io، ولا شيء آخر يلزم نشره ليصل البريد.
4. إن كان النطاق ينشر سابقًا سجل MX فارغًا. كثيرًا ما تحمل النطاقات المركونة السجل الذي معناه «هذا النطاق لا يستقبل بريدًا أبدًا». والمرسِلون الذين خزّنوا ذلك السجل مؤقتًا يجيبون بـ5.1.10 إلى أن تنتهي صلاحيته، أيًّا كان ما نشرته منذ ذلك الحين.
5. إن كان النطاق يرسل بريدًا أيضًا. ظهور 5.7.26 على بريد صادر لا علاقة له بأي من هذا — بل هو إخفاق SPF أو DMARC الخاصين بك في تغطية أيًّا كان ما أرسل الرسالة. دليل النطاق المخصص للاستقبال فقط هو الحالة الصارمة؛ أما النطاق الذي يرسل أيضًا فيحتاج إلى الطرح التدريجي المعتاد بدلاً من ذلك.

قراءة السجل تجيب عن معظم ذلك قبل أن يضطر أحد لقراءة ارتداد:

$ dig +short MX yourdomain.com

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

ارتداد لرسالة لم ترسلها قط

يصل بمظهر تقرير فشل عادي تمامًا، ينقل رسالة لم ترها قط، إلى مستلم لم تسمع به قط. لم يُخترق شيء. فقد أرسل أحدهم بريدًا كُتب فيه عنوانك أنت في المغلّف بصفته المرسِل، وقبِله خادم مستقبِل قبل أن يكتشف أنه لا يستطيع تسليمه، ثم فعل الصواب مع رسالة فاشلة: كتب تقريرًا وأرسله إلى المرسِل الذي أُعطيه. وهذا المرسِل هو أنت.

اسم هذه الظاهرة ارتداد الانتحال (backscatter)، وما تثبته يستحق أن يُقال بوضوح: لا شيء عن صندوق بريدك. فتزوير مرسِل المغلّف لا يحتاج إلى أي وصول لأي شيء — إنه سطر واحد يُكتب في محادثة. ومن فعل ذلك لم يحتج إلا إلى عنوانك ولا شيء غيره، وربما خمّنه فحسب.

ثلاثة أشياء تفصله عن ارتداد حقيقي في نحو عشر ثوانٍ:

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

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

اسم قصير على نطاق عام مشترك يجمع من هذا أكثر مما يجمعه عنوان خاص، لنفس السبب الذي يجعله يجمع بريدًا مزعجًا أكثر: فهو سهل التخمين، والمزوِّر الذي يختار مرسِلي المغلفات لا يستهدفك أنت بعينك. إنه ضجيج بخصوص شخص آخر، وخلافًا للبريد المزعج لا يوجد زر يُدرّب أي شيء — ماذا تفعل أزرار البريد المزعج فعلاً هو الدليل الخاص بالأزرار التي تنفع فعلاً.

الترتيب الذي تقرأ به واحدًا

1. حدّد أي نوع بين يديك. الخطأ في تطبيق بريدك أنت لحظة ضغطك على الإرسال رفض. أما الرسالة من MAILER-DAEMON التي وصلت بعد ذلك فهي تقرير، ولا يحمل شيئًا تقرؤه سوى التقرير.
2. تحقق من أنه عن رسالة أرسلتها فعلاً. النسخة المُعادة موجودة في الجزء الثالث. فإن لم تكن رسالتك، فهذا ارتداد انتحال، وقد انتهيت.
3. افتح المصدر الخام. الاعتذار في الأعلى هو الصياغة الجاهزة لخادمك أنت، لا السبب، والكتلة المقروءة آليًا لا تُعرض افتراضيًا في أي مكان.
4. ابحث عن Status: واقرأ الرقم الأول. فـ4 لا تزال إعادة محاولته جارية وقد تنجح من تلقاء نفسها؛ أما 5 فنهائي ولن يحدث شيء آخر.
5. اقرأ Diagnostic-Code:. هذه جملة الطرف البعيد نفسه، والمكان الوحيد الذي تُسمّى فيه فعلاً القاعدة التي رفضتك.
6. حدّد موقع الرقم الثاني. .1. هو العنوان، و.2. صندوق البريد، و.4. المسار، و.7. سياسة أحدهم. وهذا يكفي عادة لمعرفة مشكلة مَن هي.
7. تصرّف بحسب مشكلة مَن هي. فشل العنونة يُصلح بالحصول على العنوان الصحيح؛ وفشل التوجيه بإصلاح DNS؛ وفشل السياسة باستيفاء تلك السياسة، أو بأن تطلب من الطرف الآخر النظر في سجلاته الخاصة — حيث يكون الرفض نفسه مدوَّنًا بتفصيل أكبر بكثير مما أُرسل إليك.

أمران ليسا الحل أبدًا. فإعادة إرسال الرسالة دون تغيير بعد 5 يكرر الرفض نفسه، ويضر — إن تكرر بما يكفي — بسمعة نطاق الإرسال في كل مكان دفعة واحدة. والرد على التقرير لا يصل إلى أحد: فقد جاء من مرسِل مغلّف فارغ، وهذا بالضبط ما جعل تسليمه إليك ممكنًا أصلاً.

أسئلة