בדיקת SPF, DKIM ו-DMARC: מדריך הגדרה צעד אחר צעד
שלוש רשומות DNS קובעות אם המיילים שלכם מגיעים ליעד. מדריך הגדרה מסודר עם דוגמאות, סדר עבודה, טעויות נפוצות ובדיקה של התוצאה.
איך מגדירים SPF, DKIM ו-DMARC, ואיך בודקים שזה עובד? מגדירים שלוש רשומות TXT ב-DNS של הדומיין, בסדר הזה: רשומת SPF שמפרטת מי מורשה לשלוח דואר בשם הדומיין, מפתח DKIM לכל שירות ששולח, ורשומת DMARC שקובעת מה לעשות עם הודעה שנכשלה באימות. אחרי כל שלב מבצעים בדיקת SPF, DKIM ו-DMARC בכלי בדיקה, ומחמירים את המדיניות בהדרגה. התהליך כולו לוקח כמה שבועות, ורוב הזמן הוא המתנה לדוחות ולא עבודה.
המדריך הזה עובר על ההגדרה צעד אחר צעד, עם דוגמאות לרשומות. אם המיילים שלכם כבר נכנסים לספאם ואתם מחפשים אבחון של הבעיה, התחילו במדריך על מיילים מהאתר שלא מגיעים, וחזרו לכאן להגדרה.
מה כל רשומה עושה, בשורה אחת
| רשומה | איפה היא נמצאת | על מה היא עונה |
|---|---|---|
| SPF | רשומת TXT בשורש הדומיין | אילו שרתים מורשים לשלוח דואר בשם הדומיין |
| DKIM | רשומת TXT תחת שם שנקרא סלקטור | האם ההודעה נחתמה על ידי הדומיין ולא שונתה בדרך |
| DMARC | רשומת TXT בכתובת _dmarc של הדומיין | מה עושים עם הודעה שנכשלה, ולאן שולחים דוחות |
שלוש הרשומות משלימות זו את זו. SPF ו-DKIM הם שני מנגנוני אימות, ו-DMARC הוא המדיניות שנשענת עליהם.
לפני שמתחילים: ממפים את כל מי ששולח בשמכם
זה השלב שרוב מי שנכשל מדלג עליו. לפני שנוגעים ב-DNS, רושמים כל שירות ששולח דואר עם הדומיין שלכם בשדה השולח:
- תיבות הדואר של העובדים, למשל שירות דואר עסקי.
- האתר עצמו: טפסי יצירת קשר, אישורי הזמנה, איפוס סיסמה.
- מערכת דיוור לניוזלטרים.
- מערכת CRM או מערכת חשבוניות.
- מערכת כרטיסי תמיכה.
- מכשירים במשרד ששולחים סריקות או התראות.
- תוכנות שרצות בסביבת עבודה מרוחקת. עסקים שעובדים במשרד בענן שולחים לעיתים חשבוניות ודוחות ישירות מתוכנת הניהול שמותקנת שם, וגם היא נחשבת שולח.
כל שירות שיישכח ייחסם ברגע שהמדיניות תוחמר. כדאי לבדוק גם איפה מנוהל ה-DNS של הדומיין. אם אינכם בטוחים, בדיקת WHOIS מציגה את שרתי השמות, ומהם מבינים אצל איזה ספק עורכים את הרשומות.
שלב ראשון: רשומת SPF
רשומת SPF היא רשומת TXT אחת בשורש הדומיין. היא מתחילה ב-v=spf1, ממשיכה ברשימת המורשים, ומסתיימת בהוראה מה לעשות עם כל השאר.
דוגמה לדומיין שהדואר שלו מנוהל בשירות דואר בענן, והאתר שלו שולח משרת עם כתובת קבועה:
example.co.il. TXT "v=spf1 include:_spf.google.com ip4:203.0.113.25 ~all"
מה כל חלק אומר:
- v=spf1 מזהה את הרשומה כרשומת SPF.
- include: מאשר את כל השרתים של ספק מסוים. כל ספק דיוור מפרסם את הערך שצריך להוסיף.
- ip4: מאשר כתובת IP מסוימת, למשל של שרת האתר.
~allאומר שכל שרת אחר חשוד, אבל לא נדחה מיד.-allאומר שכל שרת אחר נדחה.
שלושת הכללים של SPF
- רשומה אחת בלבד. שתי רשומות SPF על אותו דומיין מבטלות זו את זו. כשמוסיפים שירות חדש, מוסיפים אותו לרשומה הקיימת ולא יוצרים רשומה נוספת.
- עד עשר שאילתות DNS. כל include, וכן המנגנונים a ו-mx, נספרים. רשומה שחורגת מעשר נכשלת כולה. זו הסיבה הנפוצה לכך שרשומה שנראית תקינה אינה עובדת.
- מתחילים בכישלון רך,
~all. עוברים לכישלון קשיח,-all, רק אחרי שמוודאים שכל השולחים רשומים.
שלב שני: DKIM לכל שירות ששולח
DKIM מוסיף לכל הודעה חתימה דיגיטלית. המפתח הפרטי נשאר אצל השירות ששולח, והמפתח הציבורי מתפרסם ב-DNS תחת שם שנקרא סלקטור.
את המפתח לא ממציאים לבד. כל שירות דואר מייצר אותו בלוח הניהול שלו ונותן לכם שני דברים: שם הסלקטור, והערך לרשומה. נראה כך:
selector1._domainkey.example.co.il. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...AQAB"
כמה דברים שכדאי לדעת:
- לכל שירות סלקטור משלו. לשירות הדואר, למערכת הדיוור ולאתר יש מפתחות נפרדים, וכולם יכולים להתקיים יחד.
- יש שירותים שנותנים רשומת CNAME במקום TXT, שמפנה למפתח שהם מנהלים. זה תקין, וכך הם יכולים להחליף מפתחות בלי שתצטרכו לגעת ב-DNS.
- אורך המפתח. מפתח של 2048 ביט הוא הסטנדרט המומלץ היום. מפתח של 1024 ביט נחשב חלש.
- אחרי שמוסיפים את הרשומה, מפעילים את החתימה בלוח הניהול של השירות. הרשומה לבדה אינה חותמת על דבר.
שלב שלישי: DMARC במצב ניטור
עכשיו מוסיפים את המדיניות. מתחילים תמיד במצב שרק מדווח ואינו חוסם:
_dmarc.example.co.il. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.co.il"
- p=none אומר לשרתים המקבלים לא לשנות דבר בטיפול בהודעות, רק לדווח.
- rua היא הכתובת שאליה נשלחים דוחות מסכמים, בדרך כלל פעם ביום מכל ספק דואר גדול.
הדוחות מגיעים כקובצי XML, וקשה לקרוא אותם בעין. כדאי להפנות אותם לתיבה ייעודית, ולהשתמש בשירות שמסכם אותם לטבלה.
מה זה יישור, ולמה הוא חשוב
DMARC לא מסתפק בכך ש-SPF או DKIM עברו. הוא דורש שהדומיין שאומת יתאים לדומיין שמופיע בשדה השולח שהנמען רואה. זה נקרא יישור (alignment).
המשמעות המעשית: מערכת דיוור יכולה לעבור SPF עם הדומיין שלה, ועדיין להיכשל ב-DMARC, כי הדומיין שאומת אינו שלכם. הפתרון הוא להגדיר במערכת הדיוור חתימת DKIM עם הדומיין שלכם. לכן השלב השני חשוב כל כך.
שלב רביעי: קוראים דוחות ומחמירים בהדרגה
משאירים את המדיניות במצב ניטור שבועיים עד ארבעה, וקוראים את הדוחות. מחפשים שני דברים: שירותים לגיטימיים שנכשלים, שאותם מתקנים, ומקורות לא מוכרים, שהם ניסיונות התחזות או שירות שנשכח.
כשכל השולחים הלגיטימיים עוברים, מחמירים בשלבים:
| שלב | רשומה | מה קורה להודעה שנכשלה |
|---|---|---|
| ניטור | p=none | כלום, רק דיווח |
| הסגר חלקי | p=quarantine; pct=25 | רבע מההודעות שנכשלו עוברות לספאם |
| הסגר מלא | p=quarantine | כל ההודעות שנכשלו עוברות לספאם |
| דחייה | p=reject | ההודעות שנכשלו נדחות ואינן מגיעות כלל |
בין שלב לשלב ממתינים שבוע או שניים וממשיכים לקרוא דוחות. p=reject הוא היעד: רק אז מי שמנסה להתחזות לדומיין שלכם נחסם באמת.
אם יש לכם תת-דומיינים ששולחים דואר, אפשר לקבוע להם מדיניות נפרדת באמצעות התג sp.
איך בודקים את התוצאה
אחרי כל שינוי בודקים, ולא מניחים שעבד. שינויים ב-DNS אינם מיידיים: עד שהערך הקודם פג אצל שרתים אחרים עוברות דקות עד שעות, לפי ערך ה-TTL של הרשומה.
בדיקה כוללת. בדיקת SPF, DKIM ו-DMARC החינמית שלנו מקבלת דומיין ומחזירה ציון, הסבר בעברית על כל רשומה והמלצות לתיקון. הכלי סופר את שאילתות ה-DNS ברשומת ה-SPF, בודק את אורך מפתח ה-DKIM ומציג את מדיניות ה-DMARC. אם אינכם יודעים את שם הסלקטור, הוא בודק את הנפוצים, ואפשר גם להזין סלקטור מסוים.
בדיקת הרשומה עצמה. בדיקת רשומות DNS מציגה את רשומות ה-TXT כפי שהן מתפרסמות בפועל, כך שרואים אם הערך שהזנתם אכן התעדכן, ואם לא נשארה רשומה כפולה.
בדיקה מהשטח. שולחים הודעה לתיבה בשירות דואר גדול, ופותחים את פרטי ההודעה המקוריים. מחפשים שלוש שורות: spf=pass, dkim=pass ו-dmarc=pass. אם אחת מהן מראה fail, שם הבעיה.
רשימת בדיקה מסכמת
- מיפינו את כל השירותים ששולחים דואר בשם הדומיין.
- יש רשומת SPF אחת בלבד, והיא כוללת את כל השולחים.
- הרשומה אינה חורגת מעשר שאילתות DNS.
- לכל שירות ששולח הוגדר DKIM עם הדומיין שלנו, והחתימה הופעלה.
- יש רשומת DMARC עם כתובת לדוחות.
- קראנו דוחות במשך שבועיים לפחות לפני שהחמרנו.
- המדיניות הגיעה ל-quarantine, והיעד הוא reject.
- יש מי שאחראי לעדכן את הרשומות כשמוסיפים שירות חדש.
טעויות נפוצות
- שתי רשומות SPF. קורה כשמוסיפים שירות חדש בלי לבדוק מה כבר קיים.
- יותר מדי include. כל ספק מוסיף שאילתות, ובסוף עוברים את המגבלה. מסירים שירותים שכבר לא בשימוש.
- קפיצה ישר ל-p=reject. בלי תקופת ניטור, שירות שנשכח מפסיק לשלוח, ומגלים זאת כשלקוח מתלונן שלא קיבל חשבונית.
- DMARC בלי כתובת לדוחות. בלי דוחות אין דרך לדעת מה נכשל.
- העתקה שגויה של מפתח DKIM. רווח מיותר או שורה חתוכה פוסלים את המפתח. יש ממשקי DNS שדורשים לפצל ערך ארוך לכמה מחרוזות.
- לשכוח את האתר. טופס יצירת הקשר שולח דואר, וגם הוא צריך להיות מכוסה.
- להגדיר ולשכוח. החלפתם מערכת דיוור? הרשומות צריכות להתעדכן.
ומה עם הדואר העסקי עצמו?
כל ההגדרות האלה מניחות שיש לכם שירות דואר מסודר על הדומיין שלכם. אם אתם עדיין שולחים מכתובת פרטית, או שהדואר יושב על אחסון האתר, כדאי לקרוא קודם את המדריך דואר עסקי על הדומיין שלכם. כשהדואר מנוהל בשירות ייעודי, הגדרת האימות פשוטה יותר, כי הספק מספק את הערכים המדויקים לכל רשומה.
שאלות נפוצות
כמה זמן לוקח עד שהשינויים ב-DNS נכנסים לתוקף?
בדרך כלל בין כמה דקות לכמה שעות, לפי ערך ה-TTL שהוגדר לרשומה. כדאי להמתין ולבדוק שוב לפני שמסיקים שמשהו לא עבד.
האם חייבים את שלוש הרשומות?
כן, אם רוצים הגנה מלאה. SPF לבדו אינו מגן על הכתובת שהנמען רואה, DKIM לבדו אינו קובע מה לעשות בכישלון, ו-DMARC אינו עובד בלי אחד מהם לפחות. ספקי דואר גדולים מסננים יותר ויותר הודעות שנשלחות בלי אימות תקין.
מה ההבדל בין כישלון רך לכישלון קשיח ברשומת SPF?
כישלון רך, שנכתב ~all, מסמן הודעות משרתים לא מורשים כחשודות. כישלון קשיח, שנכתב -all, מורה לדחות אותן. מתחילים ברך, ועוברים לקשיח אחרי שמוודאים שכל השולחים רשומים.
למה ה-SPF שלי נכשל אם הרשומה נראית נכונה?
הסיבות הנפוצות הן חריגה מעשר שאילתות DNS, שתי רשומות SPF על אותו דומיין, או שירות ששולח מכתובת שלא נכללה. כלי בדיקה שסופר את השאילתות מראה מיד אם זו הבעיה.
האם p=none מגן עליי?
לא. p=none הוא מצב ניטור בלבד. הוא מאפשר לאסוף דוחות ולהבין מי שולח בשמכם, אבל אינו חוסם התחזות. ההגנה מתחילה ב-quarantine ומושלמת ב-reject.
האם צריך להגדיר את הרשומות גם לדומיין שלא שולח דואר?
כן, וזה פשוט. לדומיין שאינו שולח דואר כלל מגדירים SPF שאינו מאשר אף שרת ומדיניות DMARC של דחייה, כך שאף אחד לא יוכל להתחזות אליו.
רוצים לבדוק את הדומיין שלכם עכשיו?
הזינו את הדומיין בכלי לבדיקת SPF, DKIM ו-DMARC וקבלו בתוך שניות ציון, הסבר על כל רשומה ורשימת תיקונים לפי סדר עדיפות. הבדיקה חינמית ואינה דורשת הרשמה, ואפשר לחזור אליה אחרי כל שינוי כדי לוודא שהוא נקלט.
רוצים עדכונים חדשים?
נשלח לכם עדכון כשיעלו מאמרים ומדריכים חדשים. בלי ספאם — ואפשר להסיר את ההרשמה בכל עת.
בהרשמה אני מאשר/ת לאמפייר אייאל לשלוח לי בדוא״ל עדכונים על מאמרים חדשים, מדריכים וחדשות השירות. ניתן להסיר את ההרשמה בכל עת. מדיניות הפרטיות
