האימייל שלכם בידיים זרות? מדריך חובה להגדרת SPF, DKIM ו-DMARC

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

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

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

מהם SPF, DKIM ו-DMARC, ואיך הם עובדים יחד?

כדי להבין את הפתרון, צריך להבין את הבעיה. פרוטוקול הדוא"ל הבסיסי (SMTP) לא כולל מנגנון אימות מובנה. זה מאפשר לכל אחד, טכנית, לשלוח מייל שנראה כאילו הגיע מהדומיין שלכם (למשל, [email protected]). כאן נכנסים לתמונה שלושת מנגנוני האימות:

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

SPF: פירוט טכני של הרשומה

רשומת SPF היא רשומת TXT ב-DNS של הדומיין, והיא בעלת מבנה מוגדר. הנה פירוט של רשומת לדוגמה: v=spf1 ip4:192.168.0.1 include:_spf.google.com ~all

• v=spf1: תג זה תמיד פותח את הרשומה ומציין שזו רשומת SPF בגרסה 1.
• ip4:192.168.0.1: מנגנון זה מאשר כתובת IPv4 ספציפית כשולח לגיטימי. קיים גם מנגנון ip6 לכתובות IPv6, וכן מנגנון mx המאשר את שרתי הדואר הנכנס של הדומיין כשולחים מורשים.
• include:_spf.google.com: זהו המנגנון הנפוץ ביותר. הוא מורה לשרת המקבל לבדוק את רשומת ה-SPF של דומיין אחר (במקרה זה, גוגל) ולהתייחס לכל השרתים המוגדרים שם כאילו היו חלק מהרשומה שלכם. כך מוסיפים שירותים כמו Google Workspace, מערכות דיוור ו-CRM. שימו לב: ניתן להוסיף עד 10 מנגנוני include או מנגנונים דומים הדורשים בדיקת DNS ברשומה אחת.
• ~all (SoftFail): תג זה קובע מה לעשות עם מיילים המגיעים ממקורות שאינם ברשימה. ~all מנחה את השרת המקבל לסמן את ההודעה כחשודה (לרוב כספאם) אך לא לדחות אותה לחלוטין. זוהי ההמלצה של גוגל.
• -all (Fail): חלופה מחמירה יותר, המורה לשרת המקבל לדחות באופן מיידי כל הודעה משולח לא מורשה.

כלל חשוב: לכל דומיין יכולה להיות רשומת SPF אחת בלבד. קיום של מספר רשומות TXT המתחילות ב-v=spf1 יגרום לכשל באימות ויבטל את ההגנה.

DKIM: פירוט טכני של החתימה הדיגיטלית

DKIM מוסיף חתימה דיגיטלית מוצפנת לכל אימייל יוצא. התהליך מבוסס על זוג מפתחות א-סימטריים:

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

רשומת ה-DNS של DKIM מקבלת שם (Host/Name) ייחודי המורכב מ"בורר" (selector) ומהדומיין עצמו. לדוגמה: google._domainkey.your-business.co.il. ה"בורר" מאפשר להשתמש במספר מפתחות DKIM שונים עבור שירותים שונים באותו דומיין. ערך הרשומה ייראה בדרך כלל כך:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

הערך מכיל את גרסת הפרוטוקול (v=DKIM1) ואת המפתח הציבורי עצמו (p=...), שהוא מחרוזת ארוכה של תווים. בסביבת Google Workspace, למשל, ניתן ליצור מפתח באורך 2048 ביט, הנחשב למאובטח ביותר.

DMARC: פירוט טכני של המדיניות והדיווח

DMARC קושר יחד את SPF ו-DKIM ומגדיר מדיניות אחידה. הרשומה מוגדרת ב-DNS תחת השם _dmarc.your-business.co.il ומורכבת מתגים (tags) המגדירים את פעולתה:

• v=DMARC1: תג חובה המציין את גרסת הפרוטוקול.
• p=none/quarantine/reject: תג המדיניות (Policy), והוא החשוב ביותר. p=none הוא מצב ניטור בלבד. p=quarantine מנחה להעביר מיילים כושלים לספאם. p=reject מנחה לדחות אותם לחלוטין.
• rua=mailto:[email protected]: מגדיר לאן יישלחו דוחות מצטברים (Aggregate Reports). דוחות אלה מספקים סיכום סטטיסטי של תעבורת המייל מהדומיין שלכם והם חיוניים לשלב הניטור.
• pct=100: תג האחוז (Percentage) קובע על איזה אחוז מהמיילים שנכשלים תופעל המדיניות. הערך נע בין 0 ל-100 (ברירת המחדל). ניתן להשתמש בו כדי להחיל מדיניות מחמירה (כמו reject) בהדרגה, למשל להתחיל עם pct=10 ולהעלות לאט.
• sp=reject: תג מדיניות תת-הדומיינים (Subdomain Policy). הוא קובע איזו מדיניות להחיל על מיילים הנשלחים מתת-דומיינים (למשל, news.your-business.co.il), אם אין להם רשומת DMARC משלהם.

דוגמה לרשומת DMARC בסיסית במצב ניטור: v=DMARC1; p=none; rua=mailto:[email protected].

למה כל עסק חייב להגדיר DMARC באופן מיידי?

התעלמות מאימות דוא"ל היא לא רק רשלנות טכנית, אלא סיכון עסקי ממשי עם תג מחיר כבד. הונאות התחזות עסקית במייל (BEC) הפכו למכרה זהב עבור פושעי סייבר. לפי נתוני ה-FBI, ההפסדים המדווחים מהונאות אלו בארה"ב לבדה הגיעו לסך של 3.05 מיליארד דולר במהלך שנת 2025. באותה שנה, הנזקים הפיננסיים המדווחים מהונאות פישינג זינקו ב-274%, מ-18.7 מיליון דולר ב-2023 ל-70 מיליון דולר ב-2024, מה שמדגיש את התחכום הגובר של התקפות אלו.

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

הדרישות החדשות של גוגל ויאהו: מה זה אומר עבור העסק שלך?

אם אתם שולחים דיוורים או מיילים בכמות גדולה, אתם כבר לא יכולים להתעלם. החל מפברואר 2024, גוגל ויאהו החלו לאכוף דרישות אימות חדשות ומחמירות. כל מי ששולח דוא"ל לכתובות Gmail או Yahoo חייב להגדיר לפחות SPF או DKIM. עבור שולחים המפיצים מעל 5,000 הודעות ביום, הדרישות מחמירות אף יותר וכוללות חובה להגדיר את כל השלושה: SPF, DKIM ורשומת DMARC תקינה.

המשמעות ברורה: אי עמידה בדרישות אלו עלולה לגרום לכך שהודעות יידחו על הסף או יסווגו אוטומטית כספאם, מה שפוגע ישירות בעבירות (deliverability) שלכם. המהלך האיץ דרמטית את אימוץ הטכנולוגיה. לפי ניתוח של EasyDMARC שפורסם בתחילת 2026, נרשם גידול של 79% באימוץ רשומות DMARC בקרב 1.8 מיליון הדומיינים המובילים בעולם בין 2023 לתחילת 2026. אימות הוא כבר לא המלצה, אלא תנאי בסיסי לתקשורת עסקית תקינה.

הקשר הישיר: אימות דוא"ל ועבירות (Deliverability)

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

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

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

מדריך בסיסי: איך מגדירים רשומות אימות דוא"ל בדומיין?

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

שלב 1: הגדרת רשומת SPF

הצעד הראשון הוא לזהות את כל השירותים ששולחים מיילים בשם הדומיין שלכם. זה כולל את ספק הדוא"ל הראשי (כמו Google Workspace או Microsoft 365), מערכות דיוור, תוכנות CRM, מערכות להנהלת חשבונות ושירותי אוטומציה. עבור כל שירות, תצטרכו למצוא את כתובת ה-SPF שלו (בדרך כלל במדריכי העזרה שלהם, תחת "email authentication").

לאחר שאספתם את כל המקורות, עליכם ליצור רשומת TXT אחת ב-DNS שלכם שתכלול את כולם. אם אתם משתמשים ב-Google Workspace ובמערכת דיוור נוספת, הרשומה תיראה בערך כך: v=spf1 include:_spf.google.com include:servers.some-newsletter.com ~all. זכרו, מותרת רק רשומת SPF אחת לדומיין.

שלב 2: הגדרת רשומת DKIM

הגדרת DKIM דורשת פעולה גם בצד שירות הדואר וגם ב-DNS. התהליך הגנרי כולל:

1. יצירת מפתח DKIM: היכנסו לממשק הניהול של השירות השולח (למשל, Google Workspace Admin Console) וחפשו את האזור המיועד לאימות דוא"ל (למשל, Apps > Google Workspace > Gmail > Authenticate email). שם, תפעילו את האפשרות ליצור מפתח DKIM חדש עבור הדומיין שלכם.
2. העתקת הנתונים: המערכת תספק לכם שני ערכים חשובים: שם הרשומה (DNS Host Name / Selector) וערך הרשומה (TXT Record Value).
3. יצירת רשומת DNS: גשו למערכת ניהול ה-DNS של הדומיין שלכם, צרו רשומת TXT חדשה, והדביקו את השם והערך שהעתקתם.
4. הפעלת האימות: לאחר שהרשומה התעדכנה ב-DNS (תהליך שיכול לקחת בין דקות ספורות ל-48 שעות), חזרו לממשק הניהול של שירות הדואר ולחצו על כפתור להפעלת האימות (למשל, 'Start Authentication' בגוגל).

יש לחזור על התהליך עבור כל פלטפורמה ששולחת מיילים בשמכם.

שלב 3: הגדרת רשומת DMARC (במצב ניטור)

לאחר ש-SPF ו-DKIM מוגדרים ועובדים, השלב האחרון הוא יצירת רשומת DMARC. שלב זה הוא קריטי ויש לבצעו בזהירות. גשו למנהל ה-DNS שלכם וצרו רשומת TXT חדשה עם הנתונים הבאים:

• שם/מארח (Host): _dmarc (או _dmarc.your-domain.com, תלוי בספק ה-DNS).
• ערך (Value): v=DMARC1; p=none; rua=mailto:[email protected];

חשוב: החליפו את כתובת המייל בכתובת ייעודית בבעלותכם שתקבל את דוחות ה-XML. תמיד מתחילים במדיניות ניטור (p=none). מדיניות זו לא חוסמת שום מייל, אלא רק אוספת נתונים ושולחת לכם דוחות על כל פעילות המייל בשם הדומיין שלכם. זהו שלב איסוף המודיעין החיוני לפני מעבר לאכיפה.

מניטור לאכיפה: איך לקרוא דוחות DMARC ולהגיע למדיניות 'reject' בבטחה

השלב הקריטי ביותר הוא המעבר ממדיניות ניטור (p=none) למדיניות אכיפה. הנתונים מראים שזהו האתגר הגדול ביותר: נכון לפברואר 2026, למרות ש-30.4% מהדומיינים המובילים אימצו DMARC, רק 12.8% מכלל הדומיינים מיישמים מדיניות אכיפה (quarantine או reject) שמגנה עליהם בפועל, כך על פי מחקר של DMARCguard שסקר 5.5 מיליון דומיינים. המשמעות היא שרוב גדול מהדומיינים עם DMARC עדיין נמצאים במצב ניטור בלבד (p=none).

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

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

לאחר תקופת ניטור (שבועיים עד חודש), תוכלו לזהות מקורות שליחה לגיטימיים ששכחתם לאמת (למשל, מערכת הנהלת חשבונות). לאחר שווידאתם ש-100% מהתעבורה הלגיטימית שלכם עוברת אימות, תוכלו להתקדם בזהירות:

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

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

מה חשוב לזכור

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

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

שאלות נפוצות

האם SPF ו-DKIM לבדם לא מספיקים?

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

מה ההבדל בין מדיניות DMARC של p=none, p=quarantine ו-p=reject?

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

האם אני חייב להגדיר את זה אם אני שולח פחות מ-5,000 מיילים ביום?

כן, מומלץ בחום. למרות שהדרישות המחמירות של גוגל ויאהו חלות רשמית על שולחים גדולים, הגדרת SPF, DKIM ו-DMARC היא שיטה מומלצת (best practice) לכל בעל דומיין. היא מגנה על המוניטין שלך ומונעת התחזות, ללא קשר לכמות המיילים.

האם ההגדרה מסובכת ויכולה לשבש לי את שליחת המיילים?

ההגדרה הראשונית של רשומות DNS היא פשוטה יחסית. עם זאת, המעבר למדיניות אכיפה (quarantine/reject) דורש זהירות וניטור של דוחות DMARC כדי לוודא שמערכות לגיטימיות (כמו מערכות דיוור או CRM) מאומתות כראוי ולא נחסמות בטעות.

מקורות

• DMARCguard
• EasyDMARC
• FBI IC3 Report / Proofpoint
• Google Workspace Help – הגדרת SPF
• Google Workspace Help – פתרון בעיות ב-SPF
• Google Workspace Help – הגדרת DKIM
• Google Workspace Help – הגדרת DMARC
• Microsoft Learn – הגנה מפני דואר זבל ב-Microsoft 365
• גיקטיים – תגית 'אימייל'

רוצים לחבר אוטומציה או AI לעסק שלכם בלי כאב ראש? דברו איתנו.