מה בדיוק נבדק
כדי שהודעה תעבור DMARC, לפחות מסלול אחד צריך להצליח: SPF תקין עם דומיין מעטפת שתואם ל-From, או DKIM תקין עם דומיין חתימה שתואם ל-From. אופן ההתאמה תלוי בהגדרה; התאמה רגועה יכולה לקבל דומיינים מאותו דומיין ארגוני, והתאמה מחמירה דורשת זהות מדויקת.
SPF שעבר עבור דומיין של ספק דיוור אינו בהכרח מספיק לדומיין העסק המוצג לנמען. לכן בודקים את דומיין האימות ולא רק את המילה pass.
דוגמה של התאמת דומיינים
נניח שהודעה מציגה From בדומיין example.com ונחתמת ב-DKIM תקין עם d=example.com. מסלול DKIM התואם עשוי לאפשר מעבר DMARC גם אם SPF נכשל. זו דוגמה מושגית, לא תוצאת בדיקה של דומיין לקוח.
אם רק DKIM של example.net עובר ו-SPF אינו תואם, החתימה אינה מוכיחה שההודעה מורשית להציג example.com. שינוי שם התצוגה אינו משנה את בדיקת הדומיין.
מדיניות אינה אותו דבר כמו תוצאת אימות
הדומיין מפרסם בקשה לטיפול בהודעות שנכשלות. ספק הקבלה מפעיל גם מדיניות מקומית, ולכן אין הבטחת מסירה או חסימה מוחלטת.
| ערך | משמעות | שיקול לפני הפעלה |
|---|---|---|
| none | אין בקשת אכיפה על סמך כשל DMARC | מתאים לאיסוף תמונה ולבירור שולחים; אינו מבקש חסימה |
| quarantine | בקשה לטפל בהודעה כחשודה | יש לבדוק השפעה על דואר עסקי תקין |
| reject | בקשה לדחות הודעה שנכשלת | יש להסדיר מקורות לגיטימיים לפני אכיפה |
מה DMARC אינו עושה
הוא אינו מצפין את ההודעה, מאמת את האדם שכתב אותה או מונע שימוש בדומיין דומה. הודעה שנשלחה מחשבון שנפרץ יכולה לעבור את בדיקות הדומיין. גם העברת הודעות ושירותי רשימות תפוצה עשויים לסבך את האבחון.
דוחות יכולים לסייע לאתר מקורות שליחה ותקלות, אך דורשים פירוש והחלטה. אין להניח שכל מקור לא מוכר הוא תוקף או שכל מקור מוכר מוגדר נכון.
איך מתחילים בעסק
ממפים מערכות שולחות, מאמתים SPF ו-DKIM ובודקים הודעות מכל מקור. לאחר מכן בוחנים דוחות ומחליטים על מדיניות. בדיקת DNS ראשונית יכולה לזהות רשומה פומבית, אך אינה מחליפה בדיקת הודעה בפועל.
תקן DMARC מעודכן ומימושים בפועל
RFC 9989 ממאי 2026 החליף את RFC 7489 והסיר את תג האחוזים pct. תיעוד ותמיכה של ספקים עשויים להתעדכן בקצב שונה. לפני שינוי אכיפה בודקים את המערכת ואת מקורות השליחה, ולא מסתמכים על אחוזים כמנגנון בטיחות אחיד.