מנתח DMARC: קריאת דוחות ותיקון כשלים אמיתיים

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

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

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

מהו מנתח DMARC?

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

DMARC מוגדר ב-RFC 7489. הוא מאפשר לבעל הדומיין לפרסם מדיניות ולקבל דוחות על הודעות שמשתמשות בדומיין בכתובת From הגלויה. נמענים גדולים כגון Google, Microsoft ו-Yahoo שולחים דוחות כאלה בדרך כלל מדי יום, אך התדירות והכיסוי עשויים להשתנות.

מנתח DMARC הופך את קובצי ה-XML המצורפים למידע תפעולי:

1. אילו כתובות IP שלחו דואר בשם הדומיין.
2. האם SPF עבר.
3. האם DKIM עבר.
4. האם לפחות אחד מהם מיושר עם דומיין From.
5. איזו disposition החיל הנמען.

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

מה מנתח DMARC צריך להראות תחילה?

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

רוב הכשלים נכללים בארבע קבוצות.

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

קריאת מנתח DMARC בלי לרדוף אחר סימנים מטעים

קראו מנתח DMARC לפי הסדר הבא: מדיניות הדומיין, נפח ההודעות, כתובת ה-IP של המקור, תוצאת SPF, תוצאת DKIM, יישור ולבסוף disposition. התחלה בסמלים האדומים עלולה להוביל לתיקון הדבר הלא נכון.

זהו תהליך מעשי.

1. בדיקת רשומת DMARC שפורסמה

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

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100"

אם הדומיין כבר משתמש ב-p=quarantine או ב-p=reject, המנתח גם עוזר לזהות מוקדם מסלולים שעלולים להיפגע מהאכיפה.

2. מיון לפי נפח תחילה

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

3. תיוג כל שולח מוכר

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

במהלך הקמה אפשר להשתמש במדריכי TrekMail על רשומות DNS נדרשות ועל בדיקת מצב DNS כבסיס לפני פירוש אותות DMARC.

4. בדיקת יישור, לא רק pass/fail

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

פרט זה מסביר תוצאות רבות שנראות סותרות.

דוגמה: דואר מ-billing.example.com נשלח דרך ספק שה-SPF שלו עובר ב-bounce.vendor.net. SPF עובר מבחינה טכנית, אך אינו מיושר עם example.com. אם DKIM חסר או חותם בדומיין הלא נכון, DMARC נכשל.

כשלים נפוצים שמנתח DMARC חושף

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

שולח לגיטימי חסר ב-SPF

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

dig txt example.com +short

# bad: two separate SPF records
"v=spf1 include:_spf.google.com ~all"
"v=spf1 include:spf.trekmail.net ~all"

# good: one merged SPF record
"v=spf1 include:_spf.google.com include:spf.trekmail.net ~all"

בשימוש בשליחה מנוהלת של TrekMail יש לבדוק בתיעוד את רכיב ה-SPF הנדרש. בחבילת Nano או לצורך שליטה ישירה, ייתכן גם שימוש ב-BYO SMTP. התיקון תלוי בפלטפורמה ששולחת בפועל ובמסלול ההחזרה שהופעל. לפני שינוי DNS ראו SMTP מנוהל של TrekMail ו-SMTP מותאם / BYO.

DKIM לא תקין

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

בהעברה SPF עשוי להיכשל מפני שכתובת ה-IP המתחברת משתנה. חתימת DKIM תקפה ומיושרת יכולה לתרום למעבר DMARC רק אם החתימה והנתונים החתומים לאחר canonicalization נשמרים תקינים. ARC עשוי לספק לנמען הקשר מקומי על היסטוריית האימות, אך אינו הופך כשל למעבר אוטומטית. ראו RFC 8617.

רעש העברה שנחשב בטעות לכשל

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

אם משתמשים בהעברה, מומלץ לקרוא את מדריכי TrekMail על העברת דוא"ל ועל העברת דוא"ל מהדומיין ל-Gmail. תיקון בשכבה הלא נכונה עלול לפגוע במסירה לגיטימית.

עומס חיפושי SPF

אם שרשרת SPF עוברת את המגבלה של 10 שאילתות DNS, עלול להיווצר PermError ותעבורה לגיטימית עלולה להיכשל אף שהספק מורשה על הנייר. מנתחים שונים מציגים זאת באופנים שונים.

אין להוסיף רכיבי include בעיוורון. הסירו רק שירותים שאומתו כלא בשימוש. השתמשו ברשומות ip4 קבועות רק לכתובות נתמכות, יציבות ומתוחזקות. לפי הצורך פצלו שולחים גדולים לתת-דומיינים ובדקו את envelope-from בפועל, את ההפעלה ואת היישור.

מה כלים טובים לניתוח DMARC עושים טוב יותר?

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

כלים רבים מציעים פענוח XML, תרשימי pass/fail, התראות, ציוני תאימות וגילוי שולחים. יש להשוות לפי תיעוד עדכני ולפי המסלולים בפועל, ולא לראות טענות שיווקיות כבדיקה עצמאית.

אלה השאלות החשובות למפעילים:

1. האם הסיווג מספק ראיות להבחנה בין העברה להתחזות?
2. האם אפשר לתעדף לפי נפח וגם לפי חשיבות עסקית?
3. האם ניתן למפות כשלים למערך השליחה בפועל?
4. האם הכלי מציג התנפחות SPF ושינויי יישור?

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

השיטה הישנה לעומת השיטה החדשה

בגישה מפוצלת שירות אחד מפענח XML, ואילו DNS, דומיינים, מארחי דואר וספקי שליחה מנוהלים במקומות אחרים. סביבת דואר משולבת ומבוססת תקנים יכולה לקרב את מצב DNS, בחירת SMTP, העברה והגירה.

לפי ההצעה הנוכחית, חבילת Nano של TrekMail מתחילה ב-$0 עבור 10 דומיינים ו-5 ג׳יגה-בייט, וחבילות בתשלום מתחילות ב-$3.50 לחודש. לשליחה מנוהלת עשוי להיות ניסיון חינם של 14 ימים לחבילות בתשלום, המחייב כרטיס אשראי. אם אין צורך בכך, ניתן להשתמש ב-Nano עם BYO SMTP לפי התנאים הנוכחיים. יש לבדוק מחירים, תכונות ומגבלות עדכניים משום שהם עשויים להשתנות.

אם הבעיה המרכזית היא פיזור בין דומיינים, ראו אירוח דוא"ל למספר דומיינים. ניהול דומיינים מפוצל הוא מקור נפוץ לבלבול DMARC.

תיקון הממצאים של מנתח DMARC

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

1. אם זה ספק אמיתי, יש לאשר ולהגדיר אותו ולבדוק יישור בהודעות שנשלחו בפועל.
2. אם זה גורם מעביר, אין לשנות SPF בעיוורון ויש לוודא שחתימת DKIM תקפה ומיושרת שורדת.
3. אם המקור אינו מוכר, יש לחקור ולשמור על המדיניות או להתקדם בהדרגה לאכיפה כשהראיות תומכות בכך.
4. אם SPF ו-DKIM נכשלים בדואר שלכם, יש להשהות את המסלול אם אפשר עד לתיקון.

לבדיקות חיות אפשר להשתמש במסוף:

dig txt _dmarc.example.com +short
dig txt example.com +short

# inspect a DKIM selector
 dig txt selector1._domainkey.example.com +short

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

מתי לעבור מ-p=none אל p=quarantine או p=reject?

מנתח DMARC מאפשר לבנות אכיפה בזהירות. אין לעבור ל-p=reject רק משום שהוא נשמע נוקשה יותר, אלא כאשר שולחים חוקיים ידועים, מיושרים ונבדקו לאורך תקופות מייצגות.

פרסום מוקדם מדי של p=reject עלול לחסום דואר שלכם. אפשר להתקדם כך:

1. להתחיל ב-p=none ולאסוף דוחות.
2. לתקן שולחים מורשים ולבדוק גם מסלולים נדירים וקריטיים.
3. לעבור בהדרגה ל-p=quarantine.
4. לעקוב אחר מנתח DMARC במשך כמה תקופות מייצגות ולהכין תכנית חזרה.
5. לאחר מכן לעבור ל-p=reject אם יומנים, בדיקות ומסלולים עסקיים תומכים בכך.

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

סיכום: שימוש במנתח DMARC לקבלת החלטות, לא לבהלה

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

TrekMail יכולה לספק דומיינים מותאמים, תיבות IMAP, ניתוב catch-all, העברת תיבות, הגירת IMAP מובנית ו-SMTP מנוהל או BYO SMTP בסביבה אחת, בהתאם לתכונות ולתצורה העדכניות. הגירת IMAP מעתיקה דואר ואינה מעבירה אוטומטית רשומות MX או יישומים.

אפשר להתחיל ב-trekmail.net או להשוות אפשרויות נוכחיות ב-trekmail.net/pricing. אם משתמשים היום ב-מנתח DMARC, כדאי לפעול כמפעיל: לסווג, לאמת, לתקן ורק אז לאכוף באופן מבוקר.