مشاركة عبر

إعداد DMARC للتحقق من صحة مجال العنوان من للمرسلين في Microsoft 365

تلميح

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

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

يمكنك تمكين DMARC لمجال عن طريق إنشاء سجل TXT في DNS. يتضمن التحقق من صحة DMARC لرسالة بريد إلكتروني العناصر التالية:

  • تحقق من محاذاة المجالات في عناوين MAIL FROM و FROM: لا تتطلب SPFوDKIM المجالات الموجودة في عناوين البريد الإلكتروني التالية "محاذاة" (مطابقة):

    • عنوان MAIL FROM: عنوان البريد الإلكتروني المستخدم في إرسال الرسالة بين خوادم البريد الإلكتروني SMTP. يعرف هذا العنوان أيضا بالعنوان 5321.MailFrom أو مرسل P1 أو مرسل المغلف.
    • عنوان من: عنوان البريد الإلكتروني في حقل رأس من الذي يظهر كمرسل رسالة في عملاء البريد الإلكتروني. يعرف هذا العنوان أيضا بالعنوان 5322.From أو مرسل P2.

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

    • يستخدم DMARC النتيجة من SPF للتحقق من كلا الشرطين التاليين:

      • جاءت الرسالة من مصدر معتمد للمجال المستخدم في عنوان MAIL FROM (المتطلب الأساسي ل SPF).
      • تتم محاذاة المجالات الموجودة في عنواني MAIL FROM و From في الرسالة. تتطلب هذه النتيجة بشكل فعال أن تكون المصادر الصالحة للرسالة في مجال العنوان من.

    • يستخدم DMARC النتيجة من DKIM للتحقق من أن المجال الذي وقع الرسالة (القيمة d= في حقل رأس DKIM-Signature كما تم التحقق من صحتها بواسطة قيمة محدد s= ) يتوافق مع المجال في العنوان من.

    تمرر الرسالة DMARC إذا تم تمرير أحد عمليات التحقق من SPF أو DKIM الموضحة أو كليهما. تفشل الرسالة في DMARC إذا فشلت عمليات التحقق من SPF أو DKIM الموضحة.

  • نهج DMARC: يحدد ما يجب فعله بالرسائل التي تفشل في DMARC (رفض أو عزل أو عدم وجود تعليمات).

  • تقارير DMARC: تحدد مكان إرسال التقارير المجمعة (ملخص دوري لنتائج DMARC الإيجابية والسلبية) وتقارير الطب الشرعي (المعروفة أيضا باسم تقارير الفشل؛ نتائج فشل DMARC الفورية تقريبا مشابهة لتقرير عدم التسليم أو رسالة ارتداد).

قبل أن نبدأ، إليك ما تحتاج إلى معرفته حول DMARC في Microsoft 365 استنادا إلى مجال بريدك الإلكتروني:

  • إذا كنت تستخدم مجال عنوان توجيه البريد الإلكتروني (MOERA) ل Microsoft Online فقط للبريد الإلكتروني (على سبيل المثال، contoso.onmicrosoft.com): على الرغم من تكوين SPF وDKIM بالفعل لمجال *.onmicrosoft.com، فأنت بحاجة إلى إنشاء سجل DMARC TXT للمجال *.onmicrosoft.com في مركز مسؤولي Microsoft 365. للحصول على الإرشادات، راجع هذا القسم لاحقا في هذه المقالة. لمزيد من المعلومات حول مجالات *.onmicrosoft.com، راجع لماذا لدي مجال "onmicrosoft.com"؟.

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

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

    • المجالات الفرعية:

      • بالنسبة لخدمات البريد الإلكتروني غير الخاضعة لعنصر التحكم المباشر (على سبيل المثال، خدمات البريد الإلكتروني المجمعة)، نوصي باستخدام مجال فرعي (على سبيل المثال، marketing.contoso.com) بدلا من مجال البريد الإلكتروني الرئيسي (على سبيل المثال، contoso.com). لا تريد أن تؤثر المشكلات المتعلقة بالبريد المرسل من خدمات البريد الإلكتروني هذه على سمعة البريد المرسل من قبل الموظفين في مجال البريد الإلكتروني الرئيسي. لمزيد من المعلومات حول إضافة مجالات فرعية، راجع هل يمكنني إضافة مجالات فرعية مخصصة أو مجالات متعددة إلى Microsoft 365؟.
      • على عكس SPF وDKIM، يغطي سجل DMARC TXT لمجال تلقائيا جميع المجالات الفرعية (بما في ذلك المجالات الفرعية غير الموجودة) التي لا تحتوي على سجل DMARC TXT الخاص بها. بمعنى آخر، يمكنك تعطيل توريث DMARC على مجال فرعي عن طريق إنشاء سجل DMARC TXT في هذا المجال الفرعي. ولكن، يتطلب كل مجال فرعي سجل SPF وDKIM ل DMARC.

    • إذا كنت تملك مجالات مسجلة ولكن غير مستخدمة: إذا كنت تملك مجالات مسجلة غير مستخدمة للبريد الإلكتروني أو أي شيء على الإطلاق (تعرف أيضا باسم المجالات المتوقفة)، فبادر بتكوين سجلات DMARC TXT في تلك المجالات لتحديد أنه لا يجب أن يأتي أي بريد إلكتروني من تلك المجالات. يتضمن هذا التوجيه المجال *.onmicrosoft.com إذا كنت لا تستخدمه للبريد الإلكتروني.

  • قد تحتاج فحوصات DMARC للبريد الوارد إلى مساعدة: إذا كنت تستخدم خدمة بريد إلكتروني تقوم بتعديل الرسائل أثناء النقل قبل التسليم إلى Microsoft 365، يمكنك تحديد الخدمة على أنها ختم ARC موثوق به حتى لا تفشل الرسائل المعدلة تلقائيا في عمليات التحقق من DMARC. لمزيد من المعلومات، راجع قسم الخطوات التالية في نهاية هذه المقالة.

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

تلميح

لإنشاء سجل DMARC TXT لمجال *.onmicrosoft.com في مركز مسؤولي Microsoft 365، راجع هذا القسم لاحقا في هذه المقالة.

لا توجد مداخل المسؤول أو أوامر PowerShell cmdlets في Microsoft 365 لإدارة سجلات DMARC TXT في المجالات المخصصة . بدلا من ذلك، يمكنك إنشاء سجل DMARC TXT لدى جهة تسجيل المجالات أو خدمة استضافة DNS (غالبا نفس الشركة).

نحن نقدم إرشادات لإنشاء سجل TXT لإثبات ملكية المجال ل Microsoft 365 لدى العديد من مسجلي المجالات. يمكنك استخدام هذه الإرشادات كنقطة بداية لإنشاء سجلات DMARC TXT. لمزيد من المعلومات، راجع إضافة سجلات DNS لتوصيل مجالك.

إذا لم تكن على دراية بتكوين DNS، فاتصل بجهة تسجيل المجالات واطلب المساعدة.

بناء الجملة لسجلات DMARC TXT

يتم وصف سجلات DMARC TXT بشكل شامل في RFC 7489.

بناء الجملة الأساسي لسجل DMARC TXT لمجال في Microsoft 365 هو:

اسم المضيف: _dmarc
قيمة TXT: v=DMARC1; <DMARC policy>; <Percentage of DMARC failed mail subject to DMARC policy>; <DMARC reports>

أو

اسم المضيف: _dmarc
قيمة TXT: v=DMARC1; p=<reject | quarantine | none>; pct=<0-100>; rua=mailto:<DMARCAggregateReportURI>; ruf=mailto:<DMARCForensicReportURI>

على سبيل المثال:

اسم المضيف: _dmarc
قيمة TXT: v=DMARC1; p=reject; pct=100; rua=mailto:rua@contoso.com; ruf=mailto:ruf@contoso.com

  • قيمة _dmarc اسم المضيف مطلوبة.

  • v=DMARC1; يحدد سجل TXT كسجل DMARC TXT.

  • نهج DMARC: يخبر نظام البريد الإلكتروني الوجهة ماذا إلى بالرسائل التي تفشل في DMARC كما هو موضح سابقا في هذه المقالة:

    • p=reject: يجب رفض الرسائل. يعتمد ما يحدث بالفعل للرسالة على نظام البريد الإلكتروني الوجهة، ولكن يتم تجاهل الرسائل عادة.
    • p=quarantine: يجب قبول الرسائل ولكن وضع علامة عليها. يعتمد ما يحدث بالفعل للرسالة على نظام البريد الإلكتروني الوجهة. على سبيل المثال، قد يتم عزل الرسالة على أنها بريد عشوائي، أو تسليمها إلى مجلد البريد الإلكتروني غير الهام، أو تسليمها إلى علبة الوارد بمعرف تمت إضافته إلى الموضوع أو نص الرسالة.
    • p=none: لا يوجد إجراء مقترح للرسائل التي تفشل في DMARC. يعتمد ما يحدث للرسالة على ميزات حماية البريد الإلكتروني في نظام البريد الإلكتروني الوجهة. يمكنك استخدام هذه القيمة لاختبار نهج DMARC وضبطه كما هو موضح لاحقا في هذه المقالة.

    تلميح

    يتم توجيه البريد الصادر من المجالات في Microsoft 365 التي تفشل في عمليات التحقق من DMARC بواسطة خدمة البريد الإلكتروني الوجهة من خلال تجمع التسليم عالي المخاطر للرسائل الصادرة إذا كان نهج DMARC للمجال هو p=reject أو p=quarantine. لا يوجد تجاوز لهذا السلوك.

  • النسبة المئوية لبريد DMARC الفاشل الخاضع لنهج DMARC: يخبر نظام البريد الإلكتروني الوجهة بعدد الرسائل التي تفشل في DMARC (النسبة المئوية) التي يتم تطبيق نهج DMARC عليها. على سبيل المثال، pct=100 يعني أن جميع الرسائل التي تفشل في DMARC تحصل على نهج DMARC المطبق عليها. يمكنك استخدام قيم أقل من 100 لاختبار نهج DMARC وضبطه كما هو موضح لاحقا في هذه المقالة. إذا لم تستخدم pct=، فإن القيمة الافتراضية هي pct=100.

  • تقارير DMARC:

    • DMARC Aggregate report URI: rua=mailto: تحدد القيمة مكان إرسال تقرير DMARC Aggregate. يحتوي التقرير التجميعي على الخصائص التالية:

      • عادة ما يتم إرسال رسائل البريد الإلكتروني التي تحتوي على التقرير التجميعي مرة واحدة في اليوم (يحتوي التقرير على نتائج DMARC من اليوم السابق). يحتوي سطر الموضوع على المجال الوجهة الذي أرسل التقرير (المرسل) والمجال المصدر لنتائج DMARC (مجال التقرير).
      • توجد بيانات DMARC في مرفق بريد XML الإلكتروني الذي من المحتمل أن يكون GZIP مضغوطا. يتم تعريف مخطط XML في الملحق C من RFC 7489. يحتوي التقرير على المعلومات التالية:
        • عناوين IP للخوادم أو الخدمات التي ترسل البريد باستخدام مجالك.
        • ما إذا كانت الخوادم أو الخدمات تمرر مصادقة DMARC أو تفشل.
        • الإجراءات التي يتخذها DMARC على البريد الذي يفشل مصادقة DMARC (استنادا إلى نهج DMARC).

      تلميح

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

      • إنشاء أتمتة باستخدام PowerShell أو Microsoft Power BI.
      • استخدم خدمة خارجية. للحصول على قائمة بالخدمات، ابحث عن DMARC في كتالوج Microsoft Intelligent Security Association (MISA) في https://www.microsoft.com/misapartnercatalog. تصف خدمات تقارير DMARC أي قيم مخصصة مطلوبة في سجل DMARC TXT.

    • عنوان URI لتقرير DMARC الجنائي: ruf=mailto: تحدد القيمة مكان إرسال تقرير DMARC Forensic (المعروف أيضا باسم تقرير فشل DMARC). يتم إنشاء التقرير وإرساله مباشرة بعد فشل DMARC مثل تقرير عدم التسليم (المعروف أيضا باسم NDR أو رسالة ارتداد).

    تلميح

    يجب عليك مراجعة تقارير DMARC التجميعية بانتظام لمراقبة من أين يأتي البريد الإلكتروني من مجالاتك، وللتحقق من حالات فشل DMARC غير المقصودة (الإيجابيات الخاطئة).

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

لمزيد من المعلومات حول DMARC، استخدم الموارد التالية:

  • سلسلة تدريب DMARC من M3AAWG (المراسلة والبرامج الضارة ومجموعة العمل المتنقلة لمكافحة إساءة الاستخدام).
  • معلومات في DMARC.org.

استخدم مركز مسؤولي Microsoft 365 لإضافة سجلات DMARC TXT لمجالات *.onmicrosoft.com في Microsoft 365

  1. في مركز مسؤولي Microsoft 365 في https://admin.microsoft.com، حدد إظهار كافة>مجالات الإعدادات>. أو، للانتقال مباشرة إلى صفحة المجالات ، استخدم https://admin.microsoft.com/Adminportal/Home#/Domains.

  2. في صفحة المجالات ، حدد المجال *.onmicrosoft.com من القائمة بالنقر فوق أي مكان في الصف بخلاف خانة الاختيار الموجودة بجانب اسم المجال.

  3. في صفحة تفاصيل المجال التي تفتح، حدد علامة التبويب سجلات DNS .

  4. في علامة التبويب سجلات DNS ، حدد إضافة سجل.

  5. في القائمة المنبثقة إضافة سجل DNS مخصص يتم فتحه، قم بتكوين الإعدادات التالية:

    • النوع: تحقق من تحديد TXT (نص ).

    • اسم TXT: أدخل _dmarc.

    • قيمة TXT: أدخل v=DMARC1; p=reject.

      تلميح

      لتحديد وجهات لتقارير DMARC Aggregate وDMARC Forensic، استخدم بناء الجملة v=DMARC1; p=reject rua=mailto:<emailaddress>; ruf=mailto:<emailaddress>. على سبيل المثال، v=DMARC1; p=reject rua=mailto:rua@contoso.onmicrosoft.com; ruf=mailto:ruf@contoso.onmicrosoft.com.

      يقوم موردو تقارير DMARC في كتالوج https://www.microsoft.com/misapartnercatalog MISA لتسهيل عرض نتائج DMARC وتفسيرها.

    • TTL: تحقق من تحديد ساعة واحدة .

    عند الانتهاء من القائمة المنبثقة إضافة سجل DNS مخصص ، حدد حفظ.

إعداد DMARC للمجالات المخصصة النشطة في Microsoft 365

تلميح

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

نوصي باتباع نهج تدريجي لإعداد DMARC لمجالات Microsoft 365. الهدف هو الوصول إلى نهج p=reject DMARC لجميع المجالات والمجالات الفرعية المخصصة، ولكن تحتاج إلى الاختبار والتحقق على طول الطريق لمنع أنظمة البريد الإلكتروني الوجهة من رفض البريد الجيد بسبب فشل DMARC غير المقصود.

يجب أن تستخدم خطة طرح DMARC الخطوات التالية. ابدأ بمجال أو مجال فرعي بحجم بريد منخفض و/أو مصادر بريد إلكتروني محتملة أقل (فرصة أقل لحظر البريد الشرعي من مصادر غير معروفة):

  1. ابدأ بنهج p=none DMARC من ومراقبة نتائج المجال. على سبيل المثال:

    سجل DMARC TXT marketing.contoso.com:

    اسم المضيف: _dmarc
    قيمة TXT: v=DMARC1; p=none; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

    تعطي تقارير DMARC Aggregate وDMARC Forensic أرقام ومصادر الرسائل التي تمرر فحوصات DMARC وتفشل فيها. يمكنك معرفة مقدار نسبة استخدام الشبكة للبريد المشروعة التي يغطيها DMARC أو لا يغطيها، واستكشاف أي مشاكل وإصلاحها. يمكنك أيضا معرفة عدد الرسائل الاحتيالية التي يتم إرسالها والمكان الذي يتم إرسالها منه.

  2. قم بزيادة نهج DMARC إلى p=quarantine نتائج المجال ومراقبتها.

    بعد وقت كاف لمراقبة تأثيرات p=none، يمكنك زيادة نهج DMARC إلى p=quarantine للمجال. على سبيل المثال:

    سجل DMARC TXT marketing.contoso.com:

    اسم المضيف: _dmarc
    قيمة TXT: v=DMARC1; p=quarantine; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

    يمكنك أيضا استخدام pct= القيمة للتأثير تدريجيا على المزيد من الرسائل والتحقق من النتائج. على سبيل المثال، يمكنك الانتقال بالزيادات التالية:

    • pct=10
    • pct=25
    • pct=50
    • pct=75
    • pct=100

  3. قم بزيادة نهج DMARC إلى p=reject نتائج المجال ومراقبتها.

    بعد وقت كاف لمراقبة تأثيرات p=quarantine، يمكنك زيادة نهج DMARC إلى p=reject للمجال. على سبيل المثال:

    سجل DMARC TXT marketing.contoso.com:

    اسم المضيف: _dmarc
    قيمة TXT: v=DMARC1; p=reject; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

    يمكنك أيضا استخدام pct= القيمة للتأثير تدريجيا على المزيد من الرسائل والتحقق من النتائج.

  4. كرر الخطوات الثلاث السابقة للمجالات الفرعية المتبقية لزيادة الحجم و/أو التعقيد، مع حفظ المجال الأصل لآخر.

    تلميح

    حظر البريد الإلكتروني المشروع في أي حجم كبير غير مقبول للمستخدمين، ولكن من المحتم تقريبا أن تحصل على بعض الإيجابيات الكاذبة. تعامل ببطء ومنهجية مع المشكلات التي يتم الكشف عنها في تقارير DMARC. يسهل موردو تقارير DMARC في كتالوج https://www.microsoft.com/misapartnercatalog MISA عرض نتائج DMARC وتفسيرها.

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

سجلات DMARC TXT للمجالات المتوقفة في Microsoft 365

تلميح

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

  1. إذا قمت بتسجيل المجالات التي لا يتوقع أي شخص على الإنترنت تلقي البريد منها، فقم بإنشاء سجل DMARC TXT التالي لدى جهة تسجيل المجالات للمجال:

    اسم المضيف: _dmarc
    قيمة TXT: v=DMARC1; p=reject;

    • pct= القيمة غير مضمنة، لأن القيمة الافتراضية هي pct=100.
    • rua=mailto: يمكن القول إن القيم و ruf=mailto: غير مطلوبة في هذا السيناريو، لأنه لا يجب أن يأتي أي بريد صالح من أي وقت مضى من المرسلين في المجال.

  2. إذا لم تستخدم المجال *.onmicrosoft.com لإرسال البريد، فستحتاج أيضا إلى إضافة سجل DMARC TXT لمجال *.onmicrosoft.com.

DMARC للبريد الوارد إلى Microsoft 365

  • تتأثر عمليات التحقق من DMARC على البريد الوارد إلى Microsoft 365 بالميزات التالية في Exchange Online Protection (EOP):

    • ما إذا كان التحليل الذكي للانتحال ممكنا أو معطلا في نهج مكافحة التصيد الاحتيالي الذي تحقق من الرسالة. تعطيل التحليل الذكي لتزييف الهوية يعطل الحماية الضمنية من عمليات التحقق من المصادقة المركبة فقط.
    • ما إذا كان نهج سجل Honor DMARC عند اكتشاف الرسالة كإعداد انتحال ممكن أو معطلا في نهج مكافحة التصيد الاحتيالي الذي تحقق من الرسالة والإجراءات المحددة استنادا إلى نهج DMARC للمجال المصدر (p=quarantineأو p=reject في سجل DMARC TXT).

    للحصول على معلومات كاملة، راجع نهج Spoof protection وDMARC للمرسل.

    لمشاهدة القيم الافتراضية لهذه الإعدادات في نهج مكافحة التصيد الاحتيالي، تحقق من قيم الإعدادات في الجدول في إعدادات نهج EOP لمكافحة التصيد الاحتيالي.

  • لا يرسل Microsoft 365 تقارير DMARC Forensic (المعروفة أيضا بتقارير فشل DMARC)، حتى إذا كان هناك عنوان صالح ruf=mailto: في سجل DMARC TXT للمجال المصدر.

  • يرسل Microsoft 365 تقارير DMARC Aggregate إلى جميع المجالات بعنوان صالح rua=mailto: في سجلات DMARC TXT، طالما أن سجل MX لمجال Microsoft 365 يشير مباشرة إلى Microsoft 365.

    إذا تم توجيه البريد من الإنترنت عبر خدمة أو جهاز تابع لجهة خارجية قبل التسليم إلى Microsoft 365 (نقاط سجل MX في مكان آخر غير Microsoft 365)، فلن يتم إرسال تقارير DMARC Aggregate. يتضمن هذا القيد سيناريوهات EOP المختلطة أو المستقلة حيث يتم تسليم البريد إلى البيئة المحلية قبل توجيهه إلى Microsoft 365 باستخدام موصل.

    تلميح

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

استكشاف أخطاء DMARC وإصلاحها

يمكنك استخدام الرسم التالي للمساعدة في استكشاف مشكلات مصادقة DMARC وإصلاحها.

رسم استكشاف الأخطاء وإصلاحها ل DMARC

الخطوات التالية

بالنسبة للبريد الوارد إلى Microsoft 365، قد تحتاج أيضا إلى تكوين خزائن ARC الموثوق بها إذا كنت تستخدم الخدمات التي تعدل الرسائل أثناء النقل قبل التسليم إلى مؤسستك. لمزيد من المعلومات، راجع تكوين خزائن ARC الموثوق بها.