מגבלת פניות SPF: בדיקה וטיפול מבוקר

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

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

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

מהי מגבלת פניות DNS ב-SPF?

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

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

RFC 7208 מגדיר את הרכיבים הנספרים: include, a, mx, ptr, exists ו-redirect. רכיבים כמו ip4, ip6 ו-all אינם צורכים את תקציב הפניות הזה בבדיקה.

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

מה נכלל במגבלה?

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

הרכיבים הבאים משתמשים בתקציב:

1. include: בודק SPF של דומיין אחר ומתאים כאשר הבדיקה ההיא עוברת.
2. a: משווה רשומות כתובת של מארח ל-IP המתחבר.
3. mx: בודק מארחי MX ואת כתובותיהם, בכפוף למגבלות נוספות.
4. ptr: משתמש ב-DNS הפוך ואינו מומלץ לשימוש.
5. exists: בודק אם שאילתת DNS לרשומת A המוגדרת מחזירה תוצאה.
6. redirect: משתמש במדיניות SPF אחרת אם שום מנגנון במדיניות הנוכחית לא התאים.

הרכיבים הבאים אינם צורכים את תקציב פניות DNS בבדיקת SPF:

• ip4
• ip6
• all

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

נדמה שהוספתם 6 שולחים, אך אחרי בדיקה רקורסיבית הנמען עשוי להגיע ל-11 או ל-12 רכיבים המחייבים פנייה ל-DNS. כך צוות חורג מהמגבלה אף שחשב שהמספר הישיר עדיין נמוך מ-10.

למה צוותים צומחים נתקלים במגבלה

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

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

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

בהמשך מספר השירותים גדל:

v=spf1 include:_spf.google.com include:servers.mcsv.net include:mail.zendesk.com include:spf.hubspot.com include:amazonses.com ~all

כעת אתם מנהלים לא רק מדיניות עצמאית, אלא שרשרת תלות שיכולה להשתנות מחוץ ל-DNS שבשליטתכם.

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

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

מה קורה כשחורגים מהמגבלה?

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

בדיקה שחורגת אינה מקבלת אישור חלקי כי הייתה קרובה למגבלה. בררו את הגורם במקום להתייחס לשגיאה כאל פרט חסר חשיבות.

הנחיות Google הנוכחיות דורשות גם אימות והתאמה מתאימים. אם אתם שולחים בהיקף גדול ל-Gmail, בדקו גם SPF וגם DKIM ואת הדרישות החלות. ראו את הנחיות שולחי הדוא"ל של Google.

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

1. תוצאות DNS ריקות. RFC 7208 ממליץ להגביל void lookups לשתיים, ובהן שאילתות כתובת המחזירות NXDOMAIN או ללא תשובה. טעות ב-include או דומיין ספק שנעלם עשויים לתרום ל-permerror.
2. גודל תשובת DNS. תשובות גדולות עלולות להיחתך ולדרוש טיפול חלופי. תקלות רשת או resolver יכולות להוביל לשגיאות זמניות או לפסקי זמן; גודל הרשומה לבדו אינו מוכיח שזה יקרה.

למה flattening אינה פתרון ללא תחזוקה

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

flattening ידנית יכולה להיראות כך:

v=spf1 ip4:192.0.2.10 ip4:192.0.2.11 ip4:198.51.100.0/24 -all

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

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

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

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

תכנון לטווח ארוך שמתחשב במגבלת SPF

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

מודל אפשרי:

1. הדומיין הראשי לדואר בין אנשים, למשל alice@company.com.
2. תת-דומיין לשיווק, למשל newsletter.company.com.
3. תת-דומיין לתמיכה, למשל support.company.com.
4. תת-דומיין לדואר תפעולי, למשל updates.company.com.

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

company.com TXT "v=spf1 include:_spf.google.com ~all"
newsletter.company.com TXT "v=spf1 include:servers.mcsv.net ~all"
support.company.com TXT "v=spf1 include:mail.zendesk.com ~all"
updates.company.com TXT "v=spf1 include:sendgrid.net ~all"

לכל בדיקת SPF עצמאית יש תקציב של 10 רכיבי פנייה. הדבר עשוי לצמצם נקודת כשל משותפת אם דומייני המעטפה אכן בשימוש וכל מדיניות מקוננת נשארת בתוך המגבלות. בדקו גם התאמת DMARC מסוג relaxed או strict.

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

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

איך בודקים את עלות פניות SPF

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

התחילו ב-dig:

dig txt example.com +short

dig txt _spf.google.com +short

dig txt spf.protection.outlook.com +short

ספרו את רכיבי הפנייה הרלוונטיים במסלול, כולל רכיבים מקוננים. בדקו היכן הבדיקה מסתיימת בהתאמה; חיבור כל המילים אינו תחליף לבדיקת SPF מלאה.

תהליך מעשי:

1. שלפו SPF TXT לדומיין שולח המעטפה האמיתי או לתת-הדומיין שלו.
2. רשמו כל include, a, mx, exists ו-redirect; בדקו גם מנגנוני DNS הפוך לא מומלצים אם נשארו ברשומה.
3. עקבו אחר מדיניות מקוננת וחזרו על הבדיקה תוך התחשבות בהתאמות ובשגיאות.
4. ודאו אילו כלים כבר אינם שולחים והסירו אותם.
5. בדקו פיצול לדומייני מעטפה מתאימים לפני שימוש ב-flattening.

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

התפקיד של TrekMail במערכת מסודרת יותר

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

זה רלוונטי לקבוצות משתמשים שונות.

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

הגישה הישנה והחדשה:

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

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

לפי המחירים הנוכחיים, Starter מתחילה ב-$3.50 לחודש. ההיצע החינמי ב-$0 מציין 10 דומיינים, 5GB אחסון משותף ו-SMTP עצמאי. תוכניות בתשלום עשויות להוסיף SMTP מנוהל, מגבלות גבוהות יותר ואוטומציה נוספת. בדקו תנאים עדכניים ב-תמחור TrekMail.

סיכום: התייחסו למגבלת SPF כאילוץ תכנון

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

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

לניהול פשוט יותר של דומיינים רבים, בדקו את יכולות TrekMail העדכניות לדומיינים מותאמים, תיבות IMAP, אחסון משותף, העברה ו-SMTP. ההתאמה והמגבלות תלויות בתוכנית. ראו את ההיצע החינמי ב-trekmail.net או השוו תוכניות ב-trekmail.net/pricing.