מסירת דואר ו-DNS

דוחות DMARC: ניתוח מקורות, התאמה ומדיניות

מאת Alexey Bulygin
ניתוח דוחות DMARC לפי כתובת מקור ותוצאות אימות

דוחות DMARC מראים תעבורה שנמענים משתתפים ראו בשם הדומיין שלכם, התאמת SPF ו-DKIM ואת הטיפול שדווח. הם עשויים לסייע בחקירת התחזות, שגיאות ספק ובהכנה לאכיפה. הם אינם מציגים אוטומטית את כל הדואר או את כל השולחים.

צוותים רבים מפרסמים DMARC, מפנים rua= לתיבה ולא מנתחים את הנתונים. XML מצטבר, שגיאות נשארות וסימני שימוש לרעה אינם מטופלים. להגדרת הבסיס, התחילו בדואר עסקי לעסקים קטנים וביצירת דואר בדומיין משלכם. לאחר מכן שלבו דוחות עם רשימת המערכות והיומנים שלכם לבניית מלאי מקורות שליחה.

אספו דוחות, זהו מקורות תקינים ותקנו התאמה. אל תתעלמו מכשלי SPF בהעברה רק כי DKIM עבר: בדקו שהחתימה נשארת תקינה ומותאמת. לאחר מכן העריכו החמרת מדיניות לפי נתונים ובדיקות.

מהם דוחות DMARC?

דוחות DMARC הם משוב מנמענים משתתפים אחרי הערכת הודעות שמשתמשות בדומיין שלכם ב-From. הם מציגים אימות, התאמה, כתובות מקור ופעולות מדיניות, ומסייעים בחקירת אבטחה ומסירת דואר. הכיסוי אינו מלא.

יש כמה סוגי דיווח.

דוחות מצטברים מבוקשים באמצעות rua ומגיעים לרוב כסיכומי XML. הם מקבצים תעבורה לפי נמען, כתובת מקור, תוצאת אימות וטיפול. כך אפשר לחקור Google Workspace, Microsoft 365, SendGrid, Mailchimp, שרת יישום או VPS לא מוכר. כתובת IP לבדה אינה מוכיחה מי שלח בפועל.

דוחות כשל מבוקשים באמצעות ruf ועשויים לספק פרטים ברמת ההודעה. תנאי יצירתם תלויים בהגדרות הדיווח ואינם בהכרח רק כשל DMARC כולל. התמיכה מוגבלת ושיקולי פרטיות גורמים לנמענים רבים לשלוח מעט או לא לשלוח כלל. התבססו על דוחות מצטברים והשתמשו בדוחות כשל כאות נוסף.

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

  1. אילו מקורות רואים נמענים מדווחים בשם הדומיין שלי?
  2. האם SPF או DKIM עוברים עם התאמה?
  3. האם נמענים מדווחים על quarantine או reject?
  4. אילו סיכונים צריך לבדוק לפני מעבר ל-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 ביעילות

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

תהליך עבודה אפשרי:

  1. התחילו במקורות בעלי מספר ההודעות הגבוה ביותר בדוחות המצטברים.
  2. קשרו כל מקור ל-Google Workspace, Microsoft 365, שיווק, יישום, תמיכה או מערכת לא מזוהה.
  3. בדקו אם SPF או DKIM עוברים עם התאמה לדומיין From המוצג.
  4. תקנו כשלים של שולחים תקינים לפני שינוי מדיניות.
  5. סמנו מקורות לא מוכרים לחקירה. גם ממסר משותף או שרת העברה יכולים להסביר תעבורה תקינה.

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

התוצאה המדווחתסיבה אפשריתפעולה
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. כלים אלה תומכים בחקירה אך אינם מבטיחים אכיפה בטוחה או הגעה לתיבת הדואר הנכנס.

שתפו מאמר זה

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

התחברות ל-TrekMail

גישה ללוח הבקרה, לתיבות הדואר ול-DNS שלכם.

או

12 תווים הסיסמאות תואמות

או

דוא״ל האיפוס נשלח

אם קיים חשבון לכתובת הזו, שלחנו אליה הוראות לאיפוס הסיסמה.

בהמשך אתם מסכימים ל תנאי השימוש ול מדיניות הפרטיות של TrekMail.