DMARC: كيفية حماية سمعة بريدك الإلكتروني
Bird
13/04/2016
البريد الإلكتروني
1 min read
النقاط الرئيسية
يساعد DMARC في حماية نطاقك من التصيد الاحتيالي والتزييف والاستخدام غير المصرح به للبريد الإلكتروني من خلال نشر ممارسات المصادقة الخاصة بك وطلب معالجة محددة للرسائل الفاشلة.
يعمل جنبًا إلى جنب مع SPF وDKIM لضمان توافق النطاق ومنع البريد الاحتيالي من الإضرار بسمعة المرسل.
تدعم سياسات DMARC القوية ثقة أعلى ومشاركة أعلى وتأمين نطاقك في المستقبل مع تحول النظام البيئي نحو نماذج السمعة القائمة على النطاق.
تعتمد فحوصات التحقق من DMARC على توافق النطاق بين مجال المرسل، ومجال Return-Path (SPF)، ومجال توقيع DKIM.
يتطلب إعداد DMARC تلقي التقارير وفهم البيانات المجمعة مقابل البيانات الجنائية وتكوين الأدوات لتحليلها.
تبدأ بسياسة p=none آمنة لمراقبة الحركة قبل الانتقال إلى حجر صحي أو رفض.
يتضمن نشر سجل DMARC إنشاء إدخال DNS TXT في _dmarc.yourdomain.com مع السياسة وعناوين التقارير والمعايير الاختيارية مثل طرح النسبة المئوية.
تُعتبر صناديق البريد للإبلاغ المناسبة (المجمعة والجنائية) وأدوات التحليل أمرًا ضروريًا لمراقبة الامتثال والكشف عن التزييف وضمان التوافق الصحيح.
يتطلب DMARC فقط واحد من الأمور التالية لكى يمر: SPF متوافق أو DKIM متوافق.
يساهم تنفيذ DMARC في تعزيز أمان البريد الإلكتروني ويلعب دورًا رئيسيًا في سلامة العلامة التجارية والثقة والتسليمية طويلة الأمد.
أبرز الأسئلة والأجوبة
ما هو DMARC ولماذا هو مهم؟
DMARC (المصادقة القائمة على النطاق، الإبلاغ، والتوافق) هي سياسة منشورة عبر نظام أسماء النطاقات (DNS) تحمي نطاقك من الانتحال والتصيد عن طريق فرض توافق النطاق وتفعيل الرؤية عبر الإبلاغ.
هل DMARC بروتوكول مصادقة؟
رقم DMARC ليس هو التوثيق نفسه - بل يعتمد على SPF و DKIM لتوثيق البريد الإلكتروني ويستخدم السياسة + التقارير للتحكم في كيفية تعامل الخوادم المستلمة مع الفشل.
ماذا يتحقق DMARC منه؟
إنه يتحقق من:
مصادقة SPF + محاذاة
مصادقة DKIM + محاذاة
يحتاج المرسل فقط إلى واحدة من هذه لتمرير DMARC للنجاح.
ما هو "التوافق العملي للمجال"؟
إنه شرط أن يتطابق المجال الظاهر من (صارم) أو يشارك نفس المجال التنظيمي (مرن) مع إما مجال مسار العودة SPF أو مجال توقيع DKIM.
لماذا يحسن DMARC إمكانية التسليم؟
لأن مقدمي خدمة البريد يثقون في المجالات المُعتمدة والمتوافقة بشكل أكبر. يمنع DMARC الرسائل المزورة من التأثير سلباً على سمعتك ويحسن من وصول الرسائل الشرعية إلى علبة الوارد.
ما هو الفرق بين التقارير المجمعة والتقارير الجنائية لـ DMARC؟
تقارير مجمعة (RUA): ملخصات XML لنتائج المصادقة عبر جميع حركة المرور.
تقارير تحقيق (RUF): عينات فردية من الرسائل الفاشلة لتحليل أعمق.
ما هي صناديق البريد التي أحتاجها قبل نشر DMARC؟
يجب عليك إنشاء عنوانين، مثل:
agg_reports@yourdomain.com (RUA)
afrf_reports@yourdomain.com (RUF)
هذا يحافظ على تقارير التدفق منفصلة ويسهل تحليلها.
ما سياسة DMARC التي يجب أن أبدأ بها؟
ابدأ دائمًا بـp=none. إنه يراقب نشاط المصادقة دون التأثير على التسليم، مما يتيح لك تحديد مشاكل المحاذاة ومحاولات التزوير بأمان.
ما هي سياسات DMARC المتاحة؟
لا شيء: رصد فقط
الحجر الصحي: إرسال الرسائل الفاشلة إلى البريد العشوائي
رفض: حظر الرسائل الفاشلة تمامًا
أين أنشر سجل DMARC؟
في نظام أسماء النطاقات (DNS) لديك في:
_dmarc.yourdomain.com
يجب أن يكون هناك سجل TXT يحدد سياستك وإصدارتك ونقاط النهاية للتقارير.
كيف يبدو السجل الأساسي لـ DMARC؟
مثال:
v=DMARC1; p=none; rua=mailto:agg_reports@yourdomain.com; ruf=mailto:afrf_reports@yourdomain.com; pct=100
ماذا يحدث إذا فشل DMARC؟
يطبق الخادم المستلم السياسة التي طلبتها (بدون، الحجر، الرفض)، على الرغم من أن المعالجة النهائية تعود في النهاية إلى المزود. يمكن أن تقلل السياسة الصارمة بشكل كبير من محاولات التصيد الاحتيالي باستخدام نطاقك.
في هذا المنشور، سنخبرك بكل ما تحتاج لمعرفته حول الاستفادة من DMARC لحماية سمعة بريدك الإلكتروني، ونقدم لك بعض النصائح حول كيفية إعدادها لمجالاتك.
نشر سياسة DMARC الخاصة بك
يتم الإعلان عن سياسة DMARC لنطاق من خلال نشر سجل DNS TXT في مكان محدد في مساحة أسماء DNS، وهو "_dmarc.domainname.tld" (لاحظ الشرطة السفلية في البداية). قد يبدو سجل سياسة DMARC الأساسي لنطاق المثال السابق، joesbaitshop.com، شيئًا مثل هذا:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
بتفكيك هذا السجل، لدينا:
v=DMARC1 يحدد إصدار DMARC (الإصدار 1 هو الخيار الوحيد الآن)
p=none يحدد المعالجة المفضلة، أو سياسة DMARC
rua=mailto:agg_reports@joesbait.com هو صندوق البريد الذي ينبغي أن تُرسل إليه التقارير التجميعية
ruf=mailto:afrf_reports@joesbait.com هو صندوق البريد الذي ينبغي أن تُرسل إليه التقارير الجنائية
pct=100 هي النسبة المئوية من البريد التي يرغب مالك النطاق في تطبيق سياسته عليها. قد ترغب النطاقات التي بدأت مؤخرًا باستخدام DMARC، خصوصًا تلك التي من المحتمل أن تولد حجمًا كبيرًا من التقارير، في البدء برقم أقل بكثير هنا لرؤية كيف تقف عمليات التعامل مع التقارير في وجه الحمل.
هناك خيارات ضبط أخرى متاحة لمالك النطاق لاستخدامها في سجل سياسة DMARC الخاص به أيضًا، لكن النصائح التي قدمناها يجب أن تكون بداية جيدة.
يتم الإعلان عن سياسة DMARC لنطاق من خلال نشر سجل DNS TXT في مكان محدد في مساحة أسماء DNS، وهو "_dmarc.domainname.tld" (لاحظ الشرطة السفلية في البداية). قد يبدو سجل سياسة DMARC الأساسي لنطاق المثال السابق، joesbaitshop.com، شيئًا مثل هذا:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
بتفكيك هذا السجل، لدينا:
v=DMARC1 يحدد إصدار DMARC (الإصدار 1 هو الخيار الوحيد الآن)
p=none يحدد المعالجة المفضلة، أو سياسة DMARC
rua=mailto:agg_reports@joesbait.com هو صندوق البريد الذي ينبغي أن تُرسل إليه التقارير التجميعية
ruf=mailto:afrf_reports@joesbait.com هو صندوق البريد الذي ينبغي أن تُرسل إليه التقارير الجنائية
pct=100 هي النسبة المئوية من البريد التي يرغب مالك النطاق في تطبيق سياسته عليها. قد ترغب النطاقات التي بدأت مؤخرًا باستخدام DMARC، خصوصًا تلك التي من المحتمل أن تولد حجمًا كبيرًا من التقارير، في البدء برقم أقل بكثير هنا لرؤية كيف تقف عمليات التعامل مع التقارير في وجه الحمل.
هناك خيارات ضبط أخرى متاحة لمالك النطاق لاستخدامها في سجل سياسة DMARC الخاص به أيضًا، لكن النصائح التي قدمناها يجب أن تكون بداية جيدة.
يتم الإعلان عن سياسة DMARC لنطاق من خلال نشر سجل DNS TXT في مكان محدد في مساحة أسماء DNS، وهو "_dmarc.domainname.tld" (لاحظ الشرطة السفلية في البداية). قد يبدو سجل سياسة DMARC الأساسي لنطاق المثال السابق، joesbaitshop.com، شيئًا مثل هذا:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
بتفكيك هذا السجل، لدينا:
v=DMARC1 يحدد إصدار DMARC (الإصدار 1 هو الخيار الوحيد الآن)
p=none يحدد المعالجة المفضلة، أو سياسة DMARC
rua=mailto:agg_reports@joesbait.com هو صندوق البريد الذي ينبغي أن تُرسل إليه التقارير التجميعية
ruf=mailto:afrf_reports@joesbait.com هو صندوق البريد الذي ينبغي أن تُرسل إليه التقارير الجنائية
pct=100 هي النسبة المئوية من البريد التي يرغب مالك النطاق في تطبيق سياسته عليها. قد ترغب النطاقات التي بدأت مؤخرًا باستخدام DMARC، خصوصًا تلك التي من المحتمل أن تولد حجمًا كبيرًا من التقارير، في البدء برقم أقل بكثير هنا لرؤية كيف تقف عمليات التعامل مع التقارير في وجه الحمل.
هناك خيارات ضبط أخرى متاحة لمالك النطاق لاستخدامها في سجل سياسة DMARC الخاص به أيضًا، لكن النصائح التي قدمناها يجب أن تكون بداية جيدة.
أداة فعالة لمكافحة البريد الاحتيالي
في كثير من الأحيان، يُذكر جنبًا إلى جنب مع بروتوكولات مصادقة البريد الإلكتروني SPF وDKIM، فإن DMARC، أو مصادقة الرسائل المعتمدة على النطاق والتقارير والتوافق، ليس في حد ذاته بروتوكول مصادقة. بدلاً من ذلك، يهدف DMARC للسماح لنا، مالكي النطاق، بحماية سمعة بريدنا الإلكتروني عن طريق:
الإعلان عن ممارسات مصادقة البريد الإلكتروني،
طلب معالجة البريد الذي يفشل في اختبارات المصادقة، و
طلب تقارير حول البريد الذي يدعي أنه من نطاقه.
يمكن أن يكون DMARC أداة فعالة لنا لاستخدامها في معركتنا ضد البريد الاحتيالي الذي يستهدف اسم نطاقنا (مثل التصيد والتزوير)، والذي يمكن أن يعزز الثقة العالية بين مستلمينا من أجل بريدنا. بالنسبة للمنظمات التي تتطلب تشفيرًا من النهاية إلى النهاية يتجاوز المصادقة، فإن تنفيذ S/MIME مع طرق جمع المفاتيح العامة للمستلم الفعالة يوفر طبقات أمان إضافية. هذه الثقة العالية يجب أن تؤدي بدورها إلى زيادة التفاعل مع بريدنا، والبريد الذي يُفتح ويولد نقرات يؤدي إلى زيادة المبيعات وعائد استثمار أعلى لحملات بريدنا الإلكتروني.
بالإضافة إلى حماية نطاقنا، نتوقع أن تنفيذ DMARC الآن سيكون وسيلة ممتازة "لضمان المستقبل" لنطاقنا. هنا في Bird، نعتقد أنه مع تقدم الصناعة إلى IPv6، من شبه المؤكد أنها ستنتقل من نموذج سمعة قائم على IP إلى نموذج سمعة قائم على النطاق. سيتطلب سمعة النطاق مصادقة قائمة على النطاق، وDMARC، بالتعاون مع DKIM وSPF، سيساعد النطاقات في إنشاء سمعة قائمة على النطاق طويلًا قبل أن يصبح ضروريًا بشكل مطلق.
في هذا المنشور، سنخبرك بكل ما تحتاج لمعرفته حول استخدام DMARC لحماية سمعة بريدك الإلكتروني وسنقدم لك نصائح حول كيفية إعدادها لنطاقاتك.
في كثير من الأحيان، يُذكر جنبًا إلى جنب مع بروتوكولات مصادقة البريد الإلكتروني SPF وDKIM، فإن DMARC، أو مصادقة الرسائل المعتمدة على النطاق والتقارير والتوافق، ليس في حد ذاته بروتوكول مصادقة. بدلاً من ذلك، يهدف DMARC للسماح لنا، مالكي النطاق، بحماية سمعة بريدنا الإلكتروني عن طريق:
الإعلان عن ممارسات مصادقة البريد الإلكتروني،
طلب معالجة البريد الذي يفشل في اختبارات المصادقة، و
طلب تقارير حول البريد الذي يدعي أنه من نطاقه.
يمكن أن يكون DMARC أداة فعالة لنا لاستخدامها في معركتنا ضد البريد الاحتيالي الذي يستهدف اسم نطاقنا (مثل التصيد والتزوير)، والذي يمكن أن يعزز الثقة العالية بين مستلمينا من أجل بريدنا. بالنسبة للمنظمات التي تتطلب تشفيرًا من النهاية إلى النهاية يتجاوز المصادقة، فإن تنفيذ S/MIME مع طرق جمع المفاتيح العامة للمستلم الفعالة يوفر طبقات أمان إضافية. هذه الثقة العالية يجب أن تؤدي بدورها إلى زيادة التفاعل مع بريدنا، والبريد الذي يُفتح ويولد نقرات يؤدي إلى زيادة المبيعات وعائد استثمار أعلى لحملات بريدنا الإلكتروني.
بالإضافة إلى حماية نطاقنا، نتوقع أن تنفيذ DMARC الآن سيكون وسيلة ممتازة "لضمان المستقبل" لنطاقنا. هنا في Bird، نعتقد أنه مع تقدم الصناعة إلى IPv6، من شبه المؤكد أنها ستنتقل من نموذج سمعة قائم على IP إلى نموذج سمعة قائم على النطاق. سيتطلب سمعة النطاق مصادقة قائمة على النطاق، وDMARC، بالتعاون مع DKIM وSPF، سيساعد النطاقات في إنشاء سمعة قائمة على النطاق طويلًا قبل أن يصبح ضروريًا بشكل مطلق.
في هذا المنشور، سنخبرك بكل ما تحتاج لمعرفته حول استخدام DMARC لحماية سمعة بريدك الإلكتروني وسنقدم لك نصائح حول كيفية إعدادها لنطاقاتك.
في كثير من الأحيان، يُذكر جنبًا إلى جنب مع بروتوكولات مصادقة البريد الإلكتروني SPF وDKIM، فإن DMARC، أو مصادقة الرسائل المعتمدة على النطاق والتقارير والتوافق، ليس في حد ذاته بروتوكول مصادقة. بدلاً من ذلك، يهدف DMARC للسماح لنا، مالكي النطاق، بحماية سمعة بريدنا الإلكتروني عن طريق:
الإعلان عن ممارسات مصادقة البريد الإلكتروني،
طلب معالجة البريد الذي يفشل في اختبارات المصادقة، و
طلب تقارير حول البريد الذي يدعي أنه من نطاقه.
يمكن أن يكون DMARC أداة فعالة لنا لاستخدامها في معركتنا ضد البريد الاحتيالي الذي يستهدف اسم نطاقنا (مثل التصيد والتزوير)، والذي يمكن أن يعزز الثقة العالية بين مستلمينا من أجل بريدنا. بالنسبة للمنظمات التي تتطلب تشفيرًا من النهاية إلى النهاية يتجاوز المصادقة، فإن تنفيذ S/MIME مع طرق جمع المفاتيح العامة للمستلم الفعالة يوفر طبقات أمان إضافية. هذه الثقة العالية يجب أن تؤدي بدورها إلى زيادة التفاعل مع بريدنا، والبريد الذي يُفتح ويولد نقرات يؤدي إلى زيادة المبيعات وعائد استثمار أعلى لحملات بريدنا الإلكتروني.
بالإضافة إلى حماية نطاقنا، نتوقع أن تنفيذ DMARC الآن سيكون وسيلة ممتازة "لضمان المستقبل" لنطاقنا. هنا في Bird، نعتقد أنه مع تقدم الصناعة إلى IPv6، من شبه المؤكد أنها ستنتقل من نموذج سمعة قائم على IP إلى نموذج سمعة قائم على النطاق. سيتطلب سمعة النطاق مصادقة قائمة على النطاق، وDMARC، بالتعاون مع DKIM وSPF، سيساعد النطاقات في إنشاء سمعة قائمة على النطاق طويلًا قبل أن يصبح ضروريًا بشكل مطلق.
في هذا المنشور، سنخبرك بكل ما تحتاج لمعرفته حول استخدام DMARC لحماية سمعة بريدك الإلكتروني وسنقدم لك نصائح حول كيفية إعدادها لنطاقاتك.
مصطلحات يجب معرفتها
قبل أن نبدأ في إعداد DMARC لنطاقك، نريد التأكد من أننا نتحدث نفس اللغة. دعونا نبدأ بتعريف بعض المصطلحات التي سنستخدمها في بقية هذا المستند.
RFC5322.From Domain
RFC5322.From Domain هو الجزء الذي يشير إلى النطاق في عنوان البريد الإلكتروني الذي يُرى عادةً بواسطة المستلم عندما يتم قراءة بريدنا الإلكتروني. في المثال التالي، نطاق RFC5322.From هو "joesbaitshop.com"
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= Domain
DKIM هو بروتوكول مصادقة يسمح للنطاق بأن يتحمل مسؤولية رسالة بطريقة يمكن التحقق منها من قبل مستلم الرسالة؛ يتم ذلك من خلال استخدام توقيعات تشفير تُدرج في رؤوس الرسالة أثناء مغادرتها لنقطة الأصل. هذه التوقيعات تعتبر لقطات فعالة لما كانت تبدو عليه الرسالة في تلك اللحظة الزمنية، ويمكن للمستلم استخدام هذه اللقطات لرؤية ما إذا كانت الرسالة قد وصلت دون تغيير إلى وجهتها. يسمى عملية إنتاج وإدراج هذه اللقطات بتوقيع DKIM، والنطاق الذي يتحمل مسؤولية الرسالة عن طريق توقيعها يُدرج اسمه في العنوان في علامة القيم كـ "d=signingDomain"، ولذلك يُشار إليها على أنها DKIM d= domain.
Return-Path Domain
نطاق مسار الإرجاع، يُسمى أحيانًا RFC5321. From Domain أو نطاق Mail From، هو النطاق الذي يتم توجيه الارتدادات إليه؛ وهو أيضًا النطاق الذي تُجرى عليه فحوصات SPF أثناء معاملة البريد الإلكتروني. لا يُرى هذا النطاق عادةً بواسطة المستلم إلا إذا كان المستلم ذكيًا بما يكفي للنظر إلى جميع الرؤوس في رسالة معينة.
بشكل افتراضي، جميع الرسائل المرسلة عبر bird.com سيكون لها birdmail.com كنطاق مسار الإرجاع، كما في المثال التالي:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
ومع ذلك، من أجل جعل DMARC يعمل لنطاقك، ستحتاج إلى الاستفادة من نطاق إرجاع مخصص، واحد سينتهي بنفس النطاق كنطاق الإرسال الخاص بك، على سبيل المثال، bounces.yourdomain.com عند استخدام yourdomain.com كنطاق الإرسال الخاص بك.
Organizational Domain
يشير مصطلح "النطاق التنظيمي" إلى النطاق الذي تم تقديمه إلى السجل لإنشاء تواجد للنطاق على الإنترنت. بالنسبة لـ Bird، فإن نطاقاتنا التنظيمية هي bird.com وbirdmail.com.
Domain Alignment
المصطلح الأخير لفهمه بخصوص DMARC هو "محاذاة النطاق"، وهناك نوعان منه: "مرن" و"صارم".
Relaxed Domain Alignment
يُقال أن هناك محاذاة نطاق مرنة بين أي نطاقين إذا كانت نطاقاتهما التنظيمية هي نفسها. على سبيل المثال، a.mail.bird.com وb.foo.bird.com لديهما محاذاة نطاق مرنة بسبب نطاقهما التنظيمي المشترك، bird.com.
Strict Domain Alignment
يُقال أن هناك محاذاة نطاق صارمة بين نطاقين إذا وفقط إذا كانت متطابقة. لذا، foo.bird.com وfoo.bird.com في محاذاة صارمة، لأن النطاقين متطابقان. من ناحية أخرى، foo.bird.com وbar.foo.bird.com فقط في محاذاة مرنة.
DMARC Domain Alignment Requirements
لكي تجتاز فحوصات التصديق لـ DMARC، يتطلب DMARC أن تكون هناك محاذاة للنطاق كما يلي:
بالنسبة لـ SPF، يجب أن يكون نطاق RFC5322.From والنطاق مسار الإرجاع في محاذاة
بالنسبة لـ DKIM، يجب أن يكون نطاق RFC5322.From والنطاق DKIM d= في محاذاة
يمكن أن تكون المحاذاة مرنة أو صارمة، بناءً على السياسة المنشورة للنطاق المرسل.
قبل أن نبدأ في إعداد DMARC لنطاقك، نريد التأكد من أننا نتحدث نفس اللغة. دعونا نبدأ بتعريف بعض المصطلحات التي سنستخدمها في بقية هذا المستند.
RFC5322.From Domain
RFC5322.From Domain هو الجزء الذي يشير إلى النطاق في عنوان البريد الإلكتروني الذي يُرى عادةً بواسطة المستلم عندما يتم قراءة بريدنا الإلكتروني. في المثال التالي، نطاق RFC5322.From هو "joesbaitshop.com"
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= Domain
DKIM هو بروتوكول مصادقة يسمح للنطاق بأن يتحمل مسؤولية رسالة بطريقة يمكن التحقق منها من قبل مستلم الرسالة؛ يتم ذلك من خلال استخدام توقيعات تشفير تُدرج في رؤوس الرسالة أثناء مغادرتها لنقطة الأصل. هذه التوقيعات تعتبر لقطات فعالة لما كانت تبدو عليه الرسالة في تلك اللحظة الزمنية، ويمكن للمستلم استخدام هذه اللقطات لرؤية ما إذا كانت الرسالة قد وصلت دون تغيير إلى وجهتها. يسمى عملية إنتاج وإدراج هذه اللقطات بتوقيع DKIM، والنطاق الذي يتحمل مسؤولية الرسالة عن طريق توقيعها يُدرج اسمه في العنوان في علامة القيم كـ "d=signingDomain"، ولذلك يُشار إليها على أنها DKIM d= domain.
Return-Path Domain
نطاق مسار الإرجاع، يُسمى أحيانًا RFC5321. From Domain أو نطاق Mail From، هو النطاق الذي يتم توجيه الارتدادات إليه؛ وهو أيضًا النطاق الذي تُجرى عليه فحوصات SPF أثناء معاملة البريد الإلكتروني. لا يُرى هذا النطاق عادةً بواسطة المستلم إلا إذا كان المستلم ذكيًا بما يكفي للنظر إلى جميع الرؤوس في رسالة معينة.
بشكل افتراضي، جميع الرسائل المرسلة عبر bird.com سيكون لها birdmail.com كنطاق مسار الإرجاع، كما في المثال التالي:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
ومع ذلك، من أجل جعل DMARC يعمل لنطاقك، ستحتاج إلى الاستفادة من نطاق إرجاع مخصص، واحد سينتهي بنفس النطاق كنطاق الإرسال الخاص بك، على سبيل المثال، bounces.yourdomain.com عند استخدام yourdomain.com كنطاق الإرسال الخاص بك.
Organizational Domain
يشير مصطلح "النطاق التنظيمي" إلى النطاق الذي تم تقديمه إلى السجل لإنشاء تواجد للنطاق على الإنترنت. بالنسبة لـ Bird، فإن نطاقاتنا التنظيمية هي bird.com وbirdmail.com.
Domain Alignment
المصطلح الأخير لفهمه بخصوص DMARC هو "محاذاة النطاق"، وهناك نوعان منه: "مرن" و"صارم".
Relaxed Domain Alignment
يُقال أن هناك محاذاة نطاق مرنة بين أي نطاقين إذا كانت نطاقاتهما التنظيمية هي نفسها. على سبيل المثال، a.mail.bird.com وb.foo.bird.com لديهما محاذاة نطاق مرنة بسبب نطاقهما التنظيمي المشترك، bird.com.
Strict Domain Alignment
يُقال أن هناك محاذاة نطاق صارمة بين نطاقين إذا وفقط إذا كانت متطابقة. لذا، foo.bird.com وfoo.bird.com في محاذاة صارمة، لأن النطاقين متطابقان. من ناحية أخرى، foo.bird.com وbar.foo.bird.com فقط في محاذاة مرنة.
DMARC Domain Alignment Requirements
لكي تجتاز فحوصات التصديق لـ DMARC، يتطلب DMARC أن تكون هناك محاذاة للنطاق كما يلي:
بالنسبة لـ SPF، يجب أن يكون نطاق RFC5322.From والنطاق مسار الإرجاع في محاذاة
بالنسبة لـ DKIM، يجب أن يكون نطاق RFC5322.From والنطاق DKIM d= في محاذاة
يمكن أن تكون المحاذاة مرنة أو صارمة، بناءً على السياسة المنشورة للنطاق المرسل.
قبل أن نبدأ في إعداد DMARC لنطاقك، نريد التأكد من أننا نتحدث نفس اللغة. دعونا نبدأ بتعريف بعض المصطلحات التي سنستخدمها في بقية هذا المستند.
RFC5322.From Domain
RFC5322.From Domain هو الجزء الذي يشير إلى النطاق في عنوان البريد الإلكتروني الذي يُرى عادةً بواسطة المستلم عندما يتم قراءة بريدنا الإلكتروني. في المثال التالي، نطاق RFC5322.From هو "joesbaitshop.com"
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= Domain
DKIM هو بروتوكول مصادقة يسمح للنطاق بأن يتحمل مسؤولية رسالة بطريقة يمكن التحقق منها من قبل مستلم الرسالة؛ يتم ذلك من خلال استخدام توقيعات تشفير تُدرج في رؤوس الرسالة أثناء مغادرتها لنقطة الأصل. هذه التوقيعات تعتبر لقطات فعالة لما كانت تبدو عليه الرسالة في تلك اللحظة الزمنية، ويمكن للمستلم استخدام هذه اللقطات لرؤية ما إذا كانت الرسالة قد وصلت دون تغيير إلى وجهتها. يسمى عملية إنتاج وإدراج هذه اللقطات بتوقيع DKIM، والنطاق الذي يتحمل مسؤولية الرسالة عن طريق توقيعها يُدرج اسمه في العنوان في علامة القيم كـ "d=signingDomain"، ولذلك يُشار إليها على أنها DKIM d= domain.
Return-Path Domain
نطاق مسار الإرجاع، يُسمى أحيانًا RFC5321. From Domain أو نطاق Mail From، هو النطاق الذي يتم توجيه الارتدادات إليه؛ وهو أيضًا النطاق الذي تُجرى عليه فحوصات SPF أثناء معاملة البريد الإلكتروني. لا يُرى هذا النطاق عادةً بواسطة المستلم إلا إذا كان المستلم ذكيًا بما يكفي للنظر إلى جميع الرؤوس في رسالة معينة.
بشكل افتراضي، جميع الرسائل المرسلة عبر bird.com سيكون لها birdmail.com كنطاق مسار الإرجاع، كما في المثال التالي:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
ومع ذلك، من أجل جعل DMARC يعمل لنطاقك، ستحتاج إلى الاستفادة من نطاق إرجاع مخصص، واحد سينتهي بنفس النطاق كنطاق الإرسال الخاص بك، على سبيل المثال، bounces.yourdomain.com عند استخدام yourdomain.com كنطاق الإرسال الخاص بك.
Organizational Domain
يشير مصطلح "النطاق التنظيمي" إلى النطاق الذي تم تقديمه إلى السجل لإنشاء تواجد للنطاق على الإنترنت. بالنسبة لـ Bird، فإن نطاقاتنا التنظيمية هي bird.com وbirdmail.com.
Domain Alignment
المصطلح الأخير لفهمه بخصوص DMARC هو "محاذاة النطاق"، وهناك نوعان منه: "مرن" و"صارم".
Relaxed Domain Alignment
يُقال أن هناك محاذاة نطاق مرنة بين أي نطاقين إذا كانت نطاقاتهما التنظيمية هي نفسها. على سبيل المثال، a.mail.bird.com وb.foo.bird.com لديهما محاذاة نطاق مرنة بسبب نطاقهما التنظيمي المشترك، bird.com.
Strict Domain Alignment
يُقال أن هناك محاذاة نطاق صارمة بين نطاقين إذا وفقط إذا كانت متطابقة. لذا، foo.bird.com وfoo.bird.com في محاذاة صارمة، لأن النطاقين متطابقان. من ناحية أخرى، foo.bird.com وbar.foo.bird.com فقط في محاذاة مرنة.
DMARC Domain Alignment Requirements
لكي تجتاز فحوصات التصديق لـ DMARC، يتطلب DMARC أن تكون هناك محاذاة للنطاق كما يلي:
بالنسبة لـ SPF، يجب أن يكون نطاق RFC5322.From والنطاق مسار الإرجاع في محاذاة
بالنسبة لـ DKIM، يجب أن يكون نطاق RFC5322.From والنطاق DKIM d= في محاذاة
يمكن أن تكون المحاذاة مرنة أو صارمة، بناءً على السياسة المنشورة للنطاق المرسل.
كيف تعمل DMARC لحماية سمعة بريدك الإلكتروني
عندما نتحدث عن مزود صندوق بريد أو نطاق آخر “يتحقق من DMARC”، أو “يقوم بالتحقق من صحة DMARC”، أو “تطبيق سياسة DMARC”، فإن ما نعنيه هو أن النطاق الذي يستقبل الرسالة يقوم بالخطوات التالية:
تحديد نطاق الرسالة RFC5322.From
التحقق من سياسة DMARC لذلك النطاق في DNS
قم بإجراء التحقق من توقيع DKIM
قم بإجراء التحقق من صحة SPF
تحقق من توافق النطاق
تطبيق سياسة DMARC
لكي تتجاوز الرسالة التحقق من صحة DMARC، يجب أن تمر الرسالة عن طريق واحد من اختبارين للمصادقة والتوافق. لذلك، ستمر الرسالة من التحقق من صحة DMARC إذا كان أي من التالي صحيحًا:
تمر الرسالة بفحص SPF ويتوافق نطاق RFC5322.From مع نطاق Return-Path، أو
تمر الرسالة بالتحقق من صحة DKIM ويتوافق نطاق RFC5322.From مع نطاق DKIM d=، أو
كل ما سبق صحيح
عندما نتحدث عن مزود صندوق بريد أو نطاق آخر “يتحقق من DMARC”، أو “يقوم بالتحقق من صحة DMARC”، أو “تطبيق سياسة DMARC”، فإن ما نعنيه هو أن النطاق الذي يستقبل الرسالة يقوم بالخطوات التالية:
تحديد نطاق الرسالة RFC5322.From
التحقق من سياسة DMARC لذلك النطاق في DNS
قم بإجراء التحقق من توقيع DKIM
قم بإجراء التحقق من صحة SPF
تحقق من توافق النطاق
تطبيق سياسة DMARC
لكي تتجاوز الرسالة التحقق من صحة DMARC، يجب أن تمر الرسالة عن طريق واحد من اختبارين للمصادقة والتوافق. لذلك، ستمر الرسالة من التحقق من صحة DMARC إذا كان أي من التالي صحيحًا:
تمر الرسالة بفحص SPF ويتوافق نطاق RFC5322.From مع نطاق Return-Path، أو
تمر الرسالة بالتحقق من صحة DKIM ويتوافق نطاق RFC5322.From مع نطاق DKIM d=، أو
كل ما سبق صحيح
عندما نتحدث عن مزود صندوق بريد أو نطاق آخر “يتحقق من DMARC”، أو “يقوم بالتحقق من صحة DMARC”، أو “تطبيق سياسة DMARC”، فإن ما نعنيه هو أن النطاق الذي يستقبل الرسالة يقوم بالخطوات التالية:
تحديد نطاق الرسالة RFC5322.From
التحقق من سياسة DMARC لذلك النطاق في DNS
قم بإجراء التحقق من توقيع DKIM
قم بإجراء التحقق من صحة SPF
تحقق من توافق النطاق
تطبيق سياسة DMARC
لكي تتجاوز الرسالة التحقق من صحة DMARC، يجب أن تمر الرسالة عن طريق واحد من اختبارين للمصادقة والتوافق. لذلك، ستمر الرسالة من التحقق من صحة DMARC إذا كان أي من التالي صحيحًا:
تمر الرسالة بفحص SPF ويتوافق نطاق RFC5322.From مع نطاق Return-Path، أو
تمر الرسالة بالتحقق من صحة DKIM ويتوافق نطاق RFC5322.From مع نطاق DKIM d=، أو
كل ما سبق صحيح
جعل DMARC يعمل لصالح نطاقك
الآن بعد أن شرحنا آلية عمل DMARC، دعنا نتحدث عن كيفية جعل DMARC يعمل لصالحنا، مما يتضمن الخطوات الثلاثة التالية:
التحضير لاستلام تقارير DMARC
اتخاذ قرار بشأن سياسة DMARC المناسبة لنطاقك
نشر سجل DMARC الخاص بك
سنقوم بتغطية كل واحدة من هذه الخطوات بالتفصيل أدناه، ولكن سنخبرك مباشرة أن الخطوة 1 المذكورة أعلاه ستستهلك حوالي 95% من وقت تحضيرك.
الآن بعد أن شرحنا آلية عمل DMARC، دعنا نتحدث عن كيفية جعل DMARC يعمل لصالحنا، مما يتضمن الخطوات الثلاثة التالية:
التحضير لاستلام تقارير DMARC
اتخاذ قرار بشأن سياسة DMARC المناسبة لنطاقك
نشر سجل DMARC الخاص بك
سنقوم بتغطية كل واحدة من هذه الخطوات بالتفصيل أدناه، ولكن سنخبرك مباشرة أن الخطوة 1 المذكورة أعلاه ستستهلك حوالي 95% من وقت تحضيرك.
الآن بعد أن شرحنا آلية عمل DMARC، دعنا نتحدث عن كيفية جعل DMARC يعمل لصالحنا، مما يتضمن الخطوات الثلاثة التالية:
التحضير لاستلام تقارير DMARC
اتخاذ قرار بشأن سياسة DMARC المناسبة لنطاقك
نشر سجل DMARC الخاص بك
سنقوم بتغطية كل واحدة من هذه الخطوات بالتفصيل أدناه، ولكن سنخبرك مباشرة أن الخطوة 1 المذكورة أعلاه ستستهلك حوالي 95% من وقت تحضيرك.
التحضير لتلقي تقارير DMARC
يجب أن يستعد أي نطاق ينشر سياسة DMARC لتلقي تقارير بخصوص نطاقه. سيتم إنشاء هذه التقارير بواسطة أي نطاق يقوم بالتحقق من صحة DMARC ويرى البريد الذي يدعي أنه من نطاقنا، وسيتم إرسالها إلينا على الأقل بشكل يومي. ستأتي التقارير بتنسيقين:
التقارير المجمعة، وهي وثائق XML تعرض بيانات إحصائية عن كمية البريد التي رأها المبلغ من كل مصدر، وما كانت نتائج المصادقة، وكيف تعامل المراسل مع الرسائل. تم تصميم التقارير المجمعة لكي يتم تحليلها بواسطة الآلة، مع تخزين بياناتها في مكان ما للسماح بتحليل حركة المرور بشكل عام، ومراجعة تدفقات رسائل نطاقنا، وربما تحديد الاتجاهات في مصادر البريد غير المصدق عليه، وربما الاحتيالي.
التقارير الجنائية، وهي نسخ فردية من الرسائل التي فشلت في المصادقة، كل واحدة مرفقة في رسالة بريد إلكتروني كاملة باستخدام تنسيق يسمى AFRF. يفترض أن تحتوي التقارير الجنائية على رؤوس وبنود الرسائل الكاملة، لكن العديد من المراسلين يزيلون أو يحجبون بعض المعلومات بسبب مخاوف الخصوصية. ومع ذلك، يمكن أن يكون التقرير الجنائي مفيدا جدا لكلا من استكشاف مشكلات المصادقة الخاصة بنطاقنا وتحديد، من خلال عناوين URI في بنيات الرسائل، المجالات والمواقع الخبيثة المستخدمة للاحتيال على عملاء مالك نطاقنا.
تشمل التحضيرات لتلقي هذه التقارير أولاً إنشاء صندوقي بريد في نطاقنا لمعالجة هذه التقارير، مثل agg_reports@ourdomain.com وafrf_reports@ourdomain.com. لاحظ أن أسماء صندوق البريد تلك عشوائية تمامًا، ولا توجد متطلبات لتسمية الجزء المحلي من صندوق البريد؛ نحن أحرار في اختيار أي أسماء نريدها، لكن نحتفظ بهذين الصندوقين منفصلين لتسهيل المعالجة.
بمجرد اختيار وإنشاء أسماء صندوق البريد في نطاقنا، فإن الخطوة التالية هنا هي وضع أدوات لقراءة هذه الصناديق والاستفادة من البيانات، خاصة تقارير البيانات المجمعة، التي تم تصميمها مرة أخرى ليتم تحليلها بواسطة الآلة، بدلاً من قراءتها بواسطة الإنسان. من ناحية أخرى، قد تكون التقارير الجنائية قابلة للإدارة ببساطة عن طريق قراءتها بأنفسنا، ولكن قدرتنا على القيام بذلك ستعتمد على فهم عميل بريدنا الإلكتروني لكيفية عرض الرسائل في تنسيق AFRF وعلى حجم التقارير التي نستقبلها.
بينما من الممكن أن نكتب أدواتنا الخاصة لمعالجة تقارير DMARC، حتى يتمكن Bird من توفير مثل هذه الخدمات لعملاء bird.com (شيء نأخذه في الاعتبار، ولكن لن نعد به الآن)، نوصي بأن نستفيد من الأدوات المتاحة بالفعل لهذه المهمة.
يجب أن يستعد أي نطاق ينشر سياسة DMARC لتلقي تقارير بخصوص نطاقه. سيتم إنشاء هذه التقارير بواسطة أي نطاق يقوم بالتحقق من صحة DMARC ويرى البريد الذي يدعي أنه من نطاقنا، وسيتم إرسالها إلينا على الأقل بشكل يومي. ستأتي التقارير بتنسيقين:
التقارير المجمعة، وهي وثائق XML تعرض بيانات إحصائية عن كمية البريد التي رأها المبلغ من كل مصدر، وما كانت نتائج المصادقة، وكيف تعامل المراسل مع الرسائل. تم تصميم التقارير المجمعة لكي يتم تحليلها بواسطة الآلة، مع تخزين بياناتها في مكان ما للسماح بتحليل حركة المرور بشكل عام، ومراجعة تدفقات رسائل نطاقنا، وربما تحديد الاتجاهات في مصادر البريد غير المصدق عليه، وربما الاحتيالي.
التقارير الجنائية، وهي نسخ فردية من الرسائل التي فشلت في المصادقة، كل واحدة مرفقة في رسالة بريد إلكتروني كاملة باستخدام تنسيق يسمى AFRF. يفترض أن تحتوي التقارير الجنائية على رؤوس وبنود الرسائل الكاملة، لكن العديد من المراسلين يزيلون أو يحجبون بعض المعلومات بسبب مخاوف الخصوصية. ومع ذلك، يمكن أن يكون التقرير الجنائي مفيدا جدا لكلا من استكشاف مشكلات المصادقة الخاصة بنطاقنا وتحديد، من خلال عناوين URI في بنيات الرسائل، المجالات والمواقع الخبيثة المستخدمة للاحتيال على عملاء مالك نطاقنا.
تشمل التحضيرات لتلقي هذه التقارير أولاً إنشاء صندوقي بريد في نطاقنا لمعالجة هذه التقارير، مثل agg_reports@ourdomain.com وafrf_reports@ourdomain.com. لاحظ أن أسماء صندوق البريد تلك عشوائية تمامًا، ولا توجد متطلبات لتسمية الجزء المحلي من صندوق البريد؛ نحن أحرار في اختيار أي أسماء نريدها، لكن نحتفظ بهذين الصندوقين منفصلين لتسهيل المعالجة.
بمجرد اختيار وإنشاء أسماء صندوق البريد في نطاقنا، فإن الخطوة التالية هنا هي وضع أدوات لقراءة هذه الصناديق والاستفادة من البيانات، خاصة تقارير البيانات المجمعة، التي تم تصميمها مرة أخرى ليتم تحليلها بواسطة الآلة، بدلاً من قراءتها بواسطة الإنسان. من ناحية أخرى، قد تكون التقارير الجنائية قابلة للإدارة ببساطة عن طريق قراءتها بأنفسنا، ولكن قدرتنا على القيام بذلك ستعتمد على فهم عميل بريدنا الإلكتروني لكيفية عرض الرسائل في تنسيق AFRF وعلى حجم التقارير التي نستقبلها.
بينما من الممكن أن نكتب أدواتنا الخاصة لمعالجة تقارير DMARC، حتى يتمكن Bird من توفير مثل هذه الخدمات لعملاء bird.com (شيء نأخذه في الاعتبار، ولكن لن نعد به الآن)، نوصي بأن نستفيد من الأدوات المتاحة بالفعل لهذه المهمة.
يجب أن يستعد أي نطاق ينشر سياسة DMARC لتلقي تقارير بخصوص نطاقه. سيتم إنشاء هذه التقارير بواسطة أي نطاق يقوم بالتحقق من صحة DMARC ويرى البريد الذي يدعي أنه من نطاقنا، وسيتم إرسالها إلينا على الأقل بشكل يومي. ستأتي التقارير بتنسيقين:
التقارير المجمعة، وهي وثائق XML تعرض بيانات إحصائية عن كمية البريد التي رأها المبلغ من كل مصدر، وما كانت نتائج المصادقة، وكيف تعامل المراسل مع الرسائل. تم تصميم التقارير المجمعة لكي يتم تحليلها بواسطة الآلة، مع تخزين بياناتها في مكان ما للسماح بتحليل حركة المرور بشكل عام، ومراجعة تدفقات رسائل نطاقنا، وربما تحديد الاتجاهات في مصادر البريد غير المصدق عليه، وربما الاحتيالي.
التقارير الجنائية، وهي نسخ فردية من الرسائل التي فشلت في المصادقة، كل واحدة مرفقة في رسالة بريد إلكتروني كاملة باستخدام تنسيق يسمى AFRF. يفترض أن تحتوي التقارير الجنائية على رؤوس وبنود الرسائل الكاملة، لكن العديد من المراسلين يزيلون أو يحجبون بعض المعلومات بسبب مخاوف الخصوصية. ومع ذلك، يمكن أن يكون التقرير الجنائي مفيدا جدا لكلا من استكشاف مشكلات المصادقة الخاصة بنطاقنا وتحديد، من خلال عناوين URI في بنيات الرسائل، المجالات والمواقع الخبيثة المستخدمة للاحتيال على عملاء مالك نطاقنا.
تشمل التحضيرات لتلقي هذه التقارير أولاً إنشاء صندوقي بريد في نطاقنا لمعالجة هذه التقارير، مثل agg_reports@ourdomain.com وafrf_reports@ourdomain.com. لاحظ أن أسماء صندوق البريد تلك عشوائية تمامًا، ولا توجد متطلبات لتسمية الجزء المحلي من صندوق البريد؛ نحن أحرار في اختيار أي أسماء نريدها، لكن نحتفظ بهذين الصندوقين منفصلين لتسهيل المعالجة.
بمجرد اختيار وإنشاء أسماء صندوق البريد في نطاقنا، فإن الخطوة التالية هنا هي وضع أدوات لقراءة هذه الصناديق والاستفادة من البيانات، خاصة تقارير البيانات المجمعة، التي تم تصميمها مرة أخرى ليتم تحليلها بواسطة الآلة، بدلاً من قراءتها بواسطة الإنسان. من ناحية أخرى، قد تكون التقارير الجنائية قابلة للإدارة ببساطة عن طريق قراءتها بأنفسنا، ولكن قدرتنا على القيام بذلك ستعتمد على فهم عميل بريدنا الإلكتروني لكيفية عرض الرسائل في تنسيق AFRF وعلى حجم التقارير التي نستقبلها.
بينما من الممكن أن نكتب أدواتنا الخاصة لمعالجة تقارير DMARC، حتى يتمكن Bird من توفير مثل هذه الخدمات لعملاء bird.com (شيء نأخذه في الاعتبار، ولكن لن نعد به الآن)، نوصي بأن نستفيد من الأدوات المتاحة بالفعل لهذه المهمة.
أي سياسة DMARC يجب استخدامها
تحدد مواصفات DMARC ثلاث خيارات لأصحاب النطاقات لاستخدامها لتحديد كيفية التعامل المفضل لديهم مع البريد الذي يفشل في تحقق صحة DMARC. الخيارات هي:
none، مما يعني معالجة البريد بنفس الطريقة التي سيتم التعامل بها دون تحقق صحة DMARC
quarantine، مما يعني قبول البريد ولكن وضعه في مكان آخر غير علبة الوارد للمستلم (عادةً مجلد البريد العشوائي)
reject، مما يعني رفض الرسالة بشكل قاطع
من المهم أن نضع في اعتبارنا أن صاحب النطاق يمكنه فقط طلب هذا النوع من المعاملة في سجله DMARC؛ الأمر متروك للمستلم للرسالة لتقرير ما إذا كان سيتم الالتزام بالسياسة المطلوبة. سيفعل البعض ذلك، بينما قد يكون البعض الآخر أكثر تساهلاً في تطبيق السياسة، مثل وضع البريد في مجلد البريد العشوائي فقط عندما تكون سياسة النطاق هي الرفض.
نوصي جميع عملائنا بأن يبدؤوا بسياسة none فقط من باب الحذر. بينما نحن واثقون من قدرتنا على توثيق بريدك بشكل صحيح من خلال توقيع DKIM، من الأفضل أن تأخذ بعض الوقت لفحص التقارير حول نطاقك قبل أن تصبح أكثر عدوانية في سياسة DMARC الخاصة بك.
تحدد مواصفات DMARC ثلاث خيارات لأصحاب النطاقات لاستخدامها لتحديد كيفية التعامل المفضل لديهم مع البريد الذي يفشل في تحقق صحة DMARC. الخيارات هي:
none، مما يعني معالجة البريد بنفس الطريقة التي سيتم التعامل بها دون تحقق صحة DMARC
quarantine، مما يعني قبول البريد ولكن وضعه في مكان آخر غير علبة الوارد للمستلم (عادةً مجلد البريد العشوائي)
reject، مما يعني رفض الرسالة بشكل قاطع
من المهم أن نضع في اعتبارنا أن صاحب النطاق يمكنه فقط طلب هذا النوع من المعاملة في سجله DMARC؛ الأمر متروك للمستلم للرسالة لتقرير ما إذا كان سيتم الالتزام بالسياسة المطلوبة. سيفعل البعض ذلك، بينما قد يكون البعض الآخر أكثر تساهلاً في تطبيق السياسة، مثل وضع البريد في مجلد البريد العشوائي فقط عندما تكون سياسة النطاق هي الرفض.
نوصي جميع عملائنا بأن يبدؤوا بسياسة none فقط من باب الحذر. بينما نحن واثقون من قدرتنا على توثيق بريدك بشكل صحيح من خلال توقيع DKIM، من الأفضل أن تأخذ بعض الوقت لفحص التقارير حول نطاقك قبل أن تصبح أكثر عدوانية في سياسة DMARC الخاصة بك.
تحدد مواصفات DMARC ثلاث خيارات لأصحاب النطاقات لاستخدامها لتحديد كيفية التعامل المفضل لديهم مع البريد الذي يفشل في تحقق صحة DMARC. الخيارات هي:
none، مما يعني معالجة البريد بنفس الطريقة التي سيتم التعامل بها دون تحقق صحة DMARC
quarantine، مما يعني قبول البريد ولكن وضعه في مكان آخر غير علبة الوارد للمستلم (عادةً مجلد البريد العشوائي)
reject، مما يعني رفض الرسالة بشكل قاطع
من المهم أن نضع في اعتبارنا أن صاحب النطاق يمكنه فقط طلب هذا النوع من المعاملة في سجله DMARC؛ الأمر متروك للمستلم للرسالة لتقرير ما إذا كان سيتم الالتزام بالسياسة المطلوبة. سيفعل البعض ذلك، بينما قد يكون البعض الآخر أكثر تساهلاً في تطبيق السياسة، مثل وضع البريد في مجلد البريد العشوائي فقط عندما تكون سياسة النطاق هي الرفض.
نوصي جميع عملائنا بأن يبدؤوا بسياسة none فقط من باب الحذر. بينما نحن واثقون من قدرتنا على توثيق بريدك بشكل صحيح من خلال توقيع DKIM، من الأفضل أن تأخذ بعض الوقت لفحص التقارير حول نطاقك قبل أن تصبح أكثر عدوانية في سياسة DMARC الخاصة بك.
