העיקרון של מגבלת בדיקות SPF פשוט: אם הערכת מדיניות SPF דורשת יותר מ-10 רכיבים שמפעילים בדיקות DNS, שרת המקבל עשוי לעצור את העיבוד ולהחזיר שגיאה קבועה. לכן דואר שההגדרות שלו נראות תקינות בלוח ניהול ה-DNS עדיין עלול להיכשל באימות בפועל. אם אתם כבר מסדרים את הדואר של הדומיין, התחילו במאמר על דואר עסקי לעסקים קטנים, ואז חזרו לטפל כאן בחלק שלרוב מתחיל להסתבך בהמשך.
זה קורה לצוותים שוב ושוב. מוסיפים Google Workspace, אחריו Microsoft 365, אחריו Mailchimp, מערכת CRM ומערכת תמיכה. כל ספק אומר: ״רק הוסיפו את ה-include שלנו״. כעבור כמה חודשים רשומת SPF תקינה מבחינה תחבירית, אבל עלולה לא לעבוד בהערכה בפועל. הודעות מתחילות להגיע לספאם וחלקן חוזרות לשולח. קשה להבין למה, משום שבמבט ראשון הרשומה עדיין נראית רגילה.
החדשות הטובות: בדרך כלל הפתרון לא מסובך. הסירו רכיבים שאינם בשימוש. אל תשתמשו ב-`mx` אלא אם יש בו צורך אמיתי. העבירו דואר שיווקי לתת-דומיין ושמרו על מדיניות פשוטה בדומיין הראשי.
מהי מגבלת בדיקות SPF?
מגבלת בדיקות SPF היא התקרה שמגדיר ה-RFC לרכיבי SPF שמפעילים DNS במהלך ההערכה. אסור לשרת המקבל לעבד יותר מ-10 רכיבים כאלה לאורך מסלול ההערכה המלא, כולל שרשראות `include` מקוננות. אם המדיניות חורגת מהתקרה, SPF עשוי להחזיר `permerror`, וההודעה מאבדת אות אימות חשוב.
RFC 7208 מגדיר את הכלל. המגבלה נועדה למנוע מ-SPF ליצור תעבורת DNS מופרזת. זו אינה אפשרות לבחירה או המלצה בלבד, אלא מגבלה של הפרוטוקול.
הנקודה שקל לפספס היא שמגבלת בדיקות SPF מצטברת. אין תקציב של 10 בדיקות ברשומה הראשית ועוד 10 בתוך כל include. לכל מסלול ההערכה יש תקציב משותף אחד.
| מנגנון SPF | עלות בדיקות | משמעות מעשית |
|---|---|---|
include: | 1 | נפוץ, אבל רכיבי include מקוננים מצטברים מהר |
a | 1 | עשוי להתאים לתצורות קטנות, אך לעיתים מיותר |
mx | 1+ | לרוב אינו מתאים להרשאת שליחה יוצאת |
ptr | 1+ | עדיף להימנע; RFC 7208 ממליץ בחום שלא להשתמש בו |
exists | 1 | נדיר וקל להגדירו בצורה שגויה |
redirect= | 1 | שימושי בתצורות מסוימות, אך עדיין נספר |
ip4 / ip6 | 0 | ללא בדיקת DNS בזמן הערכת SPF |
all | 0 | קביעת מדיניות בלבד, בלי עלות בדיקה |
למה מגבלת בדיקות SPF פוגעת ברשומות שנראות תקינות?
מגבלת בדיקות SPF עלולה לפגוע ברשומות שנראות מסודרות, משום ש-SPF אינו בוחן את המראה של רשומת TXT הראשית. מה שחשוב הוא מספר הרכיבים שמפעילים DNS וששרת המקבל מעריך לאחר מעקב אחר include, redirect, `a` ו-`mx` לאורך השרשרת.
לדוגמה:
אתם מפרסמים `v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net -all` וחושבים שהשתמשתם בשלוש בדיקות. זה לא החישוב המלא. הרשומות של Google ושל Microsoft כוללות רכיבי בדיקה נוספים בהמשך. הרשומה הגלויה קצרה, אבל מסלול ההערכה המלא לא בהכרח קצר.
לכן הבעיה של מגבלת בדיקות SPF מופיעה לעיתים בהמשך ולא ביום הראשון. כשספקים משנים את עצי SPF שלהם, המספר אצלכם עשוי לעלות גם בלי שתשנו שוב את ה-DNS.
יש מלכודת נוספת: בדיקות ריקות, המכונות void lookups. RFC 7208 ממליץ למימושים להגביל אותן לשתיים. בדיקה ריקה היא שאילתת DNS שאינה מחזירה נתונים או שמחזירה `NXDOMAIN`. שגיאת הקלדה אחת ב-include לא בהכרח תגרום לכשל, אבל שני יעדים שגויים עלולים לעשות זאת. כך במהלך בדיקת מגבלת בדיקות SPF אתם עשויים לגלות `permerror` גם כשאתם עדיין מתחת ל-10.
גם הנחיות Google לשולחים מדגישות את החשיבות: אימות חסר או פגום עשוי לגרום להודעות של שולחים בכמויות גדולות להגיע לספאם או להידחות. Google מתארת דרישה ל-SPF, ל-DKIM ול-DMARC אצל שולחים כאלה, ומציינת שהודעות שאינן עומדות בדרישות עשויות להידחות או להישלח לספאם. ראו את השאלות הנפוצות על דרישות Google לשולחים.
איך מחשבים את ניצול מגבלת בדיקות SPF?
כדי לחשב את ניצול מגבלת בדיקות SPF, התחילו ברשומה הראשית ועקבו אחר ההפניות המקוננות. ספרו כל מנגנון שמפעיל DNS במסלול ההערכה, כולל הרכיבים שלכם וההפניות הפנימיות של הספקים. אם מספר הרכיבים שמוערכים עולה על 10, אי אפשר להשלים את ההערכה תוך עמידה במגבלת הפרוטוקול.
התחילו ברשומה הראשית:
dig +short txt example.comפלט לדוגמה:
"v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"לאחר מכן בדקו כל דומיין שאליו יש הפניה:
dig +short txt _spf.google.com
dig +short txt spf.protection.outlook.comהמשיכו לעקוב עד שתגיעו רק ל-`ip4`, ל-`ip6` או לרכיבים שמסיימים את הערכת המדיניות.
פעלו לפי שיטת הספירה הבאה:
- ספרו כל
include,a,mx,ptr,existsו-redirectבמסלול ההערכה. - ספרו גם רכיבים מקוננים בתוך הרשומות שנכללות באמצעות include.
- אל תספרו
ip4,ip6אוall. - סמנו כל יעד include שאינו מחזיר נתונים. הוא עלול לגרום לבעיה של בדיקות ריקות.
אם אתם רוצים לבדוק במהירות את הגדרות DNS בזמן הוספת דומיין ב-TrekMail, התחילו בתיעוד על בדיקת מצב DNS ועל רשומות DNS נדרשות.
טעויות נפוצות סביב מגבלת בדיקות SPF
רוב התקלות הקשורות למגבלת בדיקות SPF נובעות מאותן טעויות: צבירת ספקים בדומיין ראשי אחד, השארת ספקים ישנים ברשומה, שימוש ב-`mx` כקיצור דרך ושטיחה ידנית ללא תהליך תחזוקה. אלה אינם מקרים חריגים, אלא תוצאות של ניהול DNS לא מוקפד כשהתצורה גדלה.
הגורמים העיקריים:
| טעות | למה היא מזיקה | מה עדיף לעשות |
|---|---|---|
| השארת ספקים ישנים | מבזבזת תקציב בדיקות ומרחיבה את הסיכון | הסירו כל ספק שכבר אינו משמש לשליחה |
שימוש ב-mx לאימות שליחה יוצאת | שרתי MX לקבלת דואר לרוב אינם שרתי השליחה שלכם | הרשו במפורש את השולח בפועל |
שימוש ב-ptr | איטי, לא מומלץ ורגיש לתקלות | הסירו אותו |
| שליחת הכול מדומיין אחד | דואר שיווקי ודואר טרנזקציוני חולקים תקציב SPF אחד | פצלו זרמי דואר בין תת-דומיינים |
| שטיחה ידנית | עלולה להיכשל כשספקים מחליפים כתובות IP | הפכו עדכונים לאוטומטיים או הימנעו משטיחה |
כאן צוותים מבלבלים בין מורכבות גלויה למורכבות בפועל. include יחיד של ספק עשוי לכלול כמה רכיבי בדיקה לאחר הרחבתו. לכן הגישה של ״נוסיף רק עוד שולח אחד״ עלולה ליצור בעיה עם מגבלת בדיקות SPF.
אם אתם עדיין בוחרים בין העברה, כינוי או תיבת דואר אמיתית לצורך מסוים, גם הבחירה הזאת קשורה להגדרת השולח. לקריאה נוספת: כינוי דואר בדומיין לעומת תיבת דואר והעברת דואר באמצעות כינוי.
איך מטפלים במגבלת בדיקות SPF תוך צמצום הסיכון לדואר?
הדרך העדיפה לטפל במגבלת בדיקות SPF היא להפחית את מורכבות המדיניות, ולא להוסיף עוד פתרונות מאולתרים. הסירו תחילה שולחים שאינם בשימוש, ואז העבירו מערכות עתירות שליחה לתת-דומיינים. השתמשו בשטיחה רק אם תוכלו לעדכן אותה אוטומטית.
1. הסירו רכיבים מיותרים.
מחקו ספקים שאינכם משתמשים בהם והסירו `ptr`. החליפו `mx` בהרשאה הדרושה לשולח האמיתי. מדיניות SPF רבות עשויות לחזור אל מתחת למגבלת בדיקות SPF לאחר סבב ניקוי אחד.
2. פצלו תעבורה לפי תת-דומיין.
זו לרוב גישה טובה לצוותים שגדלים.
; Primary company mail
example.com. TXT "v=spf1 include:spf.trekmail.net -all"
; Marketing mail
marketing.example.com. TXT "v=spf1 include:servers.mcsv.net include:hubspotemail.net -all"
; Transactional app mail
notify.example.com. TXT "v=spf1 include:amazonses.com -all"לכל תת-דומיין יש תקציב SPF משלו. זה עשוי להפחית את מורכבות הדומיין הראשי ולהקל על ניהול מגבלת בדיקות SPF.
3. השתמשו בשטיחה רק כמוצא אחרון.
שטיחה מחליפה רכיבי include בטווחי IP מפורשים:
; Before
v=spf1 include:vendor-a.example include:vendor-b.example -all
; After
v=spf1 ip4:192.0.2.10 ip4:192.0.2.11 ip4:198.51.100.0/24 -allהיא עשויה להפחית את ניצול הבדיקות לכמעט אפס, אבל יוצרת עבודת תחזוקה. ספקים משנים כתובות IP, הרשומה מתיישנת והאימות עלול להיכשל. אם אתם משטחים את הרשומה, הפכו את העדכון לאוטומטי.
הגישה הישנה והחדשה: ניהול מגבלת בדיקות SPF עם TrekMail
הגישה הישנה למגבלת בדיקות SPF היא להוסיף עוד ועוד ספקי תיבות דואר, פלטפורמות שיווק וממסרים לדומיין ראשי אחד, עד שצריך לחקור את היסטוריית ה-DNS כדי להבין אותו. הגישה החדשה מצמצמת רכיבים משתנים ומפרידה תפקידי שליחה מההתחלה.
הגישה הישנה: רשומת SPF עמוסה בדומיין הראשי, ספקים ישנים שלא הוסרו, תעבורה שיווקית מעורבת עם דואר מתיבות אמיתיות, ואחריות לא ברורה להרשאות השליחה.
הגישה החדשה: שמרו על אחסון תיבות פשוט, הפרידו שולחים עתירי תעבורה לתת-דומיינים, ותנו לדומיין הראשי מדיניות SPF קצרה עם מרווח מספיק.
TrekMail יכול לסייע בתצורה הזאת. בשימוש בשליחה מנוהלת של TrekMail בחבילות בתשלום, הנחיות DNS מתארות הוספת `include:spf.trekmail.net` לרשומת SPF. הרכיב עצמו נספר כבדיקה אחת, ויש לבדוק גם הפניות מקוננות אם קיימות. המחיר ההתחלתי המוצג הוא $3.50 לחודש, והתכונות המתוארות כוללות דומיינים מותאמים אישית, תיבות IMAP, catch-all, העברת דואר מתיבות, כלי הגירה מובנה וגישה ל-API. בחבילות בתשלום מתוארת תקופת ניסיון חינמית של 14 יום, המחייבת כרטיס אשראי. Nano מוצגת כחבילה חינמית ללא תקופת ניסיון ומשתמשת ב-BYO SMTP. בדקו את המחירים והתנאים העדכניים.
בחבילת Nano אפשר להשתמש ב-TrekMail כשכבת תיבות הדואר ולשלוח דרך SES, Mailgun או ממסר אחר. הקפידו על תכנון תת-דומיינים כדי שהמדיניות הראשית לא תגיע למגבלת בדיקות SPF. התיעוד על SMTP מותאם אישית (BYO), על SMTP מנוהל של TrekMail ועל התחלת הגירה בלוח הבקרה מסביר את ההיבטים התפעוליים.
אם אתם מאחדים דומיינים, תוכלו לקרוא גם על אחסון דואר למספר דומיינים ועל הגדרת דואר בדומיין שלי.
לסיכום: איך נשארים מתחת למגבלת בדיקות SPF?
כדי להישאר מתחת למגבלת בדיקות SPF, שמרו על מדיניות פשוטה. צמצמו את השולחים בדומיין הראשי והעבירו דואר בכמויות גדולות ודואר יישומים לתת-דומיינים. בדקו מחדש את רכיבי include של הספקים בכל הוספת כלי. אם המדיניות קרובה ל-10, התייחסו לכך כאות אזהרה.
זו התשובה המעשית. מגבלת בדיקות SPF אינה מקרה קצה תאורטי של RFC, אלא מגבלה תפעולית ממשית שמורגשת כשמצטברים שירותים. שמרו על רשומה קצרה ועל אחריות ברורה ל-DNS. אל תאפשרו לחמישה ספקים לחלוק מסלול אימות אחד עם תקציב מוגבל ללא בדיקה, אלא אם אתם אוהבים לנתח כותרות דואר בשעה 2 לפנות בוקר.
לתצורה מסודרת יותר, TrekMail מציע אחסון דואר למספר דומיינים בתעריף קבוע ללא חיוב לפי משתמש, עם אחסון משותף, הגירת IMAP מובנית ובחירה בין BYO SMTP ל-SMTP מנוהל של TrekMail. הזמינות והתנאים עשויים להשתנות בין חבילות. ראו את מחירי TrekMail או עברו ישירות אל TrekMail.
