למי מתאים שירות הגדרת SPF, DKIM ו-DMARC
השירות מתאים לעסק ששולח דואר דרך Google Workspace או Microsoft 365, וגם לעסק שמוסיף אתר, מערכת CRM, שירות חשבוניות או מערכת דיוור. לכל מקור שליחה יכולה להיות הגדרה שונה. מצב שבו העובדים שולחים בהצלחה אינו מוכיח שהודעות איפוס סיסמה מהאתר או חשבוניות חודשיות משתמשות באותו מסלול.
כדאי לבדוק את התצורה גם אחרי מעבר ספק, קבלת דרישת אימות ממערכת דיוור או דיווח על הודעה חשודה בשם העסק. אם חשבון אמיתי נפרץ, נדרש במקביל טיפול בגישה לתיבה ובהרשאות. שינוי רשומת DNS אינו מבטל כניסה שנגנבה, והונאה באמצעות שם תצוגה או דומיין דומה יכולה להתרחש גם כשהאימות תקין.
מה בודקים בכל אחד משלושת הפרוטוקולים
SPF, DKIM ו-DMARC ממלאים תפקידים משלימים. השאלה בבדיקה אינה רק אם קיימות שלוש רשומות, אלא האם ההודעה שנשלחה בפועל משתמשת בהן כנדרש. לפי תקן DMARC, הודעה עוברת כשהיא עוברת לפחות אחד ממסלולי האימות, SPF או DKIM, וגם עומדת בהתאמת הדומיין של אותו מסלול לכתובת From הגלויה.
חשוב להפריד בין תנאי מעבר DMARC לבין דרישות של ספק מקבל. Gmail, למשל, מפרט דרישות שונות לסוגי שולחים, ובהן דרישות נוספות לשולחים בכמות גדולה. לכן אין להסיק מהצלחה של בדיקה אחת שכל דרישות המסירה מול כל ספק הושלמו.
| מנגנון | השאלה שהוא בודק | מה לא ניתן להסיק ממנו לבדו |
|---|---|---|
| SPF | האם מקור השליחה מורשה עבור דומיין מעטפת ההודעה | שהדומיין תואם לכתובת From שהנמען רואה |
| DKIM | האם חתימה בדומיין מסוים אומתה עבור החלקים החתומים | שמדובר באדם אמין או בתוכן שאינו הונאה |
| DMARC | האם קיים מסלול אימות שעבר וגם תואם לדומיין From | שההודעה תגיע בהכרח לתיבת הדואר הנכנס |
| דוחות מצטברים | מה מקבלים מדווחים על הודעות ושולחים שנצפו | שכל הודעה או כל יעד מסירה מופיעים בדוח |
מיפוי שולחים: השלב שקודם לשינוי DNS
אנחנו מבקשים לזהות כל מערכת ששולחת בשם העסק, מי מנהל אותה ואיזו הודעה אפשר להפיק ממנה לבדיקה. לא מסתפקים בשם ספק הדואר הראשי. טופס באתר, מערכת תמיכה או שירות שהנהלת החשבונות מפעילה יכולים לשלוח מדומיין העסק בלי להיות מוכרים למי שמנהל את התיבות.
המיפוי הוא גם כלי להחלטה: מקור לא מוכר דורש בירור, ולא הרשאה אוטומטית. ייתכן שמדובר בשירות שהופסק, בהעברה דרך מערכת אחרת או בניסיון התחזות. לפני שמוסיפים מקור ל-SPF או מחברים חתימת DKIM, מוודאים שיש בעל אחריות ושימוש עסקי שאושר.
| מערכת | הודעת בדיקה | מה צריך לברר לפני שינוי |
|---|---|---|
| דואר העובדים | הודעה מתיבה עסקית | ספק פעיל, דומיין From וחתימת הדומיין |
| אתר או חנות | טופס או אישור הזמנה בבדיקה | מסלול SMTP או API ושירות השליחה בפועל |
| חשבוניות | מסמך בדיקה שאינו חיוב אמיתי | בעל חשבון הספק ואפשרויות אימות הדומיין |
| CRM ואוטומציות | התראה מתהליך מבוקר | האם כל סוגי ההתראות משתמשים באותו שולח |
| מערכת דיוור | משלוח לרשימת בדיקה מורשית | דומיין חתימה, כתובת החזרה ודרישות הספק |
איך מתבצעת ההגדרה ומה נדרש מהעסק
נדרשות הרשאות מתאימות במקום שבו מנוהל ה-DNS ולעיתים גם בממשק של כל שירות שולח. רשם הדומיין, חברת האחסון וספק הדואר יכולים להיות שלוש חברות שונות. בשלב הראשון מזהים מי מנהל מה, מתעדים את הרשומות הקיימות ומתאמים מי מאשר שינוי. אין צורך למסור סיסמאות בטופס הפנייה.
ב-Google Workspace וב-Microsoft 365 עובדים לפי ההוראות של הספק והתצורה הקיימת. מערכת חיצונית עשויה לדרוש הגדרה נפרדת; הפעלת חתימה בדואר העובדים אינה מפעילה אותה אוטומטית בשירות החשבוניות. כתובת רשומת DKIM והערך שלה נקבעים לפי המערכת, ולא באמצעות העתקת רשומה מעסק אחר.
- מאשרים את הדומיינים, המערכות השולחות ובעלי ההרשאות הכלולים.
- מתעדים DNS קיים ותלויות לפני שינוי, ומגדירים דרך חזרה מבוקרת.
- מתאימים SPF ומפעילים DKIM במערכות התומכות בהתאם להגדרות הספק.
- מפיקים הודעות בדיקה מכל מסלול שנכלל ובוחנים את תוצאות האימות אצל המקבל.
- מגדירים DMARC ויעד לדוחות בהתאם להיקף, ובוחנים מקורות וחריגות.
- קובעים אם ניתן להתקדם באכיפה ומעבירים תיעוד ואחריות להמשך.
איך יודעים שההגדרה עובדת, מעבר לבדיקה של רשומות
רשומה פומבית היא חלק מהראיה. לצורך בדיקת קבלה מפיקים הודעה מתהליך עסקי מוגדר, שומרים את מועד הבדיקה ומבררים באיזו מערכת היא נוצרה. בכותרות שהוסיף המקבל הנבדק בוחנים את תוצאות האימות וההתאמה. בודקים גם שהפעולה העסקית הושלמה, למשל שהודעת טופס הגיעה ליעד שנבחר.
כותרת שהועתקה ממקור לא מהימן אינה מספיקה להוכחת הצלחה. גם בדיקה מוצלחת לתיבה אחת אינה מייצגת את כל הספקים, העברות הדואר או התהליכים הנדירים. בסיכום מפרטים את מסלולי הבדיקה והיעדים שנבדקו, ומתעדים מה עדיין דורש בדיקה במקום לסמן את הדומיין כמוגן לחלוטין.
מתי מתקדמים מ-none ל-quarantine או reject
מדיניות none מאפשרת להתחיל מתצפית בלי לבקש מהמקבלים חסימה על בסיס DMARC. מדיניות quarantine מבקשת טיפול חשוד בהודעות שנכשלות, ו-reject מבקשת דחייה. ההחלטה אינה מבוססת רק על מספר ימים שעברו: צריך להבין אילו שולחים לגיטימיים נבדקו ואילו תהליכים טרם נצפו. למקבל נשארת מדיניות טיפול משלו.
לפני התקדמות מגדירים מי בוחן חריגות, איך מזהים פגיעה בדואר תקין ומי רשאי לאשר שינוי נוסף. הודעות חודשיות או עונתיות דורשות דוגמת בדיקה או מעקב מתאים. אם מתגלה כשל, בוחנים את המסלול הפגוע ואת הראיות לפני שינוי גורף. המדריך למעבר ל-DMARC reject מפרט את הבירור למי שרוצה להעמיק.
| שאלה | ראיה רצויה | אם אין תשובה |
|---|---|---|
| האם כל המערכות המוכרות נבדקו? | רשימת שולחים ותוצאות הודעות | משלימים מסלולים חסרים |
| האם מקור לא מוכר הוסבר? | בעל מערכת והסבר למסלול | מבררים לפני מתן הרשאה |
| האם אפשר לזהות פגיעה בשליחה? | איש קשר, יעד בדיקה ודרך דיווח | מסכמים מעקב לפני התקדמות |
| מי מטפל בשינוי ספק בעתיד? | אחריות ותהליך הוספת שולח | מגדירים בעלות כחלק מהמסירה |
מה מקבלים בסיום ומי אחראי על הדוחות
התוצר המוסכם כולל מפת שולחים, הרשומות ששונו, תוצאות בדיקות והחלטה לגבי מדיניות DMARC. חריגות נשארות ברשימה נפרדת עם הצעד הבא ובעל האחריות. תיעוד טוב מסביר גם מה יידרש כשמתווסף שירות חדש, כדי שההגדרה לא תיפגע עם החלפת מערכת דיוור או CRM.
יעד לקבלת דוחות אינו שירות ניטור בפני עצמו. מגדירים מי קורא את הדוחות, באיזו תקופה ובאיזה כלי, ומי פונה לספק במקרה הצורך. דוחות יכולים לכלול מידע תפעולי על השליחה, ולכן מבררים גם מי מקבל גישה אליהם. שירות ניתוח חיצוני, רישיון או מעקב שוטף נכללים רק כשהוסכמו בהצעה.
מה משפיע על המחיר ועל הזמן הנדרש
המחיר תלוי במספר הדומיינים, מקורות השליחה, מצב ההגדרות וזמינות בעלי ההרשאות. עסק ששולח רק מספק דואר אחד שונה מעסק עם חנות, מערכות דיוור וכמה ספקי חשבוניות. נדרש זמן נוסף כשצריך לברר מי שולח, לתאם עם ספק חיצוני או לבדוק הודעות שלא נוצרות בכל יום.
מפרידים בהצעה בין הגדרה, אבחון תקלה קיימת ומעקב לאחר ההגדרה. זמינות DNS במטמונים, הפעלת שירות אצל ספק והשלמת דגימות אינן תמיד מיידיות, ולכן אין זמן אחיד שאפשר להבטיח לכל עסק. לפני הביצוע מסכמים תכולה, מחיר, תלויות ואופן מסירת התוצאות.
מה השירות לא פותר ומה אפשר להכין כבר עכשיו
אימות דואר אינו מסנן כל פישינג ואינו מבטיח מסירה לתיבה הראשית. מוניטין השולח, תוכן, הסכמת נמענים וכללי המקבל משפיעים גם הם. במקרה של דחייה או ספאם צריך לבחון את הודעת השגיאה והמסלול שנפגע, ולא לשנות רשומות לפי ניחוש. הגנה על חשבונות העובדים והרשאות היא שכבה נפרדת.
לפנייה ציינו את הדומיין, ספק הדואר ושמות המערכות השולחות הידועות לכם. אם יש תקלה, הוסיפו מתי התחילה ואיזו הודעה אינה מגיעה, בלי תוכן אישי של לקוחות. כלי בדיקת הדומיין באתר מספק תצפיות DNS ראשוניות; הוא אינו מאמת חתימת DKIM בהודעה ואינו מחליף בדיקת מסלול שליחה מלאה.