كيف تقرأ رؤوس البريد الإلكتروني: دليل خطوة بخطوة لتتبّع أي رسالة

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

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

ما هي رؤوس البريد ولماذا تهمّ

الرؤوس أسطر بصيغة الاسم: القيمة في أعلى الرسالة الخام، يحدّدها RFC 5322. بعضها يكتبه المرسِل (From وSubject وDate)، وبعضها تضيفه الخوادم في الطريق (Received وAuthentication-Results وReturn-Path). وقد يُلَفّ الرأس الواحد على عدة أسطر: السطر التالي يبدأ بمسافة أو Tab ويتبع السطر الذي فوقه. تقرأ الرؤوس من أجل:

• تشخيص مشكلات التسليم: ترى بالضبط أي فحص مصادقة فشل ولأي نطاق.
• التحقيق في التصيّد والانتحال: هل تطابق البنية المرسِلة المرسِلَ المُدّعى؟
• إيجاد التأخير: قارن الأوقات بين القفزات لترى أين علقت الرسالة.
• التحقق من إعدادك: تأكّد أن سجلّ SPF أو مفتاح DKIM الجديد يعمل على بريد حقيقي، لا في أداة فحص DNS فقط.

كيف تعرض الرؤوس الكاملة في Gmail وOutlook وApple Mail

التطبيق	أين تضغط
Gmail (الويب)	افتح الرسالة ← ⋮ (المزيد) ← Show original، ثم انسخ النص من الصفحة التي تُفتح.
Outlook (سطح المكتب)	افتح الرسالة في نافذتها ← File ← Properties ← انسخ مربع Internet headers.
Outlook (الويب / Outlook الجديد)	افتح الرسالة ← ⋯ ← View ← View message details.
Apple Mail	حدّد الرسالة ← View ← Message ← All Headers (أو Raw Source).
Yahoo Mail	افتح الرسالة ← ⋯ ← View raw message.

انسخ كل ما فوق أول سطر فارغ؛ فهذا السطر هو نهاية الرؤوس وبداية نص الرسالة. تتغيّر أسماء القوائم بين الإصدارات، فإن لم تجد هذه التسميات بالضبط فابحث عن «original» أو «source» أو «internet headers» أو «message details».

🔍محلّل رؤوس البريداقرأ SPF وDKIM وDMARC ومسار القفزات وتأخيرها وتوافق النطاقات من رؤوس الرسالةافتح الأداة →

الحقول الأهم في الرؤوس

قد تحمل الرسالة الحقيقية 30 رأسًا أو أكثر. هذه هي التي تستحق انتباهك:

الرأس	ماذا يخبرك	من يكتبه
From	العنوان الظاهر للقارئ («header From»). يطابق DMARC هذا النطاق.	المرسِل (يمكن تزويره).
Return-Path	مرسِل الظرف الذي تعود إليه الارتدادات (MAIL FROM في SMTP). يُفحص SPF مقابل هذا النطاق.	الخادم المستقبِل، من جلسة SMTP.
Reply-To	وجهة الردود إن اختلفت عن From.	المرسِل.
Received	سطر لكل قفزة: أي خادم استلم الرسالة، ومن أين، ومتى.	كل خادم (الأحدث في الأعلى).
Authentication-Results	حكم الخادم المستقبِل على SPF وDKIM وDMARC.	مزوّد بريدك.
DKIM-Signature	التوقيع: نطاق التوقيع (d=) والمحدِّد (s=) والرؤوس الموقَّعة (h=).	النظام المرسِل.
ARC-Seal وARC-Message-Signature وARC-Authentication-Results	سلسلة Authenticated Received Chain: نتائج يحفظها وسيط مثل قائمة بريدية أو معيد توجيه.	خوادم إعادة التوجيه.
Message-ID	معرّف فريد، ينتهي عادة بنطاق المرسِل.	النظام المرسِل.
Date	وقت إنشاء برنامج المرسِل للرسالة.	المرسِل.

اقرأ سلسلة Received من الأسفل إلى الأعلى

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

يبدو السطر النموذجي هكذا:

Received: from mail-out.sender.example (mail-out.sender.example. [203.0.113.25])
        by mx.example.net with ESMTPS id abc123
        for <me@example.net>;
        Tue, 03 Oct 2023 10:11:13 -0700 (PDT)

• from هو الاسم الذي أعلنه الخادم المرسِل، يليه بين قوسين مربعين عنوان IP الذي رآه خادمك فعلًا. ثق بعنوان IP بين القوسين لا بالاسم.
• by هو الخادم الذي كتب هذا السطر.
• with هو البروتوكول (ESMTP، وESMTPS تعني أن TLS استُخدم).
• يتيح لك الطابع الزمني بعد الفاصلة المنقوطة حساب التأخير بين القفزات.

مثال عملي: أين ذهب الوقت؟

خذ ثلاث قفزات بعد قراءتها من الأسفل إلى الأعلى: يسلّم خادم التطبيق الرسالة عند 17:11:10 +0000، ويمرّرها المُرحِّل الصادر إلى مزوّدك عند 10:11:13 -0700، ويخزّنها مزوّدك عند 10:11:15 -0700. حوّل كل وقت إلى UTC قبل الطرح: 10:11:13 -0700 تساوي 17:11:13 UTC. فيكون التأخير 3 ثوانٍ ثم ثانيتين، أي 5 ثوانٍ من البداية إلى النهاية. ولو لم تحوّل المناطق الزمنية لاستنتجت أن الرسالة استغرقت سبع ساعات.

الفروق الصغيرة من 0 إلى 5 ثوانٍ طبيعية. أما الدقائق أو الساعات فتعني عادة قائمة رمادية (greylisting) أو طابورًا أو مُرحِّلًا مزدحمًا. والأرقام السالبة غالبًا انحراف ساعات بين الخوادم لا خطأ في الرسالة.

قراءة Authentication-Results: SPF وDKIM وDMARC

رأس Authentication-Results (RFC 8601) هو أسرع طريقة لترى كيف حكم الخادم المستقبِل على الرسالة. تُكتب كل طريقة بصيغة method=result تليها خصائص تسمّي الهوية التي فُحصت:

Authentication-Results: mx.example.net;
  dkim=pass header.i=@sender.example header.s=s1;
  spf=pass smtp.mailfrom=bounce@sender.example;
  dmarc=pass (p=REJECT) header.from=sender.example

قيم النتائج

الطريقة	النتائج الممكنة	ماذا تعني النتيجة السيئة عادة
SPF	pass وfail وsoftfail وneutral وnone وtemperror وpermerror	عنوان IP المرسِل غير مدرج في سجلّ SPF للنطاق، أو السجلّ معطوب (permerror تعني غالبًا أكثر من 10 استعلامات DNS أو سجلّي SPF).
DKIM	pass وfail وnone وneutral وtemperror وpermerror	عُدّلت الرسالة بعد التوقيع، أو المفتاح العام مفقود، أو لا يوجد توقيع.
DMARC	pass وfail وnone	لم ينجح SPF ولا DKIM مع المطابقة لنطاق From الظاهر.

أي خاصية تحدّد أي هوية

الخاصية	الهوية التي تسمّيها	تستخدمها
smtp.mailfrom / smtp.helo	مرسِل الظرف أو اسم HELO الذي قيّمه SPF	SPF
header.d / header.i	نطاق توقيع DKIM أو الهوية الكاملة (d= وi= في التوقيع)	DKIM
header.s	محدِّد DKIM، ويسمّي سجلّ DNS الذي يحمل المفتاح	DKIM
header.from	نطاق From الظاهر الذي قيّمه DMARC	DMARC

الجزء الذي يفوّته أكثر الناس: المطابقة (alignment)

قد يقول SPF وDKIM كلاهما pass ويفشل DMARC مع ذلك. يشترط DMARC أن يكون النطاق الذي صادق عليه SPF (smtp.mailfrom) أو DKIM (header.d) مطابقًا للنطاق في عنوان From الظاهر، ويكفي أن يتطابق أحدهما فقط. المنصّة البريدية التي توقّع بنطاقها هي تجتاز DKIM لكنها غير مطابقة حتى تضبط نطاق توقيع مخصّصًا.

لماذا تغيّر إعادة التوجيه النتائج

عند إعادة توجيه رسالة، يتصل خادم المُعيد بعنوان IP الخاص به، فلا يعود سجلّ SPF للنطاق الأصلي يدرج عنوان الاتصال، وغالبًا يفشل SPF عند المستلم النهائي. أما توقيع DKIM فيسافر مع الرسالة ويبقى صالحًا بعد إعادة التوجيه ما دامت الأجزاء الموقَّعة لم تتغيّر. لهذا يسمح DMARC بأن يحمل أيٌّ من الآليتين النجاح. والقوائم البريدية التي تعدّل الموضوع أو تضيف تذييلًا قد تكسر DKIM أيضًا، وهي المشكلة التي صُمّم ARC لحلّها: يسجّل المُعيد النتائج التي رآها في ARC-Authentication-Results ويختمها، ليقرّر المستقبِل النهائي هل يثق بالحكم الأصلي.

سير عمل من خمس خطوات للتشخيص

1. جد حكم الخادم المستقبِل. حدّد أعلى Authentication-Results أضافه مزوّدك، وتجاهل أي رأس أُضيف أبكر في السلسلة.
2. اقرأ النتائج الثلاث وسجّل الهوية التي فحصها كل منها (smtp.mailfrom وheader.d وheader.from).
3. افحص المطابقة بين الهويات ونطاق From الظاهر.
4. تتبّع سلسلة Received من الأسفل للأعلى لتأكيد المصدر وإيجاد التأخير.
5. قرّر بالاستعانة بالجدول أدناه.

ما تراه	السبب المحتمل	الحل
spf=fail أو softfail	عنوان IP المرسِل غير موجود في SPF	أضف المرسِل إلى سجلّ SPF (سجلّ واحد فقط)
spf=permerror	سجلّان SPF أو أكثر من 10 استعلامات	ادمج السجلّين وقلّل الاستعلامات
dkim=fail (body hash did not verify)	تغيّر المحتوى بعد التوقيع (تذييل، إعادة كتابة الروابط)	انقل إضافة التذييل إلى ما قبل التوقيع
dkim=none	النظام المرسِل لا يوقّع	فعّل DKIM لدى المزوّد
dmarc=fail مع نجاح SPF وDKIM	النطاقات الموثَّقة لا تطابق From	استخدم return-path مخصّصًا أو نطاق DKIM مخصّصًا
تأخير كبير عند قفزة واحدة	قائمة رمادية أو طابور أو تقييد معدّل	افحص سجلّات ذلك المُرحِّل وحدود المعدّل

لمعرفة المعايير وراء هذه النتائج انظر الدليل العملي لـ SPF وDKIM وDMARC، وللمتطلبات التي يطبّقها المزوّدون على المرسِلين بالجملة انظر قائمة متطلبات Gmail وYahoo للمرسِلين بالجملة. وإن كانت رسائلك التسويقية تفشل في الفحوص أعلاه فإن دليل إعداد List-Unsubscribe يغطي الرأس الذي يغيب في أغلب الأحيان.

كيف تكتشف رسالة منتحَلة أو مشبوهة

مرّر هذه القائمة على أي رسالة لا تثق بها:

1. هل تتفق النطاقات؟ قارن From وReturn-Path ونطاق d= في DKIM ونطاق Message-ID. البريد المشروع تتطابق نطاقاته عادة؛ أما رسالة «بنك» بـ Return-Path على نطاق غريب فلا.
2. هل يوجد سطر Authentication-Results أصلًا؟ الرسائل بلا نتائج من مزوّدك تستحق حذرًا إضافيًا.
3. هل Reply-To مختلف؟ وجود Reply-To على نطاق بريد مجاني في رسالة «مؤسسية» علامة احتيال كلاسيكية.
4. هل القفزات الخارجية الأولى منطقية؟ رسالة «مؤسسية» خرجت من نطاق IP سكني أو من بلد لا علاقة له بها مريبة.
5. هل Date معقول؟ التواريخ البعيدة في المستقبل أو الماضي، أو اختلاف المناطق الزمنية بين القفزات، قد يدل على بريد جماعي أو مزوَّر.

مثال مطابقة كامل

افترض أن رسالة تُظهر spf=pass smtp.mailfrom=bounce@mailer.shop.example وdkim=pass header.d=mailer.shop.example وdmarc=fail header.from=shop.example. نجح الفحصان ومع ذلك فشل DMARC. السبب هو المطابقة: النطاقان الموثَّقان هما mailer.shop.example بينما From الظاهر يستخدم shop.example. في المطابقة المرنة (relaxed) يُقبل نطاق فرعي من النطاق التنظيمي، فكان DMARC سينجح هنا لو استخدم السجلّ الوضع المرن الافتراضي (aspf وadkim غير مضبوطين أو r). أما إن ضبط السجلّ adkim=s أو aspf=s فيجب أن تتطابق النطاقات تمامًا وتفشل الرسالة. هذا بالضبط نوع عدم التطابق الذي يبرزه المحلّل المجاني: الصق الرؤوس فيعرض كل قفزة وتأخيرها، ويُظهر نتيجة كل مصادقة، وينبّه إلى النطاقات غير المتطابقة.

ما لا تستطيع الرؤوس إخبارك به

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

أسئلة شائعة

أين رأس Received وأيّها المرسِل الأصلي؟

يضيف كل خادم سطر Received في الأعلى، فالقفزة الأصلية هي آخر (أسفل) رأس Received. اقرأ من الأسفل إلى الأعلى.

ماذا تعني «spf=softfail» في رأس البريد؟

لم يصرّح النطاق بعنوان IP المرسِل، لكن سجلّ النطاق ينتهي بـ ~all، أي سياسة «ناعمة». غالبًا يقبل المستقبِل الرسالة ويعلّمها مشبوهة بدل رفضها.

لماذا يفشل DMARC مع نجاح SPF وDKIM؟

يشترط DMARC أيضًا المطابقة: يجب أن يطابق النطاق الموثَّق نطاق From الظاهر. نجاح SPF أو DKIM لنطاق آخر لا يحقّق DMARC.

هل يمكن تزوير رؤوس البريد؟

نعم. الرؤوس التي يكتبها المرسِل يمكن تزويرها، وكذلك أسطر Received المضافة قبل وصول الرسالة إلى خادم تثق به. اعتمد على الرؤوس التي أضافها مزوّدك.

هل من الآمن لصق رؤوس البريد في أداة على الإنترنت؟

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

المراجع ومزيد من القراءة

1. RFC 5322 — Internet Message Format
2. RFC 5321 — Simple Mail Transfer Protocol (trace fields)
3. RFC 8601 — Message Header Field for Indicating Message Authentication Status
4. RFC 7208 — Sender Policy Framework (SPF)
5. RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures
6. RFC 7489 — DMARC
7. RFC 8617 — Authenticated Received Chain (ARC)