יצירת רשומת SPF: ארגון השולחים וניהול שאילתות DNS

כשצריך ליצור רשומת SPF לדומיין, המטרה פשוטה: לאשר את השולחים הנכונים בלי לבנות סבך DNS שיגרום לתקלות כעבור כמה חודשים. בעיות רבות מתחילות באותה צורה. מוסיפים ספק, ואז עוד ספק. פתאום Microsoft מחזירה 550 5.7.515, Google מחזירה 550 5.7.26, ובשעה 11 בלילה אתם מוצאים את עצמכם נוברים ברשומות TXT.

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

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

למה רשומות SPF רבות גורמות לתקלות

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

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

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

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

גם הנחיות Google לשולחים מדגישות אימות תקין והתאמה בין דומיינים, במיוחד בדיוור המוני. SPF הוא רק חלק מהתמונה, אבל תקלה בו היא לעיתים קרובות הסימן הגלוי הראשון לבעיה.

המגבלה האמיתית: מכסה של 10 רכיבים התלויים ב-DNS

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

הרכיבים שנספרים במכסה:

• include
• a
• mx
• ptr (מומלץ להימנע ממנו)
• exists
• redirect

הרכיבים שאינם נספרים במכסה:

• ip4
• ip6
• all

חשוב לשים לב גם לשאילתות DNS ללא תוצאה תקפה, המכונות void lookups. RFC 7208 ממליץ להגביל אותן לשתיים. שגיאת הקלדה ביעד include עלולה לצרוך חלק מהמכסה הזו. חריגה מהמגבלה המומלצת, ולא עצם ההגעה אליה, עלולה לסיים את בדיקת SPF ב-PermError נוסף.

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

יצירת רשומת SPF באמצעות הפרדת מסלולי שליחה

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

זה המבנה:

1. הדומיין הראשי @ מיועד לדואר ארגוני רגיל בין אנשים.
2. תת-דומיינים מיועדים לניוזלטרים, תמיכה, התראות עסקה ושולחים מתמחים אחרים.
3. רשומת SPF אחת לכל שם מארח, ללא כפילויות או רשומות SPF ישנות שנשארו. רשומות TXT אחרות מותרות.

דוגמה לרשומת דומיין ראשי בשליחה מנוהלת של TrekMail:

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

זו רשומה ברורה: include אחד ומדיניות שקל לבדוק. עדיין צריך לוודא את עלות ההערכה הרקורסיבית ואת הכיסוי של כל השולחים המורשים.

דוגמה לתת-דומיין שיווקי:

v=spf1 include:servers.mcsv.net include:hubspot.com -all

כך Mailchimp ו-HubSpot משתמשים במכסה של marketing.example.com במקום בדומיין הארגוני הראשי, בתנאי שזהו דומיין השליחה בפועל שנבדק ב-SPF. הרחבה עתידית של התשתית שלהם עשויה אז שלא להשפיע על תיבות העובדים ב-example.com. זו דוגמה להמחשה: יש לפעול לפי ההנחיות הרשמיות העדכניות של כל ספק לאימות ולהגדרת MAIL FROM מותאם אישית. DMARC עדיין דורש SPF או DKIM עם התאמת דומיינים; מצב התאמה מחמיר ומצב מקל מתייחסים אחרת לתת-דומיינים.

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

שלב אחר שלב: כתיבת ערכי SPF בלי לנחש

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

עבדו לפי השלבים האלה:

1. רשמו כל שירות ששולח דואר בשם הדומיין שלכם.
2. סווגו כל שולח כדואר ארגוני, דואר עסקאות, תמיכה או שיווק.
3. החליטו באיזה שם מארח ישתמש כל שולח בפועל ב-MAIL FROM.
4. השתמשו במדיניות SPF התקפה המצומצמת ביותר שמכסה את כל השולחים המורשים לאותו שם מארח.
5. פרסמו רשומת SPF מסוג TXT אחת לכל שם מארח, לצד רשומות TXT אחרות לפי הצורך.

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

דוגמה ל-SMTP מנוהל של TrekMail:

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net -all
TTL: 3600

דוגמה להמחשה לשילוב TrekMail ו-SMTP חיצוני בתוכנית Nano או במבנה משולב:

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net include:amazonses.com -all
TTL: 3600

אין להחיל את הדוגמה המשולבת אוטומטית. אשרו רק את ספק ה-SMTP שבאמת שולח עבור דומיין שולח המעטפת בפועל ב-MAIL FROM, ופעלו לפי הוראותיו ל-MAIL FROM מותאם אישית. לפי מודל המוצר המתואר במקור, Nano דורש ספק SMTP משלכם לדואר יוצא; אין בכך חובה לאשר גם את TrekMail וגם את SES. המקור מציין תוכניות בתשלום החל מ-$3.50 לחודש הכוללות SMTP מנוהל, מציג את Nano כתוכנית שנשארת חינמית, ומתאר ניסיון חינם בן 14 יום לתוכניות בתשלום המחייב כרטיס אשראי. בדקו את ההצעה ואת התנאים העדכניים לפני הבחירה. לפרטי הגדרה, עיינו ב-SMTP חיצוני משלכם (BYO) וב-SMTP מנוהל של TrekMail.

פרסום הרשומה ובדיקתה

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

ב-Mac או ב-Linux:

dig txt example.com +short

ב-Windows:

nslookup -type=txt example.com

צריכה להופיע רשומת SPF אחת שמתחילה ב-v=spf1. לא רשומות SPF כפולות ולא רשומה שנשכחה ממעבר שבוצע לפני שלוש שנים. רשומות TXT אחרות שאינן קשורות ל-SPF יכולות להופיע לצידה.

בדיקות מהירות:

• הרשומה מתחילה ב-v=spf1
• היא מסתיימת ב--all לאחר מיפוי ובדיקה של כל השולחים המורשים
• היא כוללת רק שולחים שבהם משתמשים בפועל
• קיימת רשומת SPF אחת לכל שם מארח, ולא כמה רשומות

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

שגיאות SPF נפוצות ודרך הטיפול בהן

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

שני כללים מעשיים חוסכים הרבה עבודה:

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

מסמכי Google מועילים משום שהם מגדירים את המטרה האמיתית: אימות יחד עם התאמה, ולא SPF לבדו. SPF יכול לעבור בהצלחה והדואר עדיין עלול שלא לעמוד במדיניות אם דומיין From הגלוי אינו תואם לדומיין שאומת. DMARC יכול לעבור באמצעות SPF או DKIM בעלי התאמה מתאימה; התאמת תת-דומיין תלויה גם במצב המחמיר או המקל. קראו את השאלות הנפוצות על הנחיות Google לשולחי דוא״ל בעת פתרון בעיות במסירת דיוור המוני.

מתי TrekMail יכול להקל על הניהול

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

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

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

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

סיכום: צרו מבנה SPF שדורש פחות תחזוקה

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

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