كيف تكشف رسالة التصيد الاحتيالي بقراءة ترويساتها

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

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

الخطوة الأولى: استخرج الترويسات من تطبيق البريد

تخفي جميع برامج البريد الترويسات افتراضيًا. في Gmail، افتح الرسالة، وانقر على قائمة النقاط الثلاث بجوار زر الرد، واختر Show original. في Outlook على الويب، افتح قائمة النقاط الثلاث، ثم View وView message source. في Apple Mail على Mac، اختر View ثم Message ثم All Headers. وتسرد صفحة محلل الترويسات مسارات القوائم في Outlook لنظام Windows وYahoo وغيرهما.

انسخ كل ما يسبق أول سطر فارغ، فتلك هي كتلة الترويسات. أما نص الرسالة فيأتي بعده ولا حاجة إليه. على iPhone وiPad لا يعرض تطبيق Mail المدمج الترويسات إطلاقًا، لذا أعد توجيه الرسالة إلى حاسوب أو افحصها في بريد الويب.

ترويسات رسالة تصيد، سطرًا سطرًا

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

Return-Path: <[email protected]>
Authentication-Results: mx.example.com;
    spf=pass smtp.mailfrom=mail.example.net;
    dkim=none;
    dmarc=fail (p=none) header.from=examplebank.com
Received: from mail.example.net (unknown [203.0.113.45])
    by mx.example.com with ESMTPS; Thu, 29 Oct 2026 09:14:07 +0000
Received: from desktop-4kq2 (unknown [198.51.100.23])
    by mail.example.net with ESMTPA; Thu, 29 Oct 2026 09:14:05 +0000
From: "Example Bank Security" <[email protected]>
Reply-To: [email protected]
To: [email protected]
Subject: Unusual sign-in: confirm your account within 24 hours
Date: Thu, 29 Oct 2026 09:14:02 +0000
Message-ID: <20261029091402.4471@desktop-4kq2>

ما يخبرك به كل سطر

Return-Path

العنوان الذي تذهب إليه إشعارات الارتداد، ويُسمى أيضًا مرسل المغلف. هنا هو على mail.example.net، لا على نطاق المصرف. هذا وحده لا يثبت الكثير، لأن النشرات الإخبارية المرسلة عبر مزود بريد جماعي تبدو بالشكل نفسه. احتفظ به في ذهنك للأسطر التالية.

Authentication-Results

الحكم الذي سجّله مزود بريدك عند وصول الرسالة. نجح SPF، لكن لصالح mail.example.net، أي خادم المهاجم. لا يوجد توقيع DKIM. أما DMARC، وهو الفحص الوحيد الذي ينظر إلى نطاق From الذي تراه فعلًا، فقد فشل بالنسبة إلى examplebank.com. هذا أنفع سطر في الكتلة كلها.

Received (الأعلى)

أضافه خادم مزود بريدك نفسه، mx.example.com، حين قبل الرسالة من 203.0.113.45. الأسطر التي يكتبها مزودك موثوقة. وكل ما تحت هذه النقطة كتبته أجهزة لا تعرف عنها شيئًا.

Received (الأسفل)

أقدم خطوة، لذا اقرأ السلسلة من الأسفل إلى الأعلى. بدأت الرسالة على جهاز يسمّي نفسه desktop-4kq2، وسُلّمت إلى mail.example.net عبر إرسال بعد تسجيل الدخول (ESMTPA). نظام التنبيهات في المصرف لا يعمل على حاسوب مكتبي لشخص ما، أما صندوق بريد مسروق أو مستأجر فيعمل عليه.

From

يقول الاسم المعروض Example Bank Security، ويدّعي العنوان أنه من examplebank.com. يستطيع أي شخص أن يكتب أي شيء في هذا الحقل. وفشل DMARC أعلاه هو الدليل على أن سطر From هذا مزوّر.

Reply-To

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

Subject وDate

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

Message-ID

معرّف فريد يختلقه برنامج الإرسال. تختمه أنظمة الشركات الكبيرة بنطاقها الخاص. أما هذا فينتهي بـ desktop-4kq2، أي الجهاز المنزلي نفسه الوارد في سطر Received السفلي. عدم التطابق هنا قرينة لا دليل، لأن كثيرًا من البرامج المشروعة تستخدم معرّفات عامة.

بجمع هذه الأسطر تتضح القصة: رسالة تدّعي أنها من المصرف أُرسلت من حاسوب مكتبي عبر خادم بريد غريب، وفشلت في مصادقة المصرف نفسه، وتريد ردك على نطاق ثالث. يمكنك الوصول إلى هذا الاستنتاج في أقل من دقيقة متى عرفت أين تنظر، ويُبرز لك محلل الترويسات فشل DMARC وعدم تطابق Reply-To.

شرح SPF وDKIM وDMARC بلغة بسيطة

هذه الفحوص الثلاثة هي الجزء من الترويسات الذي يكتبه الخادم المستقبِل بعد اختبار الرسالة، لا نصًا كتبه المرسل. ويجيب كل منها عن سؤال مختلف.

SPF

هل يُسمح لهذا الخادم بإرسال البريد باسم نطاق مرسل المغلف؟ ينشر مالك النطاق قائمة بالخوادم المسموح لها في DNS، ويقارنها المستقبِل بعنوان IP المتصل. يفحص SPF نطاق Return-Path، لا عنوان From الذي تراه، ولهذا يمكن لرسالة تصيد أن تجتاز SPF لصالح نطاقها الخاص. راجع SPF في المسرد.

DKIM

هل وقّع نطاقٌ ما الرسالة، وهل عُدّلت منذ توقيعها؟ يضيف خادم الإرسال توقيعًا تشفيريًا، ويتحقق منه المستقبِل بمفتاح عام منشور في DNS الخاص بالموقّع. وتسمّي قيمة header.d= النطاق الذي وقّع. والتوقيع الصالح من نطاق لا علاقة له بالمرسل لا يقول شيئًا عن العلامة التجارية في سطر From.

DMARC

هل يطابق النطاق الوارد في سطر From نطاقًا اجتاز SPF أو DKIM؟ خطوة المواءمة هذه هي ما يربط الفحوص بالاسم الذي تقرؤه فعلًا. ويتيح DMARC أيضًا لمالك النطاق أن يخبر المستقبِلين بما يفعلونه بالرسائل الفاشلة: لا شيء (p=none)، أو العزل، أو الرفض. ولهذا قد تصل رسالة مزوّرة إلى صندوق الوارد لديك حين لا تكون الشركة الحقيقية قد فعّلت الإنفاذ.

معنى كل نتيجة

الحالة الأصعب: كل الفحوص تنجح

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

Authentication-Results: mx.example.com;
    spf=pass smtp.mailfrom=examplebank-secure.com;
    dkim=pass header.d=examplebank-secure.com;
    dmarc=pass header.from=examplebank-secure.com
From: "Example Bank" <[email protected]>

تثبت المصادقة أن examplebank-secure.com هو من أرسل هذه الرسالة. لكنها لا تستطيع أن تخبرك هل يعود هذا النطاق إلى مصرفك. هذا الجزء مهمتك أنت، وخلاصته أن تقرأ النطاق نفسه ببطء شديد. وهذه أكثر الحيل التي نراها:

• كلمات إضافية. الاسم الحقيقي مع -secure أو -login أو -support أو -verify.
• أحرف مستبدلة. rn مكان m، أو الرقم صفر مكان الحرف o، أو حرف مكرر أو ناقص.
• امتداد مختلف. الاسم الصحيح على .co أو .net أو نطاق علوي جديد بدلًا من الامتداد الذي تستخدمه الشركة.
• الاسم الحقيقي كنطاق فرعي. في examplebank.com.account-check.net يكون النطاق الفعلي هو account-check.net. اقرأ النطاقات من اليمين.
• أبجديات متشابهة. الحرف السيريلي а يبدو مطابقًا للحرف اللاتيني a. وفي الترويسات الخام تظهر هذه النطاقات غالبًا بادئةً بـ xn--، وهي طريقة ترميز أسماء النطاقات غير اللاتينية.
• اسم معروض يتولى المهمة. "Example Bank" أمام عنوان على نطاق بريد ويب مجاني. كثير من الهواتف لا تعرض إلا الاسم، فانقر عليه لترى العنوان.

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

علامات الخطر في ترويسات البريد، مرتبة حسب الأهمية

بعض الإشارات تقترب من الدليل، وبعضها لا يُحسب إلا حين يتراكم. هكذا نقدّر وزنها تقريبًا.

روتين من خمس دقائق لأي رسالة مريبة

1. 1

   انسخ الترويسات كاملة

   استخدم Show original أو View source كما هو موضح أعلاه، وانسخ الكتلة كلها، بما فيها كل أسطر Received.

2. 2

   الصقها في محلل ترويسات

   يعرض محلل ترويسات البريد الإلكتروني لدينا From وReply-To وReturn-Path جنبًا إلى جنب، ويُظهر نتائج SPF وDKIM وDMARC، ويسرد مسار التسليم من الأقدم إلى الأحدث. ويجري التحليل داخل متصفحك.

3. 3

   قارن DMARC بنطاق From

   ابحث عن dmarc= والنطاق المجاور له. فشلٌ لعلامة تجارية تعرفها كافٍ لتتوقف هنا وتحذف الرسالة.

4. 4

   اقرأ كل نطاق ببطء، من اليمين

   ينبغي أن تعود From وReply-To والنطاق الذي اجتاز DKIM كلها إلى الشركة. وانتبه لحيل النطاقات المشابهة المذكورة أعلاه.

5. 5

   اقرأ سلسلة Received من الأسفل

   السطر الأدنى هو حيث بدأت الرسالة. لا تثق إلا بالأسطر التي أضافها مزودك في الأعلى. يستطيع المرسل أن يُدرج تحتها أسطر Received مزيفة، بل وسطر Authentication-Results مزيفًا.

6. 6

   افحص الروابط دون النقر عليها

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

إذا ظننت أنها رسالة تصيد

• لا تنقر، ولا ترد، ولا تفتح المرفقات. الرد يؤكد أن عنوانك مقروء، والمرفقات هي الطريق المعتاد لوصول البرمجيات الخبيثة.
• تواصل مع الشركة بطريقة أخرى. اكتب عنوان موقعها في متصفحك أو استخدم الرقم المدوّن على بطاقتك أو عقدك، ولا تستخدم أبدًا الرقم الوارد في الرسالة.
• أبلغ عنها في تطبيق البريد. في Gmail، استخدم قائمة النقاط الثلاث ثم Report phishing. في Outlook، استخدم Report ثم Report phishing. فهذا يدرّب الفلتر لصالح جميع مستخدمي الخدمة.
• أعد توجيهها إلى مجموعة العمل لمكافحة التصيد (Anti-Phishing Working Group) على [email protected]، التي تشارك البلاغات مع شركات الأمن والمتصفحات.
• في الولايات المتحدة، أبلغ لجنة التجارة الفيدرالية FTC عبر ReportFraud.ftc.gov، خاصةً إذا تعلّق الأمر بأموال أو بيانات شخصية.
• إذا كنت قد أدخلت كلمة مرور بالفعل، فغيّرها الآن على الموقع الحقيقي، وفعّل التحقق بخطوتين، وغيّرها في كل مكان آخر أعدت استخدامها فيه. ويغطي دليلنا عن التحقق مما إذا كان بريدك قد ورد في تسريب بيانات الساعة الأولى بعد الانكشاف.

المصادر

• IETF، RFC 7208: Sender Policy Framework (SPF)، بما في ذلك معنى pass وfail وsoftfail وneutral.
• IETF، RFC 6376: DomainKeys Identified Mail (DKIM) Signatures.
• IETF، RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC)، المنشور في 2026 والذي يحل محل RFC 7489.
• IETF، RFC 8601: Message Header Field for Indicating Message Authentication Status، الذي يعرّف ترويسة Authentication-Results.
• لجنة التجارة الفيدرالية الأمريكية (FTC)، How to Recognize and Avoid Phishing Scams، لعناوين الإبلاغ الخاصة بـ FTC وAPWG.
• مجموعة العمل لمكافحة التصيد (APWG)، Report Phishing.