הסבר על דרישת BIMI לגבי DMARC p=reject
הסבר על דרישת BIMI לגבי DMARC p=reject
רוב הטמעות BIMI הכושלות נובעות מסיבה אחת: מדיניות DMARC שגויה. ארגונים מתמקדים ביצירת קובץ הלוגו בפורמט SVG ומתעלמים מדרישת האימות שקובעת האם הלוגו יוצג בכלל.
BIMI הוא פרוטוקול אבטחה, לא תכונת מיתוג. ספקיות תיבות הדואר מציגות את הלוגו שלכם רק לאחר שהן מאמתות באופן קריפטוגרפי שההודעה מקורה בדומיין שלכם [1].
מאמר זה מתאר את דרישת הקדם של DMARC עבור BIMI, משווה בין שלוש מדיניויות האכיפה, ומפרט כיצד להכין את הדומיין שלכם.
מהו DMARC?
Domain-based Message Authentication, Reporting, and Conformance (DMARC) הוא תקן אימות דוא"ל שמונע משולחים בלתי מורשים להשתמש בדומיין שלכם בכותרת From.
DMARC בנוי על גבי שני פרוטוקולים בסיסיים:
- SPF (Sender Policy Framework): מאמת שכתובת ה-IP השולחת מורשית על ידי בעל הדומיין.
- DKIM (DomainKeys Identified Mail): מחיל חתימה קריפטוגרפית על כל הודעה כך שהמקבל יכול לאשר שההודעה לא שונתה במהלך המשלוח.
רשומת 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 או מגישים בקשה ל-Verified Mark Certificate (VMC).
השתמשו ב-makeBIMI כדי לבדוק את הדומיין שלכם. הכלי שולח שאילתות לרשומות ה-DNS שלכם, מעריך את תצורת ה-SPF וה-DMARC שלכם, ומדווח האם הדומיין שלכם עומד בדרישת האכיפה עבור BIMI.
לאחר שהדומיין שלכם עובר את הבדיקה, צרו את קובץ ה-SVG התקני שלכם ופנו לתיווך CA כגון 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/