Defaults.Exposed › דוחות
מדוע SPF שלי נכשל? בעיית 10 הבדיקות של SaaS עבור שולחים בבריטניה ובאיחוד האירופי (2026)
פורסם 2026-07-09
נתונים נכון ל-2026-06-29 · מתודולוגיה גרסה 7. נתוני מפקד מצטברים על פני 261 מיליון דומיינים מדורגים. ראו כיצד אנו מדרגים.
כאשר SPF נכשל עבור עסק המשתמש בכלי SaaS בבריטניה או באיחוד האירופי, הסיבה הסבירה ביותר היא כלל RFC אחד שמעולם לא נאלצתם לחשוב עליו: מעבר ל-10 בדיקות DNS, SPF אינו מחזיר “כישלון” — הוא מחזיר PermError, כלומר הרשומה מטופלת כאילו אינה קיימת. לפחות 797,263 דומיינים כבר חצו את הקו הזה. 2,119,539 נוספים עומדים בדיוק על 9–10 בדיקות — כלי אחד חדש מרחיק אותם מהצוק.
מדוע SPF נשבר כאשר מוסיפים כלי SaaS?
SPF פועל על ידי רישום שרתי הדואר המורשים לשלוח בשם הדומיין שלכם. עסקים מודרניים אינם מפעילים שרתי דואר משלהם בדרך כלל — הם משתמשים ב-Google Workspace לדואר פנימי, ב-Mailchimp לקמפיינים, ב-HubSpot לרצפי מכירות, ב-Pipedrive לתקשורת CRM. כל פלטפורמה מספקת לכם שורת include: להדביק ב-DNS שלכם.
הבעיה: כל include: הוא בפני עצמו בדיקת DNS. וכל רשומה בתוך אותו include עשויה להפעיל בדיקות נוספות באופן רקורסיבי. RFC 7208 §4.6.4 קובע מכסה קשיחה של עשר. מעבר לעשר, שרת הדואר המקבל מפסיק לבצע הערכה ומחזיר PermError — וPermError אינו כישלון רך שמסתיים בספאם. הוא אומר שרשומת SPF שלכם מטופלת כאילו אינה קיימת. אימות הדואר האלקטרוני נכשל על רגל ה-SPF.
לא תראו זאת בלוח ה-DNS שלכם. המונה פועל רק במהלך הערכה חיה. יכולות להיות לכם שלוש שורות include: ברשומה הגלויה ועדיין להיות בעומק שתים עשרה בדיקות, כי רשומת SPF של כל ספק מושכת אליה sub-includes משלה.
כמה דומיינים כבר מעל המגבלה?
לפחות 797,263. זהו הספירה לאחר שפתרנו כל יעד include: של SPF שאוזכר 100 פעמים או יותר — 10,842 יעדים שונים המכסים 95.2% מכל הפניות include — ותמחרנו את השרשרת המלאה של כל דומיין. הספירה השטחית (מה שתמצאו על ידי ספירת השורות הגלויות בלבד ברשומה) מוצאת בערך 7,958. הנתון לאחר תמחור השרשרת גדול פי 100, כי כמעט כל הנזק בלתי נראה בתוך יעדי include.
המצב שהכי סביר להשפיע על עסק אירופאי:
| תרחיש | מה קורה |
|---|---|
| Google Workspace + Mailchimp + HubSpot + כלי נוסף | ככל הנראה ב-10 בדיקות או מעליהן |
| אחסון IONOS + כל שלושה כלי SaaS | סיכון גבוה: יעד SPF של IONOS עצמו מוסיף מספר צמתים |
| אחסון OVH + שני כלי עסקאות + CRM | הסיכון תלוי בעומק SPF של OVH בזמן ההערכה |
| Microsoft 365 בלבד | סיכון נמוך: SPF של Microsoft קומפקטי ומתוחזק היטב |
ספקי אחסון אירופאים ופגמים בברירות מחדל של SPF
ספק האחסון שהתחלתם איתו חשוב — כי חלקם קובעים ברירות מחדל של SPF שכבר צורכות כמה מעשר הבדיקות שלכם לפני שתחברו כלי SaaS אחד.
מבין ספקי האחסון הגדולים ביותר שבהם משתמשים דומיינים אירופאים במפקד שלנו:
| ספק | דומיינים המשתמשים בו | SPF קפדני (-all) | DMARC אוכף |
|---|---|---|---|
| IONOS (EU) | 4,346,526 | 0.3% | 1.0% |
| OVH | 2,132,049 | 43.7% | 2.2% |
| Microsoft 365 | 10,205,070 | 85.0% | 21.7% |
| Google Workspace | 12,145,313 | 8.0% | 18.5% |
IONOS בולט לשלילה: 1.0% בלבד מדומיינים מאוחסנים ב-IONOS מיישמים DMARC, כלומר הרוב המכריע אינם מאומתים בכלל. דומיינים של OVH משיגים תוצאות טובות יותר בהגדרת SPF הקפדנית (43.7%) אך נופלים ל-2.2% באכיפת DMARC — SPF בלבד, ללא DMARC לשם קשרו לכותרת From:, מגן רק על הגלישה, לא על מה שהנמען רואה.
Microsoft 365 הוא החריג לטובה: 85.0% מהדומיינים המאוחסנים ב-Microsoft משתמשים ב-SPF קפדני, בעיקר מפני שאשף תהליך הדואר של Microsoft קובע -all כברירת מחדל. Google Workspace קובע ~all (softfail) כברירת מחדל, ומשאיר 92% מהדומיינים שלו ללא הגנה קפדנית.
כיצד לאבחן כשל SPF תוך פחות מ-60 שניות
הבדיקה המהירה ביותר היא כלי חינמי המעריך את שרשרת הבדיקות המלאה — לא רק את הרשומה הגלויה. הריצו nslookup -type=TXT yourdomain.com בשורת הפקודה וספרו כל include: שתראו. לאחר מכן בדקו כל אחד מאותם רשומות וספרו את שלהם. אם אתם נגמרים מאצבעות לפני שנגמרים ה-includes, אתם באזור הסכנה.
גישה אמינה יותר: בדקו את הדומיין שלכם כאן — הסורק מעריך את השרשרת המלאה שנפתרה, מסמן PermError, ומראה לכם אילו מנגנונים צורכים את תקציב הבדיקות שלכם.
שלוש תוצאות אבחוניות:
- PermError — כבר עברתם את העשר. כל דואר אלקטרוני שאתם שולחים נכשל בבדיקת SPF אצל הנמען.
- ב-9–10 בדיקות — אתם על הצוק. השילוב הבא עם SaaS יזרוק אתכם.
- Softfail (~all) במקום hardfail (-all) — אתם מתחת למגבלה אבל הרשומה מוגדרת באופן מתירני מדי לספק הגנה אמיתית. ראו את דוח הגדרות SPF שגויות לתמונה המלאה על
-allלעומת~all.
כיצד לתקן SPF כאשר משתמשים במספר כלי SaaS
ישנן שלוש גישות, לפי סדר הקביעות:
1. ביקורת וגיזום. התחילו ברשימת כל include: ברשומה הנוכחית שלכם. הסירו כל פלטפורמה שאינכם משתמשים בה עוד — ספקי שירות דואר ישנים, כלי CRM מחוזים קודמים, פלטפורמות שניסיתם ונטשתם. זה חינמי ולעתים קרובות מחזיר כמה בדיקות. כל include: שמוסר עשוי להסיר 1–3 בדיקות משנה.
2. שיטוח רשומת SPF. שיטוח SPF פותר את כל יעדי ה-include: לטווחי ה-IP הבסיסיים שלהם וכותב אותם ישירות לרשומה שלכם כמנגנוני ip4: ו-ip6:. מנגנוני IP אינם מפעילים בדיקות, כך ששיטוח יכול לפרט עשרות מקורות שליחה ועדיין לשבת על אפס בדיקות. החיסרון: עליכם לשטח מחדש בכל פעם שספק מעדכן את כתובות ה-IP השולחות שלו, וזה קורה ללא הודעה. רוב הארגונים משתמשים בשירות שיטוח SPF בתשלום (PowerDMARC, EasyDMARC, Dmarcian ואחרים מציעים זאת) או בונים תהליך עבודה לניטור.
3. שימוש במאקרו SPF. מאקרו RFC 7208 מאפשרים לבנות רשומות שמבצעות בדיקת DNS אחת בלבד לכל בדיקה ועונות באופן דינמי, במקום שרשרת של includes. מאקרו דורשים תמיכה באחסון DNS ומאמץ מסוים ביישום, אך הם הפתרון הנקי ארכיטקטוראלי עבור ארגונים עם שולחי SaaS רבים.
לאחר תיקון SPF, שלבו אותו עם אכיפת DMARC — SPF ללא DMARC מאמת רק את שולח הגלישה, לא כתובת ה-From: בכותרת שהנמענים רואים.
שאלות נפוצות
מדוע רשומת SPF שלי עוברת את כלי ה-DNS שלי אך עדיין נכשלת בכותרות הדואר האלקטרוני?
רוב כלי חיפוש ה-DNS סופרים רק את המנגנונים הגלויים ברשומה שלכם עצמכם, לא את בדיקות המשנה שאותם מנגנונים מפעילים. יכולות להיות לכם שתי שורות include: ועדיין לחצות את המגבלה אם רשומת כל ספק מכילה מספר נוספות. רק כלי תמחור שרשרת (או שרת דואר מקבל) סופר את העומק המלא. בדקו את הדומיין שלכם לראיית ספירת השרשרת האמיתית.
האם כישלון SPF אומר שהמיילים שלי ילכו לספאם?
PermError (יותר מדי בדיקות) אומר שרגל ה-SPF באימות מחזירה תוצאה שאינה תוצאה — נעדרת למעשה. DMARC מעריך גם SPF וגם DKIM; אם DKIM עובר, DMARC עדיין יכול לעבור למרות PermError ב-SPF. אם לא עובר אף אחד, DMARC נכשל, והתוצאה תלויה במדיניות DMARC שלכם. ב-p=none, הדואר עדיין מסופק אך הכישלון מתועד. ב-p=quarantine או p=reject, הדואר מסונן או מוחזר. תקנו SPF כדי שלא תהיו תלויים ב-DKIM בלבד.
כמה בדיקות משתמש ערימת SaaS טיפוסית? הרשומה ב-p99 במפקד שלנו כבר עומדת על 9 בדיקות — בדיוק על המגבלה — לפני הוספת כל דבר. רשומת Google Workspace מוסיפה 3–4 בדיקות; Mailchimp מוסיפה 1–2; HubSpot מוסיפה 1–3 בהתאם לתצורה הנוכחית שלה. שלושה כלים עיקריים בתוספת ברירת המחדל של ספק האחסון שלכם מספיקים לעתים קרובות כדי לחצות את העשרה.
האם שיטוח SPF בטוח?
כן, בתנאי שתשמרו אותו מעודכן. שיטוח ממיר שרשרות include: לטווחי IP סטטיים — אם ספק מסובב את כתובות ה-IP השולחות שלו ולא שיטחתם מחדש, תתחילו לדחות את הדואר שלהם. רוב הארגונים משתמשים בשירות שיטוח מנוהל שמנטר שינויי IP במקום לתחזק זאת ידנית.
ה-SPF שלי כך מאז שנים — מדוע הוא נכשל פתאום? כי הספקים שלכם עדכנו את רשומות ה-SPF שלהם, לא שלכם. בכל פעם שפלטפורמת SaaS מוסיפה טווח IP שליחה חדש או מקיננת include נוסף, עלות השרשרת שלכם עולה ללא כל שינוי מצדכם. מגבלת 10 הבדיקות מוערכת חי בעת קבלת ההודעה, לכן שינוי ספק ביום שלישי בבוקר יכול לשבור את ה-SPF שלכם בצהריים של יום שלישי.
האם תיקון SPF משפר את מסירת הדואר האלקטרוני? הוא מסיר מקור לכישלון אימות, שהוא תנאי מוקדם למסירה עקבית — במיוחד מאז שגוגל ויאהו אוכפות יישור DMARC עבור שולחים מרובים. SPF לבדו אינו התמונה המלאה: שלבו אותו עם DKIM ו-DMARC לאימות דואר אלקטרוני מלא.
בדקו את SPF שלכם חינם
אם אינכם בטוחים אם רשומת SPF שלכם מעל מגבלת הבדיקות — או מוגדרת בצורה חלשה מדי להגן על הדומיין שלכם — הריצו בדיקה חינמית. היא מעריכה את השרשרת המלאה שנפתרה ומראה לכם בדיוק היכן התקציב מושקע.
בדקו את הדומיין שלכם ← · תקנו SPF ← · דוח SPF PermError ← · דוח הגדרות SPF שגויות ← · מודל בשלות אימוץ SPF ← · תקנו DMARC ← · נתונים מצטברים בלבד. הנתונים מאוחסנים ומעובדים באיחוד האירופי.