הגדרת SPF עובדת היטב עם שולח אחד. לאחר שמוסיפים Google Workspace, Mailchimp, Zendesk וממשק תפעולי, Microsoft עשויה להחזיר דואר עם 550 5.7.515. הרשומה חרגה ממגבלת 10 השאילתות, ואימות של הודעות יוצאות עלול להיכשל בלי התראה ברורה.
זו המלכודת. ל-SPF יש תקרה קשיחה בפרוטוקול, וצוותים עשויים להגיע אליה עם שירות השליחה השלישי או הרביעי. הפתרון הרגיל, הוספת include: נוספת, כבר אינו עובד. לתחביר הבסיסי עיינו במדריך רשומת SPF לדוא״ל. כאן נתמקד במבנה לכמה שולחים, בשינויי ספקים ובצמצום שכתובים חוזרים.
למה SPF נשבר עם כמה שולחים
RFC 7208 מגביל בדיקת SPF ל-10 שאילתות DNS לרשומה. המנגנונים include, a, mx, exists ו-redirect נספרים גם באופן רקורסיבי. אם include של ספק מפנה לעוד שלושה, כולם צורכים מהמכסה. ב-11 מתקבלת PermError והדואר עלול להידחות.
הדפוס קבוע. מתחילים עם שתי הפניות, השיווק מוסיף HubSpot, התמיכה Freshdesk והפיתוח SendGrid. השרשראות עמוקות מהצפוי, מגיעים ל-12 ו-Google עשויה להחזיר 550 5.7.26.
| מנגנון | צורך שאילתה? | הערה למפעיל |
|---|---|---|
include: | כן, כולל המקוננות | מקובל לספקים, אך השרשרת עשויה להשתנות |
ip4: / ip6: | לא | מתאים לשולח קבוע שבשליטתכם |
mx | כן | לעיתים מיותר; החליפו ב-ip4 כשאפשר |
a | כן | לא יעיל ל-SPF; עדיף ip4 |
ptr | כן | מיושן; אין להשתמש בו |
redirect | כן | מעביר את הבדיקה לרשומה של דומיין אחר |
-all / ~all | לא | מסיים את המדיניות; כללו אחד |
החשבון פשוט אך נסתר עד לתקלה. לכן SPF לכמה שולחים מתחיל בתכנון ולא בהעתקה.
בדקו את רשומת SPF לפני שמוסיפים דבר
ראשית הסירו מה שכבר אינו נחוץ. דומיינים רבים שומרים includes משירותים שבוטלו מזמן, וכל אחד מבזבז מכסה. מנקים ואז בונים.
בדקו מה פורסם בפועל:
dig txt yourdomain.com +shortלאחר מכן עקבו אחר עומק כל include:
dig txt _spf.google.com +short
dig txt spf.protection.outlook.com +shortהשוו לדוחות DMARC המצטברים. אם אין תעבורה מכתובות הספק, ודאו שהשירות אינו בשימוש לפני ההסרה.
שלושה שיפורים מהירים:
- החליפו
mxבכתובת הקבועה באמצעותip4:אם היא בשליטתכם, וכך תחסכו שאילתה. - הסירו includes של שירותים שאינם בשימוש.
- בדקו כפילויות. שתי רשומות TXT שמתחילות ב-
v=spf1באותו דומיין גורמות מיד ל-PermError.
כך מתפנות לעיתים 2-3 שאילתות. עיינו במדריך להגדרת רשומת SPF.
חלוקה לתת דומיינים: מבנה SPF שניתן להרחיב
חלוקה לתת דומיינים היא דרך אמינה לנהל כמה שולחים במסגרת מגבלת 10. SPF נבדק מול דומיין Return-Path ולא מול כותרת From הגלויה. העבירו זרמים שאינם דואר ארגוני לתת דומיינים, וכל זרם יקבל מכסה חדשה של 10.
זהו המבנה:
דומיין ראשי: דואר אנושי בלבד
השאירו את הדומיין הראשי נקי עם ספק התיבות העיקרי בלבד.
v=spf1 include:spf.trekmail.net -allinclude אחד ושאילתה אחת. כלי שיווק חדש אינו משנה את אותה רשומת SPF של דואר ההנהלה.
תת דומיין לשיווק: קמפיינים וניוזלטרים
; news.example.com
v=spf1 include:spf.hubspot.com include:servers.mcsv.net -allHubSpot ו-Mailchimp משתמשים במכסה של news.example.com ולא בזו של הדומיין הראשי. הגבלה שם אינה חייבת לעצור ישירות דואר ארגוני, אם כי אותות מוניטין רחבים עדיין עשויים להשפיע.
תת דומיין לתמיכה: מערכות כרטיסים
; help.example.com
v=spf1 include:mail.zendesk.com -allתת דומיין תפעולי: התראות וקבלות
; alerts.example.com
v=spf1 include:amazonses.com -allכאשר Zendesk שולחת בשם support@help.example.com, המקבל בודק את help.example.com ואינו משתמש ברשומת SPF של הדומיין הראשי. זו מטרת ההפרדה.
| הדרך הישנה | הדרך החדשה |
|---|---|
| כל השולחים ברשומת SPF ראשית אחת | הדומיין הראשי כולל רק את ספק התיבות |
| שינוי אצל ספק עלול לפגוע בכל הדואר | התקלה מוגבלת בעיקר לתת הדומיין |
| מכסה משותפת לכל הזרמים | לכל תת דומיין מכסה של 10 |
| שכתוב SPF עם כל כלי | המבנה עמיד יותר לשינויים |
השטחת SPF: מוצא אחרון
אם כל הדואר חייב לצאת מהדומיין החשוף ואי אפשר להשתמש בתתי דומיינים, ניתן לשקול השטחה. היא ממירה includes לכתובות IP בתוך ip4:, שאינן צורכות שאילתות. הפתרון עובד אך דורש תחזוקה.
ספקי SaaS משנים טווחי IP. אם SendGrid מוסיפה מחר טווח והרשומה נשארת עם כתובות האתמול, SPF עלול להיכשל. אל תשטיחו ידנית ללא בדיקה תכופה. בעת הצורך השתמשו בשירות SPF דינמי אמין שמנטר שינויים ומעדכן TXT בצורה מבוקרת.
השטחה היא מעקף ולא תכנון אידיאלי. העדיפו חלוקה לתת דומיינים כשאפשר.
אימות שהגדרת SPF עובדת
אחרי כל שינוי בדקו ישירות מה DNS ציבורי מחזיר. אל תסתמכו רק על לוחות של רשם או ספק. לכל שם מארח צריכה להיות בדיוק רשומת SPF תקפה אחת.
# Check the root record
dig txt example.com +short
# Check a subdomain
dig txt news.example.com +short
# Verify DMARC while you're at it
dig txt _dmarc.example.com +shortנדרשת רשומת TXT אחת שמתחילה ב-v=spf1 לכל שם מארח, לא שתיים ולא רשומה ישנה ממעבר קודם.
שלחו הודעת בדיקה ל-Gmail, בחרו "הצגת המקור" בתפריט שלוש הנקודות וחפשו:
SPF: PASS with IP [your sending IP]
DKIM: PASS
DMARC: PASSFAIL או SOFTFAIL מחייבות בדיקה לפני שליחה בנפח גבוה. לבעיות מעבר ל-SPF, המדריך לאותות מוניטין השולח מציג את התמונה הרחבה.
איך TrekMail מפשטת SPF בכמה דומיינים
דומיין אחד כבר דורש תשומת לב. 50 דומיינים של לקוחות עם ספקים ומערכות DNS שונים צורכים זמן רב. TrekMail שומרת על טביעת SPF קטנה וצפויה.
ה-include המרכזי הוא include:spf.trekmail.net. בהגדרה הנוכחית הוא צורך שאילתה אחת ללא redirects מקוננים. Microsoft 365 עשויה לצרוך 2-3 שאילתות דרך הפניות פנימיות, ו-Google Workspace עשויה להשתנות. אמתו תמיד מול DNS.
כך ההגדרה נשארת פשוטה ליזם, צוותים מצמצמים טעויות הצטרפות וסוכנויות מקבלות תבנית חוזרת. הוסיפו את TrekMail, הפרידו ספקים אחרים ועקבו אחר הספירה. הסיכון קטן אך אינו נעלם. ראו אחסון דוא״ל לכמה דומיינים.
בודק מצב ה-DNS של TrekMail יכול לסמן התנגשויות SPF במסגרת הבדיקות הנתמכות לפני שהן נראות למשתמשים. להגדרה המלאה ראו רשומות DNS נדרשות.
סיכום: תכננו SPF פעם אחת ונהלו שינויים
SPF טוב מתחיל במבנה. הסירו includes ישנים, חלקו שולחים לתת דומיינים עם 10 שאילתות לכל אחד והשאירו בדומיין הראשי ספק אחד, include אחד ו--all אחד. אמתו באמצעות dig ולא רק בלוחות.
TrekMail מציעה לדומיין אחד או למאה אחסון מרובה דומיינים במחיר קבוע, include קצר, אחסון משותף ובדיקת DNS. לפי התוכניות המתוארות, Nano כוללת 10 דומיינים עם SMTP לבחירתכם, ללא כרטיס ובחינם במסגרת התנאים. Starter מתחילה ב-$3.50 לחודש עם SMTP מנוהל וניסיון של 14 יום המחייב כרטיס. בדקו תוכניות עדכניות בtrekmail.net/pricing.
