הגדרה
DMARC (Domain-based Message Authentication, Reporting, and Conformance) הוא מנגנון אימות מייל בר-הרחבה המאפשר לבעל דומיין לפרסם מדיניות הניתנת לקריאה על ידי מכונה ב-DNS, להצהיר מה שרתי דואר מקבלים צריכים לעשות כאשר הודעה נכנסת נכשלת בבדיקות יישור SPF או DKIM, ולאפשר לשרתים אלה לשלוח דוחות מובנים בחזרה לבעל הדומיין. שלושת ערכי המדיניות של DMARC — none, quarantine ו-reject — מעניקים לבעלי דומיין שליטה מדורגת על איך מייל לא מאומת המתחזה כמגיע מהדומיין שלהם מטופל על ידי תשתית הקבלה הגלובלית.
DMARC פותח בשיתוף פעולה על ידי קבוצה של משתתפי תעשייה כולל PayPal, Google, Microsoft, Yahoo, ReturnPath ובעלי עניין אחרים באקוסיסטם של מייל, ופורסם לראשונה כ-IETF RFC 7489 במרץ 2015. המפרט מתוחזק על ידי קבוצת העבודה DMARC.org. הוא מרחיב ומתאם שני תקני אימות מוקדמים יותר: SPF (RFC 7208) ו-DKIM (RFC 6376), שבהם הוא משתמש כאותות קלט אך אינו מחליף.
כיצד זה פועל
מדיניות DMARC מתפרסמת כרשומת DNS TXT ב-_dmarc.<domain>. רשומה ייצוגית נראית כך: v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; adkim=s; aspf=s. התגים העיקריים הם:
v=DMARC1— מזהה גרסהp=— מדיניות:none(ניטור בלבד),quarantine(משלוח לספאם/אשפה) אוreject(השלכת ההודעה לחלוטין)rua=— URI יעד דוח מצרפי; מקבל סיכומי XML יומיים של תוצאות אימות מספקי תיבות דואר משתתפיםruf=— URI יעד דוח פורנזי; מקבל דוחות ברמת הודעה מצונזרים עבור כשלים בודדיםpct=— אחוז ההודעות שעליהן המדיניות חלה (מאפשר השקה מבוימת)adkim=ו-aspf=— מצב יישור:s(קפדני, דורש התאמת דומיין מדויקת) אוr(סבלני, מאפשר התאמת תת-דומיין)
החדשנות הקריטית ש-DMARC מציגה היא יישור מזהה. מעבר SPF או מעבר DKIM נחשב תואם DMARC רק אם הדומיין המאומת מיושר עם דומיין כותרת RFC5322.From — כתובת “From:” שמשתמשי מייל רואים. זה סוגר את הפער שנשאר על ידי SPF ו-DKIM הפועלים באופן עצמאי: הודעה יכולה לעבור SPF בדומיין אחר (שולח המעטפה) ולעבור DKIM עבור דומיין חתימה של צד שלישי, אך עדיין להיות הונאה אם כותרת ה-From מציגה דומיין שונה. DMARC דורש לפחות אחד מ-SPF או DKIM לייצר מעבר מיושר.
דוחות מצרפיים (RUA) מועברים כקבצי XML דחוסים, בדרך כלל תוך 24 שעות מסיום תקופת הדיווח, על ידי ספקי תיבות דואר כולל Google (Gmail), Microsoft (Outlook/Exchange Online Protection), Yahoo Mail, Apple iCloud Mail, Comcast ואחרים. דוחות אלה מכילים ספירות הודעה לכל IP מקור, תוצאות SPF, תוצאות DKIM וטיפול DMARC. כלים כגון DMARCIAN, Valimail, Postmark DMARC Digests ו-Google Postmaster Tools מספקים לוחות מחוונים המנתחים ומדמיינים דוחות אלה.
היכן תיתקלו ב-DMARC
DMARC נתקל בכל מקום שבו מתרחשת שליחת מייל בנפח גבוה או בסיכון גבוה. מאז פברואר 2024, Google ו-Yahoo דורשות שולחים של יותר מ-5,000 הודעות ביום לכתובות Gmail או Yahoo Mail שיהיה להם רשומת DMARC מפורסמת עם לפחות p=none — שינוי מדיניות תעשייה משמעותי שלמעשה הפך את DMARC לחובה עבור שולחי כמויות גדולות. Microsoft הודיעה על דרישות דומות עבור תיבות דואר צרכניות של Outlook.com ב-2025.
עבור פלטפורמות תחרות השולחות הצבעות אישור מייל בקנה מידה, DMARC משרת שני תפקידים. ראשית, הוא מגן על המוניטין של הדומיין השולח על ידי הוראה לשרתי הקבלה לדחות הודעות מזויפות — מונע מצד שלישי לזייף את כתובת ה-From של פלטפורמת התחרות בקמפיינים של פישינג, מה שייפגע בעמדת המסירה של הדומיין. שנית, דוחות DMARC מצרפיים מספקים ערוץ ניטור תפעולי: בעל הדומיין יכול לראות, על פני כל ספקי תיבות הדואר המשתתפים, איזה חלק מההודעות היוצאות עוברות SPF ו-DKIM, ולסמן תקלות תצורת תשתית לפני שהן מביאות לכשלי מייל אישור בכמות גדולה.
ספקי שירותי מייל כולל SendGrid, Mailgun, Amazon SES, Postmark ו-SparkPost מפרסמים הנחיות על תצורת DMARC לצד תשתית השליחה שלהם. כלי אבחון DNS כולל MXToolbox DMARC Lookup, DMARC Inspector של DMARCIAN ובודק הרשומות של EasyDMARC מאפשרים לבעלי דומיין לאמת מדיניות שפורסמה.
דוגמאות מעשיות
חברת תחרות מתחילה לשלוח מיילי אישור באמצעות תת-דומיין חדש confirm.votes.example.com. לדומיין האב votes.example.com יש p=reject ברשומת DMARC שלו. מכיוון שרשומות ה-SPF וה-DKIM עבור תת-הדומיין החדש עדיין לא מוגדרות, מיילי אישור נכשלים ביישור DMARC ונדחים על ידי Gmail. המנהל מאבחן את הבעיה דרך נתוני דוח מצרפי המראים כשל DMARC של 100% בתת-הדומיין, מוסיף את רשומות ה-DNS המתאימות של SPF include וסלקטור DKIM, ומאפס את מדיניות תת-הדומיין של DMARC של תת-הדומיין (sp=none) זמנית במהלך ההשקה.
מותג מפעיל תחרות הגשת תמונות עם פרסים בסך של 50,000 דולר. מתחזה מנסה לשלוח מיילי פישינג באמצעות דומיין התחרות של המותג ככתובת ה-From, ומפנה את המצביעים לדף אישור מזויף לקציר אישורי מייל. מכיוון שמדיניות ה-DMARC של הדומיין היא p=reject, Gmail, Outlook ו-Yahoo Mail כולן משליכות את ההודעות המזויפות לפני המסירה, ומגנות הן על משתתפי התחרות והן על המוניטין של השולח של המותג.
מושגים קשורים
DMARC תלוי הן ב-רשומת SPF והן ב-DKIM כקלטי האימות שלו — מעבר DMARC דורש לפחות אחד מאלה ליישור עם דומיין כותרת ה-From. עבור פעולות תחרות, ההשפעה המשולבת של SPF, DKIM ו-DMARC על מיקום תיבת הדואר הנכנס היא הגורם הטכני העיקרי הקובע אם הודעות אישור של הצבעת אישור מייל מגיעות לתיבות הדואר הנכנס של המצביעים. תקן BIMI, המאפשר תצוגת לוגו מותג בלקוחות תיבת דואר נכנס כמדד אמון, דורש מדיניות DMARC של p=quarantine או p=reject כתנאי מקדים.
