בדקו מה הדוח מכסה לפני קריאת האחוזים
רשמו מי הפיק את הדוח, לאיזה דומיין, באיזה חלון זמן ובאיזה מזהה. בדקו אם זו רשומה שכבר עובדה ואם הנתונים הגיעו מכל המקורות שציפיתם להם. Google מציגה את הדוחות כדרך להבין שולחים ותוצאות אימות; המידע משקף את היקף הדיווח שהתקבל, לא מדידה מלאה של כל הדואר בעולם.
RFC 9990 ממאי 2026 מגדיר את הדיווח המצטבר בנפרד ממנגנון DMARC. ספקים ומנתחים עשויים להציג פורמטים ושדות שונים לפי המימוש. מסמך שנשלח לתיבת הדוחות הוא קלט חיצוני, ולכן אין לפתוח קבצים או לאפשר ניתוח אוטומטי לא מבוקר רק בגלל שם הקובץ.
קראו שדות לפי השאלה שהם עונים עליה
הטבלה היא כלי קריאה מקורי שמסכם שאלות תפעוליות, ולא תחליף לסכמת XML של גרסה מסוימת. שמות השדות כאן הם מונחים נפוצים בדיווח. אם המנתח אינו מזהה שדה או מציג שגיאה, מסמנים פער במקום להתייחס לחוסר מידע כתוצאת הצלחה.
בשדות XML נפוצים, report_metadata מתאר את פרטי הדוח, source_ip את המקור, count את הכמות ו-header_from את דומיין From. יש להבחין בין policy_evaluated לבין auth_results לפי סכמת הדוח והמימוש.
| שדה או תחום | מה בודקים | מה לא מסיקים לבדו |
|---|---|---|
| פרטי הדוח | מקור, מזהה ותחילת וסוף חלון | שכל הדואר בתקופה מכוסה |
| מקור וכמות | מקור וכמות מדווחת | שזהות הספק מאומתת לפי IP בלבד |
| דומיין From | הדומיין שמולו נבחנת התאמה | שתוכן ההודעה לגיטימי |
| הערכת מדיניות | תוצאות DMARC והטיפול המדווח | שההודעה הגיעה ל-inbox |
| אימות גולמי | דומיינים ותוצאות SPF/DKIM | ש-pass גולמי מבטיח התאמה |
| מדיניות וחריגות | איזו תצורה נצפתה והסבר לטיפול | שכל מקבל פעל באותה דרך |
הפרידו בין אימות לבין התאמת דומיינים
DMARC יכול להצליח כאשר לפחות אחד משני המנגנונים, SPF או DKIM, מצליח וגם מספק התאמה לדומיין From לפי מצב ההתאמה. הצלחת SPF עבור דומיין של ספק אינה בהכרח התאמה לדומיין העסק. בדקו איזה דומיין נבחן, ולא רק כמה פעמים הופיעה המילה pass.
הדוגמה סינתטית: From הוא shop.example, SPF מצליח עבור ספק אחר, וחתימת DKIM מצליחה ומתאימה ל-shop.example. DMARC יכול להצליח דרך DKIM גם בלי התאמת SPF. זהו הסבר עקרוני, לא דוח שנמדד באתר של לקוח ולא הוראה להוסיף דומיין לרשומת DNS.
מקור לא מוכר דורש שיוך ולא הרשאה אוטומטית
השוו את המקור לרשימת מערכות: תיבת דואר, אתר, CRM, חשבוניות ודיוור. בקשו מבעל המערכת ראיה מתאימה, כגון הגדרות שולח או מזהה ניסיון מאושר. כתובת משותפת לספקים או שינוי תשתית יכולים להקשות על שיוך, ולכן זיהוי לפי שם מארח בלבד אינו מספיק.
אל תרחיבו SPF או תחריגו ספק רק כדי להוריד אחוז כישלון. כישלון יכול לנבוע ממערכת לגיטימית שמוגדרת לא נכון, מהעברה או משליחה לא מורשית. לכל מקור מגדירים אחראי, הסבר, פעולה ובדיקת המשך. אם אין ראיה, הוא נשאר בבירור.
דוגמה: כישלון גבוה הגיע ממערכת עסקית שנוספה
התרחיש להמחשה בלבד. אחרי חיבור מערכת חשבוניות מופיעות רשומות חדשות שנכשלות בהתאמה. הצוות מקשר אותן למערכת דרך בעלים ונתוני ניסיון, ובודק את תצורת השליחה. לא משנים את כל מדיניות הדומיין בגלל דוח אחד, ולא מניחים שכל כישלון הוא ניסיון תקיפה.
אחרי תיקון בודקים חלונות דיווח מתאימים ואת דפוס השליחה הרלוונטי. שינוי מדיניות בתוך תקופה ומטמוני DNS יכולים להקשות על השוואה פשוטה. גם ירידה בכישלונות אינה הוכחה שהונאות בשם תצוגה או מחשבון לגיטימי שנפגע נפתרו.
סיימו ברשימת מקורות ופעולות שניתן לבדוק
המסירה כוללת חלון, כיסוי, מקורות מוכרים, פערים וראיית בדיקה לאחר תיקון. אכיפה היא החלטה נפרדת שדורשת מוכנות; RFC 9989 הסיר את pct, ולכן הוראה ישנה להגדיל אחוזים אינה מנגנון בטיחות אחיד. בדקו תיעוד ומימוש לפני כל שינוי.
ב-CyberFixCrew אפשר לתאם מיפוי שולחים ובירור אימות דואר במסגרת השירותים הקיימים. דוח מצטבר אינו תוכן תיבה ואין צורך לשלוח תיבות לקוחות כדי להתחיל. אין הבטחת מסירה או חסינות מהתחזות; התוצר הוא תמונת דיווח עם מגבלות והמשך טיפול.
