שומרים את ההודעה ובודקים את הכתובת
אל תשיבו לשולח החשוד ואל תפתחו את הקישור או הקובץ המצורף. שמרו את ההודעה המקורית ואת שעת הקבלה. אם לקוח דיווח עליה, בקשו עותק מקורי או כותרות בערוץ מתאים, ללא מידע אישי שאינו נחוץ.
בדקו את כתובת From המלאה, כתובת Reply-To והדומיין המדויק. שם החברה בשדה התצוגה ולוגו בהודעה אינם הוכחה לזהות השולח. פנו לאיש הקשר דרך פרטים שכבר מוכרים לכם.
ארבעה מצבים שאסור לערבב
הטבלה היא מסגרת אבחון מוצעת, ולא מסקנה על הודעה מסוימת.
| מצב | מה אפשר לראות | המשך הבירור |
|---|---|---|
| שם תצוגה | שם העסק לצד כתובת חיצונית לא קשורה | אזהרה פנימית ובדיקה מול איש הקשר |
| דומיין דומה | שינוי אות, סיומת או מבנה הדומיין | תיעוד והעברה לטיפול מתאים; DMARC בדומיין שלכם לא שולט בו |
| זיוף הדומיין האמיתי | From משתמש בדומיין העסק אך האימות לא תואם | בדיקת כותרות, SPF/DKIM/DMARC ומקורות מורשים |
| תיבה שנפרצה | ייתכן אימות תקין לצד שליחה שלא אושרה | בדיקת כניסות, כללי העברה, הרשאות וחיבורים |
למה צריך כותרות דואר
תוצאת האימות שמוסיף שירות הקבלה מסייעת לברר איזה דומיין אומת ובאיזו שיטה. בוחנים את Authentication-Results שהוסיף שרת קבלה מהימן; טקסט שהשולח עצמו הוסיף אינו ראיה אמינה.
בדוגמה הבאה, שעוצבה להמחשה בלבד, דומיין החתימה שונה מדומיין From. כשלון SPF והיעדר התאמה ב-DKIM אינם מאפשרים להסיק לבדם מי שלח או האם התיבה נפרצה.
מה עושים לפי הממצאים
אם נחשדת השתלטות על התיבה, פועלים ממכשיר נקי ובתיאום עם מנהל הדואר: מגבילים גישה, מבטלים חיבורים, בודקים הרשאות יישומים וכללי העברה ומסדירים אימות נוסף. שומרים לוגים לפני פעולות שמוחקות מידע.
אם מדובר בזיוף דומיין, ממפים את השולחים הלגיטימיים ובודקים התאמת SPF או DKIM לדומיין הגלוי. אין לעבור מיד ל-reject בלי לוודא שמערכות האתר, CRM והדיוור ממשיכות לשלוח כראוי.
מתי לערב את העסק מעבר לצוות הטכני
כאשר נשלחה בקשת תשלום מזויפת או נחשף מידע, צריך לתאם עם בעל העסק ועם האחראים הרלוונטיים את הטיפול ואת ההודעות הנדרשות. שינוי טכני לא מבטל העברה כספית שכבר בוצעה. אימות של שינוי פרטי תשלום נעשה בערוץ עצמאי שהוכר קודם.
