DMARC. צעד אחר צעד.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) הוא תנאי מקדים בלתי ניתן לוויתור עבור BIMI. דומיין עם p=none לעולם לא יציג לוגו ב-Gmail או Apple Mail, ללא קשר למידת הדיוק בהגדרת קובץ ה-SVG. מדריך זה מכסה את המסלול המלא מהפריסה הראשונית ועד לאכיפה מלאה.

דרישות מקדימות

לפני יצירת רשומת DMARC, ודאו שהפריטים הבאים כבר במקומם:

1. רשומת SPF — רשומת TXT בדומיין הראשי שלכם המציינת אילו שרתי דואר מורשים לשלוח בשמכם. לדוגמה: v=spf1 include:_spf.google.com -all
2. רשומת DKIM — מפתח ציבורי המפורסם ב-DNS, בו שרתי הקבלה משתמשים לאימות חתימות הדואר שלכם. ספק הדואר שלכם מייצר זאת.
3. גישה ל-DNS — הרשאות כתיבה לאזור ה-DNS של הדומיין שלכם (Cloudflare, Route 53, GoDaddy, או לוח הבקרה של רשם הדומיינים שלכם).

DMARC דורש שלפחות אחד מבין SPF או DKIM יהיה מוגדר כראוי ומיושר עם דומיין ה-From: לפני שיתפקד.

שלב 1: יצירת רשומת ניטור (p=none)

התחילו עם מדיניות ניטור בלבד. זו מתעדת כשלי אימות מבלי להשפיע על מסירת הדואר.

_dmarc.yourdomain.com  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; pct=100"

מדריך תגיות:

פרסמו רשומה זו והמתינו 48–72 שעות להפצת DNS.

שלב 2: קריאת הדוחות המצטברים

דוחות מצטברים (RUA) מגיעים כקבצי XML מצורפים, בדרך כלל פעם ביום לכל מקור שליחה. הם מציגים:

• אילו כתובות IP שלחו דואר בטענה לייצג את הדומיין שלכם
• האם SPF ו-DKIM עברו או נכשלו
• כמה הודעות נשלחו מכל מקור

מה לחפש: כל שירות שליחה לגיטימי (ספק הדואר שלכם, CRM, מערכת תמיכה, פלטפורמת שיווק) שנכשל ביישור SPF או DKIM חייב להיות מתוקן לפני שתעברו לאכיפה. מעבר ל-p=reject עם כשלי יישור שלא טופלו יגרום לחסימת דואר לגיטימי.

מקורות נפוצים הדורשים הגדרת DKIM/SPF נפרדת: Mailchimp, Salesforce, HubSpot, Zendesk, SendGrid, Google Workspace, Microsoft 365.

שלב 3: מעבר ל-p=quarantine

לאחר שכל מקורות השליחה הלגיטימיים עוברים אימות, עדכנו את המדיניות להסגרת הודעות שנכשלו:

_dmarc.yourdomain.com  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=25"

התחילו עם pct=25 כדי להחיל את מדיניות ההסגר על 25% בלבד מההודעות הנכשלות. נטרו במשך שבוע עד שבועיים. אם לא מוסגר דואר לגיטימי, העלו ל-pct=100.

שלב 4: מעבר ל-p=reject

אכיפה מלאה. הודעות לא מאומתות נדחות לחלוטין ולעולם לא נמסרות.

_dmarc.yourdomain.com  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100"

זוהי דרישת המינימום עבור BIMI. Gmail ו-Apple Mail לא יעבדו את רשומת ה-BIMI שלכם אלא אם לדומיין שלכם יש p=quarantine או p=reject עם pct=100. מדיניות של p=none אינה נראית ל-BIMI — הלוגו לעולם לא יופיע, ללא קשר למידת הדיוק בשאר ההגדרות.

מדוע p=none חוסם BIMI

מפרט BIMI דורש מספקי תיבות הדואר לאמת שלדומיין השולח יש מדיניות DMARC נאכפת לפני הצגת הלוגו. הרציונל: לוגו הוא אות אמון. הצגת לוגו עבור דומיין שלא אכף בקרות נגד התחזות תאפשר לתוקפים להציג לוגואים מאומתים בהודעות פישינג. p=none לא מספק אכיפה, ולכן הספקים מסרבים לכבד את רשומת ה-BIMI.

יישור: הפרט שרוב המדריכים מדלגים עליו

DMARC עובר רק כאשר הדומיין המאומת מיושר עם דומיין כותרת ה-From:. קיימים שני מצבי יישור:

• מרופף (ברירת מחדל): הדומיין הארגוני חייב להתאים. mail.example.com מיושר עם example.com.
• מחמיר: הדומיין המדויק חייב להתאים. mail.example.com אינו מיושר עם example.com.

עבור BIMI, השתמשו ביישור מרופף (adkim=r; aspf=r) אלא אם יש לכם סיבה ספציפית למחמיר. יישור מחמיר גורם לכשלים עבור תת-דומיינים ושירותי שליחה של צדדים שלישיים.

מדריך רשומה מלא

_dmarc.yourdomain.com  IN  TXT  "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:[email protected]; pct=100"

השלבים הבאים

לאחר שהדומיין שלכם מגיע ל-p=reject:

1. צרו את ה-SVG עבור BIMI — השתמשו ב-makeBIMI™ ליצירת קובץ לוגו תואם W3C SVG Tiny P/S. חינם, ללא צורך בחשבון.
2. הריצו בדיקת DMARC — כלי בדיקת הדומיין של makeBIMI מאמת את מצב רשומות ה-DMARC, SPF ו-BIMI שלכם בזמן אמת.
3. השיגו תעודה — להצגת לוגו ב-Gmail, נדרש VMC או CMC. veriBIMI℠ מתווך את תהליך התעודה המלא, כולל ניהול אכיפת DMARC, הכנת SVG והגשה ל-CA.