הגדרת רשומת SPF: מדריך שלבים ובדיקה

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

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

המדריך מכסה את תחביר SPF, דוגמאות לתצורות TrekMail עם Managed SMTP או BYO, פרסום ב-DNS ובדיקה בשורת הפקודה. אם עדיין לא הגדרתם דואר לדומיין, התחילו בהגדרת דואר בדומיין שלכם, ואז חזרו להוספת שכבת האימות.

מה SPF עושה

SPF, קיצור של Sender Policy Framework, מפרסם ברשומת DNS מסוג TXT אילו שרתים מורשים לשלוח באמצעות זהות של דומיין מסוים. השרת המקבל משווה את כתובת ה-IP של השולח למדיניות הזאת. התוצאה תלויה במנגנונים ובמסייגים התואמים, והמקבל מחליט כיצד לטפל בהודעה לפי מדיניותו. לפי RFC 7208, SPF בודק את זהות MAIL FROM, כלומר שולח המעטפת, וגם HELO כאשר זה רלוונטי, ולא את כותרת From שהנמען רואה.

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

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

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

שגוי: שתי רשומות נפרדות	נכון: רשומה אחת ממוזגת
`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`

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

שלב 1: מיפוי כל השירותים ששולחים באמצעות הדומיין

לפני שינוי DNS, רשמו את כל השירותים ששולחים בשם @yourdomain.com ובדקו את שולח המעטפת בפועל. שירות שנשכח עשוי לקבל תוצאת SPF fail לאחר החלת רשומה עם -all. ההחלטה אם לדחות את ההודעה נתונה למקבל. ההשוואה בין חמש דקות מיפוי לשעות של אבחון היא המחשה, לא הבטחה למשך העבודה; היקף הבדיקה תלוי בתצורה שלכם.

בדקו בין היתר את השירותים הבאים:

דואר ארגוני: TrekMail, Google Workspace, Microsoft 365
הודעות תפעוליות: Amazon SES, SendGrid, Mailgun, Postmark
שיווק: Mailchimp, HubSpot, Klaviyo, Brevo
כלי SaaS: Zendesk, Freshdesk, Shopify, Intercom

חלק מהשירותים משתמשים בדומיין return-path משלהם, כגון bounce.mailchimp.com. במקרה כזה בדיקת SPF מתבצעת עבור אותו דומיין, ולכן אין צורך אוטומטי להוסיף את השירות לרשומה שלכם. אם השירות מוגדר להשתמש בדומיין שלכם לצורך יישור DMARC, המצב עשוי להיות שונה. בדקו את תיעוד הספק ואת שולח המעטפת בפועל לפני השמטת שירות.

שלב 2: בניית רשומת SPF

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

רכיב	דוגמה	תפקיד
גרסה	`v=spf1`	חובה. כל רשומת SPF מתחילה בערך הזה.
include	`include:domain.com`	מעריך את מדיניות SPF של ספק דרך DNS. נספר במגבלת 10 הרכיבים שמחייבים שאילתות DNS.
ip4	`ip4:203.0.113.0/24`	מאשר ישירות כתובת IPv4 או טווח CIDR, בלי צורך בשאילתת DNS.
ip6	`ip6:2001:db8::/32`	אותו עיקרון עבור IPv6.
-all	`-all`	מחזיר fail לשולח שאינו תואם. המקבל קובע את הטיפול בפועל. מתאים לשקילה לאחר אימות כל השולחים הלגיטימיים.
~all	`~all`	מחזיר softfail לשולח שלא נכלל. אינו מבטיח מסירה, ויכול לשמש בתקופת מעבר מבוקרת.

שלב 3: הגדרת SPF לפי ספק

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

תרחיש A: TrekMail Managed SMTP במסלולי Starter ו-Agency

אם Managed SMTP זמין ופעיל במסלול הנוכחי שלכם, ו-TrekMail הוא שירות השליחה היחיד, הדוגמה הבאה יכולה לשמש בסיס. בדקו את הוראות DNS העדכניות בחשבון:

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

TrekMail מנהל את כתובות ה-IP המשויכות למסלול השליחה הזה. יש לכלול גם שירותי שליחה מורשים נוספים, אם קיימים.

תרחיש B: TrekMail BYO SMTP עם תצורת שליחה משלכם

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

# Amazon SES
v=spf1 include:amazonses.com -all

# SendGrid
v=spf1 include:sendgrid.net -all

תרחיש C: Google Workspace

v=spf1 include:_spf.google.com -all

תרחיש D: Microsoft 365

v=spf1 include:spf.protection.outlook.com -all

תרחיש E: שילוב TrekMail ופלטפורמת שיווק

משתמשים ב-TrekMail לדואר הצוות וב-HubSpot לקמפיינים? מזגו את הרכיבים הדרושים לרשומה אחת. בדוגמה הבאה ערך HubSpot הוא ערך המחשה ייעודי לחשבון:

v=spf1 include:spf.trekmail.net include:456789.spf05.hubspotemail.net -all

ערך include של HubSpot ייחודי לפורטל שלכם. העתיקו את הערך שלכם ממסך הגדרות DNS ב-HubSpot, ולא ממדריך כללי.

שלב 4: פרסום ב-DNS

פרסמו את מדיניות SPF כרשומת TXT אצל ספק DNS של הדומיין. התחברו ל-Cloudflare, ל-Namecheap, ל-GoDaddy, ל-Route 53 או לשירות שמנהל את DNS בפועל. אם כבר קיימת רשומת SPF, ערכו אותה.

סוג: TXT
מארח/שם: @, או השאירו ריק בהתאם לספק ולדומיין המיועד
ערך: מחרוזת SPF המלאה, למשל v=spf1 include:spf.trekmail.net -all
TTL: 3600 שניות (1 שעה)

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

שלב 5: בדיקת רשומת SPF

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

# Mac, Linux, or Windows PowerShell
nslookup -q=txt yourdomain.com

# Linux/Mac alternative
dig txt yourdomain.com +short

בדקו את שלוש הנקודות הבאות:

קיימת בדיוק רשומת SPF אחת שמתחילה ב-v=spf1
כל מנגנוני include הדרושים מופיעים
הרשומה מסתיימת ב--all או ב-~all, בהתאם למדיניות שבחרתם

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

פתרון תקלות SPF נפוצות

תקלות רבות בהגדרת SPF משתייכות לשלוש הקטגוריות הבאות. השתמשו בהודעת השגיאה המלאה, בתוצאות האימות ובבדיקת DNS כדי לזהות את הגורם.

1. מגבלת 10 הרכיבים המחייבים שאילתות DNS, PermError

SPF מאפשר במהלך ההערכה עד 10 רכיבים שמחייבים שאילתות DNS. אלה כוללים בין היתר include, a, mx, ptr, exists ו-redirect. גם רכיבים בהערכות מקוננות נספרים; זו אינה פשוט מגבלה על מספר חבילות DNS. חריגה מעבר ל-10 מובילה ל-PermError, והמקבל עשוי לדחות הודעות בעקבותיה.

תסמין: כלי הבדיקה מציג PermError או "too many DNS lookups".

פתרון: שקלו להעביר שירותים כגון Mailchimp או Zendesk לתת-דומיין כמו support.yourdomain.com. לתת-הדומיין יש תקציב נפרד של 10 רכיבים המחייבים שאילתות DNS. יש להגדיר גם את זהות MAIL FROM או return-path בפועל לשימוש בתת-הדומיין ולבדוק יישור DMARC. יצירת רשומת TXT נפרדת בלבד אינה מעבירה את בדיקת SPF לתת-הדומיין.

2. תיבות צרכניות של Microsoft, 550 5.7.515

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

3. SoftFail עם ~all לעומת HardFail עם -all

מסייג	המסר למקבל	מתי להשתמש
`~all` (SoftFail)	מחזיר softfail לשולח שאינו תואם; המקבל מחליט אם למסור.	במעבר מבוקר ובמהלך מיפוי השולחים, למשל 2 עד 4 שבועות אם זה מתאים לתהליך.
`-all` (HardFail)	מחזיר fail לשולח שאינו תואם; אינו מבטיח דחייה אוטומטית.	לאחר אישור כל השולחים הלגיטימיים ובדיקה שהמדיניות מתאימה לתפעול.

~all מחזיר SoftFail, ואילו ?all מחזיר Neutral: זו אינה תוצאת SPF fail שלילית, אלא הימנעות מקביעה אם השולח מורשה. עם זאת, SPF לבדו אינו מונע זיוף של כתובת השולח הגלויה. לאחר בדיקת כל השולחים, אפשר לשקול מעבר ל--all לצד DKIM ו-DMARC.

הגדרת SPF עם TrekMail

ניהול DNS וניתוח שגיאות SMTP דורשים זמן. אם אשף SPF, DKIM ו-DMARC זמין בחשבון הנוכחי שלכם, הוא יכול לסייע בבחירת הגדרה מתאימה ל-Managed SMTP או ל-BYO. בדיקת DNS משווה רשומות לערכים הצפויים; היא אינה מוכיחה חתימה תקפה של הודעה, יישור DMARC או הגעה לתיבה הנכנסת. בדקו ערכים והודעות אמיתיות מול התצורה שלכם.

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

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