DMARC, SPF ו-DKIM בשפה פשוטה: איך מגינים על המייל של העסק

למה בכלל צריך את זה

פרוטוקול המייל נבנה בימים שבהם אף אחד לא חשב על הונאות. כברירת מחדל, כל שרת יכול לשלוח הודעה שכתוב בה "מאת: info@yourcompany.co.il". שלוש רשומות DNS פותרות את זה: SPF, DKIM ו-DMARC. הן מגדירות מי מורשה לשלוח בשם הדומיין, ומה לעשות עם מי שלא.

SPF: רשימת השולחים המורשים

SPF היא רשומת TXT בדומיין שמפרטת אילו שרתים או שירותים מורשים לשלוח מייל בשמו, למשל Google Workspace, Microsoft 365, מערכת שיווק ומערכת חשבוניות. השרת המקבל בודק אם השולח נמצא ברשימה.

כמה דברים כדאי לדעת:

• הרשומה מסתיימת לרוב ב-~all (כישלון רך) או ב--all (כישלון קשיח). השני מחמיר יותר.
• יש מגבלה של 10 חיפושי DNS ברשומה. מי שמוסיף הרבה שירותים עלול לחרוג ממנה, ואז SPF נכשל.
• SPF בודק את כתובת ה"מעטפה" של ההודעה, ולא בהכרח את הכתובת שהמשתמש רואה.

DKIM: חתימה דיגיטלית

DKIM מוסיף להודעה חתימה קריפטוגרפית. השרת השולח חותם, והמקבל בודק את החתימה מול מפתח ציבורי שמפורסם ב-DNS תחת שם בצורה selector._domainkey.yourdomain.com. החתימה מאפשרת לבדוק שההודעה לא שונתה בדרך ושהיא נחתמה על ידי מי שמחזיק במפתח.

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

DMARC: מה עושים כשהבדיקות נכשלות

DMARC היא רשומת TXT בכתובת _dmarc.yourdomain.com. היא עושה שני דברים: קובעת מדיניות ומגדירה דוחות.

הדברים הבאים נכונים ל-p שבמדיניות:

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

שימו לב שהמדיניות היא בקשה מהמקבל, וההחלטה בסוף שלו. כדי ש-DMARC יעבור, אחת מבדיקות SPF או DKIM צריכה לעבור ולהתיישר (alignment) עם הדומיין שרואה המשתמש בשדה "מאת".

הרשומה מכילה גם כתובת לדוחות (rua), שאליה נשלחים דוחות מצטברים: מי שלח הודעות בשם הדומיין וכמה מהן עברו. הדוחות הם מה שמאפשר להתקדם בבטחה.

באיזה סדר מטמיעים

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

דילוג מהיר ל-reject בלי שלב הדוחות עלול לגרום לכך שמיילים אמיתיים, כמו חשבוניות או הצעות מחיר, יידחו.

מה הן לא עושות

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

• לא מונעות פריצה לתיבה. מי שגנב סיסמה שולח מהתיבה האמיתית וההודעה תעבור.
• לא עוצרות דומיין דומה. מי שרושם דומיין דומה, כמו cornpany.com במקום company.com, יכול להגדיר לו DMARC משלו, וההודעות ממנו יעברו.
• לא משנות שם תצוגה מזויף.
• לא מחליפות הדרכה ואימות דו-שלבי. ראו איך בודקים אם אפשר להתחזות אליכם.

מה הסריקה החינמית שלנו בודקת

הסריקה המהירה ב-PhishingU קוראת את מדיניות ה-DMARC (none, quarantine או reject), בודקת שקיימת רשומת SPF, ומנסה למצוא DKIM תחת מספר שמות נפוצים. היא אינה בודקת את חוזק רשומת SPF או את דוחות ה-DMARC, ו"לא נמצא DKIM" אינו מוכיח שאין. את הדוח המלא מכינה הצוות שלנו ונשלח לכתובת בדומיין שנסרק, והדוח הראשון ללא עלות.

לעמוד נוסף על הנושא: בדיקת רשומת SPF, DMARC ו-DKIM.

איך נראית רשומת DMARC, ומה כל חלק בה

דוגמה לרשומה בסיסית, שנכתבת כרשומת TXT בכתובת _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

• v=DMARC1 מצהיר על גרסת הפרוטוקול.
• p=none היא המדיניות. כדי להגן בפועל, עוברים בהמשך ל-quarantine או ל-reject.
• rua היא הכתובת שאליה נשלחים דוחות מצטברים.

אפשר להוסיף אפשרויות כמו pct (אחוז ההודעות שהמדיניות חלה עליהן) ומדיניות נפרדת לתת-דומיינים. מי שמתחיל, מספיק לו להתחיל מהבסיס ולהתקדם בהדרגה.

טעויות נפוצות

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

מי צריך להתעסק בזה

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

טבלת מדיניות DMARC במבט אחד

כך נראית ההבדלה בין שלוש המדיניות, מהמעקב אל האכיפה:

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

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

אם אין לכם עדיין DMARC, התחילו ב-p=none עם כתובת דוחות, המתינו כמה שבועות כדי לקבל תמונה מלאה של מי שולח בשם הדומיין, תקנו SPF ו-DKIM לפי הדוחות, ורק אז עברו ל-quarantine. הקפידו שהכתובת שמקבלת את הדוחות היא תיבה שמישהו בודק, ולא תיבה שנשכחה. אחרי המעבר ל-reject כדאי להמשיך לקרוא דוחות מדי פעם, כי מערכת חדשה שמצטרפת לארגון (חשבוניות, שיווק, CRM) עלולה לשלוח בשם הדומיין בלי שהוגדרה.

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