DMARC מול SPF: מה ההבדל, ובאיזה מהם אתם צריכים? (2026)
פורסם · עודכן
הנתונים נכונים ל-2026-08-16 · מתודולוגיה v8. נתוני מפקד מצרפיים על פני 276 מיליון דומיינים מדורגים. “אכיפה” משמעה מדיניות DMARC של
quarantineאוreject. ראו איך אנחנו מדרגים.
חלק מעמוד העוגן של DMARC — אימוץ DMARC, בשלות וטבלאות דירוג, נמדדים על פני המפקד כולו.
אתם צריכים את שניהם — קודם SPF, אחר כך DMARC — כי הם עונים על שאלות שונות. SPF הוא רשימה: אילו שרתים מורשים לשלוח דוא”ל עבור הדומיין שלי? DMARC הוא מדיניות: מה על השרתים המקבלים לעשות עם הודעה שנכשלת באימות — ואיך אדע שזה קרה? אף אחד מהם לא מחליף את השני. SPF בלי DMARC משאיר את כתובת ה”מאת” הגלויה ניתנת לזיוף; ל-DMARC בלי SPF (או DKIM) אין מה לאכוף. המפקד מראה כמה פעמים השניים מתבלבלים זה בזה: נכון ל-2026-08-16, 51.24% מתוך 276 מיליון דומיינים מדורגים מפרסמים SPF, אבל רק 11.83% אוכפים DMARC — פער של עשרות מיליוני עסקים שביצעו את שלב אחד ומאמינים שסיימו.
מה SPF באמת עושה
SPF (Sender Policy Framework) הוא רשומת DNS TXT אחת שמפרטת את השרתים המורשים לשלוח דואר עבור הדומיין שלכם — ספק תיבות הדואר שלכם, כלי הניוזלטר, ה-CRM. כששרת דואר מקבל הודעה שטוענת שהגיעה מכם, הוא בודק אם השרת שמסר אותה נמצא ברשימה שלכם.
שני פרטים חשובים כאן, כי הם מגדירים את גבולות SPF:
- SPF בודק את השולח הטכני, לא את הגלוי. הכתובת ש-SPF מאמת היא שולח המעטפה (ה-”Return-Path” — הכתובת שאליה חוזרות הודעות שנדחו). הוא לעולם לא מסתכל על שורת ה”מאת” שאדם קורא בתיבת הדואר שלו. שתי הכתובות האלה יכולות להיות שונות לחלוטין, וברוב ההונאות הן אכן שונות.
- SPF לא אומר מה קורה בכישלון. הרשומה מסתיימת במגדיר (
-allאו~all) שמציע לשרתים המקבלים איך להתייחס לשולחים שאינם ברשימה, אבל אין הוראה מחייבת ואין משוב אליכם. מבין הדומיינים עם SPF, רק 39.2% בכלל משתמשים ב--allהמחמיר; 55.9% משתמשים ב-~all, שרוב השרתים המקבלים מוסרים בכל מקרה.
SPF הוא צנרת הכרחית. הוא איננו, בפני עצמו, הגנה — נקודה שהנתונים מבהירים בבוטות: 30.9% מכלל הדומיינים מפרסמים SPF אבל אין להם DMARC בכלל (פער הביטחון המדומה, נמדד).
מה DMARC באמת עושה
DMARC (Domain-based Message Authentication, Reporting and Conformance) יושב מעל SPF ו-DKIM ומוסיף את שלושת הדברים שחסרים להם:
- הוא מגן על הכתובת שאנשים רואים. DMARC דורש הלימה (alignment): הדומיין שעבר את SPF או DKIM חייב להתאים לדומיין שבכותרת ה”מאת” הגלויה. זה סוגר את הפער ש-SPF משאיר פתוח — תוקף כבר לא יכול לעבור SPF על התשתית שלו עצמו תוך הצגת השם שלכם.
- הוא אומר לשרתים המקבלים מה לעשות בכישלון. רשומת ה-DMARC שלכם מפרסמת מדיניות:
p=none(למסור בכל זאת, רק לדווח),p=quarantine(תיקיית ספאם), אוp=reject(לסרב). זו שכבת האכיפה ש-SPF מעולם לא הייתה לו. - הוא מדווח בחזרה אליכם. השרתים המקבלים שולחים לכם דוחות מצרפיים שמראים מי שולח בשם הדומיין שלכם — לגיטימי ואחר. זהו היחיד מבין התקנים האלה עם לולאת משוב, וכך מהדקים את השאר בבטחה.
המלכוד: DMARC מגן רק ב-quarantine או reject. רשומה שחונה על p=none מנטרת ולא עושה דבר מעבר לכך — p=none אינו הגנה. נכון ל-2026-08-16, ל-74.20% מהדומיינים אין רשומת DMARC כלל, 13.96% יושבים על ניטור בלבד, ורק 11.83% אוכפים.
SPF מול DMARC, זה לצד זה
| SPF | DMARC | |
|---|---|---|
| מה זה | רשימת שרתים המורשים לשלוח עבור הדומיין שלכם | מדיניות למה שקורה כשהאימות נכשל |
| השאלה שהוא עונה עליה | ”האם זה הגיע משרת מאושר?" | "האם השולח הגלוי תואם למי שאומת — ואם לא, מה עכשיו?” |
| מה הוא בודק | שולח המעטפה (Return-Path) — בלתי נראה לקורא | הלימה בין SPF/DKIM לכתובת ה”מאת” שאנשים רואים |
| בכישלון | מציע תוצאה (-all/~all); השרת המקבל מחליט | מורה על תוצאה שבחרתם: none / quarantine / reject |
| דיווח בחזרה אליכם | אין | דוחות מצרפיים על כל מי ששולח בשם הדומיין שלכם |
| שורד העברה (forwarding) | לרוב נשבר — המעביר אינו ברשימה שלכם | כן, כשהלימת DKIM נשמרת (החתימות נוסעות עם ההודעה) |
| עוצר לבדו התחזות ב”מאת” הגלוי | לא | כן — ב-quarantine או reject, עם SPF/DKIM מתחת |
| אימוץ (2026-08-16) | 51.24% מפרסמים | 11.83% אוכפים |
הסיכום בשורה אחת: SPF מאמת נתיב; DMARC מגן על זהות. השרתים המקבלים שוקלים את SPF כאות אחד מני רבים. DMARC באכיפה הוא הכרעה.
למה SPF לבדו נכשל
שלוש סיבות מבניות, לא באגים ביישום:
פער כותרת ה”מאת”. SPF לעולם לא בוחן את שורת ה”מאת”. נוכל שולח מתשתית scammer-domain.com עם החברה שלכם בשדה ה”מאת” הגלוי: SPF בודק את דומיין המעטפה שלו מול רשומת ה-SPF שלו, עובר בנקיון, והזיוף נוחת ונראה אותנטי. רק דרישת ההלימה של DMARC תופסת את זה — ולכן זיוף דוא”ל נותר שגרתי נגד דומיינים עם SPF בלבד, ולכן 88.17% מהדומיינים המדורגים עדיין ניתנים להתחזות.
העברה (forwarding). כשמישהו מעביר אוטומטית את הדואר שלכם (כתובת ישנה לחדשה, כינוי תפוצה), שרת ההעברה הוא שמוסר אותו — והשרת הזה אינו ברשומת ה-SPF שלכם, כך ש-SPF נכשל על דואר לגיטימי לחלוטין. זו אינה תצורה שגויה; כך העברה עובדת. חתימות DKIM שורדות העברה, ולכן DMARC (שעובר על SPF מולם או DKIM מולם) מתמודד עם זה ו-SPF גולמי לא יכול. פרטים: העברה שוברת SPF.
אין השלכות, אין משוב. אפילו רשומת SPF מושלמת עם -all נסמכת על כך שכל שרת מקבל יבחר לפעול, ולא מספרת לכם דבר על מה שנשלח בשמכם. DMARC הופך את זה להוראה מפורשת ועוד דוח.
באיזה סדר לפרוס
הסדר חשוב כי DMARC צורך את מה ש-SPF ו-DKIM מייצרים. פרסו מלמעלה למטה:
- SPF קודם. פרסמו רשומת TXT אחת שמפרטת כל שולח לגיטימי, המסתיימת ב-
~allבזמן האימות, וב--allבסיום. תקנו SPF. - DKIM שני. הפעילו חתימה אצל ספק הדואר שלכם — זה מה ששומר על האימות שלם דרך העברות. תקנו DKIM.
- DMARC על
p=none, עם דיווח. פרסמוv=DMARC1; p=none; rua=mailto:...וקראו את הדוחות בפועל — מספר מפתיע של דומיינים מפרסמים DMARC באופן עיוור, בלי כתובת דיווח בכלל. שלבים לפי ספק: Google Workspace · Microsoft 365. - הדקו ל-
quarantine, ואזrejectברגע שהדוחות מראים שהדואר הלגיטימי שלכם עובר. השלב הזה הוא ההגנה; כל מה שלפניו הוא הכנה. ההתקדמות הבטוחה.
דילוג קדימה שובר דברים בשני הכיוונים. DMARC-לפני-SPF/DKIM שולח להסגר את הדואר הלגיטימי שלכם עצמכם. SPF-ולעצור — מצב הסיום הנפוץ ביותר, 30.9% מכלל הדומיינים — משאיר את כתובת ה”מאת” הגלויה פתוחה. רק 2.79% מהדומיינים משלימים את כל השלבים.
מקרי הקצה, בכנות
- רשימות תפוצה יכולות לשבור את שניהם. רשימות שמשכתבות נושאים או מוסיפות כותרות תחתונות מבטלות חתימות DKIM וגם נכשלות ב-SPF (שרת הרשימה הוא ששולח). רשימות מודרניות משכתבות את כותרת ה”מאת” כפיצוי. אם הקהילה שלכם חיה על רשימות תפוצה, צפו לקצת כאב ב-
reject— זה ניתן לניהול, לא סיבה להישאר ב-none. - SPF יכול לעבור בזמן ש-DMARC נכשל. פלטפורמות שליחה רבות משתמשות בדומיין שלהן כשולח המעטפה, כך ש-SPF עובר — ללא הלימה עם דומיין ה”מאת” שלכם. הדואר הזה זקוק ל-DKIM עם הלימה (דומיין חתימה מותאם, שפלטפורמות טובות תומכות בו) כדי לעבור DMARC. אם ה-DMARC שלכם נכשל בזמן ש-SPF ו-DKIM עוברים, הלימה היא כמעט תמיד הסיבה.
- ל-SPF יש מגבלה של 10 שאילתות DNS. שרשרו יותר מדי רשומות
include:והרשומה תחזיר שגיאה קבועה ותתעלם לחלוטין. אחדו לפני שאתם מהדקים את DMARC, אחרת תאכפו על גבי SPF שבור. - גם דומיינים שלעולם לא שולחים דוא”ל צריכים את שניהם — בגרסאות המחמירות ביותר (
v=spf1 -allו-p=reject) — אחרת הדומיינים החונים והבלתי-משומשים שלכם הם הקלים ביותר לזיוף. - DMARC אינו סוף הדרך. הוא עוצר התחזות לדומיין המדויק. דומיינים דמויי-מקור, תעלולי שם-תצוגה ותיבות דואר אמיתיות שנפרצו הם בעיות אחרות — אמיתיות, אבל לא סיבה לדלג על סוג התקיפה האחד שאתם כן יכולים לחסום עם שלוש רשומות DNS.
שאלות נפוצות
האם DMARC זהה ל-SPF? לא. SPF הוא רשימה של שרתי שליחה מאושרים, הנבדקת מול כתובת שהקורא לעולם לא רואה. DMARC בודק שמי שאומת תואם לכתובת ה”מאת” הגלויה, מחיל את המדיניות שבחרתם בכישלון, ומדווח בחזרה אליכם.
האם אני צריך DMARC אם כבר יש לי SPF? כן. SPF לבדו לא מגן על כתובת ה”מאת” הגלויה — ל-30.9% מהדומיינים יש SPF ואין DMARC, והם נותרים ניתנים לזיוף. SPF הוא תנאי מוקדם ל-DMARC, לא תחליף.
האם אפשר להשתמש ב-DMARC בלי SPF? טכנית כן, אם DKIM קיים — DMARC עובר על כל מנגנון עם הלימה. בפועל תרצו את שניהם מתחת: SPF תופס מה ש-DKIM מפספס ולהפך (העברה היא המקרה הקלאסי שבו רק DKIM שורד).
מה להגדיר קודם?
SPF, אחר כך DKIM, אחר כך DMARC על p=none עם דיווח, ואז אכיפה. DMARC זקוק לשני הראשונים עובדים לפני שאפשר להדק אותו בבטחה.
האם משהו מזה עולה כסף? לא — SPF, DKIM ו-DMARC הם כולם רשומות DNS חינמיות. ההשקעה היא תשומת לב וסדר, לא תקציב. (קריאת דוחות DMARC קלה יותר עם מציג דוחות חינמי או בתשלום, אבל ההגנה עצמה לא עולה דבר.)
בדקו איפה הדומיין שלכם עומד
לרוב הדומיינים יש את הרשימה ולא את המנעול. בדקו את שלכם בחינם ובפרטיות — תראו את מצב ה-SPF, ה-DKIM וה-DMARC שלכם יחד, ומה הצעד הבא.
בדקו את הדומיין שלכם ← · תקנו SPF ← · תקנו DMARC ← · איך אנחנו מדרגים ← · נתונים מצרפיים בלבד. הנתונים מאוחסנים ומעובדים באיחוד האירופי.