כשל SPF: קודי שגיאה, סיבות ותיקון רשומות DNS

האימייל שלכם חזר. בכותרות מופיע spf=fail. מולכם שגיאת 550 5.7.1 או 550 5.7.26, ולקוח ממתין לתשובה שמעולם לא הגיעה.

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

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

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

מהו כשל SPF?

כשל SPF מתרחש כאשר שרת הדואר המקבל בודק את רשומת Sender Policy Framework של הדומיין ומגלה שכתובת ה-IP השולחת אינה מורשית. SPF מפורסם כרשומת DNS TXT בדומיין ומפרט כל כתובת IP ושירות דואר שרשאים לשלוח בשמכם. כשהבדיקה נכשלת, השרת דוחה את ההודעה מיד (hard fail) או מקבל אותה כחשודה (soft fail). בשני המקרים מדיניות DMARC סופרת זאת ככשל.

SPF בודק את שולח המעטפה, כתובת MAIL FROM שסוכמה במהלך לחיצת היד של SMTP, ולא את כותרת "From" הידידותית שהנמען רואה. ההבדל חשוב כשמאתרים את נקודת הכשל.

קראו את קוד השגיאה לפני כל שינוי

שרתי דואר שונים מחזירים קודי SMTP שונים לכשל SPF. הקוד מלמד מה החליטה המקבלת ומדוע; טיפול ב-550 5.7.26 כמו בקוד כללי 550 5.7.1 מבזבז זמן אבחון. התאימו את הקוד לסיבה לפני שינוי רשומת DNS כלשהי.

שלב 1: מצאו בכותרות את כתובת ה-IP שנכשלה

אל תנחשו איזו כתובת IP גרמה לכשל. פתחו את הכותרות הגולמיות של ההודעה שחזרה או של הודעת ההחזרה וחפשו Authentication-Results. הכותרת מציגה את כתובת ה-IP המדויקת שהמקבלת בדקה ואת החלטתה.

Authentication-Results: mx.google.com;
   spf=fail (google.com: domain of team@example.com does not designate
   192.0.2.55 as permitted sender)

שני פרטי החקירה נמצאים שם: כתובת ה-IP השולחת (192.0.2.55) והדומיין שנבדק (example.com). כעת זהו למי שייכת הכתובת:

• כלי SaaS שהוספתם לאחרונה? (HubSpot, Zendesk, Shopify)
• שרת האינטרנט? (WordPress, cPanel)
• שירות העברת דואר? (ראו את סעיף מלכודת ההעברה בהמשך)

לאחר מכן בדקו את רשומת ה-SPF הנוכחית בחיפוש מהיר:

dig +short txt yourdomain.com | grep spf

אם מופיעה יותר משורה אחת שמתחילה ב-v=spf1, כבר מצאתם אחת מהבעיות.

שלב 2: שלושת התיקונים הנפוצים לכשל SPF

רוב מקרי הכשל נובעים מאחת משלוש סיבות: include חסר של ספק, רשומה כפולה או חריגה ממגבלת 10 בדיקות DNS. בחרו בתיקון שמתאים לממצא משלב 1.

תיקון 1: Include חסר (פער בספק)

הוספתם כלי אימייל חדש - HelpScout,‏ HubSpot,‏ Zendesk או אימייל תפעולי של Shopify - אך לא עדכנתם את ה-DNS. השירות שולח בשמכם מכתובת IP שלא הרשיתם. זו סיבה נפוצה במיוחד לכשל SPF אחרי צירוף ספק חדש.

רשומה שנכשלת:

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

רשומה שעוברת (לאחר הוספת HelpScout):

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

מצאו בתיעוד הספק את מחרוזת ה-SPF include הדרושה. הוסיפו אותה לרשומת SPF TXT הקיימת ואל תיצרו רשומה חדשה. כל שירות שדרכו אתם שולחים חייב להופיע.

תיקון 2: רשומה כפולה (שגיאת תחביר מכרעת)

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

שגוי - שתי רשומות נפרדות:

v=spf1 include:spf.trekmail.net -all
v=spf1 include:_spf.google.com -all

נכון - מיזוג לרשומה אחת:

v=spf1 include:spf.trekmail.net include:_spf.google.com -all

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

תיקון 3: מגבלת 10 בדיקות (כשל ארכיטקטורה)

RFC 7208 מגביל בדיקת SPF ל-10 בדיקות DNS, כדי למנוע שימוש בשרתים להגברת DNS. מנגנונים כמו include,‏ a ו-mx נספרים במגבלה, וגם include מקונן שבו הספק כולל רשומה של ספק אחר.

חריגה מ-10 בדיקות יוצרת PermError ו-SPF נכשל לכולם. עקבו אחר הרשומה כדי לבדוק את המספר הנוכחי:

dig +short txt yourdomain.com

ספרו ידנית כל מנגנון include,‏ a ו-mx, ולאחר מכן עקבו אחר ה-include המקוננים של כל ספק. אם עברתם את המגבלה, יש שתי דרכים נקיות:

1. פצלו שולחים לתת-דומיינים. העבירו כלי שיווק בנפח גבוה אל marketing.yourdomain.com. תת-הדומיין מקבל תקציב חדש של 10 בדיקות, נפרד לחלוטין מרשומת הדומיין הראשי.
2. שטחו את הרשומה. החליפו שרשראות include בכתובות ה-IP שאליהן הן נפתרות, באמצעות ip4: או ip6:. אלה אינן נספרות כבדיקות. החיסרון הוא צורך בעדכון ידני כשהספקים מחליפים כתובות IP.

יש מלכודת נוספת: מגבלת בדיקות ריקות. אם יותר משתי בדיקות בשרשרת מחזירות NXDOMAIN - למשל בגלל טעות כמו include:spf.gogle.com - הרשומה נפסלת לפי RFC 7208 §11.1. טעות אחת ב-include מקונן כלשהו עלולה להכשיל את כל בדיקת SPF.

מלכודת ההעברה: מדוע SPF נכשל בדואר לגיטימי

הנה כשל SPF שאינו קשור לתצורת ה-DNS. אתם שולחים אימייל לכתובת בוגרים (alice@university.edu) שמעבירה אוטומטית ל-Gmail (alice@gmail.com). Gmail רואה את האימייל מגיע מכתובת ה-IP של שרת האוניברסיטה. רשומת ה-SPF שלכם אינה מרשה את הכתובת ולכן הבדיקה נכשלת, אף שהגדרתם הכול נכון.

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

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

אם אתם מפעילים העברה ברמת התשתית ורוצים שכתוב תואם SPF, כדאי להבין את Sender Rewriting Scheme (SRS). כך מתווכים יכולים לשכתב את שולח המעטפה כדי ש-SPF יעבור ביעד הסופי. לכשלי מסירה רחבים יותר, המדריך להגדרה ותיקון של העברת אימייל מפרט את מסלול האבחון המלא.

אמתו את התיקון לפני שממשיכים

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

שלחו אימייל בדיקה לכתובת Gmail ופתחו את הכותרות הגולמיות. חפשו Authentication-Results. זו התוצאה הרצויה:

Authentication-Results: mx.google.com;
   spf=pass (google.com: domain of team@example.com designates
   192.0.2.55 as permitted sender)

אם עדיין מופיע spf=fail או spf=softfail, התיקון טרם הופץ או שנותרה בעיה ברשומה. השוו את ה-IP בכותרות לרשומה המעודכנת. הם צריכים להתאים.

אפשר גם לבדוק את הרשומה ישירות:

dig +short txt yourdomain.com

ודאו שקיימת בדיוק רשומה אחת שמתחילה ב-v=spf1, שכל שירותי השליחה כלולים ושהרשומה מסתיימת ב--all (hard fail) או ~all (soft fail).

ניהול SPF במספר דומיינים

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

ה-SMTP המנוהל של TrekMail - זמין ב-Starter במחיר $3.50/חודש ומעלה - מצמצם את התצורה ל-include אחד בכל דומיין. TrekMail מנהלת החלפת IP, ניטור החזרות, יישור DKIM ותשתית המסירה. סוכנויות בתוכנית Agency ($23.25/חודש) יכולות להחיל תבנית DNS אחידה על כל דומייני הלקוחות במקום לרדוף אחר כשלים במאות רשומות.

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

כשל SPF: הגרסה הקצרה

כשל SPF פירושו שהשרת המקבל בדק את ה-DNS, מצא שה-IP השולח אינו רשום ואכף את המדיניות. Hard fail (-all) פירושו דחייה. Soft fail (~all) פירושו תיקיית ספאם. PermError פירושו שהרשומה פגומה וש-SPF נכשל לכל שולח עד לתיקון הרשומה.

בצעו את התיקונים לפי הסדר:

1. מצאו את כתובת ה-IP שנכשלה בכותרת Authentication-Results
2. הוסיפו את ה-include החסר של הספק אם שירות חדש גרם לכשל
3. מזגו רשומות SPF כפולות לרשומה אחת
4. הפחיתו את בדיקות ה-DNS אל מתחת ל-10 או פצלו שולחים בנפח גבוה לתת-דומיינים
5. אם SPF נכשל בדואר מועבר, הטמיעו DKIM. ‏SPF אינו שורד תחנת ממסר

בחרו קודם בתיקון הנכון, אמתו אותו בכותרות וסיימתם.