בדיקת רשומת SPF: מי יכול לשלוח אימייל בשם הדומיין הזה?

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

הוספה כמקור מועדף הורידו מתוךGoogle Play הורידו מתוךApp Store

איך משתמשים

הקלידו את הדומיין שאתם רוצים לבדוק, או הדביקו כתובת אימייל או קישור: אנחנו משתמשים רק בדומיין שלהם.
לחצו על “בדיקת SPF”. אנחנו קוראים את רשומת ה-SPF ועוקבים אחרי כל include, כמו ששרת מקבל היה עושה.
שימו לב איך הרשומה מסתיימת ולמספר השאילתות: מה שתרצו לראות הוא “-all” או “~all” ו-10 שאילתות או פחות.

מה כל תוצאה אומרת

לדומיין הזה אין SPF: הוא לא מציין אילו שרתים רשאים לשלוח את האימייל שלו, וכך קל יותר להתחזות אליו. אם זה הדומיין שלכם, פרסמו רשומת SPF.
ברשומת ה-SPF יש שגיאות: שרתים מקבלים לא יכולים להחיל אותה, ולכן מבחינתם לדומיין אין SPF. הסימנים למטה מסבירים מה לא תקין.
כל אחד יכול לשלוח אימייל בשם הדומיין הזה: הרשומה מסתיימת ב“+all”, שמתיר לכל השרתים בעולם. כשהוא מוגדר כך, SPF לא מגן על כלום.
ה-SPF לא מגן על הדומיין באופן מלא: הרשומה לא אומרת מה לעשות עם שרתים שלא ברשימה שלה, ולכן אימייל מזויף בשם הדומיין לא מסומן.
ה-SPF מוגדר נכון: הדומיין מפרט את השרתים שרשאים לשלוח את האימייל שלו ומבקש מהשרתים המקבלים לסמן או לדחות את השאר. SPF לבדו לא עוצר התחזות: DMARC הוא שאומר לשרתים המקבלים מה לעשות.

מה כל סימן אומר

הדומיין לא מפרסם רשומת SPF.
דומיין (זה או דומיין כלול) מפרסם יותר מרשומת SPF אחת. מותרת רק אחת, ולכן השרתים המקבלים מתייחסים לכך כשגיאה.
ברשומה יש רכיב שכתוב לא נכון, ולכן השרתים המקבלים מתייחסים אליה כשגיאה.
הרשומה דורשת יותר מ-10 שאילתות DNS כשסופרים את כל ה-include. מעל 10, השרתים המקבלים מתייחסים אליה כשגיאה.
אחד ה-include מפנה לדומיין שאין לו רשומת SPF, ולכן השרתים המקבלים מתייחסים לרשומה כשגיאה.
ה-include יוצרים לולאה: דומיין בסופו של דבר כולל את עצמו.
הרשומה מסתיימת ב“+all”: כל שרת בעולם יכול לשלוח אימייל בשם הדומיין הזה.
הרשומה מסתיימת ב“?all”: היא לא אומרת כלום על שרתים שלא ברשימה, ולכן היא לא מגנה.
הרשומה מסתיימת ב“~all”: אימייל משרתים אחרים מסומן כחשוד אבל לא נדחה. זו ההגדרה הנפוצה ביותר.
אין “all” בסוף הרשומה, ולכן שרתים שלא ברשימה מקבלים תוצאה ניטרלית ואין שום הגנה.
הרשומה משתמשת ב“ptr”, מנגנון איטי שהתקן ממליץ להימנע ממנו. שרתים מקבלים רבים מדלגים עליו.
הרשומה משתמשת במאקרו (רכיבים עם %) שמשתנים בכל הודעה, ולכן אנחנו לא יכולים לעקוב אחרי החלק הזה ומספר השאילתות בפועל עשוי להיות גבוה יותר.

באילו מדינות הכלי עובד

עובד עם דומיינים מכל מדינה. אנחנו קוראים את הרשומה כמו שהשרתים המקבלים קוראים אותה (RFC 7208): המנגנונים שלה, איך היא מסתיימת, כל include ו-redirect עד 30 שאילתות, ומספר שאילתות ה-DNS שלה מול המגבלה של 10.

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

שאלות נפוצות

מה זה SPF?

Sender Policy Framework: רשומת DNS שבה דומיין מפרט את השרתים שמורשים לשלוח את האימייל שלו. השרת שמקבל הודעה בודק אם השרת שמסר אותה נמצא ברשימה הזו.

מה עדיף, “-all” או “~all”?

“-all” מבקש מהשרתים המקבלים לדחות אימייל משרתים שלא ברשימה; “~all” מבקש לסמן אותו כחשוד. שניהם מגנים, ודומיינים רבים משתמשים ב“~all” ומשאירים ל-DMARC להחליט מה לעשות. “+all” ו“?all” לא מגנים.

למה המגבלה של 10 שאילתות חשובה?

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

האם SPF לבדו עוצר אימיילים מזויפים?

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