הגדרת רשומת SPF: דוגמאות, מגבלות ותקלות נפוצות

אם אתם מקימים תשתית דוא״ל ב-2026, בדקו היטב את רשומת SPF. שגיאות עלולות לגרום לסינון לספאם או לדחייה, בהתאם למקבל ולאימות אחר. רשומה תקינה לבדה אינה מבטיחה הגעה לתיבת הדואר הנכנס.

מאז פברואר 2024 החמירו Google ו-Yahoo את דרישות האימות לקבוצות מסוימות של שולחים. SPF חסר או שגוי עשוי להשפיע, אך אינו גורם אוטומטית ל-SMTP 550 אצל כל מקבל. בדקו את הכללים החלים ואת תשובת השגיאה המלאה.

למייסד עם דומיין אחד, תקלה עשויה למנוע ממשקיע לקבל מצגת. לספק שירותים מנוהלים עם 500 דומיינים של לקוחות, יום שני עלול להתחיל בפניות על כשל בשליחה ל-Gmail. תצורה וניטור נכונים מצמצמים סיכון בלי למנוע כל תקלה.

המדריך מסביר מה SPF עושה, איך בונים רשומה, אילו תקלות עלולות לפגוע במסירה וכיצד מנהלים הגדרות רבות באופן מסודר.

מה SPF עושה ומה לא

Sender Policy Framework (SPF) הוא פרוטוקול הרשאה מבוסס DNS המוגדר ב-RFC 7208. הרשומה מגדירה אילו מערכות רשאיות לשלוח עבור זהות המעטפת הנבדקת. זו אינה שכבת הגנה כללית, והיא אינה מאמתת לבדה את כתובת השולח הגלויה.

איך הבדיקה פועלת

כש-Gmail מקבל הודעה מ-alice@yourcompany.com, SPF אינו מסתכל רק על From שמוצג בממשק. הזהות הרלוונטית היא שולח המעטפת ב-MAIL FROM, המשמש להחזרות ובדרך כלל נרשם ב-Return-Path לאחר המסירה. כשהמעטפת ריקה אפשר לבדוק את זהות HELO המתאימה. המקבל מביא את מדיניות הדומיין ובוחן את כתובת ה-IP השולחת.

התאמה למנגנון מתאים יכולה להפיק pass. כתובת שלא הותרה יכולה לקבל softfail עם ~all או fail עם -all; גם neutral ושגיאות אפשריים. התוצאה אינה מורה אוטומטית לקבל או לדחות.

ההבדל בין From ל-Return-Path

הטענה ש-90% מהמתחילים טועים כאן אינה נתון מסקר מאומת. העיקר הטכני: SPF אינו בודק את From שמוצג ב-Outlook או Apple Mail, אלא את זהות המעטפת הרלוונטית.

המכשול: Mailchimp עשויה להשתמש בדומיין החזרות משלה, כגון bounce-mc.us1.mailchimp.com. אז המקבל בודק SPF של Mailchimp, לא שלכם. הרשומה שלכם יכולה להיות תקינה בלי להיבדק עבור הודעה זו; התצורה בפועל קובעת.

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

מדוע SPF עדיין חשוב

גם עם DKIM ו-DMARC, SPF חשוב לדרישות השולחים החלות. תשובה כגון 550 5.7.515 Access Denied דורשת בדיקה לפי הכללים המסוימים של Microsoft. היא אינה מוכיחה שכל SPF חסר גורם לשגיאה הזאת אצל כל מקבל.

תצורת בסיס: ספק שליחה אחד

עסק קטן עם ספק עיקרי אחד, כגון TrekMail, Google Workspace או Microsoft 365, ואולי כלי שיווק אחד, זקוק להגדרה ברורה. איחוד הרשאות נכון כאשר הן באמת חלות על אותו דומיין מעטפת.

כלל הבסיס: מדיניות SPF אחת בדיוק לכל שם DNS שנבדק.

הוספת רשומת SPF שנייה במקום מיזוג עם הקיימת גורמת ל-PermError בהערכת SPF. הבעיה היא בחירת כמה רשומות מדיניות SPF, לא עצם קיומן של כמה רשומות TXT שאינן קשורות. המקבל מחליט כיצד לטפל בתוצאה.

רכיבי רשומת SPF

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

השוואת TrekMail לעסק קטן

ההשוואה להמחשה מציגה Google Workspace במחיר $6-$18 למשתמש לחודש. לעשרה משתמשים מדובר ב-$720-$2,160 לשנה. Starter של TrekMail מתוארת במחיר $3.50 לחודש ועד 100 משתמשים. אלה דוגמאות היסטוריות; בדקו מחירים, תנאים ושירותים כלולים כיום. include:spf.trekmail.net עשוי להתאים למסלול נתמך, אך אינו משלים אוטומטית את כל DNS והאימות.

כמה שולחים: ניהול לסוכנויות

ספקי שירותים וסוכנויות עשויים להשתמש ב-HubSpot למכירות, ב-Zendesk לתמיכה, ב-Klaviyo לשיווק וב-TrekMail לדואר השוטף. לא כל כלי צריך אוטומטית include בדומיין הראשי. בדקו את דומיין המעטפת שכל שירות משתמש בו בפועל.

אחדו הרשאות החלות על אותו דומיין במדיניות אחת, תוך התחשבות במגבלת 10 רכיבי DNS הרלוונטיים.

ניהול מגבלת 10 רכיבי DNS

RFC 7208 §4.6.4 מגביל מנגנונים ומשנים רלוונטיים המחייבים DNS במהלך ההערכה ל-10, כולל רכיבים מקוננים. אין זו ספירת כל מנות DNS. המגבלה מסייעת למנוע שימוש לרעה בתשתית וגם דורשת תשומת לב בתצורות תקינות.

רכיבים הנספרים כשהם מוערכים: include:, a, mx, exists, redirect. Exists משתמש בשאילתת A, ו-redirect מעביר את ההערכה כאשר מנגנונים קודמים לא התאימו. גם ptr, שאינו מומלץ, נספר.

מנגנונים שאינם צורכים את התקציב הזה: ip4:, ip6:, all

המכשול של include מקונן

מוסיפים include:bluehost.com, שנראה כרכיב 1. בדוגמה מקוננת להמחשה, הרשומה יכולה לכלול spf.protection.outlook.com ו-mail.bluehost.com, כך שרכיב אחד מוביל להערכת שלושה רכיבים. גם spf.protection.outlook.com יכול להפנות הלאה. זו אינה קביעה על תצורת Bluehost הנוכחית; בדקו ערכים ומסלול בפועל.

אם המסלול עובר 10 רכיבים רלוונטיים, מוחזר PermError. זה אינו SPF fail ואינו בהכרח העלמת דואר בלי הודעה. בדקו רישומים, תשובות SMTP ותוצאות אימות אחרות כדי לקבוע את ההשפעה.

בדיקת התקציב

אל תנחשו. השתמשו בכלי שורת פקודה או כלי המחשה אמין. ב-Mac וב-Linux אפשר להתחיל כך:

dig +short txt yourdomain.com

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

השטחת SPF לעומת חלוקה לתת-דומיינים

כשיש סיכון לחרוג ממגבלת 10 רכיבים, אפשר לבחון שתי אפשרויות. לא כל סוכנות חורגת בהכרח, והגעה למגבלה אינה חריגה ממנה.

אפשרות 1: השטחת SPF עם סיכוני תחזוקה

השטחה מחליפה שרשראות include: נבחרות בכתובות עדכניות, למשל באמצעות ip4:. ip4: אינו צורך את תקציב רכיבי DNS, אבל מאות כתובות עלולות ליצור מגבלות ובעיות ניהול אחרות. בדקו גם משפחות כתובות ומשמעות המדיניות המקורית.

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

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

אפשרות 2: חלוקה לתת-דומיינים

אפשר לפצל זרמי שליחה לפי דומיין מעטפת במקום לכלול הכל בדומיין הראשי. SPF מעריך את MAIL FROM בפועל, ואפשר להגדיר לו תת-דומיין.

האם השיווק צריך לשלוח עם team@company.com, או שמתאים news@marketing.company.com? שינוי From הגלוי לבדו אינו משנה את דומיין SPF.

דומיין ראשי (company.com): שמרו על הרשאות רלוונטיות ברורות, למשל לדואר ארגוני וחיוני. הרשומות הבאות הן דוגמאות; אמתו ערכי ספק עדכניים לפני הפרסום.

v=spf1 include:spf.trekmail.net -all

תת-דומיין שיווקי (marketing.company.com): הגדירו את השירותים להשתמש בו באמת כדומיין מעטפת.

v=spf1 include:servers.mcsv.net include:hubspot.com -all

לדומיין SPF נפרד שבאמת נמצא בשימוש יש תקציב של 10 רכיבים משלו. בדקו גם יישור DMARC מקל או מחמיר. פגיעה ב-marketing.company.com אינה נשארת בהכרח רק שם: מקבלים יכולים לצרף אותות מהדומיין הארגוני ומ-IP משותף. זו חלוקה ניהולית, לא הבטחה להגנה מלאה על דואר המנכ״ל.

ראו תבניות הגדרת SPF ואת מדריך הגדרה לכמה ספקי שליחה. בדקו כל דוגמה מול השירותים בפועל.

בדיקות לאחר הפרסום

שמירה בעורך DNS אינה סוף ההגדרה. בדקו פרסום, תחביר ושליחה אמיתית בצעדים הבאים.

1. בדיקת פרסום ומטמוני DNS

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

nslookup -type=txt yourdomain.com 8.8.8.8

8.8.8.8 מכוון לפותר הציבורי של Google במקום לפותר ספק האינטרנט. גם ל-Google יש מטמון. תשובה תקינה שם אינה מוכיחה שכל פותר או מקבל בעולם כבר רואה את הערך החדש.

2. אימות תחביר

בדקו תחביר והתנהגות הערכה. נקודות נפוצות:

• רווח לפני v=spf1 עלול למנוע זיהוי כרשומת SPF
• ip4: 192.1.1.1: הרווח אחרי הנקודתיים אינו תקין
• כמה מנגנוני all: all תמיד תואם ולכן מנגנונים מאוחרים אינם מגיעים להערכה
• רכיבי include: כפולים עלולים לבזבז תקציב כשהם מוערכים; ההשפעה תלויה במסלול ובשגיאות

השתמשו בבדיקת תחביר ואמתו את התוצאה בעצמכם. אשף DNS של TrekMail עשוי להציג אזהרות לפי יכולותיו העדכניות, אך אינו מחליף בדיקה מלאה.

3. מגבלת חיפושים ללא תוצאה

RFC 7208 ממליץ להגביל void lookups ל-2 חיפושים ללא תוצאה, כגון NXDOMAIN או תשובה ללא נתונים רלוונטיים. זו מגבלה נפרדת שיכולה להיות ניתנת להגדרה במימוש.

טעות כמו include:spf.trekmaill.net, עם l נוספת, עשויה להחזיר תשובה ריקה: void lookup של 1. שתי תשובות ריקות אינן עוברות עדיין את הגבול המומלץ; חריגה עשויה להפיק PermError. אך יעד include ללא SPF שימושי יכול לגרום לשגיאה נפרדת מוקדם יותר.

בדקו גם תשובות DNS עדכניות. בודק תחביר לבדו אינו מגלה כל שגיאת הערכה או יעד ריק.

4. ניתוח כותרות של הודעה אמיתית

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

spf=pass (google.com: domain of user@yourdomain.com designates 192.0.2.1 as permitted sender)

spf=neutral או spf=softfail מצדיקים בדיקת מדיניות, דומיין מעטפת וכתובת שליחה, אך אינם תמיד שגיאת הגדרה. בדקו גם DKIM ויישור DMARC. ראו בדיקת מצב DNS להנחיות נוספות.

תקלות נפוצות

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

1. SPF בעת העברה

SPF מעריך כתובת שליחה עבור זהות מעטפת, ולכן העברה מסורתית יכולה להיתקל בקושי.

Alice שולחת ל-Bob, והוא מעביר ל-Charlie. אם שולח המעטפת המקורי נשמר, Charlie רואה את כתובת השרת של Bob בזמן בדיקת מדיניות הדומיין המקורי. הבדיקה יכולה להיכשל גם עבור דואר לגיטימי, לפי התצורה.

SPF לבדו אינו פותר את כל ההעברות. DKIM יכול להישאר תקין אם הכותרות והגוף החתומים נשמרים לפי הקנוניזציה ותנאי המפתח. DMARC דורש גם יישור. SRS יכול לשכתב מעטפת עבור SPF של המעביר, בלי לשחזר את יישור From המקורי.

ראו את מדריך העברת דואר דומיין ויכולת מסירה להסבר ההבדלים. אף מסלול אינו מבטיח הגעה לתיבה.

2. מנגנון ptr

בתחילת שנות 2000 היה ptr, המבוסס על DNS הפוך, נפוץ יותר:

v=spf1 ptr -all

RFC ממליץ לא להשתמש ב-ptr בגלל אמינות ועומס DNS, אך אינו מסיר אותו מהתחביר. מדיניות מקבלים משתנה; אין כלל שכל רשומה כזאת נענשת או מתעלמים ממנה. החליפו הרשאות ptr קיימות לאחר מיפוי ובדיקות. זה נפרד מחשיבות רשומות PTR לתשתית שרת דואר.

3. הסיכון ב-+all

זו דוגמה לא בטוחה; אל תפרסמו את ערכי הספק בלי בדיקה:

v=spf1 include:spf.google.com +all

משמעות המסייגים:

• -all = fail לכתובות שלא התאימו קודם, לא הוראת דחייה אוטומטית
• ~all = softfail לכתובות שלא התאימו קודם, לא הבטחת קבלה או סימון
• +all = pass לכל כתובת שמגיעה למנגנון

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

4. Return-Path אצל שירותי שליחה חיצוניים

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

בדקו תמיכה של ה-ESP בתת-דומיין Return-Path משלכם, למשל bounce.yourcompany.com, והגדירו את DNS הנדרש. ראו יישור DMARC ומוניטין דומיין.

כלי יצירה: תועלת וזהירות

כלי יצירת SPF שונים באיכותם וביכולותיהם. הם יכולים לעזור, אך כל פלט דורש בדיקה לפני פרסום.

כלים שימושיים

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

בודקי תחביר יכולים למצוא נקודתיים חסרות ותווים לא חוקיים. חיפושים ריקים דורשים גם בדיקת DNS; אמתו את היקף הכלי בכל שינוי.

מקומות הדורשים זהירות

לא כל אשף בלחיצה אחת משתמש באותה ברירת מחדל. ?all מפיק neutral לכתובות שלא התאימו קודם. בחרו מדיניות לאחר מיפוי שולחים; -all ו-~all מפיקים תוצאות שונות אך אינם מבטיחים מסירה.

כלי פיצול מחרוזות: גבול מחרוזת DNS TXT הוא 255 אוקטטים, לא בהכרח אותו מספר תווי Unicode. SPF ארוך יכול להיפצל לכמה מחרוזות ברשומת TXT אחת, לא לשתי רשומות מדיניות נפרדות:

• מבנה תקין: "v=spf1 include:a..." "include:b... -all" (שתי מחרוזות, רשומה אחת; דוגמה סכמטית שיש להוסיף בה רווח גבול מתאים בשימוש אמיתי)
• שגוי: שתי רשומות SPF TXT נפרדות גורמות ל-PermError בבחירה

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

לדיון נוסף בכלים ראו מדריך כלי יצירת SPF והגדרתו.

איחוד הגדרות ב-TrekMail

חבילות גדולות אינן בהכרח מוצרים גרועים. הן מאגדות שירותים וגובות לעיתים לפי משתמש. התאמת השירותים הכלולים תלויה בצורכי הלקוח ובחוזים הנוכחיים.

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

v=spf1 include:spf.trekmail.net -all

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

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

בעת העברה, סקירת העברת IMAP ומדריך רשומות DNS נדרשות מסייעים לתכנן ולבדוק נתוני תיבות ואת MX, SPF, DKIM ו-DMARC בנפרד. IMAP אינו מעביר DNS או הגדרות יישומים, ו-MX עוסק בעיקר בניתוב נכנס. תכננו מעבר לאחר אימות ובדיקות סנכרון; בדקו את יכולות לוח הבקרה העדכניות בייבוא דומיינים בכמות.

ניהול SPF לאורך זמן

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

הבדיקות העיקריות:

1. בדקו מדיניות. הריצו dig +short txt yourdomain.com וספרו רק רשומות SPF שנבחרות, לא כל TXT. יותר ממדיניות אחת באותו שם גורמת ל-PermError.
2. אחדו הרשאות מתאימות. השתמשו ברשומת SPF TXT אחת לשירותים שבאמת שולחים עם אותו דומיין מעטפת.
3. העריכו תקציב DNS. אם המסלול עובר 10 רכיבים, בחנו פישוט או תת-דומייני מעטפת אמיתיים. השטחה מחייבת תחזוקה אמינה.
4. בחרו -all במודע. שקלו מעבר מ-~all לאחר מיפוי ובדיקות. טפלו ב-+all בעדיפות עם שינוי בטוח; המקבל עדיין מחליט.
5. בדקו יישור Return-Path. בחנו דומיין החזרות משלכם הנתמך ב-Mailchimp או HubSpot, וגם DKIM תקין ומיושר לצורך DMARC.
6. אל תעצרו ב-SPF. העברה יכולה להכשיל SPF ושינויים יכולים לפגוע גם ב-DKIM. הגדירו את שלושתם: SPF, DKIM ו-DMARC, ובדקו מסלולים אמיתיים.

רשומת SPF בת 50 בתים היא המחשה, לא גודל קבוע. תצורה תקינה מסייעת לצמצם סיכונים ליחסי לקוחות. בדקו בכל שינוי בשליחה וגם בקביעות; בדיקה שנתית בלבד עשויה לא להספיק.

ארגנו את ניהול DNS. בדקו את ההצעה החינמית של TrekMail ואת המחירים, התנאים והיקף התמיכה העדכניים ב-SPF, DKIM ו-DMARC.