אחת מאבני היסוד לעבירוּת הוא אימות דומיינים מדוורים באמצעות פרוטוקולי אימות הדומיין SPF ו-DKIM. מהי רשומת SPF ואיך נכון להגדיר אותה?
תוכן עניינים
האזנה לפודקאסט
במאמרים קודמים כתבתי על ה”קרם דה לה קרם” של אימות והגנה על דומיינים:
פרוטוקול BIMI: פרוטוקול חדש יחסית המאפשר למדוורים ומותגים להציג את הלוגו הרשמי שלהם, מעין “חותם המלך” באימייל. לאחר הטמעה מתאימה ועמידה בכללים מסוימים, מדוורים יכולים להציג את הלוגו שלהם ב-Inbox של ספקיות אימייל כגון Gmail (אך לא ב-Outlook למשל).
פרוטוקול DMARC: גם הוא פרוטוקול חדש יחסית שמטרתו להגן על דומיינים מפני Spoof (התחזות של מדוורים לא מורשים). הוא מציף תשתיות המדוורות בשם הדומיין (מורשות ושאינן מורשות) ובתהליך אבולוציה נכון של Policy לעבור למצב אכיפה שיש ביכולתו גם להן על הדומיין וגם לשפר את העבירוּת.
שני הפרוטוקולים הללו הם הקצפת על העוגה. אך כמו בכל עוגה צריך לבנות תחילה בסיס חזק ורק לאחר מכן להוסיף קצפת (DMARC) ולסיום את הדובדבן שבקצפת (BIMI).
אין טעם בהגדרת DMARC ללא הטמעה נכונה של SPF ו-DKIM מאחר ו-DMARC (ו-BIMI) נשען על יסודותיהם של SPF ו-DKIM ובודק אותם.
הבסיס אם כך, הוא אימות דומיינים מדוורים באמצעות פרוטוקולי אימות הדומיין SPF ו-DKIM.
במאמר זה ארחיב בנושא פרוטוקול SPF ובהמשך במאמר נפרד על פרוטוקול DKIM.
SMTP
פרוטוקול SMTP לשליחת מיילים (Simple Mail Transfer Protocol) כשמו כן הוא: הוא פשוט. הוא פותח עוד בתקופת ARPANET שקדמה לרשת האינטרנט הציבורית המוכרת לנו כיום.
בהקשר של אימות דומיין הוא כולל ארבע פקודות חשובות בלבד:
EHELO/HELO, MAIL FROM (נקרא גם: return-patch / envelop from/bounce address ), RCPT TO, DATA.
בשל האופן בו נבנה פרוטוקול SMTP, ה-mail from יכול להיות ריק ופעמים רבות משמש ל-Abuse על ידי ספאמרים.
מנגנון SMTP לכשעצמו אינו כולל מנגנוני הגנה וכאן נכנסים פרוטוקולים לאימות דומיין (SPF ו-DKIM).
מה זה אימות דומיין?
תהליך Email Authentication משמש ספקיות אימייל ומסננות ספאם כאחד מה- data points בהחלטות הסינון שלהן כדי להחליט לגבי מיקומם של אימיילים: תיבת האימייל, לספאם, להיחסם.
זה יכול להיות תהליך סינון בספקית אימייל קטנה כמו ארגון עסקי בעל תשתיות אימייל עצמאיות, או ספקית אימייל ציבורית גדולה המטפלת במיליארדי אימיילים כגוןGmail וזקוקה לנקודות אחיזה (data points) כחלק מהאלגוריתמים שהיא מפעילה לסינון דואר.
מה זה SPF?
פרוטוקול SPF הוא מאבני היסוד של אימות דומיין (domain authentication) ויש להשתמש בו בתבונה.
פרוטוקול SPF (Sender Policy Framework RFC 7208) “רוכב” מעל פרוטוקול SMTP ומאפשר להגדיר מקורות מאושרים מהם אימיילים נשלחים (sources) ברמת הדומיין השולח כגון כתובות IP, תחומי כתובות (רשתות), רשומות אחרות (A record, MX record, PTR record), כתובות ורשתות של צדדי ג’ וכדומה.
באמצעות הוספת רשומת TXT ל-DNS של הדומיין השולח, פרוטוקול SPF מאפשר למנהל הדומיין להגדיר מקורות המורשים לשלוח בשם הדומיין. הוא גם מאפשר למנהל הדומיין להגדיר חוקים במקרה של אי התאמה (pass, fail, soft fail, neutral).
טעויות, מגבלות וסכנות בהגדרת SPF
לכל דומיין יכולה להיות רק רשומת SPF אחת המוגדרת כרשומת TXT. בשרתי DNS רבים קיימת רשומה מסוג SPF, אך היא אינה נתמכת עוד ואין להשתמש בה אלא רק ברשומת TXT.
קיימת מגבלה של 10 קריאות DNS (DNS lookups). במקרים רבים רשומת ה-SPF על סף הקיבולת שלהם או במקרה הגרוע עוברת את המגבלה, מה שיוצר בעיות אימות. במקרים אלה אפשר להשתמש בכלים חיצוניים (חלק מכלי ה-DMARC מציעים Smart SPF), או לפצל email streams שונים לתת דומיינים נפרדים.
ה-DNS בכל עסק הוא יצור חי המשתנה באופן תדיר. פעמים רבות רשומות SPF כוללות פתיחת הרשאות נרחבת מידי בעיקר על ידי ספקים למיניהם: מערכות CRM, מערכות דיוור, גופים כגון גוגל (Google Workspace) או Microsoft Office 365 שמבקשות לפתוח הרשאות נרחבות מאוד למאות אלפי כתובות אימייל.
לדוגמא: ההרשאה הבאה (ראו בתמונה) לקוחה מהנחיית Gmail עסקי למשתמשי Google Workspace (Gsuite). היא כוללת פתיחת הרשאה למאות אלפי כתובות אימייל של רשת Google לשלוח אימייל בשם הדומיין המדוור. האם נדרשת הרשאה נרחבת כל כך? ככל הנראה לא. האם Gmail מאפשרת ללקוחות עסקיים לצמצם את המרחב למינימום? ככל הנראה לא…
אם אתם עוברים בין מערכות דיוור או CRM כדאי לא להשאיר הרשאות ישנות וגם לא כדאי לספק הרשאות נרחבות מידי אם לא חייבים. כל רשומה היא עוד DNS lookup ובנוסף הרחבה מיותרת של סיכון ל-abuse של הדומיין.
אני נתקל ברשומות SPF חסרות תועלת, רשומות מסוכנות המאשרות יותר מידי מקורות, או רשומות ארוכות מידי (מעל מגבלת 10 ה-DNS lookups) מה שגורם לחלק מהמקורות המאושרים להיות לא מאומתים ויצירה של בעיית deliverability.
אימות דומיינים חייב להיות תוך שימת לב לפרטים הקטנים. זה מתחיל ב-DNS שהוא תשתית קריטית בכל עסק שיש לו דומיין (כמעט כל עסק כיום).
כדאי לזכור שעבור כל אימייל שמדוורים שולחים מתקיימות מספר קריאות אל שרת ה-DNS של הדומיין המדוור. משמעות הדבר כי DNS חייב להיות זמין, מהיר ומאובטח והרשומות בו צריכות להיות מנוהלות בקפדנות. די בשינוי קטן, מחיקת פסיק, הוספה או החסרה של תווים כדי לשנות הגדרות קריטיות לפעילות תקינה של פעילות האימייל שלכם.
אני ממליץ כי דומיינים פעילים (לא parked) ינוהלו בשרת DNS מקצועי הנפרד מרשם הדומיינים. דומיינים שאינם בשימוש יכולים להישאר ב-DNS של רשם הדומיינים וכדאי להוסיף להם רשומות SPF (ראו Parked domains בהמשך).
שרתי Cloudflare או שרתי CLOUDNS הם אופציות מצוינות ולשתי הספקיות ההלו יש מסלול חינמי. ראו הרחבה כאן
חלק מהשיקולים בבחירת ניהול רשומות SPF כולל בחינה של הפרדת פעילות דיוור שונות תחת sub-domains נפרדים או במקרים מסוימים תחת דומיינים נפרדים.
האזנה לפודקאסט המלא
Parked Domains
מאוד שכיח שעסקים רושמים דומיינים רבים כדי לתפוס את שם הדומיין בסיומות TLD שונות, או רושמים דומיינים שונים הכוללים וריאציות עם שם העסק (cousin domains), דומיינים של מותגים שלהם, או המייצגים את תחומי העיסוק שלהם.
פעמים רבות הדומיינים הרשומים הללו אינם מדוורים אלא פשוט “חונים” (parked) ברשם הדומיינים. הסכנה מדומיינים אלה היא שהם יכולים להיות מנוצלים לרעה על ידי ספאמרים. לכן ההמלצה היא להוסיף לדומיינים אלה את רשומת SPF שאינה מתירה אף מקור ומגדירה hard fail על הכל.
זו רשומת ה-SPF שכדאי להוסיף לדומיינים במצב parked (דומיינים לא מדוורים): v=spf1 -all
כמו כן, כדאי להוסיף להם DMARC Policy מצב reject ולנטר אותם עם כלי.
באמצעות EasyDMARC אפשר להוסיף דומיינים לא מדוורים ללא חיוב נוסף.
include / redirect
מצב redirect יכול לשמש בד”כ כשארגון גדול מנהל דומיינים שונים סביב העולם (כגון נציגויות שונות במדינות שונות) ששולחים אימיילים מתשתית אחת שבשליטה מוחלטת של אותו הארגון. אלא שבגלל הסכנות הטמונות ביישום זה (לאור ההרשאות שהוא מעניק) נדיר יותר לראות אותו והוא מומלץ ליישום על ידי מומחים בלבד.
פקודות מאקרו – SPF Macros
יישום נדיר יחסית בשל מורכבותו, אך הוא מאפשר למדוורים מתוחכמים להסתיר את התשתית השולחת שלהם, לייצר רשומת SPF קצרה הכולל הגדרות ברזולוציה טובה של מקורות מורשים ושל מקורות שאינם מורשים.
מאקרו יכול לבוא כפתרון במקרה של ריבוי שאילתות (כאמור המגבלה היא 10 שאילתות).
בשל פוטנציאל הסיכון הטמון בו מומלץ ליישום על ידי מומחים מיומנים בלבד.
כלי לבדיקת הגדרות SPF
באמצעות הכלי הזה תוכלו לבדוק את רשומת ה-SPF שלכם וגם כמה קריאות DNS היא צורכת.
אני סלע יפה, מומחה אימייל מרקטינג ועבירוּת אימיילים. כשיהיה לך רצון לשפר את ביצועי האימייל מרקטינג שלך, כך אוכל לעזור לך: אני מזמין אותך לפגישת יעוץ ראשונית של 1/2 שעה ללא עלות בנושא עבירוּת אימיילים ואסטרטגיית אימייל מרקטינג. book a 1/2 email deliverability discovery call.
לקריאה נוספת
כלים לבדיקת רשומות EmailStuff
שימוש בכלי DMRC ליצירת Smart SPF
Understanding SPF Authentication | Kickbox University
יצירת SPF Macros
Sella Yoffe
Email Deliverability & Email Marketing Expert
working with global email senders, startups, and ESPs to improve their deliverability and email authentication
Podcast host & Blogger @ CRM.BUZZ & EmailGeeks.Show
