החלפת מפתח DKIM היא פעולה חשובה, אבל היא אינה עוצרת לבדה מתקפת DKIM Replay. במתקפה כזו התוקף אינו מזייף חתימה: הוא משיג הודעה חוקית שכבר נחתמה ושולח אותה שוב, ללא שינוי. לכן SPF עשוי להיכשל, אך DKIM המיושר לדומיין עדיין עובר — וגם DMARC עשוי לעבור אפילו במדיניות p=reject.
למה DMARC לא חוסם את ה-Replay?
DMARC דורש ש-SPF או DKIM יעברו ויהיו מיושרים לדומיין From. אם התוקף משדר מחדש את גוף ההודעה והכותרות החתומות בלי לשנות אותם, חתימת DKIM המקורית נשארת תקפה. השרת המקבל רואה הודעה בעלת חתימה חוקית, גם אם כתובת ה-IP השולחת אינה שייכת לתשתית המקורית.
קודם כול: לוודא שזה Replay
- השוו Message-ID, חתימת DKIM, תוכן וכותרות בין העותקים.
- בדקו אם ה-IP השולח מוכר ומורשה או שייך ל-relay לגיטימי.
- חפשו נפח חריג: הרבה הודעות עם DKIM pass ממקורות שלא הופיעו במלאי השולחים.
- השלימו מיפוי של כל המערכות ששולחות בשם הדומיין לפני הסרת selector.
הטעות הנפוצה: לסובב מפתח ולהשאיר את הישן ב-DNS
יצירת מפתח חדש אינה מבטלת את החתימות הישנות. כל עוד הרשומה הציבורית של ה-selector הישן זמינה ב-DNS, שרתים יכולים לאמת הודעות ישנות שנחתמו באמצעותו. לאחר שהודעות לגיטימיות שנמצאות בתנועה הגיעו ליעדן, יש להסיר את הרשומה הישנה — בזהירות ובהתאם למלאי השולחים.
סדר תגובה מעשי
- שמרו ראיות ברמת ההודעה ואשרו שמדובר בשידור חוזר.
- זהו איזה selector ואיזה דומיין חתמו על ההודעה.
- עצרו או הגבילו את מקור החשיפה הראשוני אם הוא ידוע.
- עברו לחתימה במפתח חדש בכל השולחים המורשים.
- המתינו לחלון סביר להודעות לגיטימיות בתנועה ואז הסירו את רשומת ה-selector הישן.
- נטרו ניסיונות אימות מול הרשומה הישנה וחריגות נפח לאחר ההסרה.
ניטור ב-Amazon SES
AWS ממליצה לחבר Configuration Set של SES ליעד אירועים כמו Amazon Data Firehose או EventBridge, ולהשוות את אירועי המסירה לדוחות DMARC מסוג rua. כאשר דוחות DMARC מציגים DKIM pass מכתובות IP שלא מופיעות באירועי השליחה של SES, במיוחד בנפח גדול, מתקבל אות חזק ל-Replay.
ב-Route 53 אפשר להגדיר TTL קצר יחסית, למשל כ-300 שניות, לפני החלפה מתוכננת ולהפעיל DNS query logging כדי לראות אם ממשיכים לבקש את ה-selector הישן. מומלץ שההתראה תגיע לאדם לבחינה; הסרה אוטומטית עלולה לשבור דואר לגיטימי. ב-BYODKIM הארגון שולט ברשומת ה-TXT, ואילו Easy DKIM מנוהל על ידי AWS.
מה כן עושה DMARC
מעבר הדרגתי מ-p=none ל-p=quarantine ולבסוף p=reject נשאר חיוני נגד התחזות רגילה, אך אינו תחליף לביטול מפתח שחתימתו נוצלה ל-Replay. שתי שכבות ההגנה מטפלות באיומים שונים, ולכן צריך ליישם את שתיהן.
מקור
AWS Security Blog: Beyond DKIM key rotation — understanding email replay attacks, פורסם ב־2 בנובמבר 2026.
תמונה: Angela Roma / Pexels. רישיון Pexels Free מאפשר שימוש ועריכה באתר, ברשתות חברתיות ובשיווק. התמונה להמחשה בלבד ואינה מעידה על קשר או תמיכה מצד AWS. דף המקור · תנאי הרישיון.
