شرح متطلبات BIMI لسياسة DMARC p=reject

تعود معظم حالات فشل نشر BIMI إلى سبب واحد: سياسة DMARC غير صحيحة. تركز المؤسسات على إنشاء ملف الشعار بصيغة SVG وتتجاهل متطلبات المصادقة التي تحدد ما إذا كان الشعار سيُعرض أصلاً.

BIMI هو بروتوكول أمان، وليس ميزة للعلامة التجارية. لا يعرض مزودو صناديق البريد شعارك إلا بعد التحقق التشفيري من أن الرسالة صادرة من نطاقك [1].

تصف هذه المقالة المتطلبات المسبقة لـ DMARC من أجل BIMI، وتقارن بين سياسات التطبيق الثلاث، وتوضح كيفية إعداد نطاقك.

ما هو DMARC؟

DMARC (مصادقة الرسائل المستندة إلى النطاق والإبلاغ والمطابقة) هو معيار لمصادقة البريد الإلكتروني يمنع المرسلين غير المصرح لهم من استخدام نطاقك في ترويسة From.

يعتمد DMARC على بروتوكولين أساسيين:

1. SPF (إطار سياسة المرسل): يتحقق من أن عنوان IP المرسل مصرح به من قبل مالك النطاق.
2. DKIM (البريد المعرَّف بمفاتيح النطاق): يطبق توقيعاً تشفيرياً على كل رسالة حتى يتمكن المستلم من التأكد من عدم تعديل الرسالة أثناء النقل.

يوجه سجل DMARC الخوادم المستقبلة، مثل Gmail وYahoo، حول كيفية التعامل مع الرسائل التي تفشل في اجتياز كل من SPF وDKIM.

سياسات DMARC الثلاث

تنشر سجل DMARC الخاص بك كسجل TXT في منطقة DNS الخاصة بك. تحدد علامة p= سياسة التطبيق.

1. p=none (وضع المراقبة)

يسلم الخادم المستقبل الرسائل الفاشلة إلى صندوق الوارد ويرسل تقارير مجمعة إلى العنوان الذي تحدده. استخدم هذه السياسة لتحديد مصادر الإرسال المشروعة قبل الانتقال إلى التطبيق. حالة BIMI: ❌ مرفوض. لا يعرض مزودو صناديق البريد شعارات BIMI للنطاقات التي تستخدم p=none.

2. p=quarantine (وضع التطبيق)

يوجه الخادم المستقبل الرسائل الفاشلة إلى مجلد البريد العشوائي أو غير المرغوب فيه. حالة BIMI: ✅ مقبول. هذه هي الحد الأدنى من السياسة المؤهلة لـ BIMI. يجب أن تنطبق السياسة على 100% من الرسائل. إما أن تضمّن pct=100 أو تحذف علامة pct (القيمة الافتراضية هي 100).

3. p=reject (وضع التطبيق الصارم)

يسقط الخادم المستقبل الرسائل الفاشلة. لا يتم تسليمها. حالة BIMI: ✅ مقبول. هذه هي السياسة الموصى بها لـ BIMI.

لماذا يتطلب BIMI التطبيق

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

لو قبل BIMI سياسة p=none، لتمكن المهاجم من انتحال نطاقك والتسبب في عرض مزود صندوق البريد لشعارك بجانب رسالة تصيد احتيالي. يضمن اشتراط p=quarantine أو p=reject أن مالك النطاق قد حظر البريد غير المصادق عليه قبل منح الشعار.

اعتبارات النطاقات الفرعية

كثيراً ما تستخدم المؤسسات نطاقات فرعية لتدفقات بريد مختلفة، مثل marketing.company.com أو receipts.company.com. يتطلب BIMI أن يكون النطاق التنظيمي في وضع التطبيق.

إذا نشر نطاقك التنظيمي p=reject لكنه تجاوز النطاقات الفرعية باستخدام sp=none، فسيفشل BIMI للبريد المرسل من تلك النطاقات الفرعية. يجب أن ينطبق التطبيق على كل من النطاق التنظيمي ونطاقاته الفرعية.

كيفية تدقيق البنية التحتية الخاصة بك

تأكد من حالة DMARC الخاصة بك قبل إنشاء ملف SVG أو التقدم للحصول على شهادة العلامة الموثقة (VMC).

استخدم makeBIMI لتدقيق نطاقك. تستعلم الأداة عن سجلات DNS الخاصة بك، وتقيّم تكوين SPF وDMARC، وتُبلغ عما إذا كان نطاقك يستوفي متطلبات التطبيق لـ BIMI.

بعد اجتياز نطاقك للتدقيق، أنشئ ملف SVG المتوافق وتواصل مع وسيط جهة إصدار الشهادات مثل veriBIMI للحصول على شهادتك.

المراجع

[1] M. Blank, et al. "Brand Indicators for Message Identification (BIMI)." IETF Datatracker, RFC 9091, https://datatracker.ietf.org/doc/html/rfc9091 [2] DMARC.org. "Overview." DMARC, https://dmarc.org/overview/