דוגמאות SPF מוכנות להעתקה ולשימוש

רוב הדוגמאות לרשומת SPF ברשת פשוטות מדי או עמוסות במקרי קצה שלא תפגשו. מה שנחוץ הוא תבניות שמתאימות לייצור עבור שלוש תצורות המכסות 95% מהדומיינים. רשומת TXT אחת שמתחילה ב-v=spf1 ומסתיימת ב--all. טעות עלולה לגרום לנמענים כמו Google ו-Microsoft לדחות דואר עם שגיאות SMTP לא ברורות, כגון 550 5.7.26.

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

תבניות רשומת SPF לכל תצורת שליחה

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

תרחיש 1: שולח יחיד (ספק אחד מטפל בכול)

כל הדואר נשלח דרך פלטפורמה אחת. זו התצורה הנקייה ביותר ובדרך כלל היעד המועדף.

TrekMail (מסלול Starter, Pro או Agency):

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

Google Workspace:

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

Microsoft 365:

v=spf1 include:spf.protection.outlook.com -all

include אחד ו--all אחד. זה הכול. מנוצלת 1 מתוך 10 שאילתות DNS מותרות.

תרחיש 2: שולח היברידי (תיבת דואר + שירות תפעולי)

אתם משתמשים בספק ראשי לתיבה ובשירות נפרד לדואר תפעולי או שיווקי. הדבר נפוץ במסלול Nano של TrekMail, שמשתמש ב-SMTP משלכם, או כאשר מצרפים כלי כמו Amazon SES או Mailchimp.

TrekMail Free + Amazon SES:

v=spf1 include:amazonses.com -all

Google Workspace + Mailchimp:

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

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

תרחיש 3: מערך מרובה שולחים (סיכון גבוה)

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

v=spf1 include:spf.trekmail.net include:hubspot.com include:mail.zendesk.com include:spf.bamboohr.com -all

על הנייר יש ארבע הכללות, אך כל include עשוי להכיל שאילתות מקוננות. HubSpot לבדו עשוי להוסיף 3-4 שאילתות. אם השרשרת חורגת מ-10, הנמענים מחזירים PermError ומתייחסים לדואר כלא מאומת. אם המערך שלכם דומה, סעיף המגבלה הבא חיוני.

כיצד פועל תחביר SPF: החלקים החשובים

SPF הוא רשימת הרשאות מבוססת DNS שמוגדרת ב-RFC 7208. היא אומרת לשרתים המקבלים אילו כתובות IP רשאיות לשלוח דואר עבור הדומיין. אלה הרכיבים שתפגשו בדוגמה מעשית:

רכיב	דוגמה	פעולה
גרסה	`v=spf1`	חובה. חייבת להיות הטקסט הראשון ברשומה.
הכללה	`include:spf.trekmail.net`	מאשרת את כל כתובות ה-IP שרשומות ב-SPF של דומיין אחר.
מנגנון IP	`ip4:192.0.2.1`	מאשר ישירות IP קבוע ואינו צורך שאילתת DNS.
HardFail	`-all`	דוחה IP שלא צוין במפורש. השתמשו באפשרות זו.
SoftFail	`~all`	מסמן כתובות שלא נכללו כחשודות. מתאים רק לבדיקת מעבר.

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

מגבלת 10 השאילתות: המקום שבו רשומות SPF רבות נכשלות

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

כל אחד מהמנגנונים הבאים צורך 1 שאילתה: include, a, mx, redirect, exists, ptr (מיושן, אין להשתמש בו).

המנגנונים הבאים אינם צורכים שאילתות: ip4, ip6, all.

השאילתות רקורסיביות. הוספת include:bluehost.com צורכת 1 שאילתה. אם רשומת SPF של Bluehost מכילה include:spf.protection.outlook.com, השאילתה המקוננת נספרת במגבלה שלכם. חיבור 3-4 ספקים עם הכללות מקוננות עלול כבר לעבור את 10.

מגבלת השאילתות הריקות שלעתים נשכחת

RFC 7208 §11.1 מוסיף מגבלה משנית: לכל היותר 2 שאילתות DNS שלא מחזירות תוצאה, NXDOMAIN או תשובה ריקה. שגיאת כתיב ב-include:spf.trekmaill.net, עם 'l' נוספת, צורכת 1 שאילתה ריקה. שתי שגיאות מכשילות את הרשומה כולה.

כיצד לפתור את מגבלת השאילתות בלי השטחה

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

השתמשו בתתי-דומיין להפרדת שולחים

אל תעמיסו את כל הכלים על הדומיין הראשי. כל תת-דומיין מקבל מכסה חדשה של 10 שאילתות.

דואר ארגוני: @company.com, רק הספק הראשי (TrekMail, Google וכדומה)
שיווק: @news.company.com, Mailchimp, HubSpot
תמיכה: @support.company.com, Zendesk, Freshdesk

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

החליפו שאילתות DNS במנגנוני IP

אם יש לכם שרת דואר עם כתובת קבועה, ציינו את ה-IP ישירות במקום מנגנון a.

צורך 1 שאילתה:

v=spf1 a:mail.company.com -all

צורך 0 שאילתות:

v=spf1 ip4:192.0.2.55 -all

כל ip4 או ip6 שמחליף מנגנון אחר מפנה שאילתה לכלי SaaS שמחייבים include.

שגיאות SPF קריטיות שפוגעות בהעברת הדואר

שגיאה 1: שתי רשומות SPF באותו דומיין

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

שגוי:

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

נכון:

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

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

שגיאה 2: שימוש ב-+all

לעולם אל תשתמשו ב-+all. הערך מאשר הכול ואומר לשרתים שכל אדם יכול לשלוח בשם הדומיין. השתמשו תמיד ב--all (HardFail).

שגיאה 3: הסתמכות על SPF בלבד לדואר מועבר

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

לשם כך קיים DKIM: הוא חותם על תוכן ההודעה והחתימה יכולה לשרוד העברה. אם אתם תלויים ברשימות דיוור או ב-העברת אימייל, SPF לבדו אינו מספיק. נחוצים DKIM, ועדיף גם מדיניות DMARC שמקבלת אחד מהם. Sender Rewriting Scheme (SRS) משלים את התהליך באמצעות שכתוב שולח המעטפה כדי ש-SPF יעבור בתחנה הבאה.

כיצד TrekMail מפשטת את ניהול SPF

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

הגישה של TrekMail תלויה במסלול:

Free ($0/mo, ללא כרטיס): SMTP משלכם. אתם כוללים את רשומת SPF של הספק. שליטה מלאה ועלות אפס.
Starter ($3.50/mo) ו-Pro ($10/mo): SMTP מנוהל. הוסיפו include:spf.trekmail.net ואנו נטפל בתשתית ה-IP. כאשר השרתים משתנים, ה-DNS נשאר ללא שינוי.
Agency (.25/mo): אותו SMTP מנוהל, המיועד לניהול כמה דומיינים. אפשר להחיל תבנית SPF אחידה על דומייני לקוחות. הכללה אחת משאירה די מכסת שאילתות לכלים אחרים.

כל המסלולים בתשלום כוללים ניסיון חינם למשך 14 יום, עם כרטיס נדרש. אשף SPF/DKIM/DMARC המובנה מנחה בהגדרת DNS ומסמן שגיאות לפני המעבר לייצור.

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

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

ספרו את השאילתות. הריצו dig TXT yourdomain.com או השתמשו במאמת SPF. אם עברתם את 10, הרשומה כבר נכשלת.
מזגו רשומות כפולות. דומיין אחד, רשומת v=spf1 אחת.
הפרידו שולחים כבדים. העבירו כלי שיווק ותמיכה לתתי-דומיין.
החליפו מנגנוני a ב-ip4 כאשר השרתים קבועים.
סיימו ב--all. ללא חריגים.