יותר מדי בדיקות DNS ב-SPF היא שגיאה שנראית קטנה עד שהדואר מתחיל להיכשל. אז ההשלכות עלולות לגדול מהר. אם הדומיין חורג ממגבלת בדיקות SPF, שרתי המקבלים עשויים להחזיר PermError ולא להצליח להעריך את הרשומה כתקינה. חשבוניות, תשובות, התראות ודואר יישומים עלולים שלא לעבור בדיקות אימות.
אם אתם משפרים את יכולת ההגעה של הדואר ובונים תצורת דואר עסקית תקינה, זו חלק מאותה עבודה. המדריך של TrekMail על דואר עסקי לעסקים קטנים מכסה את התמונה הרחבה. המאמר הזה מתמקד בכשל המסוים של ריבוי בדיקות DNS ב-SPF ובטיפול בו בלי לנתק שולחים אמיתיים.
בקצרה: ל-SPF יש מגבלה קשיחה של 10 רכיבים שמפעילים DNS בזמן ההערכה. הספירה כוללת גם הפניות מקוננות. הספקים שלכם נספרים, וגם הספקים שלהם. שגיאות הקלדה ורכיבי include שאינם בשימוש עלולים להשפיע. כשחורגים מהגבול, זו בעיה אמיתית בעיבוד הדואר, לא אזהרה שאפשר להתעלם ממנה.
מה פירוש יותר מדי בדיקות DNS ב-SPF?
המשמעות היא ששרת המקבל צריך להעריך יותר מ-10 רכיבים שמפעילים DNS בבדיקת רשומת SPF. לפי RFC 7208, המימוש חייב להחזיר PermError במקרה כזה. בשלב הזה עיבוד המדיניות נעצר ואי אפשר לקבוע שהרשאת השליחה שהתכוונתם לתת תקינה.
הכלל נועד לעצור רקורסיית DNS יקרה או מזיקה. הוא אינו נתון לבחירה. RFC 7208 מחייב להחזיר PermError כשהמגבלה נחרגת. גם התיעוד של Microsoft בנושא SPF מזהיר שריבוי בדיקות יגרום לכשל SPF.
לכן הבעיה נפוצה בדומיינים שאליהם נוספו כלים במשך שנים: Google Workspace, אחריו Microsoft 365, מערכת CRM, מערכת קריאות שירות, פלטפורמת דיוור ואולי שירות העברה או ממסר. כל include נראה תמים בפני עצמו. הבעיה היא השרשרת כולה.
גם ״רק שלושה רכיבי include״ לא מעידים שאתם בטוחים. include אחד יכול להפנות לעוד כמה רכיבי בדיקה פנימיים. המגבלה עוסקת במסלול ההערכה המלא, לא רק בשורה הראשונה שהדבקתם ב-DNS.
אילו מנגנוני SPF נספרים במגבלה?
רק חלק ממנגנוני SPF מפעילים DNS. ההבחנה הזאת חשובה: החלפת הפניות רקורסיביות בהרשאה פשוטה יותר, היכן שאפשר, היא לעיתים הדרך המהירה לטיפול. בלי לדעת מה נספר, אי אפשר לבדוק את הרשומה כראוי.
| מנגנון | עלות בדיקות | הערות |
|---|---|---|
include: | 1 | מקור מרכזי לחריגה בגלל המשך ההפניות הרקורסיביות. |
a | 1 | מחפש רשומות A או AAAA. |
mx | 1+ | מפעיל בירור MX ועשוי להיות כפוף גם למגבלות משנה של MX. |
ptr | 1+ | השימוש בו אינו מומלץ כלל. הימנעו ממנו. |
exists | 1 | נפוץ בתצורות מתקדמות או עתירות מאקרו. |
redirect= | 1 | מעביר את עיבוד SPF לרשומה אחרת. |
ip4 / ip6 | 0 | רכיבים סטטיים שאינם דורשים בדיקת DNS חיה. |
all | 0 | קביעת מדיניות בלבד, ללא עלות בדיקה. |
יש מלכודת נוספת. RFC 7208 ממליץ להגביל בדיקות ריקות לשתיים: שאילתות שמחזירות NXDOMAIN או אינן מחזירות נתונים. זה עלול לסבך את האבחון, משום שהרשומה יכולה להיכשל גם אם חשבתם שאתם מתחת ל-10.
למשל, שגיאת ההקלדה ב-
include:spf.trekmaill.netעלולה לגרום לבדיקה ריקה. שני דומיינים שגויים בשרשרת מקרבים אתכם לתקרה המומלצת לבדיקות ריקות. חריגה ממנה עשויה להחזיר PermError בלי קשר לתקציב הרכיבים הכולל.
איך בודקים ריבוי בדיקות DNS ב-SPF?
התחילו ברשומת SPF הראשית, הרחיבו כל include וספרו את המנגנונים שמפעילים DNS לאורך מסלול ההערכה המלא. אל תנחשו ואל תסתמכו על צילום מסך ישן. בדקו את עץ הרשומות ואת הנתונים שמפורסמים ב-DNS עכשיו.
התחילו ברשומה הראשית:
dig +short txt example.comלאחר מכן הרחיבו כל include שמצאתם:
dig +short txt _spf.google.com
# or
dig +short txt spf.protection.outlook.com
dig +short txt spf.trekmail.netבמעקב אחר השרשרת ספרו כל include, a, mx, exists ו-redirect שמוערך בפועל. ספרו גם רכיבים מקוננים. אם ספק שינה את SPF שלו בשבוע שעבר, הרשומה שהייתה ״בטוחה״ עלולה כעת לחרוג בלי ששיניתם דבר.
רשימת בדיקה פשוטה:
- שלפו את רשומת SPF מסוג TXT שפורסמה כעת לדומיין.
- הרחיבו כל דומיין שנכלל באופן רקורסיבי.
- ספרו את כל המנגנונים שמפעילים DNS במסלול ההערכה המלא.
- בדקו שגיאות הקלדה, ספקים שיצאו משימוש ותשובות ריקות.
- הסירו שירותים כפולים לפני שתנסו פתרונות מורכבים.
אם אתם מגדירים במקביל דומיין חדש, המדריך לרשומות DNS נדרשות של TrekMail מראה את מבנה הבסיס המסודר שכדאי לשמר.
מה גורם בדרך כלל לריבוי בדיקות DNS ב-SPF?
הסיבה היא בדרך כלל הצטברות ספקים, לא טעות דרמטית אחת. רוב הרשומות הבעייתיות נבנו באמצעות הוספת include אחר include לאורך חודשים או שנים. איש לא היה אחראי למדיניות המלאה, והיא המשיכה לגדול עד שהאימות נפגע.
הסיבות הנפוצות פשוטות וצפויות:
ספקים ישנים לא הוסרו לאחר הגירה. כלי שיווק נוספו לאותו דומיין ראשי של דואר החברה. כמה צוותים אישרו שולחים שונים בלי מלאי משותף. מישהו העתיק דוגמת SPF של ספק בלי לבדוק כמה רכיבי include מקוננים יש בה.
גם תצורות של SMTP מותאם אישית הן גורם שכיח. הפעלת כמה שירותי שליחה מדומיין ראשי אחד מגדילה את הסיכון לחריגה. SMTP מנוהל של TrekMail עשוי לפשט את התצורה באמצעות איחוד השליחה מאחורי include אחד, אך עדיין צריך לבדוק את מסלול ההערכה המלא. ב-BYO SMTP אתם מנהלים בעצמכם את השפעת כל ספק על SPF.
לכן סוכנויות מרגישות את הבעיה יותר מעסקים עם דומיין אחד. שאריות תצורה ישנות מתפשטות בין עשרות אזורי DNS של לקוחות, ו-include שנשכח עשוי להישאר שנים.
פתרון מומלץ: פיצול דואר לפי תת-דומיין
הפתרון המסודר ביותר הוא לעיתים שינוי מבני: העבירו זרמי דואר שונים לתת-דומיינים שונים. לכל תת-דומיין יש רשומת SPF ותקציב בדיקות משלו. כך אפשר לשמור על דומיין ראשי פשוט ולמקם שולחים עתירי תעבורה בנפרד.
לדוגמה:
# Root domain for staff and transactional mail
example.com. TXT "v=spf1 include:spf.trekmail.net -all"
# Marketing subdomain for bulk mail
news.example.com. TXT "v=spf1 include:servers.mcsv.net include:spf.mailvendor.com -all"זה אפשרי משום ש-SPF נבדק מול שולח המעטפה, לא רק מול כותרת From הגלויה. תיבת התמיכה וכלי הדיוור שלכם אינם חייבים לחלוק אותו תקציב SPF.
בפועל, זה הפתרון שהייתי שוקל תחילה. הוא עשוי לצמצם את השפעת התקלות ואת מורכבות הדומיין הראשי. הפרדת הזרמים יכולה גם לסייע בהפחתת השפעת המוניטין של דיוור וקמפיינים על דואר הליבה, אך אינה מבטיחה בידוד מוניטין מלא.
אם אתם בונים מחדש סביב גבולות דומיין ברורים יותר, קראו גם את המאמרים של TrekMail על יצירת דואר עם הדומיין שלכם ועל אחסון דואר למספר דומיינים.
האם כדאי לשטח SPF כדי לפתור ריבוי בדיקות?
שטיחה יכולה לפתור את החריגה באמצעות החלפת שרשראות include ברכיבי ip4 ו-ip6 ישירים. מנגנוני IP סטטיים אינם דורשים בדיקות DNS במהלך הערכת SPF. המחיר הוא תחזוקה: הנתונים הסטטיים עלולים להתיישן ברגע שספק משנה את התשתית.
לפני שטיחה:
v=spf1 include:spf.example-vendor.com -allאחרי שטיחה:
v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.12 -allשטיחה עשויה להתאים כאשר:
- הספק מפרסם טווחי IP יציבים.
- יש לכם אוטומציה לרענון הרשומה.
- אתם מטפלים במצב חירום זמני וצריכים לשקם את השליחה.
שטיחה מסוכנת כאשר:
- הספק מחליף כתובות IP לעיתים קרובות.
- אתם מנהלים דומיינים רבים ידנית.
- אין לכם ניטור שיזהה שינוי בנתונים.
לכן שטיחה יכולה לטפל בחריגה, אבל אינה בהכרח הפתרון הנכון לטווח ארוך. ללא תחזוקה, אתם מחליפים סוג כשל אחד באחר.
הגישה הישנה והחדשה לריבוי בדיקות SPF
צוותים רבים פועלים בשיטה הישנה: מוסיפים עוד שינויי DNS ומקווים ששום דבר לא יישבר. גישה טובה יותר היא לצמצם רכיבים משתנים: פחות שולחים, גבולות דומיין ברורים יותר ופלטפורמה מנוהלת אחת לדואר העסקי השוטף. זה פחות מרשים מ״אופטימיזציית SPF מתקדמת״, אבל עשוי להקל על הניהול.
| הגישה הישנה | הגישה החדשה |
|---|---|
| להמשיך להוסיף include של צדדים שלישיים לדומיין הראשי | להשאיר את הדומיין הראשי מינימלי ולהעביר שולחים בכמויות גדולות לתת-דומיינים |
| להשתמש במערכת דואר אחרת לכל תהליך עבודה | לאחד דואר עסקי שוטף בפלטפורמה אחת |
| לשטח רשומות ידנית ולשכוח לעדכן | להשתמש בשליחה מנוהלת היכן שאפשר ולשטח רק עם אוטומציה |
| לאבחן חריגת SPF רק אחרי ירידה במסירה | לבדוק את מספר הרכיבים בכל שינוי ספק |
TrekMail עשוי להתאים כאן. בתצורות עסקיות וסוכנויות רגילות, include אחד קל יותר לניהול מאוסף ספקים ישנים. התכונות המתוארות כוללות דומיינים מותאמים אישית, תיבות IMAP, תמיכה ב-catch-all, העברת דואר מתיבות, כלי הגירה, גישה ל-API ו-BYO SMTP או SMTP הכלול בחבילות בתשלום. מחיר Starter המוצג מתחיל ב-$3.50 לחודש בחיוב שנתי, ובחבילות בתשלום מתוארת תקופת ניסיון חינמית של 14 יום המחייבת כרטיס אשראי. Nano מוצגת כחבילה חינמית שאינה מחייבת כרטיס. בדקו את התנאים והזמינות העדכניים.
אם אתם מעבירים דואר קיים במקום להמשיך לתקן אחסון ישן ומסובך, סקירת הגירת IMAP של TrekMail מכסה את צד ההעברה.
מה לעשות עכשיו אם ריבוי בדיקות SPF פוגע בדואר?
אם השגיאה מתרחשת עכשיו, טפלו קודם בסיכון הגבוה ביותר: החזירו הערכת SPF תקינה לזרמי הדואר החשובים. בדרך כלל צריך להסיר include שאינם בשימוש, להפריד שולחי שיווק ולצמצם את הדומיין הראשי למינימום הנדרש לדואר עסקי אמיתי.
- ערכו מלאי של כל שולח פעיל בדומיין.
- מחקו include של שירותים שבוטלו או מוכפלים.
- העבירו דואר בכמויות גדולות או דואר יישומים לתת-דומיין אם אפשר.
- שמרו על רשומה ראשית קצרה וצפויה.
- בדקו מחדש אחרי כל שינוי. אל תבצעו סדרת עריכות בלי בדיקה.
דוגמה פשוטה לדומיין ראשי עם שליחה מנוהלת של TrekMail:
v=spf1 include:spf.trekmail.net -allרשומה משולבת עם שולח נוסף יכולה להיראות כך:
v=spf1 include:_spf.google.com include:spf.trekmail.net -allזכרו את המלכודת המוכרת: רשומת SPF אחת מסוג TXT לכל דומיין. פרסום שתי רשומות SPF נפרדות יוצר כשל אחר.
לאחר הניקוי, עקבו במשך כמה ימים אחר תוצאות DMARC והאימות. חריגה ממגבלת SPF מסתתרת לעיתים בתוך בעיית ניהול DNS רחבה יותר, אז אל תעצרו בסימן התקין הראשון.
לסיכום: צמצום ריבוי בדיקות SPF לאורך זמן
הפתרון המתמשך הוא ארכיטקטורה פשוטה יותר, לא תחבולות DNS חכמות יותר. שמרו על דומיין ראשי מצומצם, השתמשו בתת-דומיינים לכלי דיוור ואחדו שולחים היכן שאפשר. שטחו רק אם תוכלו לתחזק את התוצאה. בדקו את עץ include המלא בכל הוספת ספק.
זו תוכנית העבודה. הבעיה מופיעה כאשר איש אינו אחראי למפת השולחים. כשהאחריות ברורה, הטיפול נעשה מסודר יותר.
לנקודת התחלה מסודרת יותר, TrekMail מיועד לאחסון דואר למספר דומיינים עם עומס ניהול DNS מוגבל, אחסון משותף, הגירת IMAP מובנית וללא מודל תמחור לפי משתמש. אפשר לבדוק את החבילה החינמית או להשוות חבילות בתשלום במחירי TrekMail. לעבודות ניקוי קשורות, ראו גם הגדרת העברת דואר ופתרון תקלות.
אפשר לטפל בריבוי בדיקות SPF. אל תתייחסו אליו כאזהרה קוסמטית, אלא ככשל אימות.
מקורות: RFC 7208 והנחיות SPF של Microsoft.
