include שלא היה קיים
רשומת SPF הפנתה לכתובת של ספק שפשוט לא נפתרת ב-DNS. שבעה דומיינים נכשלו באימות במשך שבועות, ובדיקה אוטומטית שנעלה את הערך אישרה אותו במקום לתפוס אותו. מאז הבדיקה שואלת אם הכתובת נפתרת בפועל.
DNS
שלוש רשומות שקובעות אם הדואר שלכם נכנס
SPF אומר מי מורשה לשלוח בשם הדומיין, DKIM חותם על ההודעה כדי שאפשר יהיה לאמת שלא שונתה, ו-DMARC אומר לנמען מה לעשות כששתי הראשונות נכשלות. בלי שלושתן, גם דואר לגיטימי לחלוטין מסונן.
אנחנו כותבים את שלושתן, בודקים אותן, ומתקנים כשמשהו זז אצל הרשם
שלושתן
מה כל רשומה עושה, בשורה אחת
| הרשומה | מה היא אומרת | מה קורה בלעדיה |
|---|---|---|
| SPF | אלה השרתים שמורשים לשלוח בשם הדומיין הזה | כל אחד יכול לשלוח בשמכם, וחלק מהתיבות יסננו גם אתכם |
| DKIM | ההודעה חתומה, ואפשר לאמת שהיא לא שונתה בדרך | אין הוכחה שההודעה יצאה מכם, ו-DMARC לא יכול לעבור |
| DMARC | אם SPF ו-DKIM נכשלים, עשה כך, ודווח לי | אין מדיניות, אין דוחות, ואין דרך לדעת שמתחזים לכם |
שלושתן נבדקות אצל הנמען, לא אצלכם. זו הסיבה שאפשר להיות בטוחים שהכול תקין ולגלות ההפך רק מלקוח.
איפה זה נשבר
שש התקלות הנפוצות. כמה מהן יש לכם
סמנו כל תקלה שאתם לא בטוחים שאין לכם. כאן ציון גבוה הוא הבעיה.
מתוך 6
אף תקלה לא מסומנת. אם זה מפני שבדקתם, מצוין. אם זה מפני שלא בדקתם, הסריקה למטה לוקחת דקה.
כל תקלה מסומנת היא דואר שנופל בשקט אצל חלק מהנמענים. את כולן אפשר לראות בסריקה לקריאה בלבד.
שש מתוך שש. זה לא נדיר: אלה בדיוק התקלות שנצברות בדומיין שעבר כמה ספקים. הסריקה תראה איזו מהן קיימת באמת.
מהשטח
שלוש תקלות שקרו לנו, וזו הסיבה שאנחנו כותבים את זה
המקרים האלה קרו בתשתית שלנו, נמצאו ותוקנו. הם כאן כי הם מלמדים יותר מכל טבלה:
מפתחות DKIM שנמחקו
בדיקה תקופתית זיהתה מפתח שנראה חסר וייצרה אותו מחדש, ובכך מחקה את הקיים. מאז יש חלון המתנה של חצי שעה לפני יצירה מחדש, ורק כשכל המפתחות חסרים.
רשומה נכונה בצילום מסך שנשמר
הרשומה תוקנה במערכת, אבל צילומי מצב ישנים שנשמרו על ארבעה דומיינים המשיכו להציג ללקוח את הערך המת. תיקון במקום אחד אינו תיקון אם משטח אחר מציג עותק שמור.
מה עושים
מ-DMARC none ועד reject, בלי לחסום את עצמכם
הסדר הנכון, כי מעבר ישיר ל-reject חוסם גם מערכות שלכם שלא ידעתם ששולחות.
- יום 0 p=none דיווח בלבד. מתחילים לקבל דוחות על כל מי ששולח בשמכם
- שבוע 2 קוראים את הדוחות מוצאים את המערכת הישנה, את המדפסת, את הספק שנשכח
- שבוע 4 p=quarantine מה שנכשל הולך לספאם, לא נזרק. עדיין רואים
- שבוע 8 p=reject רק אחרי חודש של דוחות נקיים. עכשיו אי אפשר להתחזות לכם
שאלות על רשומות DNS לדואר
אפשר לשים שתי רשומות SPF על דומיין אחד
לא, וזו התקלה הנפוצה ביותר שאנחנו רואים. התקן מגדיר רשומת SPF אחת בדיוק, ושתיים גורמות לכל הבדיקה להיכשל, כולל עבור השולח החוקי. את שני הספקים מאחדים לרשומה אחת עם שני include.
מה זה alignment ולמה DMARC נכשל למרות ש-DKIM תקין
DMARC דורש שהדומיין שנבדק ב-SPF או ב-DKIM יתאים לדומיין שמופיע לנמען בשורת השולח. חתימת DKIM תקינה על דומיין של ספק אינה מיישרת מול הדומיין שלכם, ולכן DMARC נכשל למרות ששתי הבדיקות עברו כל אחת בנפרד.
כמה זמן צריך להישאר ב-DMARC none לפני שמהדקים
לפחות שבועיים של דוחות, ובארגון עם הרבה מערכות ששולחות, לרוב חודש. המטרה של השלב הזה היא לגלות מי עוד שולח בשמכם ולא ידעתם: מערכת שיווק ישנה, מדפסת, או ספק חיצוני. מעבר ל-reject לפני שמצאתם את כולם חוסם אותם.
למה יש מגבלה של עשר בדיקות DNS ב-SPF
כדי שבדיקה אחת לא תגרור עשרות שאילתות DNS ותשמש לתקיפה. כל include נחשב, ו-include לספק גדול יכול לגרור כמה בעצמו. רשומה שעוברת את המגבלה נכשלת בשקט, ורוב הכלים במסך לא יראו זאת כי הם לא סופרים לעומק.
אפשר לבדוק שהרשומות באמת עובדות
כן, ורק כך כדאי. הדרך האמינה היא לשלוח הודעה לכתובת חיצונית ולפתוח את פרטי ההודעה המקוריים אצל הנמען, שם מופיעות שלוש התוצאות במפורש. בדיקה במסך של הרשם מראה מה כתבתם, לא מה העולם רואה.
לבדוק את שלוש הרשומות שלכם עכשיו
סריקה לקריאה בלבד שמראה איך הדומיין שלכם נראה לנמען, ומה חסר.
לבדוק דומיין