תארו לעצמכם שלקוח שלכם מקבל מייל מכתובת שנראית בדיוק כמו של העסק שלכם – אותו דומיין, אותה חתימה, אותו לוגו – ובו בקשה "דחופה" להעביר תשלום לחשבון בנק חדש. הוא משלם, ורק אחרי כמה ימים מתברר שאף אחד אצלכם לא שלח את ההודעה. התרחיש הזה, שנקרא בעגה המקצועית BEC (Business Email Compromise), הוא אחת מהונאות הסייבר היקרות בעולם: לפי הדוח השנתי של ה-IC3 ב-FBI לשנת 2024, התקבלו 21,442 תלונות על הונאות BEC עם הפסדים מדווחים של כ-2.77 מיליארד דולר.

החדשות הטובות: יש שלוש רשומות DNS פשוטות יחסית – SPF, DKIM ו-DMARC – שמקשות מאוד על מתחזים לשלוח מיילים בשם הדומיין שלכם. והן כבר לא "נחמד שיהיה": Gmail ו-Outlook.com הפכו אותן לדרישה של ממש. במדריך הזה נסביר מה כל אחת עושה, למה זה חשוב לעסק קטן או בינוני בישראל, ואיך להטמיע אותן צעד אחר צעד בלי לשבור את המיילים הלגיטימיים שלכם.

למה זה רלוונטי דווקא עכשיו?

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

  • Google (Gmail) – מאז 1 בפברואר 2024, כל מי ששולח לתיבות Gmail אישיות חייב לעבור לפחות SPF או DKIM. מי ששולח יותר מ-5,000 הודעות ביום חייב גם SPF וגם DKIM, רשומת DMARC (מותר להתחיל ב-p=none) ו"יישור" (Alignment) בין הדומיין בשדה From לבין הדומיין שעבר אימות. Google גם דורשת לשמור על שיעור דיווחי ספאם נמוך מ-0.3%.
  • Microsoft (Outlook.com) – החל מ-5 במאי 2025, דומיינים ששולחים יותר מ-5,000 הודעות ביום לתיבות הצרכנים של Outlook.com חייבים לעבור SPF ו-DKIM ולהחזיק רשומת DMARC של לפחות p=none. הודעות שלא עומדות בכך נדחות עם שגיאה 550; 5.7.515 Access denied.

גם אם העסק שלכם שולח הרבה פחות מ-5,000 מיילים ביום, השורה התחתונה זהה: דומיין בלי אימות תקין נראה חשוד יותר בעיני מסנני הספאם, ומשאיר דלת פתוחה למתחזים. בישראל ראינו לא מעט קמפיינים כאלה – למשל, במאי 2025 מערך הסייבר הלאומי הזהיר מפני מיילים שהתחזו למשרד המשפטים, לפרקליטות ולמשטרה כדי לגרום לנמענים להוריד קובץ זדוני.

מעטפת דואר רשום עם חותמות – המחשה לאימות זהות השולח
צילום: Eesti Post · Public domain · Wikimedia Commons

SPF, DKIM ו-DMARC – בשפה פשוטה

נסו לחשוב על זה כמו על דואר רשום: צריך לדעת מי מורשה לשלוח, לוודא שהחותמת אמיתית, ולהחליט מה עושים עם מכתב מזויף.

  • SPF (Sender Policy Framework) – רשומת TXT ב-DNS שמפרטת אילו שרתים וכתובות IP מורשים לשלוח דואר בשם הדומיין שלכם. שרת מקבל בודק אם ההודעה הגיעה ממקור שמופיע ברשימה.
  • DKIM (DomainKeys Identified Mail) – חתימה קריפטוגרפית שמתווספת לכל הודעה יוצאת. המפתח הציבורי מפורסם ב-DNS, וכך הצד המקבל יכול לוודא שההודעה באמת יצאה מהדומיין שלכם ולא שונתה בדרך. יתרון חשוב: DKIM יכול לשרוד העברה (Forwarding), מה שלא תמיד נכון לגבי SPF.
  • DMARC – ה"מנצח על התזמורת". הרשומה אומרת לשרת המקבל מה לעשות עם הודעה שנכשלה בבדיקות (לא לעשות כלום, להעביר לספאם, או לדחות), ובנוסף גורמת לשרתים לשלוח לכם דוחות על כל מי ששולח מיילים בשם הדומיין שלכם – כולל מתחזים.

שלב 1: מיפוי – מי שולח מיילים בשם הדומיין שלכם?

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

  • שירות הדואר הארגוני (Microsoft 365, Google Workspace או שרת אחר).
  • מערכת דיוור / ניוזלטר.
  • מערכת CRM, מערכת הנהלת חשבונות או חשבוניות דיגיטליות.
  • האתר עצמו (טפסי יצירת קשר, חנות WooCommerce, התראות).
  • מערכות תמיכה, זימון תורים, מדפסות וסורקים ששולחים מייל.

שלב 2: הגדרת SPF נכונה

  1. היכנסו לניהול ה-DNS של הדומיין (אצל רשם הדומיין, Cloudflare וכדומה) ובדקו אם כבר קיימת רשומת TXT שמתחילה ב-v=spf1.
  2. לדומיין יכולה להיות רק רשומת SPF אחת. שתי רשומות גורמות לשגיאה (permerror) ולכישלון האימות. אם יש כמה – אחדו אותן לרשומה אחת.
  3. הוסיפו את כל השולחים מהשלב הקודם. לדוגמה, לפי התיעוד של Microsoft, ארגון ששולח רק דרך Microsoft 365 ישתמש ב: v=spf1 include:spf.protection.outlook.com -all. ספקים אחרים מפרסמים את ה-include המדויק שלהם בתיעוד.
  4. שימו לב למגבלת 10 בדיקות DNS: כל include, a, mx ו-redirect נספרים, כולל includes מקוננים. חריגה גורמת לכישלון SPF. כתובות ip4/ip6 לא נספרות.
  5. בסיום הרשומה: -all (Hard fail) הוא ההמלצה של Microsoft כשאתם בטוחים שהרשימה מלאה. ~all (Soft fail) מתאים לתקופת מעבר.

שלב 3: הפעלת DKIM

  1. בממשק הניהול של ספק הדואר (Microsoft 365 / Google Workspace) הפעילו חתימת DKIM לדומיין המותאם שלכם, והוסיפו ל-DNS את הרשומות שהספק מציג.
  2. Gmail דורשת מפתח DKIM של 1024 ביט לפחות.
  3. הפעילו DKIM גם במערכת הדיוור, ב-CRM ובכל שירות צד שלישי – כך שהחתימה תהיה עם הדומיין שלכם, ולא עם הדומיין של הספק. זה התנאי ל"יישור" שבלעדיו DMARC ייכשל.

שלב 4: DMARC בהדרגה – מניטור לאכיפה

הטעות הנפוצה ביותר היא לקפוץ ישר ל-p=reject ולגלות שחצי מהחשבוניות לא מגיעות ללקוחות. גם Google וגם Microsoft ממליצות על פריסה הדרגתית:

  1. המתינו לפחות 48 שעות אחרי הגדרת SPF ו-DKIM (ההמלצה של Google) לפני הוספת DMARC.
  2. התחילו במצב ניטור: צרו רשומת TXT בשם _dmarc עם ערך כמו v=DMARC1; p=none; rua=mailto:[email protected]. כתובת ה-rua מקבלת דוחות מצרפיים – Google ממליצה תמיד לכלול אותה, ועדיף לתיבה ייעודית ולא לתיבה אישית.
  3. קראו את הדוחות במשך כמה שבועות. הם מגיעים כקובצי XML, ולכן כדאי להיעזר בכלי ניתוח DMARC. חפשו שולחים לגיטימיים שנכשלים (ותקנו אותם) ושולחים לא מוכרים (אלה המתחזים).
  4. עברו ל-p=quarantine, אפשר בהדרגה עם התגית pct. Microsoft מציעה מדרגות של 10, 25, 50, 75 ו-100 אחוז.
  5. לבסוף p=reject – רק כשהדוחות נקיים. Microsoft ממליצה להתחיל מתת-דומיינים בנפח נמוך ולהשאיר את הדומיין הראשי לסוף.

אל תשכחו את הדומיינים "השקטים"

לעסקים רבים יש דומיינים נוספים – גרסת ‎.com לצד ‎.co.il, שמות מותג ישנים, דומיינים שנרכשו "ליתר ביטחון". דומיין שלא שולח דואר הוא מטרה נוחה למתחזים. Microsoft ממליצה להגדיר עבורם:

  • SPF שאומר שאף אחד לא מורשה לשלוח: v=spf1 -all
  • DMARC באכיפה מלאה: v=DMARC1; p=reject;

רשומת DMARC של דומיין מכסה אוטומטית גם את תת-הדומיינים שלו שאין להם רשומה משלהם.

טעויות נפוצות שכדאי להכיר

  • שתי רשומות SPF נפרדות לאותו דומיין (למשל אחרי מעבר ספק).
  • שירות דיוור ששולח בשם הדומיין שלכם אבל חותם DKIM עם הדומיין שלו – ולכן אין יישור.
  • טופס יצירת קשר באתר וורדפרס ששולח מייל ישירות מהשרת, במקום דרך SMTP מאומת.
  • רשומת DMARC שנשארת על p=none לנצח: היא נותנת נראות, אבל לא חוסמת אף מתחזה.
  • שכחה לעדכן את SPF כשמוסיפים מערכת חדשה ששולחת מיילים.

איך בודקים שהכול עובד?

  • שלחו מייל לתיבת Gmail, פתחו את "הצגת המקור" (Show original) וודאו ש-SPF, DKIM ו-DMARC מסומנים PASS.
  • השתמשו בכלי בדיקה מקוון לרשומות DNS. מרכז הסייבר הבריטי (NCSC), למשל, מציע כלי חינמי לבדיקת אבטחת הדואר של דומיין.
  • המשיכו לעקוב אחרי דוחות DMARC גם אחרי המעבר ל-reject – כל ספק חדש שמצטרף צריך להיכנס לרשומות.
  • בשלב מתקדם יותר, שקלו גם הצפנת הדואר בתעבורה עם TLS ו-MTA-STS, כפי שממליץ ה-NCSC.

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

שורה תחתונה

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

מקורות