דואר עסקי בספאם: איך בודקים SPF, DKIM ו־DMARC?

דואר עסקי בספאם: קודם מגדירים את התקלה

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

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

השאלה הבאה היא מה היקף ההפרעה. האם היא מתרחשת אצל נמען אחד, אצל ארגון מסוים או בכמה שירותי דואר? בדקו אם רק החשבוניות נפגעו, או גם הודעות שהעובדים שולחים ידנית. נסו לזהות אם התקלה התחילה לאחר החלפת מערכת, דומיין או ספק. התשובות מכוונות את הבדיקה ומונעות שינוי מיותר במערכת שעובדת.

ממפים מי שולח בשם הדומיין

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

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

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

SPF: אילו שרתים רשאים לשלוח?

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

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

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

DKIM: חתימה דיגיטלית על ההודעה

DKIM מוסיף חתימה דיגיטלית לרכיבים של הודעת הדואר. המקבל בודק אותה בעזרת מידע שבעל הדומיין החותם פרסם ב־DNS. זו בדיקת מקור ושלמות של החלקים החתומים, ולא הצפנה של גוף ההודעה. היא גם אינה מבטיחה שהקישור או הקובץ המצורף בטוחים.

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

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

DMARC: ההתאמה לכתובת שהנמען רואה

DMARC מחבר את תוצאות האימות לדומיין בשדה ״מאת״. לצורך מעבר נדרשת לפחות דרך אחת תקינה ומתואמת: SPF שעבר עם דומיין מתאים, או DKIM שעבר עם דומיין חתימה מתאים. מצב שבו שתי הבדיקות עברו עבור דומיינים אחרים עדיין יכול להיכשל ב־DMARC.

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

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

מה בודקים במעקב ההודעות?

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

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

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

דוגמה מסומנת: Outlook תקין, חשבוניות בספאם

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

בבדיקה מתברר שמדובר בשני מסלולי שליחה. העובדים שולחים את ההודעות האישיות ממערכת הדואר, ואילו החשבוניות יוצאות משירות נפרד. הצוות אוסף כותרות של הודעה מכל מסלול ובודק איזה דומיין עבר SPF, מי חתם ב־DKIM ומה הייתה תוצאת DMARC. לאחר מכן הוא משווה את הממצאים להוראות ספק החשבוניות.

רק אם מזהים אי־התאמה מתכננים תיקון מתאים. לאחר השינוי שולחים הודעת בדיקה מוסכמת ובודקים שוב את האימות ואת מיקום המסירה. אם האימות תקין אך המקבל עדיין מסנן את ההודעה, ממשיכים לבדוק גורמים אחרים. אין להסיק שהפתרון לכל בעיית מסירה הוא להוסיף שרת לרשומה או להחליש את מדיניות הנמען.

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

האימות תקין ועדיין יש ספאם?

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

כאשר האימות תקין, ממשיכים לפי הראיות: האם הבעיה קשורה לתוכן מסוים, לקישור, לקובץ מצורף, לשינוי בהיקף השליחה או למדיניות של ארגון מקבל? אלה כיווני בירור, לא אבחנה אוטומטית. שומרים דוגמאות מייצגות ומשווים ביניהן בלי לשלוח שוב ושוב את אותה הודעה לקבוצת לקוחות.

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

איך משנים בלי לפגוע במערכות אחרות?

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

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

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

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

שאלות נפוצות על דואר עסקי בספאם

האם SPF לבדו מספיק?

לא. הוא בודק מקור שליחה עבור דומיין המעטפה ואינו מחליף חתימת DKIM או בדיקת התאמה ב־DMARC. יש לבחון את המערך המלא ואת ההודעה בפועל.

למה לא להוסיף מיד את העסק לרשימת המורשים?

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

מה צריך להעביר לחברת המחשוב?

דוגמה מייצגת, זמן שליחה, מערכת המקור, הודעת שגיאה וכותרות אם ההודעה נמצאה. מוסרים רק את המידע הנדרש בערוץ מורשה, בלי סיסמאות או קודי אימות.

האם אפשר להבטיח שכל הודעה תגיע לדואר הנכנס?

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

בדקנו את המקורות הרשמיים ב־15 באוקטובר 2026. התהליך והדוגמה מוצעים להתאמה, ואינם הוראה לשנות רשומות ללא בדיקת הסביבה. לקבלת סיוע בבירור ובהגדרות ראו שירותי מחשוב לעסקים של Hot PC.