כאשר הודעות מהדומיין הארגוני מגיעות לספאם, נדחות או מתחזות בקלות יחסית, שלושת השמות הראשונים שצריך לבדוק הם SPF, DKIM ו־DMARC. הם עובדים יחד, אבל כל אחד פותר חלק אחר בבעיה. הגדרה חלקית או קשיחה מדי עלולה לפגוע במשלוח תקין, ולכן כדאי לעבוד לפי סדר ולבדוק כל מקור של דואר יוצא.
מה עושה כל מנגנון?
SPF הוא רשומת TXT ב־DNS שמפרטת אילו שרתים ושירותים מורשים לשלוח דואר עבור הדומיין. השרת המקבל משווה את מקור ההודעה למדיניות שפורסמה.
DKIM מוסיף חתימה קריפטוגרפית להודעה. המפתח הציבורי מתפרסם ב־DNS, והשרת המקבל משתמש בו כדי לוודא שהחתימה תקפה ושהתוכן לא שונה בדרך. ה־selector של DKIM משתנה בין ספקים, ולכן אין שם רשומה אחיד לכל ארגון.
DMARC בודק שהדומיין המופיע בשדה From הגלוי מיושר עם הדומיין שאומת באמצעות SPF או DKIM. הוא גם מאפשר לפרסם מדיניות לטיפול בכשלונות ולקבל דוחות מצטברים. לפי RFC 9989, DMARC נשען על מנגנוני האימות הבסיסיים ומומלץ להשתמש גם ב־SPF וגם ב־DKIM.
שלב ראשון: למפות את כל מקורות השליחה
לפני שמשנים DNS, יש להכין רשימה מלאה של כל מערכת ששולחת בשם הדומיין: Microsoft 365 או Google Workspace, מערכת דיוור, CRM, מערכת חשבוניות, טופס באתר, אפליקציה, מדפסת, שירות תמיכה וספקי צד שלישי. מקור לגיטימי שנשכח מהמיפוי עלול להיכשל אחרי הקשחת המדיניות.
בארגון עם כמה מחלקות, כדאי לבדוק גם תתי־דומיין. לדוגמה, דואר שיווקי יכול לצאת מ־marketing.example.com במקום מהדומיין הראשי. Microsoft ממליצה לשקול הפרדה כזו לשירותים שאינם בשליטה מלאה של הארגון, כדי שתקלה בהם לא תפגע במוניטין הדואר הראשי.
שלב שני: לבדוק את רשומות ה־DNS
אפשר לבדוק רשומות באמצעות כלי DNS ארגוני, כלי של ספק הדומיין או פקודות בסיסיות:
nslookup -type=TXT example.com
nslookup -type=TXT _dmarc.example.com
nslookup -type=TXT selector._domainkey.example.comהחליפו את example.com בדומיין שלכם ואת selector בשם שהוגדר אצל ספק הדואר. אל תנחשו selector: מצאו אותו במסוף הניהול או בתיעוד הספק.
ב־SPF יש לשים לב במיוחד לשתי טעויות נפוצות: יותר מרשומת SPF אחת באותו דומיין, או רשומה שלא כוללת שירות צד שלישי ששולח בפועל. Microsoft מציינת שצריך להיות SPF יחיד לדומיין, ולכן יש למזג מקורות לרשומה אחת תקינה במקום לפרסם כמה רשומות נפרדות.
שלב שלישי: לאמת הודעה אמיתית
שלחו הודעת בדיקה מכל אחד ממקורות השליחה אל תיבה חיצונית ובדקו את הכותרות המלאות. חפשו שדה Authentication-Results ותוצאות כמו SPF=pass, DKIM=pass ו־DMARC=pass. תוצאה אחת מוצלחת אינה מבטיחה שכל המערכות מכוסות; יש לבדוק מערכת־מערכת.
DMARC עובר כאשר לפחות אחד משני המנגנונים — SPF או DKIM — עובר וגם מיושר עם דומיין From. לכן הודעה יכולה להציג SPF=pass ועדיין להיכשל ב־DMARC אם הדומיינים אינם מיושרים.
שלב רביעי: להפעיל DMARC בהדרגה
Microsoft ממליצה להתחיל במדיניות ניטור p=none, לאסוף דוחות ולזהות מקורות לגיטימיים שלא הוגדרו. לאחר תיקון הפערים עוברים ל־p=quarantine, ורק לאחר בדיקה מסודרת ל־p=reject. מעבר חד ל־reject בלי מיפוי מוקדם עלול לגרום לדחיית דואר תקין.
דוגמת ניטור בסיסית:
v=DMARC1; p=none; rua=mailto:[email protected]כתובת הדוחות צריכה להיות תיבה שהארגון מסוגל לקלוט ולנתח. דוחות DMARC הם בדרך כלל קבצי XML מצטברים; הם אינם תחליף לניטור תפעולי, אבל מסייעים לזהות שולחים לא מוכרים וכשלים באימות.
צ'קליסט קצר לפני הקשחה
- מיפוי מלא של ספקי הדואר והשירותים השולחים בשם הדומיין.
- רשומת SPF יחידה ועדכנית, ללא מקורות שכבר אינם בשימוש.
- חתימת DKIM פעילה לכל פלטפורמת שליחה משמעותית.
- בדיקת alignment בין From לבין SPF או DKIM.
- DMARC במצב ניטור ודוחות שמגיעים לתיבה פעילה.
- מעבר מדורג ל־quarantine ואז reject, לאחר בדיקה.
- בדיקה נפרדת של דומיינים חונים ותתי־דומיין.
אימות דואר אינו מבטיח שכל הודעת פישינג תיחסם, והוא גם אינו מחליף סינון, הדרכת משתמשים ובקרות תשלום. אם הארגון מקבל חשבוניות במייל, מומלץ לשלב גם את שבע הבדיקות לפני העברת תשלום.
צילום: Sven Brandsma / Unsplash, ברישיון Unsplash. דף המקור | תנאי הרישיון.
