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

בדיקת SPF, DKIM ו-DMARC: מדריך הגדרה צעד אחר צעד

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

אבירפורסם בתאריך: 11.10.20268 דק׳ קריאה

איך מגדירים 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

  1. רשומה אחת בלבד. שתי רשומות SPF על אותו דומיין מבטלות זו את זו. כשמוסיפים שירות חדש, מוסיפים אותו לרשומה הקיימת ולא יוצרים רשומה נוספת.
  2. עד עשר שאילתות DNS. כל include, וכן המנגנונים a ו-mx, נספרים. רשומה שחורגת מעשר נכשלת כולה. זו הסיבה הנפוצה לכך שרשומה שנראית תקינה אינה עובדת.
  3. מתחילים בכישלון רך, ~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 וקבלו בתוך שניות ציון, הסבר על כל רשומה ורשימת תיקונים לפי סדר עדיפות. הבדיקה חינמית ואינה דורשת הרשמה, ואפשר לחזור אליה אחרי כל שינוי כדי לוודא שהוא נקלט.

רוצים עדכונים חדשים?

נשלח לכם עדכון כשיעלו מאמרים ומדריכים חדשים. בלי ספאם — ואפשר להסיר את ההרשמה בכל עת.

בהרשמה אני מאשר/ת לאמפייר אייאל לשלוח לי בדוא״ל עדכונים על מאמרים חדשים, מדריכים וחדשות השירות. ניתן להסיר את ההרשמה בכל עת. מדיניות הפרטיות

מאמרים קשורים

Microsoft 365 Business: Basic, Standard או Premium?

Microsoft 365 Business: Basic, Standard או Premium?

שלושת רישיונות Microsoft 365 Business נבדלים ביישומי Office ובשכבת האבטחה. מדריך להתאמת רישיון לכל תפקיד, עם טבלת השוואה וטעויות נפוצות.

13.10.20268 דק׳
כמה עולה Microsoft 365 לעסק? ממה מורכבת העלות

כמה עולה Microsoft 365 לעסק? ממה מורכבת העלות

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

13.10.20268 דק׳