דוחות DMARC מראים תעבורה שנמענים משתתפים ראו בשם הדומיין שלכם, התאמת SPF ו-DKIM ואת הטיפול שדווח. הם עשויים לסייע בחקירת התחזות, שגיאות ספק ובהכנה לאכיפה. הם אינם מציגים אוטומטית את כל הדואר או את כל השולחים.
צוותים רבים מפרסמים DMARC, מפנים rua= לתיבה ולא מנתחים את הנתונים. XML מצטבר, שגיאות נשארות וסימני שימוש לרעה אינם מטופלים. להגדרת הבסיס, התחילו בדואר עסקי לעסקים קטנים וביצירת דואר בדומיין משלכם. לאחר מכן שלבו דוחות עם רשימת המערכות והיומנים שלכם לבניית מלאי מקורות שליחה.
אספו דוחות, זהו מקורות תקינים ותקנו התאמה. אל תתעלמו מכשלי SPF בהעברה רק כי DKIM עבר: בדקו שהחתימה נשארת תקינה ומותאמת. לאחר מכן העריכו החמרת מדיניות לפי נתונים ובדיקות.
מהם דוחות DMARC?
דוחות DMARC הם משוב מנמענים משתתפים אחרי הערכת הודעות שמשתמשות בדומיין שלכם ב-From. הם מציגים אימות, התאמה, כתובות מקור ופעולות מדיניות, ומסייעים בחקירת אבטחה ומסירת דואר. הכיסוי אינו מלא.
יש כמה סוגי דיווח.
דוחות מצטברים מבוקשים באמצעות rua ומגיעים לרוב כסיכומי XML. הם מקבצים תעבורה לפי נמען, כתובת מקור, תוצאת אימות וטיפול. כך אפשר לחקור Google Workspace, Microsoft 365, SendGrid, Mailchimp, שרת יישום או VPS לא מוכר. כתובת IP לבדה אינה מוכיחה מי שלח בפועל.
דוחות כשל מבוקשים באמצעות ruf ועשויים לספק פרטים ברמת ההודעה. תנאי יצירתם תלויים בהגדרות הדיווח ואינם בהכרח רק כשל DMARC כולל. התמיכה מוגבלת ושיקולי פרטיות גורמים לנמענים רבים לשלוח מעט או לא לשלוח כלל. התבססו על דוחות מצטברים והשתמשו בדוחות כשל כאות נוסף.
בפועל, הדוחות מסייעים לחקור שאלות כגון:
- אילו מקורות רואים נמענים מדווחים בשם הדומיין שלי?
- האם SPF או DKIM עוברים עם התאמה?
- האם נמענים מדווחים על quarantine או reject?
- אילו סיכונים צריך לבדוק לפני מעבר ל-
p=quarantineאו ל-p=reject?
כיצד דוחות DMARC פועלים?
רשומת DMARC מציינת היכן אתם מבקשים לקבל משוב. פרסמו TXT תחת _dmarc.yourdomain.com, בחרו מדיניות והוסיפו כתובות דיווח. נמענים משתתפים יכולים לשלוח נתונים. יעד דיווח בדומיין חיצוני עשוי לדרוש הרשאה נוספת ב-DNS.
דוגמה לרשומת ניטור:
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100"הדוגמה מבקשת ניטור ללא אכיפת DMARC ודוחות מצטברים ל-dmarc@example.com. האפשרויות adkim=s ו-aspf=s דורשות התאמת דומיין מלאה. הן אופציונליות ואינן הבחירה הטובה ביותר לכל סביבה. בהתאמה גמישה, ברירת המחדל, עשוי להספיק אותו דומיין ארגוני. בדקו את ההשלכות על השולחים שלכם.
התגים החשובים:
v=DMARC1: תג גרסה נדרש.p=: הטיפול המבוקש בכשל DMARC.rua=: יעד לדוחות מצטברים.ruf=: יעד לדוחות כשל.pct=: שיעור הודעות DMARC שנכשלות שעליו מבוקשת אכיפה; התמיכה משתנה.adkimו-aspf: מצב התאמה ל-DKIM ול-SPF.
פורמט הדיווח והמדיניות מוגדרים ב-RFC 7489. לכן דוחות גולמיים מגיעים לרוב כקובצי XML מצורפים ודחוסים שצריך לנתח.
מה מופיע בדוחות מצטברים?
דוחות מצטברים מסכמים תעבורה מדווחת לפי ארגון, כתובת מקור, מספר הודעות, SPF, DKIM וטיפול. הבדילו בין תוצאות אימות גולמיות לבין הערכת מדיניות DMARC הכוללת התאמה. אימות שעובר אינו בהכרח אימות מותאם.
בדרך כלל תמצאו:
- הנמען המדווח, למשל Google או Microsoft.
- טווח התאריכים.
- כתובת ה-IP שמסרה דואר לנמען הזה.
- מספר ההודעות שנצפו מאותו מקור.
- תוצאת אימות SPF הגולמית.
- תוצאת אימות DKIM הגולמית.
- הערכת SPF הכוללת התאמה ל-From.
- הערכת DKIM הכוללת התאמה ל-From.
- הטיפול המדווח לפי DMARC: none, quarantine או reject.
לא כל כשל SPF מעיד על בעיה בשולח המקורי. העברה משנה לעיתים את כתובת השליחה. אם DKIM נשאר תקין ומותאם, DMARC יכול לעבור.
נמען: gmail.com
כתובת מקור: 198.51.100.24
מספר הודעות: 842
דומיין From: example.com
SPF: fail
DKIM: pass
DMARC: pass
טיפול: none
זה עשוי להתאים להעברה ששימרה DKIM מותאם. בדקו את המקור ואת החתימה; אימות שעובר אינו מוכיח שהתוכן בטוח או שהשולח מאושר לצורכי העסק.
נמען: outlook.com
כתובת מקור: 203.0.113.77
מספר הודעות: 314
דומיין From: example.com
SPF: fail
DKIM: fail
DMARC: fail
טיפול: quarantine
המצב דורש חקירה. ייתכן שמדובר בשולח מוגדר לא נכון, בספק חדש שלא השלים אימות, בשימוש לרעה או בשינוי בדרך. הדוח לבדו אינו מוכיח התחזות.
דוחות מצטברים מול דוחות כשל
דוחות מצטברים מספקים תמונה של התעבורה שנמענים משתתפים מדווחים. דוחות כשל עשויים להציג אירועים בודדים. מצטברים הם בסיס שימושי לדומיינים רבים, אך אינם מבטיחים מלאי שלם או שינוי מדיניות בטוח.
| סוג דוח | מבוקש באמצעות | המידע שמתקבל | שימוש | המציאות ב-2025-2026 |
|---|---|---|---|---|
| מצטבר | rua=mailto:... | לרוב סיכומי XML יומיים לפי מקור, אימות וטיפול | מלאי מקורות, תיקון התאמה והכנת מדיניות | מקור נתונים חשוב עם כיסוי חלקי |
| כשל / פורנזי | ruf=mailto:... | פרטי הודעה, לעיתים חלקיים או מושחרים | חקירת כשל או שימוש לרעה מסוים | תמיכה מוגבלת; נמענים גדולים עשויים לשלוח מעט או לא לשלוח |
לוח דוחות שימושי כשספקו מסביר את ההבדלים והנתונים מסייעים בשינוי הגדרות בפועל. תצוגה לבדה אינה מתקנת התנהגות שליחה.
קריאת דוחות DMARC ביעילות
התחילו במקורות בעלי נפח גבוה, קשרו אותם למערכות עסקיות ותקנו כשלים לגיטימיים. לאחר מכן בדקו גם מקורות נדירים אך חיוניים. נפח אינו מדד העדיפות היחיד.
תהליך עבודה אפשרי:
- התחילו במקורות בעלי מספר ההודעות הגבוה ביותר בדוחות המצטברים.
- קשרו כל מקור ל-Google Workspace, Microsoft 365, שיווק, יישום, תמיכה או מערכת לא מזוהה.
- בדקו אם SPF או DKIM עוברים עם התאמה לדומיין From המוצג.
- תקנו כשלים של שולחים תקינים לפני שינוי מדיניות.
- סמנו מקורות לא מוכרים לחקירה. גם ממסר משותף או שרת העברה יכולים להסביר תעבורה תקינה.
אל תתמקדו רק בכשלים קטנים כשהשולחים העיקריים מוגדרים לא נכון. תעדפו לפי נפח וחשיבות עסקית יחד.
| התוצאה המדווחת | סיבה אפשרית | פעולה |
|---|---|---|
| SPF pass, DKIM pass, DMARC pass | האימות וההתאמה נראים תקינים | תעדו את המקור ובדקו לגיטימיות בנפרד |
| SPF fail, DKIM pass, DMARC pass | העברה או בעיית נתיב SPF | בדקו את הנתיב ואת שימור DKIM תקין ומותאם |
| SPF pass, DKIM fail, DMARC pass | בעיה ב-DKIM בעוד SPF מותאם עובר | חקרו DKIM, במיוחד עבור נתיבי העברה |
| SPF fail, DKIM fail, DMARC fail | שימוש לרעה, הגדרה שגויה או שינוי בדרך | חקרו את המקור ואת עיבוד ההודעה |
| כתובת לא מוכרת עם תעבורה ממשית | ספק לא רשום, ממסר משותף, העברה או שימוש לרעה | זהו תחילה; אל תחסמו על סמך הדוח בלבד |
תיקונים נפוצים כוללים:
- הוספת include מתאים ב-SPF לשולח תקין מאומת, במסגרת מגבלות SPF.
- הפעלת חתימת DKIM לדומיין אצל הספק.
- הגדרת return-path מותאם להשגת התאמת SPF.
- העברת שליחת ספק לתת-דומיין אם זה מתאים למדיניות שלכם.
- תיקון העברה במקום הסתמכות על SPF בלבד.
בדיקת שורת פקודה מסייעת לבחון תשובות DNS זמינות, אך אינה בהכרח זהה לכל המטמונים שהנמענים השתמשו בהם:
dig TXT _dmarc.example.com +short
dig TXT example.com +short
dig TXT selector1._domainkey.example.com +shortלהגדרות DNS, היעזרו בתיעוד TrekMail על רשומות DNS נדרשות ועל דואר שמגיע לספאם.
בעיות שהדוחות עשויים לחשוף
דוחות DMARC מסייעים למצוא אימות ספק חסר, שגיאות התאמה, בעיות העברה ומדיניות שאינה נבדקת. השלימו אותם עם רשימת השליחה והיומנים הפנימיים.
כלי חדש עשוי לשלוח בשם הדומיין לפני השלמת SPF או DKIM. כתובת לא מוכרת בדוח היא רמז לחקירה, לא הוכחה שזהו המקרה.
SPF יכול לעבור לדומיין המעטפת בעוד DMARC נכשל אם הוא אינו מותאם ל-From ואין גם DKIM מותאם שעובר. הדבר עשוי לקרות במערכות שיווק או קריאות שירות ללא דומיין החזרות מתאים.
הסתמכות על SPF בלבד רגישה להעברה. אם אין DKIM תקין ומותאם, DMARC עלול להיכשל בדרך. קראו על הגדרת העברת דואר ותיקון תקלות ובדקו העברה בנפרד משליחה ישירה.
בעיה נוספת היא פרסום p=none ואיסוף דוחות בלי לנתח אותם. כך מפספסים הזדמנות לחקור שגיאות וסימני שימוש לרעה.
גם מעבר מהיר מדי ל-p=reject מסוכן. זהו מקורות לגיטימיים ובדקו תעבורה חשובה ונדירה לפני החמרה. דוחות לבדם אינם מוכיחים שהמעבר בטוח.
התפקיד של TrekMail
דוחות מועילים כשאפשר לפעול לפי ממצאיהם. TrekMail יכול לרכז ניהול דומיינים, בדיקות DNS ושליחה כדי לצמצם עבודה ידנית. עדיין צריך להעריך מקורות חיצוניים.
בניהול מפוצל, דומיינים נמצאים אצל מארחים שונים, SMTP בשירותים נפרדים ודוחות בתיבה משותפת. מקור שליחה חדש יכול לחמוק מהרשימה.
בתהליך מרוכז משתמשים בלוח TrekMail ובהוראות DNS ואימות הזמינות ובוחרים SMTP משלכם או מנוהל. תיבות, העברה והעברת דואר יכולים להיות מנוהלים באותה סביבה. לכמה סביבות לקוח, קראו על אירוח דואר למספר דומיינים.
TrekMail מספק בהתאם למסלול דומיינים מותאמים, תיבות IMAP, קליטה כוללת, העברה, העברת IMAP ו-API. Nano משתמש ב-SMTP משלכם לפי תיעוד SMTP מותאם. מסלולים בתשלום יכולים להשתמש ב-SMTP מנוהל. מחיר Starter המוזכר כאן מתחיל ב-$3.50 לחודש; Nano מתואר כחינמי ללא כרטיס. ייתכן שמוצעת תקופת ניסיון של 14 יום לתכונות בתשלום עם דרישת כרטיס אשראי. בדקו מחירים ותנאים עדכניים.
דוחות אינם מתקנים דבר בעצמם. הם מצביעים על כיווני חקירה, וסביבת ניהול מרוכזת יכולה להקל על ביצוע תיקונים.
מעבר מ-p=none ל-quarantine או reject
דוחות עשויים לסייע להעריך אם שולחים תקינים עוברים אימות עם התאמה. שלבו מלאי מקורות, בדיקות של תעבורה נדירה ותוכנית התאוששות לפני אכיפה. אל תניחו שכל הכשלים שנותרו זדוניים או לא חשובים.
הרשומות הבאות הן חלופות עוקבות למסלול אפשרי. פרסמו רק רשומת מדיניות אחת בכל שלב:
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=25"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100"אחוז אינו מבטיח חלוקת תעבורה מדויקת: הוא נוגע לדואר שנכשל ב-DMARC ונמענים אינם מיישמים אותו באופן אחיד. בחנו מחזורי דיווח רלוונטיים, בדקו מקורות חיוניים ונדירים וודאו ש-DKIM נשאר תקין ומותאם בהעברה. הנמען עשוי לחרוג מהמדיניות המבוקשת.
Google דורשת משולחי Gmail כלליים SPF או DKIM. לשולחים בתפוצה רחבה נדרשים שניהם עם DMARC והתאמה רלוונטית. ראו תנאים בשאלות נפוצות על הנחיות לשולחי Gmail.
סיכום: השתמשו בדוחות כחלק מהתפעול
דוחות DMARC מספקים מידע שימושי אך חלקי על מקורות, אימות וטיפול. נתחו אותם בקביעות עם רשימת השליחה והיומנים כדי לחקור כשלים ולא רק לשמור אותם.
כשיש הרבה דומיינים וספקים, פישוט הניהול יכול לעזור. TrekMail מציע לפי המסלול אירוח למספר דומיינים, אחסון משותף, העברת IMAP, SMTP משלכם או מנוהל ובדיקות אימות. בדקו יכולות ותמחור עדכניים במחירי TrekMail. כלים אלה תומכים בחקירה אך אינם מבטיחים אכיפה בטוחה או הגעה לתיבת הדואר הנכנס.