Defaults.Exposed

Defaults.Exposed › תיקונים › SPF (Sender Policy Framework)

כיצד לתקן SPF (Sender Policy Framework)

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

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

מה זה יכול לעלות לכם

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

הגרסה הקצרה

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

SPF (Sender Policy Framework) הוא הפתרון. זוהי שורת טקסט אחת בהגדרות ה-DNS של הדומיין שלך שמפרטת אילו שירותי דואר מורשים באמת לשלוח מייל בשמך. ספקי דואר מקבלים — Gmail, Outlook, כולם — בודקים את הרשימה הזו לפני שהם מחליטים אם הודעה אמיתית. אין רשימה, או רשימה חלשה, ואין להם על מה להסתמך.

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

מה זה יכול לעלות לך

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

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

מה זה בעצם

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

אתה מפרסם שורת טקסט קצרה בהגדרות ה-DNS של הדומיין שלך — “רשומת TXT” — שמציינת את שירותי הדואר המורשים לשלוח בשמך. משהו כזה:

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

בשפה פשוטה, זה אומר: “דואר אמיתי מאיתנו מגיע משרתי Google ושרתי SendGrid — דחה כל דבר אחר שטוען להיות אנחנו.”

שני החלקים שחשובים לציון שלך:

  1. האם הרשומה קיימת? זהו הגדול (הוא נושא את המשקל הגדול ביותר מכל בדיקת דואר בודדת). אין רשומה פירושו שלמקבלים אין רשימה לבדוק מולה, כך שהתחזות פתוחה לחלוטין. יש גם כשל עדין כאן: אם לדומיין שלך יש שתי רשומות SPF או יותר, הכללים אומרים שכולן לא חוקיות — כך שבפועל אין לך SPF כלל, אפילו שנראה שיש לך.

  2. האם המדיניות מחמירה מספיק? רשומה יכולה להתקיים ועדיין להיות חסרת שיניים. הסיומת — מנגנון ה”all” — היא ההוראה לשרתים המקבלים:

    • -all (hard fail) — דחה כל דבר שאינו ברשימה. החזק ביותר. ניקוד מלא.
    • ~all (soft fail) + DMARC מוגדר ל-reject — ההגדרה המומלצת המודרנית. הגנה שוות ערך ל-hard fail, ללא הסיכון שדואר מועבר יחזור. ניקוד מלא.
    • ~all + DMARC מוגדר ל-quarantine — מקובל, מעט חלש יותר; העבר DMARC ל-reject להגנה מלאה.
    • ~all לבד (ללא אכיפת DMARC) — חלש. זה אומר “כנראה מזויף, תמסור בכל זאת.” דואר מזויף עדיין עובר. זה המלכודת שבה עסקים רבים נופלים וחושבים שהם מוגנים.
    • ?all (neutral) — לא מספק הגנה.
    • +all — מסוכן באופן פעיל: הוא אומר לעולם שכל אחד רשאי לשלוח בשמך. לעולם אל תשתמש בזה.

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

מה נראה “טוב”: רשומת SPF אחת בדיוק, שמפרטת כל שירות ששולח בחוקיות דואר בשמך, שמסתיימת ב--all (או ~all בזוג עם DMARC ב-p=reject), ונשארת בנוח מתחת ל-10 בדיקות.

כיצד לתקן (חינם, ~10 דקות)

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

שלב 1 — רשום כל שירות ששולח מייל בשמך. זה החלק שאנשים מבצעים בטעות. כתוב את כולם: ספק תיבות הדואר שלך (Google Workspace, Microsoft 365 וכו’), בנוסף לכל כלי ניוזלטר, CRM, מערכת תמיכה, פלטפורמת מסחר אלקטרוני, אפליקציית חשבוניות/חשבונאות ומערכת הזמנות. אם שירות שולח דואר בשמך ואתה שוכח אותו, ה-SPF שלך יחסום את הדואר שלו כשתחמיר את המדיניות.

שלב 2 — פרסם רשומת TXT אחת בדומיין הראשי שלך. שלב את שורות ה-”include” של כל השולחים שלך לרשומה אחת. לפי פלטפורמה נפוצה:

רשומה משולבת נראית כך:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net -all

היכן להוסיף אותה, לפי ספק:

שלב 3 — התחל בטוח, ואז אכוף. בעוד אתה מאשר שרשימת השולחים שלך שלמה, פרסם עם ~all (soft fail) כדי שלא ייחסם שום דבר לגיטימי בטעות. ברגע שאישרת שכל הדואר הלגיטימי שלך עדיין זורם, החמר ל--all (hard fail) — או, טוב יותר, השאר ~all והוסף מדיניות DMARC של p=reject, שהיא הזיווג המודרני המומלץ.

שלב 4 — ודא שיש לך בדיוק רשומה אחת. אם כבר קיימת רשומת SPF ישנה, ערוך אותה ולא תוסיף שנייה. שתי רשומות v=spf1 מבטלות זו את זו ומשאירות אותך ללא הגנה.

שלב 5 — שמור עין על ספירת הבדיקות. אם יש לך הרבה שולחים, ייתכן שתחרוג ממגבלת 10 הבדיקות. אם זה קורה, איחד — חלק מהספקים מציעים “SPF flattening”, או הסר שולחים שאינך משתמש בהם עוד.

שלב 6 — בדוק מחדש את הדומיין שלך כדי לאשר שהוא עכשיו עובר, עם הרשומה הקיימת והמדיניות המחמירה.

טעויות נפוצות

היכן זה מתאים

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

הגדירו זאת אצל ספק האחסון שלכם

שלב אחר שלב עבור ספקים פופולריים:

שאלות נפוצות

אני לא טכני — האם אני יכול לטפל בזה בעצמי?

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

כבר יש לנו רשומת SPF — האם זה אומר שאנחנו מוגנים?

לא בהכרח. קיום רשומה הוא המחצית הראשונה; הגדרתה בצורה קפדנית היא המחצית השנייה. רשומה שמסתיימת ב-'~all' (soft fail) ללא DMARC מאחוריה אומרת לשרתים המקבלים 'אולי זה מזויף, אבל תמסור בכל זאת' — דבר המספק הגנה מינימלית. שתי רשומות SPF, או אחת שמבצעת יותר מדי בדיקות, נחשבת שבורה ואינה מעניקה לך כל הגנה למרות שנראית קיימת. שני החלקים חייבים להיות נכונים.

האם התיקון יפסיק את המייל שלי מלהגיע ליעד?

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

מה ההבדל בין '~all' ל-'-all', ואיזה להשתמש?

'-all' (hard fail) אומר לשרתים לדחות כל דבר שאינו ברשימה — ההגדרה החזקה ביותר. '~all' (soft fail) אומר 'כנראה לא לגיטימי, אבל קבל בכל זאת.' ההמלצה המודרנית היא '~all' בשילוב עם מדיניות DMARC של 'reject' — הזוג הזה נותן לך את אותה ההגנה כמו '-all' ללא הסיכון שדואר מועבר יחזור. '~all' לבד, ללא DMARC שמאכף, היא הקונפיגורציה החלשה שיש להימנע ממנה.

האם SPF יעצור את כל זיוף הדואר בעצמו?

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

כמה זמן עד שזה ייכנס לתוקף, והאם זה יכול לעלות כסף?

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