مصادقة البريد الإلكتروني في Microsoft 365

تلميح

هل تعلم أنه يمكنك تجربة الميزات في Microsoft Defender XDR Office 365 الخطة 2 مجانا؟ استخدم الإصدار التجريبي Defender لـ Office 365 لمدة 90 يوما في مركز الإصدارات التجريبية لمدخل Microsoft Defender. تعرف على الأشخاص الذين يمكنهم التسجيل وشروط الإصدار التجريبي هنا.

بصفتك مؤسسة Microsoft 365 مع علب بريد في Exchange Online، أو مؤسسة مستقلة Exchange Online Protection (EOP) دون Exchange Online علب البريد، فإن حماية تكامل رسائل البريد الإلكتروني من المرسلين في مجالاتك أمر مهم. يجب أن يشعر المستلمون بالثقة في أن الرسائل الواردة من المرسلين في مجالك تأتي حقا من المرسلين في مجالك.

مصادقة البريد الإلكتروني (المعروفة أيضا باسم التحقق من صحة البريد الإلكتروني) هي مجموعة من المعايير لتحديد ومنع تسليم رسائل البريد الإلكتروني من المرسلين المزورين (المعروف أيضا باسم الانتحال). يستخدم المرسلون المخادعون بشكل شائع في اختراق البريد الإلكتروني للأعمال (BEC) والتصيد الاحتيالي وهجمات البريد الإلكتروني الأخرى. وتشمل هذه المعايير ما يلي:

  • إطار عمل نهج المرسل (SPF): يحدد خوادم البريد الإلكتروني المصدر المصرح لها بإرسال بريد للمجال.
  • DomainKeys Identified Mail (DKIM):يستخدم مجالا لتوقيع العناصر المهمة للرسالة رقميا للتأكد من عدم تغيير الرسالة أثناء النقل.
  • مصادقة الرسائل المستندة إلى المجال وإعداد التقارير والتوافق (DMARC): يحدد الإجراء للرسائل التي تفشل في التحقق من SPF أو DKIM للمرسلين في المجال، ويحدد مكان إرسال نتائج DMARC (إعداد التقارير).
  • سلسلة المستلمين المصادق عليها (ARC): تحافظ على معلومات مصادقة البريد الإلكتروني الأصلية بواسطة الخدمات المعروفة التي تعدل الرسائل أثناء النقل. يمكن لخادم البريد الإلكتروني الوجهة استخدام هذه المعلومات لمصادقة الرسائل التي قد تفشل في DMARC.

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

لتكوين مصادقة البريد الإلكتروني للبريد المرسل من مؤسسات Microsoft 365 مع علب بريد في مؤسسات Exchange Online أو مستقلة Exchange Online Protection (EOP) دون Exchange Online علب البريد، راجع المقالات التالية:

لمنع فشل مصادقة البريد الإلكتروني بسبب الخدمات التي تعدل البريد الوارد المرسل إلى مؤسسة Microsoft 365، راجع تكوين خزائن ARC الموثوق بها.

توضح بقية هذه المقالة ما يلي:

لماذا يحتاج البريد الإلكتروني عبر الإنترنت إلى المصادقة

حسب التصميم، لا يبذل البريد الإلكتروني البسيط لبروتوكول نقل البريد (SMTP) على الإنترنت أي جهد للتحقق من أن مرسل الرسائل هو من يدعي أنه.

تتكون رسالة البريد الإلكتروني SMTP القياسية من مغلف رسالة ومحتوى رسالة:

  • يحتوي مغلف الرسالة على معلومات لنقل الرسالة وتلقيها بين خوادم SMTP. يتم وصف مغلف الرسالة في RFC 5321. لا يرى المستلمون مغلف الرسالة أبدا لأنه تم إنشاؤه أثناء عملية إرسال الرسالة.
  • يحتوي محتوى الرسالة على حقول رأس الرسالة (تسمى بشكل جماعي رأس الرسالة) ونص الرسالة. يتم وصف رأس الرسالة في RFC 5322.

وبسبب هذا التصميم، تحتوي الرسالة على قيم مرسل متعددة:

  • عنوان MAIL FROM (المعروف أيضا بالعنوان 5321.MailFrom أو مرسل P1 أو مرسل المغلف) هو عنوان البريد الإلكتروني المستخدم في إرسال الرسالة بين خوادم البريد الإلكتروني SMTP. عادة ما يتم تسجيل هذا العنوان في حقل عنوان Return-Path في رأس الرسالة (على الرغم من أن خادم البريد الإلكتروني المصدر يمكنه تعيين عنوان بريد إلكتروني مختلف ل Return-Path ). يتم استخدام عنوان البريد الإلكتروني هذا في تقارير عدم التسليم (المعروفة أيضا باسم NDRs أو الرسائل المرتدة).
  • عنوان من (المعروف أيضا باسم 5322.From العنوان أو مرسل P2) هو عنوان البريد الإلكتروني في حقل رأس من ، وهو عنوان البريد الإلكتروني للمرسل الذي يظهر في عملاء البريد الإلكتروني.

يوضح المثال التالي النسخة المبسطة من إرسال رسالة صالح بين خادمي بريد إلكتروني SMTP:

S: HELO woodgrovebank.com
S: MAIL FROM: dubious@proseware.com
S: RCPT TO: astobes@tailspintoys.com
S: DATA
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that we have the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

في هذا المثال:

  • يعرف خادم البريد الإلكتروني المصدر نفسه على أنه woodgrovebank.com إلى خادم البريد الإلكتروني الوجهة tailspintoys.com في الأمر HELO.
  • مستلم الرسالة هو astobes@tailspintoys.com.
  • عنوان MAIL FROM في مغلف الرسالة (المستخدم لإرسال الرسالة بين خوادم البريد الإلكتروني SMTP) هو dubious@proseware.com.
  • عنوان From الموضح في عميل البريد الإلكتروني للمستلم هو security@woodgrovebank.com.

على الرغم من أن هذه الرسالة صالحة وفقا ل SMTP، فإن مجال عنوان MAIL FROM (proseware.com) لا يتطابق مع المجال في عنوان من (woodgrovebank.com). هذه الرسالة هي مثال كلاسيكي على الانتحال، حيث من المحتمل أن يخدع الهدف المستلم عن طريق إخفاء المصدر الحقيقي للرسالة لاستخدامه في هجوم تصيد احتيالي.

من الواضح أن البريد الإلكتروني SMTP يحتاج إلى مساعدة للتحقق من أن مرسلي الرسائل هم الذين يدعون أنهم!

كيفية عمل SPF وDKIM وDMARC معا لمصادقة مرسلي رسائل البريد الإلكتروني

يصف هذا القسم سبب حاجتك إلى SPF وDKIM وDMARC للمجالات على الإنترنت.

  • SPF: كما هو موضح في إعداد SPF لتحديد مصادر البريد الإلكتروني الصالحة لمجال Microsoft 365 الخاص بك، يستخدم SPF سجل TXT في DNS لتحديد مصادر البريد الصالحة من مجال MAIL FROM، وما يجب فعله إذا تلقى خادم البريد الإلكتروني الوجهة البريد من مصدر غير معرف ('فشل صعب' لرفض الرسالة؛ "فشل بسيط" لقبول الرسالة ووضع علامة لها).

    مشكلات SPF:

    • يتحقق SPF من صحة مصادر المرسلين في مجال MAIL FROM فقط. لا يأخذ SPF المجال في العنوان من أو المحاذاة بين مجالي MAIL FROM و From:

      • يمكن للمهاجم إرسال بريد إلكتروني يمرر مصادقة SPF (سلبية خاطئة) باتباع الخطوات التالية:
        • تسجيل مجال (على سبيل المثال، proseware.com) وتكوين SPF للمجال.
        • إرسال بريد إلكتروني من مصدر صالح للمجال المسجل، باستخدام عناوين البريد الإلكتروني من في مجال مختلف (على سبيل المثال، woodgrovebank.com).
      • قد تتحكم خدمة البريد الإلكتروني الشرعية التي ترسل البريد نيابة عن مجالات أخرى في عنوان MAIL FROM. لا تتطابق المجالات الأخرى ومجال MAIL FROM، لذلك لا يمكن للرسائل تمرير مصادقة SPF (إيجابية خاطئة).

    • فواصل SPF بعد أن تواجه الرسائل إعادة توجيه البريد الإلكتروني المستندة إلى الخادم التي تعيد توجيه الرسائل أو ترحيلها .

      • يؤدي إعادة توجيه البريد الإلكتروني المستند إلى الخادم إلى تغيير مصدر الرسالة من الخادم الأصلي إلى خادم إعادة التوجيه.
      • خادم إعادة التوجيه غير مصرح له بإرسال بريد من مجال MAIL FROM الأصلي، لذلك لا يمكن للرسالة تمرير مصادقة SPF (إيجابية خاطئة).

    • يتطلب كل مجال وأي مجالات فرعية سجلات SPF الفردية الخاصة به. لا ترث المجالات الفرعية سجل SPF للمجال الأصل. يصبح هذا السلوك مشكلة إذا كنت تريد السماح للبريد الإلكتروني من المجالات الفرعية المعرفة والمستخدمة، ولكن منع البريد الإلكتروني من المجالات الفرعية غير المعرفة وغير المستخدمة.

  • DKIM: كما هو موضح في إعداد DKIM لتوقيع البريد من مجال Microsoft 365، يستخدم DKIM مجالا لتوقيع العناصر المهمة للرسالة رقميا (بما في ذلك عنوان من) ويخزن التوقيع في رأس الرسالة. يتحقق الخادم الوجهة من عدم تغيير العناصر الموقعة للرسالة.

    كيف يساعد DKIM SPF: يمكن ل DKIM التحقق من صحة الرسائل التي تفشل في SPF. على سبيل المثال:

    • الرسائل من خدمة استضافة البريد الإلكتروني حيث يتم استخدام نفس عنوان MAIL FROM للبريد من مجالات أخرى.
    • الرسائل التي تواجه إعادة توجيه البريد الإلكتروني المستند إلى الخادم.

    نظرا لأن توقيع DKIM في رأس الرسالة غير متأثر أو متغير في هذه السيناريوهات، فإن هذه الرسائل قادرة على تمرير DKIM.

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

    مثل SPF، يمكن للمهاجم إرسال بريد إلكتروني يمرر مصادقة DKIM (سلبية خاطئة) باتباع الخطوات التالية:

    • تسجيل مجال (على سبيل المثال، proseware.com) وتكوين DKIM للمجال.
    • إرسال بريد إلكتروني باستخدام عناوين البريد الإلكتروني من في مجال مختلف (على سبيل المثال، woodgrovebank.com).

  • DMARC: كما هو موضح في إعداد DMARC للتحقق من صحة مجال العنوان من للمرسلين في Microsoft 365، يستخدم DMARC SPF وDKIM للتحقق من المحاذاة بين المجالات في عنواني MAIL FROM و From. يحدد DMARC أيضا الإجراء الذي يجب أن يتخذه نظام البريد الإلكتروني الوجهة على الرسائل التي تفشل في DMARC، ويحدد مكان إرسال نتائج DMARC (التمرير والفشل).

    كيف يساعد DMARC SPF وDKIM: كما هو موضح سابقا، لا يحاول SPF مطابقة المجال في مجال MAIL FROM وعناوين From. لا يهتم DKIM إذا كان المجال الذي وقع الرسالة يطابق المجال في العنوان من.

    يعالج DMARC أوجه القصور هذه باستخدام SPF وDKIM للتأكد من تطابق المجالات في عنواني MAIL FROM و From.

    مشكلات DMARC: الخدمات المشروعة التي تعدل الرسائل أثناء النقل قبل فواصل التسليم SPF وDKIM وبالتالي عمليات التحقق من DMARC.

  • ARC: كما هو موضح في تكوين ختم ARC الموثوق به، يمكن للخدمات المشروعة التي تعدل الرسائل أثناء النقل استخدام ARC للحفاظ على معلومات مصادقة البريد الإلكتروني الأصلية للرسائل المعدلة.

    كيف يساعد ARC DMARC: يمكن لنظام البريد الإلكتروني الوجهة تحديد الخدمة على أنها ختم ARC موثوق به. يمكن ل ARC بعد ذلك استخدام معلومات مصادقة البريد الإلكتروني المحفوظة للتحقق من صحة الرسالة.

مصادقة البريد الإلكتروني الوارد للبريد المرسل إلى Microsoft 365

بسبب مخاوف التصيد الاحتيالي واعتماد نهج مصادقة البريد الإلكتروني القوية بشكل أقل من الكامل من قبل مرسلي البريد الإلكتروني على الإنترنت، يستخدم Microsoft 365 مصادقة البريد الإلكتروني الضمنية للتحقق من البريد الإلكتروني الوارد. توسع مصادقة البريد الإلكتروني الضمنية عمليات فحص SPF وDKIM وDMARC العادية باستخدام إشارات من مصادر أخرى لتقييم البريد الإلكتروني الوارد. وتشمل هذه المصادر ما يلي:

  • سمعة المرسل.
  • محفوظات المرسلين.
  • محفوظات المستلمين.
  • التحليل السلوكي.
  • تقنيات متقدمة أخرى.

لمشاهدة إعلان Microsoft الأصلي حول المصادقة الضمنية، راجع بحر من التصيد الاحتيالي الجزء 2 - محسن لمكافحة الانتحال في Microsoft 365.

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

المصادقة المركبة

يتم دمج نتائج عمليات التحقق من المصادقة الضمنية ل Microsoft 365 وتخزينها في قيمة واحدة تسمى المصادقة المركبة أو compauth باختصار. compauth يتم ختم القيمة في عنوان Authentication-Results في رؤوس الرسائل. يستخدم عنوان Authentication-Results بناء الجملة التالي:

Authentication-Results:
   compauth=<fail | pass | softpass | none> reason=<yyy>

يتم شرح هذه القيم في عنوان رسالة Authentication-results.

يمكن للمسؤولين والمستخدمين فحص رؤوس الرسائل لاكتشاف كيفية تعريف Microsoft 365 للمرسل كمرسل مريب مخادع أو شرعي.

تلميح

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

تركز الأمثلة التالية على نتائج مصادقة البريد الإلكتروني فقط ( compauth القيمة والسبب). يمكن لتقنيات حماية Microsoft 365 الأخرى تحديد الرسائل التي تمرر مصادقة البريد الإلكتروني على أنها منتحلة، أو تحديد الرسائل التي تفشل في مصادقة البريد الإلكتروني على أنها شرعية.

  • السيناريو: المجال في سجل SPF أو توقيع DKIM لا يتطابق مع المجال في العنوان من.

  • النتيجة: يمكن أن تفشل الرسالة في المصادقة المركبة. على الرغم من فشل المصادقة المركبة، قد يظل مسموحا بالرسالة إذا لم تشير التقييمات الأخرى إلى طبيعة مريبة:

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

  • السيناريو: لا يحتوي مجال fabrikam.com على سجلات SPF أو DKIM أو DMARC.

  • النتيجة: يمكن أن تفشل الرسائل الواردة من المرسلين في مجال fabrikam.com في المصادقة المركبة:

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=none
  action=none header.from=fabrikam.com; compauth=fail reason=001
From: chris@fabrikam.com
To: michelle@contoso.com

  • السيناريو: يحتوي مجال fabrikam.com على سجل SPF ولا يوجد سجل DKIM. تطابق المجالات الموجودة في عنواني MAIL FROM و From.

  • النتيجة: يمكن للرسالة تمرير المصادقة المركبة، لأن المجال الذي مرر SPF يطابق المجال في العنوان من:

    Authentication-Results: spf=pass (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=bestguesspass
  action=none header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • السيناريو: يحتوي المجال fabrikam.com على سجل DKIM بدون سجل SPF. يتطابق المجال الذي وقعه DKIM على الرسالة مع المجال في عنوان من.

  • النتيجة: يمكن للرسالة تمرير المصادقة المركبة، لأن المجال في توقيع DKIM يطابق المجال في العنوان من:

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=pass
  (signature was verified) header.d=outbound.fabrikam.com;
  contoso.com; dmarc=bestguesspass action=none
  header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • السيناريو: المجال في سجل SPF أو توقيع DKIM لا يتطابق مع المجال في العنوان من.

  • النتيجة: يمكن أن تفشل الرسالة في المصادقة المركبة:

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

كيفية تجنب فشل مصادقة البريد الإلكتروني عند إرسال البريد إلى Microsoft 365

تلميح

يمكن لعملاء Microsoft 365 استخدام الطرق التالية للسماح بالرسائل الواردة من المرسلين التي تم تحديدها على أنها تزييف الهوية أو فشل المصادقة:

  • تكوين سجلات SPF وDKIM وDMARC للمجالات الخاصة بك: استخدم معلومات التكوين التي يوفرها مسجل المجال أو خدمة استضافة DNS. هناك أيضا شركات تابعة لجهة خارجية مخصصة للمساعدة في إعداد سجلات مصادقة البريد الإلكتروني.

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

    1. ابدأ بنشر سجل SPF يحتوي على جميع مصادر البريد الإلكتروني التي تعرفها (خاصة مكان وجود نسبة استخدام الشبكة للشركات)، واستخدم قيمة قاعدة الإنفاذ "فشل مبدئي" (~all). على سبيل المثال:

      fabrikam.com IN TXT "v=spf1 include:spf.fabrikam.com ~all"

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

    2. اكتشف المزيد من مصادر البريد الإلكتروني لرسائلك وقم بتضمينها. على سبيل المثال:

      • خوادم البريد الإلكتروني المحلية.
      • البريد الإلكتروني المرسل من موفر خدمة تأجير البرامج (SaaS).
      • البريد الإلكتروني المرسل من خدمة استضافة السحابة (Microsoft Azure وGoDaddy و Rackspace وAmazon Web Services وما إلى ذلك).

      بعد تحديد جميع مصادر البريد الإلكتروني لمجالك، يمكنك تحديث سجل SPF لاستخدام قيمة قاعدة الإنفاذ "فشل صعب" (-all).

    3. إعداد DKIM لتوقيع الرسائل رقميا.

    4. قم بإعداد DMARC للتحقق من تطابق المجالات في عنواني MAIL FROM و From، لتحديد ما يجب فعله بالرسائل التي تفشل في عمليات التحقق من DMARC (رفض أو عزل)، وتحديد خدمات التقارير لمراقبة نتائج DMARC.

    5. إذا كنت تستخدم مرسلين مجمعين لإرسال بريد إلكتروني نيابة عنك، فتحقق من أن المجال في عنوان من يطابق المجال الذي يمرر SPF أو DMARC.

  • يمكنك استضافة البريد الإلكتروني للمجال أو توفير بنية أساسية للاستضافة يمكنها إرسال البريد الإلكتروني:

    • تأكد من أن عملائك لديهم وثائق تشرح كيفية تكوين SPF لمجالاتهم.
    • ضع في اعتبارك توقيع DKIM للبريد الصادر DKIM، حتى إذا لم يقم العميل بإعداد DKIM بشكل صريح في مجاله (تسجيل الدخول باستخدام مجال افتراضي). يمكنك حتى التوقيع المزدوج على البريد الإلكتروني باستخدام توقيعات DKIM (مع مجال شركتك ومجال العميل إذا/عندما يكون متوفرا).

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