רשומת SPF לדוא״ל: הגדרה ובדיקה לדומיין עסקי

הודעת הדוא"ל שלך חזרה. היא לא הועברה לספאם, אלא נדחתה בקבלה. השרת החזיר 550 5.7.26 או 550 5.7.515, וההודעה לא המשיכה ליעדה. הסיבה עשויה להיות רשומת SPF לדוא"ל חסרה או מבנה שגוי של הרשומה הקיימת. עם זאת, הקודים האלה אינם מוכיחים ש-SPF הוא הגורם היחיד. יש לבדוק גם את הודעת השגיאה המלאה ואת תוצאות האימות האחרות.

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

Google: 550 5.7.26 - דוא"ל שלא אומת אינו מתקבל

Microsoft: 550 5.7.515 - זהות השולח לא אומתה

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

מהי רשומת SPF לדוא"ל?

רשומת SPF היא רשומת TXT ב-DNS שמגדירה אילו שרתי דואר רשאים לשלוח בשם הדומיין שלך. כשהודעה מגיעה ל-Gmail או ל-Outlook, השרת המקבל מאתר את הרשומה ומשווה את כתובת ה-IP השולחת למקורות המורשים. התאמה מחזירה בדרך כלל pass; ללא התאמה, הכללים הבאים קובעים את תוצאת SPF. התוצאה אינה כשלעצמה החלטה למסור או לדחות את ההודעה.

SPF בודק את מעטפת SMTP, כלומר את הדומיין שב-MAIL FROM, ולא את כתובת השולח הגלויה בשדה "מאת" בתיבת הדואר של הנמען. רשומת TXT מתפרסמת בדומיין המעטפת הנבדק; בדומיין הראשי נהוג להשתמש בשם @. להבנת הקשר בין רכיבי DNS, המדריך הגדרת דוא"ל בדומיין שלך מסביר את התהליך המלא מההתחלה.

הכלל: רשומת SPF אחת

מפרט SPF, שהוא RFC 7208, מתיר לכל דומיין רשומת TXT אחת בלבד שמתחילה ב-v=spf1. אם השרת המקבל מוצא שתי רשומות SPF בדומיין הנבדק, תוצאת הבדיקה היא PermError. עד לתיקון הכפילות אי אפשר להשלים הערכת SPF תקינה. השאלה אם הודעות יידחו תלויה במדיניות הקבלה ובאימותים האחרים.

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

לפני כל שינוי, בדקו מה כבר מפורסם בדומיין:

dig +short txt yourdomain.com

ספרו את השורות שמתחילות ב-v=spf1. אם יש שתיים, זו סיבה ל-PermError. תקנו קודם את הכפילות, לפני בדיקת בעיות SPF נוספות.

לא תקין - שתי רשומות גורמות ל-PermError בבדיקת הדומיין הזה:

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

תקין - מאחדים אותן לרשומת SPF אחת לדוא"ל:

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

רשומת SPF לדוא"ל: הגדרה מעשית מינימלית

התוכן המדויק תלוי בשרתים שבאמת שולחים את הדואר שלך. יש לאשר רק מקורות שנמצאים בשימוש. כל include: נוסף צורך חלק ממכסת ההערכה ועשוי לאשר טווחי IP שאינם בשליטתך.

תרחיש A: SMTP מנוהל של TrekMail (מסלולי Starter ו-Agency)

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

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

תרחיש B: המסלול החינמי של TrekMail (ספק SMTP משלך)

אם ההצעה הנוכחית של מסלול Nano תומכת בכך, אפשר לחבר ספק SMTP משלך, כגון Amazon SES, SendGrid או Mailgun. יש לאשר את כתובות ה-IP שלו, לא את אלה של TrekMail:

v=spf1 include:amazonses.com -all

החליפו את include:amazonses.com בערך שהספק מציין בתיעוד שלו. אל תאשרו טווחי IP שאינם בשימוש.

תרחיש C: תצורה משולבת - TrekMail + Google Workspace

עוברים מ-Google או משתמשים בשני שירותי שליחה בזמן המעבר? שלבו אותם ברשומה אחת:

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

רכיבי הרשומה

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

המגבלה של 10 רכיבים הקשורים ל-DNS

מפרט SPF (RFC 7208) מגביל ל-10 את מספר הרכיבים הקשורים ל-DNS שמופעלים במהלך הערכה. זו אינה ספירה של כל שאילתות DNS הבודדות. include:, a, mx והמשנה redirect נספרים, לרבות רכיבים רלוונטיים שמופעלים ברשומות מקוננות. ip4: ו-ip6: אינם נספרים. חריגה מ-10 מחזירה תוצאת SPF מסוג PermError.

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

מה נספר במסגרת המגבלה:

• include: וגם הפניות include מקוננות שמופעלות בתוכו
• a, mx, redirect

מה לא נספר:

• ip4: ו-ip6: - כתובות IP ישירות אינן משתמשות בשרשרת החיפוש הזו
• all

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

dig +short txt yourdomain.com

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

אימות רשומת SPF לדוא"ל

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

1. שלחו הודעה מהדומיין שלכם לחשבון Gmail שבשליטתכם.
2. פתחו את ההודעה ב-Gmail.
3. לחצו על תפריט שלוש הנקודות → הצגת המקור.
4. חפשו Authentication-Results.

כך נראית תוצאה שעוברת את הבדיקה:

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

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

טעויות SPF נפוצות

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

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

ניהול רשומות SPF לדוא"ל בכמה דומיינים

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

לסוכנויות ולספקי שירותים מנוהלים, אחידות בהגדרות יכולה לעזור. אם התכונות כלולות במסלול הנוכחי, לוח הניהול הרב-דומייני ואשף SPF/DKIM/DMARC של TrekMail מאפשרים להחיל הגדרות עקביות. בהתאם להצעה ולתנאים החלים, מסלולים בתשלום מתחילים ב-$3.50 לחודש ועשויים לכלול שליחת SMTP מנוהלת. ב-מסלול Nano, כשהאפשרות נתמכת, משתמשים בספק SMTP משלכם ומנהלים את מוניטין ה-IP של מסלול השליחה. זה עשוי להתאים לחשבונות SES או Mailgun שכבר נבנה להם מוניטין שליחה טוב ויש להם מכסות גבוהות.

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

רשומת SPF לדוא"ל: רשימת בדיקה לפני פרסום

לפני פרסום רשומת SPF, עברו על הרשימה לפי הסדר:

1. בדקו רשומות קיימות: dig +short txt yourdomain.com - רק שורה אחת שמתחילה ב-v=spf1.
2. מפו כל שירות ששולח בשם הדומיין, כולל הודעות תפעוליות, שיווק וכלי תמיכה.
3. כתבו רשומה אחת שמכסה את כולם. איחוד, לא הוספת רשומות נפרדות.
4. השתמשו ב--all לאחר מיפוי מלא; בחרו ב-~all במודע בזמן מעבר והימנעו מ-+all.
5. ספרו את הרכיבים הקשורים ל-DNS שמופעלים והישארו במסגרת המגבלה של 10.
6. פרסמו רשומת TXT בדומיין המעטפת; לדומיין הראשי השתמשו ב-@.
7. שלחו הודעת בדיקה ל-Gmail ובדקו תחת הצגת המקור אם מופיע spf=pass.

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

רשומת SPF נכונה מספקת בסיס טוב. יש לבדוק אותה שוב כשספקי השליחה או טווחי ה-IP שלהם משתנים. הגדרה שגויה עלולה להוביל לאבחון יומני החזרות ולהפרעה בדוא"ל העסקי. נסו את TrekMail בחינם אם הצעת Nano הנוכחית זמינה ללא כרטיס אשראי. לפי התנאים החלים, המסלולים בתשלום מתחילים ב-$3.50 לחודש ועשויים לכלול תקופת ניסיון חינמית של 14 ימים; בדקו את ההצעה העדכנית.