Defaults.Exposed › דוחות

SPF ~all מול -all: Softfail או Hardfail — מה בחרו 139 מיליון רשומות (2026)

פורסם 2026-07-03

נתונים נכון ל-2026-06-29 · מתודולוגיה v7. נתוני מפקד מצרפיים על פני 261 מיליון דומיינים מדורגים. כל הנתונים מצרפיים — לעולם איננו מפרסמים את הרשומה של עסק בודד. ראו כיצד אנחנו מדרגים.

כל רשומת SPF מסתיימת במנגנון “all” — הפסיקה לגבי דואר מכל מקום שאינו ברשימה שלכם — והאינטרנט בחר באופן גורף באפשרות הרכה: 55.8% מתוך 139 מיליון הדומיינים המפרסמים SPF מסתיימים ב-~all (softfail), לעומת 39.3% המסתיימים ב--all (hardfail). תו אחד מפריד בין “דחה זיופים” לבין “כנראה זיוף — מסור אותו בכל זאת”. איזו מהאפשרויות נכונה עבורכם תלויה בהגדרה שנייה שרוב הבעלים אף פעם לא מגדירים.

מה בעצם ~all ו—all אומרים לשרת המקבל?

• -all (hardfail): “דחה דואר מכל מקום אחר.” לא נחרץ.
• ~all (softfail): “דואר ממקום אחר כנראה אינו לגיטימי — קבל אותו, אולי סמן אותו.” משיכת כתפיים.
• ?all (neutral): “אין דעה.” נבחר על ידי 3.0% מהמפרסמים; הגנה בשם בלבד.
• +all: “כל אחד רשאי לשלוח בשמי.” מפורסם על ידי 36,014 דומיינים, וגרוע יותר מהיעדר רשומה — לבעיית שטיח-הפתחים יש דוח משלה.

אז ~all שגוי? רק אם הוא לבדו — וכמעט תמיד כך הוא

ל-softfail יש נימוק מודרני בר-הגנה: הנחיות השולחים של Google, ורוב פרקטיקות המסירוּת יחד איתן, מתכנסות אל ~all בשילוב עם מדיניות DMARC אוכפת (p=reject). השילוב מגן באותה מידה כמו -all בכל שרת מקבל שמעריך DMARC — כולל כעת כל ספקי תיבות הדואר הגדולים — מבלי לגרום לדחייה נחרצת של דואר מועבר לגיטימי, הקורבן הקלאסי של -all. בתצורה הזו למשיכת הכתפיים יש שיניים: DMARC מספק את הפסיקה ש-SPF סירב לתת.

אבל השילוב הוא כל העיקר, והנה מה שהמפקד מוסיף שמדריכי הגדרה אינם יכולים: מתוך 77,484,057 רשומות softfail באינטרנט, רק 7.1 מיליון — כאחת מתוך 11 — כוללות מדיניות DMARC אוכפת מאחוריהן. עבור שאר 70.4 מיליון הדומיינים, ~all הוא בדיוק כפי שהוא נשמע. הרשומה שלהם מזהה את הזיוף ומעבירה אותו הלאה בנפנוף.

האם המנדטים של 2024 לא תיקנו את זה?

לא — וההבחנה חשובה יותר משרוב הסיקור מרמז. Google ו-Yahoo החלו לדרוש אימות משולחים בכמות גדולה בפברואר 2024, כאשר Microsoft הצטרפה במאי 2025: SPF או DKIM עוברים ומיושרים, בתוספת רשומת DMARC ב-מינימום p=none. המנדטים אינם מגיעים לכדי דרישת אכיפה — דומיין עם ~all, רשומת p=none ו-DKIM מיושר עומד בדרישות במלואן, ונשאר בר-זיוף לחלוטין. המנדטים תיקננו את הניירת, לא את ההגנה. האמצע הבלתי-אכוף הזה — תואם, מפורסם, בר-זיוף — הוא בדיוק הפער שהמפקד הזה מודד, והוא האוכלוסייה הגדולה ביותר באבטחת דואר אלקטרוני.

אז במה הרשומה שלכם צריכה להסתיים?

1. אתם שולחים דואר והעברה חשובה (ניוזלטרים, רשימות תפוצה, כתובות אליאס): ~all עם DMARC p=reject מאחוריו — השילוב המומלץ למעלה.
2. אתם שולחים דואר מהגדרה מבוקרת בקפדנות: -all עובד ומצהיר על המדיניות ברשומה עצמה. מפו תחילה את השולחים שלכם — סיומת קפדנית על רשומה שלא מופתה שוברת דואר אמיתי, או גרוע מכך.
3. הדומיין לעולם אינו שולח: -all בתוספת p=reject, כבר היום. אין דבר לגיטימי שקיים כדי להגן עליו, ולכן אין מה לשבור.

בכל סיומת שתבחרו, הלקח בשורה אחת של המפקד תקף: המכשיר חשוב רק כמידת מה שאוכף אותו. היכן אתם עומדים על אותו סולם הוא ניתן למדידה.

שאלות נפוצות

האם SPF ~all או -all עדיף? אף אחד מהם, באופן גורף. ~all עם מדיניות DMARC אוכפת הוא התבנית שהנחיות Google ממליצות עליה — הגנה שווה בשרתים מקבלים שמעריכים DMARC מבלי לשבור דואר מועבר. -all מתאים לשולחים מבוקרים בקפדנות. ~all לבדו — מצבם של כל דומייני ה-softfail למעט אחד מתוך 11 — הוא האפשרות החלשה.

מה המשמעות של SPF softfail? ~all אומר לשרתים המקבלים שדואר משרתים שאינם ברשימה כנראה אינו לגיטימי אך עדיין יש לקבל אותו, בדרך כלל בחשדנות. הוא הופך להגנה אמיתית רק כאשר מדיניות DMARC פועלת על הכישלון; ראו SPF ללא DMARC.

האם hardfail -all ישבור את הדואר המועבר שלי? זה יכול: העברה שולחת מחדש את הדואר שלכם משרת המעביר, ששרת ה-SPF שלכם אינו מפרט, ו-hardfail מזמין דחייה עוד לפני ש-DKIM או DMARC נכנסים לתמונה. אותו סיכון הוא הסיבה שהשילוב ~all + p=reject קיים.

האם Google ו-Microsoft דורשים -all כעת? לא. מנדטי השולחים בכמות גדולה דורשים אימות מיושר ועובר ורשומת DMARC ב-מינימום p=none — ללא אכיפה, ללא מכשיר ספציפי. הדחייה של Google לדואר מסחרי לא-תואם פעילה; Microsoft מסמנת כישלונות כזבל ומתקדמת לעבר דחייה מוחלטת. תאימות אינה הגנה.

בדקו במה הרשומה שלכם מסתיימת — ומה עומד מאחוריה

שתי בדיקות מגלות לכם את שניהם, בחינם, ב-30 שניות. אם אתם אחת מתוך 70.4 מיליון משיכות הכתפיים הבלתי-אכופות, התיקון הוא רשומת DNS, לא רכישה.

בדקו את הדומיין שלכם → · תקנו SPF → · תקנו DMARC → · מודל הבשלות של SPF → · מפת ה-+all → · נתונים מצרפיים בלבד. הנתונים נשמרים ומעובדים באיחוד האירופי.