استخدام DMARC للتحقق من صحة البريد الإلكتروني
ملاحظة
هل تريد تجربة Microsoft 365 Defender؟ تعرف على المزيد حول كيفية تقييم Microsoft 365 Defender وتجربتها.
ينطبق على
تعمل مصادقة الرسائل وإعداد التقارير والمطابقة (DMARC) المستندة إلى المجال مع إطار نهج المرسل (SPF) والبريد المعرف في DomainKeys (DKIM) لمصادقة مرسلي البريد والتأكد من أن أنظمة البريد الإلكتروني الوجهة تثق في الرسائل المرسلة من مجالك. يوفر تنفيذ DMARC مع SPF وDKIM حماية إضافية من الانتحال والتصيد الاحتيالي. يساعد DMARC في تلقي أنظمة البريد لتحديد ما يجب فعله بالرسائل المرسلة من مجالك التي تفشل في عمليات التحقق من SPF أو DKIM.
تلميح
تفضل بزيارة كتالوج Microsoft Intelligent Security Association (MISA) لعرض موردي الجهات الخارجية الذين يقدمون تقارير DMARC Microsoft 365.
كيف يعمل SPF وDMARC معا لحماية البريد الإلكتروني في Microsoft 365؟
قد تحتوي رسالة البريد الإلكتروني على عناوين منشئ أو مرسل متعددة. يتم استخدام هذه العناوين لأغراض مختلفة. على سبيل المثال، ضع في اعتبارك هذه العناوين:
عنوان "البريد من": يحدد المرسل ويحدد مكان إرسال إشعارات الإرجاع إذا حدثت أي مشاكل في تسليم الرسالة، مثل إشعارات عدم التسليم. يظهر هذا في جزء المغلف من رسالة بريد إلكتروني ولا يعرضه تطبيق البريد الإلكتروني. يسمى هذا أحيانا عنوان 5321.MailFrom أو عنوان المسار العكسي.
عنوان "من": العنوان المعروض كعنوان "من" بواسطة تطبيق البريد. يعرف هذا العنوان كاتب البريد الإلكتروني. أي علبة بريد الشخص أو النظام المسؤول عن كتابة الرسالة. يسمى هذا أحيانا عنوان 5322.From.
يستخدم SPF سجل DNS TXT لتوفير قائمة بعناوين IP المرسلة المخولة لمجال معين. عادة، يتم إجراء عمليات التحقق من SPF فقط مقابل عنوان 5321.MailFrom. وهذا يعني أن عنوان 5322.From لا تتم مصادقته عند استخدام SPF بمفرده. يسمح هذا لسيناريو حيث يمكن للمستخدم تلقي رسالة، والتي تمرر فحص SPF ولكن لديه عنوان مرسل منتحل 5322.From. على سبيل المثال، ضع في اعتبارك نسخة SMTP هذه:
S: Helo woodgrovebank.com
S: Mail from: phish@phishing.contoso.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 User,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that Microsoft has the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .
في هذه النسخة، تكون عناوين المرسل كما يلي:
البريد من العنوان (5321.MailFrom): phish@phishing.contoso.com
من العنوان (5322.From): security@woodgrovebank.com
إذا قمت بتكوين SPF، فسينفذ الخادم المتلقي فحصا مقابل عنوان البريد من phish@phishing.contoso.com. إذا جاءت الرسالة من مصدر صالح للمجال phishing.contoso.com، فسيتم تمرير فحص SPF. نظرا لأن عميل البريد الإلكتروني يعرض فقط عنوان "من"، يرى المستخدم أن هذه الرسالة جاءت من security@woodgrovebank.com. مع SPF وحده، لم تتم مصادقة صلاحية woodgrovebank.com أبدا.
عند استخدام DMARC، يقوم الخادم المتلقي أيضا بإجراء فحص مقابل عنوان From. في المثال أعلاه، إذا كان هناك سجل DMARC TXT في مكانه woodgrovebank.com، فسيفشل التحقق مقابل عنوان "من".
ما هو سجل DMARC TXT؟
مثل سجلات DNS ل SPF، سجل DMARC هو سجل نص DNS (TXT) الذي يساعد على منع الانتحال والتصيد الاحتيالي. يمكنك نشر سجلات DMARC TXT في DNS. تتحقق سجلات DMARC TXT من أصل رسائل البريد الإلكتروني من خلال التحقق من عنوان IP الخاص بكاتب البريد الإلكتروني مقابل مالك المجال المرسل. يحدد سجل DMARC TXT خوادم البريد الإلكتروني الصادرة المعتمدة. يمكن لأنظمة البريد الإلكتروني الوجهة بعد ذلك التحقق من أن الرسائل التي تتلقاها تنشأ من خوادم البريد الإلكتروني الصادرة المعتمدة.
يبدو سجل DMARC TXT من Microsoft على النحو التالي:
_dmarc.microsoft.com. 3600 IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.contoso.com; ruf=mailto:d@ruf.contoso.com; fo=1"
لمزيد من الموردين الخارجيين الذين يقدمون تقارير DMARC Microsoft 365، تفضل بزيارة كتالوج MISA.
إعداد DMARC للبريد الوارد
ليس عليك القيام بأي شيء لإعداد DMARC للبريد الذي تتلقاه في Microsoft 365. يتم الاهتمام بها جميعا. إذا كنت تريد معرفة ما يحدث للبريد الذي يفشل في تمرير فحوصات DMARC، فراجع كيفية معالجة Microsoft 365 للبريد الإلكتروني الوارد الذي يفشل DMARC.
إعداد DMARC للبريد الصادر من Microsoft 365
إذا كنت تستخدم Microsoft 365 ولكنك لا تستخدم مجالا مخصصا، أي أنك تستخدم onmicrosoft.com، فلن تحتاج إلى القيام بأي شيء آخر لتكوين DMARC أو تنفيذه لمؤسستك. تم إعداد SPF لك بالفعل Microsoft 365 يقوم تلقائيا بإنشاء توقيع DKIM للبريد الصادر. لمزيد من المعلومات حول هذا التوقيع، راجع السلوك الافتراضي ل DKIM Microsoft 365.
إذا كان لديك مجال مخصص أو كنت تستخدم خوادم Exchange محلية بالإضافة إلى Microsoft 365، فستحتاج إلى تنفيذ DMARC يدويا للبريد الصادر. يتضمن تنفيذ DMARC لمجالك المخصص الخطوات التالية:
الخطوة 1: تحديد مصادر البريد الصالحة لمجالك
إذا كنت قد قمت بإعداد SPF بالفعل، فقد مررت بالفعل بهذا التمرين. ومع ذلك، بالنسبة إلى DMARC، هناك اعتبارات إضافية. عند تحديد مصادر البريد لمجالك، هناك سؤالان تحتاج إلى الإجابة عنهما:
ما هي عناوين IP التي ترسل رسائل من مجالي؟
بالنسبة إلى البريد المرسل من جهات خارجية بالنيابة عني، هل سيتطابق المجالان 5321.MailFrom و5322.From؟
الخطوة 2: إعداد SPF لمجالك
الآن بعد أن أصبحت لديك قائمة بجميع المرسلين الصالحين، يمكنك اتباع الخطوات لإعداد SPF للمساعدة في منع تزييف هوية الملفات.
على سبيل المثال، بافتراض أن contoso.com يرسل بريدا من Exchange Online، وخادم Exchange محلي عنوان IP الخاص به هو 192.168.0.1، وتطبيق ويب عنوان IP الخاص به هو 192.168.100.100، سيبدو سجل SPF TXT كما يلي:
contoso.com IN TXT " v=spf1 ip4:192.168.0.1 ip4:192.168.100.100 include:spf.protection.outlook.com -all"
كأفضل ممارسة، تأكد من أن سجل SPF TXT الخاص بك يأخذ في الاعتبار المرسلين التابعين لجهات خارجية.
الخطوة 3: إعداد DKIM لمجالك المخصص
بمجرد إعداد SPF، تحتاج إلى إعداد DKIM. يتيح لك DKIM إضافة توقيع رقمي إلى رسائل البريد الإلكتروني في رأس الرسالة. إذا لم تقم بإعداد DKIM وبدلا من ذلك سمحت Microsoft 365 باستخدام تكوين DKIM الافتراضي لمجالك، فقد تفشل DMARC. وذلك لأن تكوين DKIM الافتراضي يستخدم مجال onmicrosoft.com الأولي كعنوان 5322.From، وليس مجالك المخصص. يفرض هذا عدم تطابق بين عناوين 5321.MailFrom و5322.From في كل رسائل البريد الإلكتروني المرسلة من مجالك.
إذا كان لديك مرسلون تابعون لجهة خارجية يرسلون البريد نيابة عنك وكان البريد الذي يرسلونه غير متطابق مع عناوين 5321.MailFrom و5322.From، فسيفشل DMARC في هذا البريد الإلكتروني. لتجنب ذلك، تحتاج إلى إعداد DKIM لمجالك بشكل خاص مع هذا المرسل الخارجي. يسمح هذا Microsoft 365 بمصادقة البريد الإلكتروني من خدمة الجهات الخارجية هذه. ومع ذلك، فإنه يسمح للآخرين، على سبيل المثال، Yahoo وGmail و Comcast بالتحقق من البريد الإلكتروني المرسل إليهم من قبل جهة خارجية كما لو كان بريدا إلكترونيا أرسلته أنت. وهذا مفيد لأنه يسمح للعملاء ببناء الثقة مع مجالك بغض النظر عن مكان علبة البريد الخاصة بهم، وفي الوقت نفسه لن يضع Microsoft 365 علامة على رسالة بريد عشوائي بسبب تزييف الهوية لأنها تمرر عمليات التحقق من المصادقة لمجالك.
للحصول على إرشادات حول إعداد DKIM لمجالك، بما في ذلك كيفية إعداد DKIM لمرسلي الجهات الخارجية حتى يتمكنوا من تزييف مجالك، راجع استخدام DKIM للتحقق من صحة البريد الإلكتروني الصادر المرسل من مجالك المخصص.
الخطوة 4: تشكيل سجل DMARC TXT لمجالك
على الرغم من وجود خيارات أخرى لبناء الجملة لم يتم ذكرها هنا، إلا أن هذه هي الخيارات الأكثر استخداما Microsoft 365. تشكيل سجل DMARC TXT لمجالك بالتنسيق:
_dmarc.domain TTL IN TXT "v=DMARC1; p=policy; pct=100"
حيث:
المجال هو المجال الذي تريد حمايته. بشكل افتراضي، يحمي السجل البريد من المجال وكافة المجالات الفرعية. على سبيل المثال، إذا حددت _dmarc.contoso.com، فإن DMARC يحمي البريد من المجال وكافة المجالات الفرعية، مثل housewares.contoso.com أو plumbing.contoso.com.
يجب أن تكون TTL دائما مكافئة لساعة واحدة. ستختلف الوحدة المستخدمة ل TTL، سواء كانت ساعات (ساعة واحدة) أو دقائق (60 دقيقة) أو ثوان (3600 ثانية)، اعتمادا على جهة تسجيل المجالات الخاصة بمجالك.
تشير pct=100 إلى أنه يجب استخدام هذه القاعدة ل 100٪ من البريد الإلكتروني.
يحدد النهج النهج الذي تريد أن يتبعه الخادم المتلقي إذا فشل DMARC. يمكنك تعيين النهج إلى بلا أو عزل أو رفض.
للحصول على معلومات حول الخيارات التي يجب استخدامها، تعرف على المفاهيم في أفضل الممارسات لتنفيذ DMARC في Microsoft 365.
امثله:
تعيين النهج إلى بلا
_dmarc.contoso.com 3600 IN TXT "v=DMARC1; p=none"تم تعيين النهج إلى العزل
_dmarc.contoso.com 3600 IN TXT "v=DMARC1; p=quarantine"تم تعيين النهج لرفض
_dmarc.contoso.com 3600 IN TXT "v=DMARC1; p=reject"
بمجرد تشكيل السجل الخاص بك، تحتاج إلى تحديث السجل لدى جهة تسجيل المجالات.
بريد DMARC (ميزة المعاينة العامة)
تنبيه
قد لا يتم إرسال رسائل البريد يوميا، وقد يتغير التقرير نفسه أثناء المعاينة العامة. يمكن توقع رسائل البريد الإلكتروني لتقرير DMARC المجمع من حسابات المستهلكين (مثل حسابات hotmail.com أو outlook.com أو live.com).
في هذا المثال سجل DMARC TXT: dmarc.microsoft.com. 3600 IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com; fo=1"، يمكنك مشاهدة عنوان rua ، في هذه الحالة، تمت معالجته بواسطة شركة Agari تابعة لجهة خارجية. يستخدم هذا العنوان لإرسال "ملاحظات مجمعة" للتحليل، ويتم استخدامه لإنشاء تقرير.
تلميح
تفضل بزيارة كتالوج MISA لعرض المزيد من موردي الجهات الخارجية الذين يقدمون تقارير DMARC Microsoft 365. راجع "مصادقة الرسائل المستندة إلى المجال وإعداد التقارير والمطابقة (DMARC) الخاصة ب IETF.org" للحصول على مزيد من المعلومات حول عناوين DMARC "rua".
أفضل الممارسات لتنفيذ DMARC في Microsoft 365
يمكنك تنفيذ DMARC تدريجيا دون التأثير على بقية تدفق البريد. إنشاء وتنفيذ خطة نشر تتبع هذه الخطوات. نفذ كل خطوة من هذه الخطوات أولا باستخدام مجال فرعي، ثم مجالات فرعية أخرى، وأخيرا مع مجال المستوى الأعلى في مؤسستك قبل الانتقال إلى الخطوة التالية.
مراقبة تأثير تنفيذ DMARC
ابدأ بسجل وضع مراقبة بسيط لمجال فرعي أو مجال يطلب من متلقي DMARC إرسال إحصائيات حول الرسائل التي يرونها باستخدام هذا المجال. سجل وضع المراقبة هو سجل DMARC TXT الذي تم تعيين نهجه إلى بلا (p=none). تنشر العديد من الشركات سجل DMARC TXT مع p=none لأنها غير متأكدة من مقدار البريد الإلكتروني الذي قد تفقده من خلال نشر نهج DMARC أكثر تقييدا.
يمكنك القيام بذلك حتى قبل تنفيذ SPF أو DKIM في البنية الأساسية للمراسلة. ومع ذلك، لن تتمكن من عزل البريد أو رفضه بشكل فعال باستخدام DMARC حتى تقوم أيضا بتنفيذ SPF وDKIM. أثناء تقديم SPF وDKIM، ستوفر التقارير التي تم إنشاؤها من خلال DMARC أرقام ومصادر الرسائل التي تمرر هذه الفحوصات، وتلك التي لا تقوم بذلك. يمكنك بسهولة معرفة مقدار نسبة استخدام الشبكة المشروعة التي تغطيها أو لا تغطيها، واستكشاف أي مشاكل وإصلاحها. ستبدأ أيضا في معرفة عدد الرسائل الاحتيالية التي يتم إرسالها، والمكان الذي يتم إرسالها منه.
اطلب من أنظمة البريد الخارجية عزل البريد الذي يفشل في DMARC
عندما تعتقد أن جميع أو معظم نسبة استخدام الشبكة المشروعة محمية بواسطة SPF وDKIM، وتفهم تأثير تنفيذ DMARC، يمكنك تنفيذ نهج العزل. نهج العزل هو سجل DMARC TXT الذي تم تعيين نهجه إلى العزل (p=quarantine). من خلال القيام بذلك، تطلب من متلقي DMARC وضع رسائل من مجالك تفشل DMARC في المكافئ المحلي لمجلد البريد العشوائي بدلا من علب الوارد الخاصة بعملائك.
طلب عدم قبول أنظمة البريد الخارجية للرسائل التي تفشل في DMARC
الخطوة الأخيرة هي تنفيذ نهج رفض. نهج الرفض هو سجل DMARC TXT الذي تم تعيين نهجه لرفض (p=reject). عند القيام بذلك، تطلب من متلقي DMARC عدم قبول الرسائل التي تفشل في عمليات التحقق من DMARC.
كيفية إعداد DMARC للمنطاق الفرعي؟
يتم تنفيذ DMARC عن طريق نشر نهج كسجل TXT في DNS وهو هرمي (على سبيل المثال، سيتم تطبيق نهج منشور contoso.com على sub.domain.contonos.com ما لم يتم تعريف نهج مختلف بشكل صريح للمنطق الفرعي). وهذا مفيد لأن المؤسسات قد تكون قادرة على تحديد عدد أقل من سجلات DMARC عالية المستوى للتغطية الأوسع. يجب توخي الحذر لتكوين سجلات DMARC للمجال الفرعي الصريح حيث لا تريد أن ترث المجالات الفرعية سجل DMARC لمجال المستوى الأعلى.
يمكنك أيضا إضافة نهج نوع حرف بدل ل DMARC عندما لا ينبغي أن ترسل المجالات الفرعية بريدا إلكترونيا، عن طريق إضافة
sp=rejectالقيمة. على سبيل المثال:_dmarc.contoso.com. TXT "v=DMARC1; p=reject; sp=reject; ruf=mailto:authfail@contoso.com; rua=mailto:aggrep@contoso.com"
كيفية معالجة Microsoft 365 للبريد الإلكتروني الصادر الذي يفشل DMARC
إذا كانت الرسالة صادرة من Microsoft 365 وفشلت في DMARC، وقمت بتعيين النهج إلى p=quarantine أو p=reject، يتم توجيه الرسالة من خلال تجمع التسليم عالي المخاطر للرسائل الصادرة. لا يوجد تجاوز للبريد الإلكتروني الصادر.
إذا نشرت نهج رفض DMARC (p=reject)، فلن يتمكن أي عميل آخر في Microsoft 365 من انتحال مجالك لأن الرسائل لن تتمكن من تمرير SPF أو DKIM لمجالك عند ترحيل رسالة صادرة عبر الخدمة. ومع ذلك، إذا قمت بنشر نهج رفض DMARC ولكن لم تتم مصادقة كل رسائل البريد الإلكتروني عبر Microsoft 365، فقد يتم وضع علامة على بعضها كبريد عشوائي للبريد الإلكتروني الوارد (كما هو موضح أعلاه)، أو سيتم رفضه إذا لم تنشر SPF وتحاول ترحيله إلى الخارج عبر الخدمة. يحدث ذلك، على سبيل المثال، إذا نسيت تضمين بعض عناوين IP للخوادم والتطبيقات التي ترسل البريد نيابة عن مجالك عند تشكيل سجل DMARC TXT.
كيفية معالجة Microsoft 365 للبريد الإلكتروني الوارد الذي يفشل DMARC
إذا كان نهج DMARC الخاص بالخادم المرسل، p=rejectExchange Online Protection (EOP) يضع علامة على الرسالة على أنها منتحلة بدلا من رفضها. بمعنى آخر، للبريد الإلكتروني الوارد، Microsoft 365 يعامل p=reject بالطريقة p=quarantine نفسها. يمكن للمسؤولين تحديد الإجراء الذي يجب اتخاذه على الرسائل المصنفة على أنها تزييف داخل نهج مكافحة التصيد الاحتيالي.
تم تكوين Microsoft 365 بهذا الشكل لأن بعض رسائل البريد الإلكتروني المشروعة قد تفشل في DMARC. على سبيل المثال، قد تفشل رسالة في DMARC إذا تم إرسالها إلى قائمة بريدية تقوم بعد ذلك بترحيل الرسالة إلى جميع المشاركين في القائمة. إذا Microsoft 365 رفض هذه الرسائل، فقد يفقد الأشخاص البريد الإلكتروني المشروع ولا تتوفر لديهم أي طريقة لاسترداده. بدلا من ذلك، ستظل هذه الرسائل تفشل DMARC ولكن سيتم وضع علامة عليها على أنها بريد عشوائي ولن يتم رفضها. إذا رغبت في ذلك، فلا يزال بإمكان المستخدمين الحصول على هذه الرسائل في علبة الوارد الخاصة بهم من خلال هذه الأساليب:
يضيف المستخدمون المرسلين الآمنين بشكل فردي باستخدام عميل البريد الإلكتروني.
يمكن للمسؤولين استخدام التحليل الذكي المخادع أو قائمة السماح/الحظر للمستأجر للسماح بالرسائل من المرسل المخادع.
يقوم المسؤولون بإنشاء قاعدة تدفق بريد Exchange (تعرف أيضا باسم قاعدة النقل) لكافة المستخدمين التي تسمح بالرسائل الخاصة بالمرسلين المحددين.
لمزيد من المعلومات، راجع إنشاء قوائم المرسلين الآمنة.
كيفية استخدام Microsoft 365 لسلسلة المستلمين المصادق عليها (ARC)
ستستفيد جميع علب البريد المستضافة في Microsoft 365 الآن من ARC مع تحسين إمكانية تسليم الرسائل وتعزيز الحماية من الانتحال. تحافظ ARC على نتائج مصادقة البريد الإلكتروني من جميع الوسطاء المشاركين، أو القفزات، عند توجيه رسالة بريد إلكتروني من الخادم الأصلي إلى علبة بريد المستلم. قبل ARC، قد تتسبب التعديلات التي يجريها الوسطاء في توجيه البريد الإلكتروني، مثل قواعد إعادة التوجيه أو التواقيع التلقائية، في فشل DMARC بحلول الوقت الذي وصل فيه البريد الإلكتروني إلى علبة بريد المستلم. باستخدام ARC، يسمح الاحتفاظ بالتشفير لنتائج المصادقة Microsoft 365 بالتحقق من أصالة مرسل البريد الإلكتروني.
تستخدم Microsoft 365 حاليا ARC للتحقق من نتائج المصادقة عندما تكون Microsoft هي ARC Sealer، ولكنها تخطط لإضافة دعم لمحولات ARC الخارجية في المستقبل.
استكشاف أخطاء تنفيذ DMARC وإصلاحها
إذا قمت بتكوين سجلات MX لمجالك حيث لا يكون EOP هو الإدخال الأول، فلن يتم فرض حالات فشل DMARC لمجالك.
إذا كنت عميلا، ولم يشير سجل MX الأساسي لمجالك إلى EOP، فلن تحصل على فوائد DMARC. على سبيل المثال، لن يعمل DMARC إذا قمت بتوجيه سجل MX إلى خادم البريد المحلي ثم توجيه البريد الإلكتروني إلى EOP باستخدام موصل. في هذا السيناريو، المجال المتلقي هو أحد Accepted-Domains ولكن EOP ليس MX الأساسي. على سبيل المثال، افترض contoso.com يشير MX في حد ذاته ويستخدم EOP كسجل MX ثانوي، يبدو سجل MX الخاص ب contoso.com كما يلي:
contoso.com 3600 IN MX 0 mail.contoso.com
contoso.com 3600 IN MX 10 contoso-com.mail.protection.outlook.com
سيتم توجيه البريد الإلكتروني بالكامل أو معظمه أولا إلى mail.contoso.com لأنه MX الأساسي، ثم سيتم توجيه البريد إلى EOP. في بعض الحالات، قد لا تقوم حتى بسرد EOP كسجل MX على الإطلاق وربط الموصلات لتوجيه بريدك الإلكتروني. لا يجب أن يكون EOP هو الإدخال الأول للتحقق من صحة DMARC الذي يجب القيام به. إنها تضمن فقط التحقق من الصحة، للتأكد من أن جميع الخوادم المحلية/غير التابعة ل O365 ستقوم بعمليات التحقق من DMARC. DMARC مؤهل لفرضه لمجال العميل (وليس الخادم) عند إعداد سجل DMARC TXT، ولكن الأمر متروك للخادم المتلقي للقيام بالفعل بالإنفاذ. إذا قمت بإعداد EOP كخادم استلام، فإن EOP يقوم بتنفيذ DMARC.
لمزيد من المعلومات
هل تريد المزيد من المعلومات حول DMARC؟ يمكن أن تساعد هذه الموارد.
تتضمن رؤوس رسائل مكافحة البريد العشوائي حقول بناء الجملة والرأس المستخدمة من قبل Microsoft 365 لعمليات التحقق من DMARC.
خذ سلسلة تدريب DMARC من M3AAWG (المراسلة والبرامج الضارة ومجموعة عمل مكافحة إساءة استخدام الأجهزة المحمولة).
استخدم قائمة الاختيار في dmarcian.
انتقل مباشرة إلى المصدر في DMARC.org.
راجع أيضًا
كيفية استخدام Microsoft 365 إطار نهج المرسل (SPF) لمنع الانتحال
إعداد SPF في Microsoft 365 للمساعدة في منع الانتحال
استخدم DKIM للتحقق من صحة البريد الإلكتروني الصادر المرسل من مجالك المخصص في Microsoft 365
الملاحظات
إرسال الملاحظات وعرضها المتعلقة بـ