מחולל רשומת SPF: בדיקת הפלט לפני פרסום ב-DNS

מצאתם מחולל רשומת SPF חינמי, סימנתם כל אפשרות - Google Workspace,‏ Mailchimp וה-CRM שלכם - והדבקתם את הפלט ישירות ב-DNS. כעבור שבועיים Gmail דוחה חשבוניות עם 550 5.7.26, ו-Outlook מחזיר 550 5.7.515. תור התמיכה מתמלא.

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

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

מה מחולל רשומת SPF באמת עושה

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

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

3 מצבי הכשל שכל מחולל SPF מחמיץ

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

1. PermError עקב רשומה כפולה

לדומיין חייבת להיות בדיוק רשומת SPF אחת. RFC 7208 קובע בבירור: אם השרת המקבל מוצא שתי רשומות TXT שמתחילות ב-v=spf1, הוא מחזיר PermError, כשל קבוע. Gmail ו-Yahoo עשויות לטפל ב-PermError כמו בהיעדר SPF. הדואר חוזר או מועבר בשקט לספאם.

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

2. מגבלת הבדיקות הרקורסיביות

RFC 7208 מגביל בדיקת SPF ל-10 בדיקות DNS בדיוק. הספירה כוללת כל include:,‏ a,‏ mx,‏ exists ו-redirect, וכן כל בדיקה מקוננת שמפעילים מנגנוני include. המחולל סופר את המנגנונים שבחרתם, אך לא את מה שבתוכם.

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

3. מגבלת הבדיקות הריקות (RFC 7208 §11.1)

יש מגבלה נוספת: לא יותר מ-2 שאילתות DNS שמחזירות תוצאה ריקה (NXDOMAIN). טעות אחת ב-include: יוצרת בדיקה ריקה. שתי טעויות כאלה מכשילות את רשומת ה-SPF כולה, גם אם בדיקת התחביר של המחולל עברה.

תרחיש: include:spf.trekmaill.net (אות 'l' נוספת). התחביר תקין ומחולל ה-SPF מסמן אותו כנכון. השרת המקבל מבצע בדיקה ולא מוצא דבר - בדיקה ריקה #1. include שגוי נוסף והרשומה כולה נכשלת.

איך לבדוק פלט של מחולל SPF לפני פריסה

לפני פרסום פלט שהמחולל יצר, הריצו את שלוש הבדיקות האלה מול ה-DNS הפעיל. הן אורכות חמש דקות ומגלות את הבעיות הקריטיות שהמחולל החמיץ: רשומות כפולות, עומק בדיקות מוגזם ותחביר פגום. הפעולות עובדות ב-macOS,‏ Linux ושורת הפקודה של Windows.

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

הריצו זאת לפני כל שינוי ב-DNS:

nslookup -type=txt yourdomain.com

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

# Broken - two records, PermError guaranteed:
"v=spf1 include:_spf.google.com -all"
"v=spf1 include:spf.trekmail.net -all"

# Fixed - merged into one:
v=spf1 include:_spf.google.com include:spf.trekmail.net -all

שלב 2: ספרו בדיקות רקורסיביות

בדקו את התוכן של כל include: ברשומה:

dig +short txt _spf.google.com

פלט:

"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

include:_spf.google.com יחיד מפעיל 4 בדיקות בפועל. חזרו על כך לכל ספק וסכמו. אם הסך עולה על 10, צריך לשנות את המבנה, בדרך כלל באמצעות העברת דואר תפעולי לתת-דומיין (send.yourdomain.com) עם רשומה קצרה משלו.

שלב 3: בדקו את המנגנונים

השוו את המחרוזת שהמחולל יצר לטבלה:

רשימת בדיקה לתחביר SPF

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

1. רשומה אחת לכל דומיין. מזגו אם קיימת כפילות. לעולם אל תפרסמו שתיים.
2. מתחילה ב-v=spf1. ללא וריאציות. השתמשו במחרוזת המדויקת.
3. מסתיימת ב--all או ~all. לעולם לא +all או ?all.
4. כתובות IP לפני include. מנגנוני ip4: ו-ip6: אינם צורכים בדיקות DNS - הציבו אותם ראשונים להערכה מהירה יותר.
5. ללא הפניה עצמית. include:yourdomain.com יוצר לולאה אינסופית. מחקו אותו.
6. ללא השטחה ידנית של כתובות IP אלא אם אוטומציה שומרת עליהן מעודכנות. אם Google מחליפה כתובות ואינכם מעדכנים, הדואר עלול להיכשל בשקט.
7. סך הבדיקות ≤ 10. ספרו הכול, כולל מנגנוני include מקוננים.

רשומה המתאימה לייצור:

v=spf1 ip4:192.0.2.1 include:spf.trekmail.net include:_spf.google.com -all

כתובות IP ראשונות (ללא עלות בדיקה), אחריהן include, ובסוף hard fail. זה הכול.

מדוע סוכנויות ועסקים קטנים גדלים מעבר למחוללי SPF

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

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

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

איך TrekMail מצמצמת את בעיית מחולל ה-SPF

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

לעסקים קטנים: Include יחיד, ללא תחזוקה

בתוכנית Starter של TrekMail ($3.50/חודש), המסירה היוצאת עוברת דרך SMTP מנוהל של TrekMail. רשומת ה-SPF הופכת לשורה אחת:

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

TrekMail מנהלת החלפת IP ומוניטין שולח מאחורי ה-include. בדרך כלל אין צורך לשנות שוב את הרשומה עבור TrekMail עצמה. אין צורך בהפעלת מחולל או בביקורת בדיקות כעבור שישה חודשים כשמוסיפים כלי SaaS.

לסוכנויות: תבנית אחת לכל לקוח

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

הדרך של TrekMail: תבנית אחת בכל דומייני הלקוחות:

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

בתוכנית Agency ($23.25/חודש), מנהלים 1,000+ דומיינים מלוח בקרה אחד. תקנון הדואר הארגוני על TrekMail מסיר את בעיית הבדיקות הרקורסיביות מערוץ התקשורת העיקרי. אם אתם מרחיבים מערך רב-דומיינים, ראו איך אחסון אימייל למספר דומיינים משנה את הניהול.

לתצורת ה-DNS המלאה ש-TrekMail מצפה לה לצד SPF - MX,‏ DKIM ו-DMARC - המסמך על רשומות DNS נדרשות מסביר את כל הארבע במקום אחד.

שאלות נפוצות על מחולל רשומת SPF

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

האם אפשר להשתמש בשני מחוללים להשוואת הפלט?

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

המחולל אומר שהרשומה תקינה. מדוע הדואר חוזר?

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

מתי להשתמש ב--all לעומת ~all?

השתמשו ב--all (HardFail) בייצור כדי לדחות מיד שולחים לא מורשים. השתמשו ב-~all (SoftFail) רק בתקופת מעבר שבה אינכם בטוחים שכל שולח נרשם. זהו מצב זמני, לא יעד. מחולל שבוחר כברירת מחדל ?all או +all מיטיב ליצור מראית עין של פעולה יותר מאשר יכולת מסירה ממשית.

הגרסה הקצרה

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

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

אם אתם מעדיפים לדלג על התהליך כולו, TrekMail מרכזת את השליחה היוצאת ב-include: יחיד. שורה אחת ב-DNS, ללא חשבון בדיקות וללא אבחון PermError.

התחילו תקופת ניסיון חינם של 14 יום - נדרש כרטיס אשראי ואפשר לבטל בכל עת.