מתחילים בהודעה מהמערכת הנכונה
שלחו הודעת בדיקה מותרת מהמערכת שרוצים לבדוק לתיבה שבשליטתכם. פתחו את מקור ההודעה או את הכותרות המלאות אצל המקבל. שימרו פרטים רק בהיקף הנדרש והסירו כתובות אישיות ותוכן לפני שיתוף.
ייתכנו כמה חתימות בהודעה אחת. רשמו לכל חתימה את d, דומיין החתימה, ואת s, הבורר שמזהה את המפתח. אין להניח ש-selector של התיבה הראשית הוא גם הבורר של מערכת הדיוור.
איך מרכיבים את שם הרשומה
הדוגמה הבאה היא מקוצרת ומלאכותית. היא מציגה רק את השדות הדרושים לאיתור השם, ולא חתימה שאפשר לאמת קריפטוגרפית.
TXT או CNAME: פועלים לפי הספק
Google Workspace מפרסמת הוראות להוספת מפתח ציבורי ב-TXT. Microsoft 365 משתמשת ב-CNAME עבור דומיין מותאם. ב-CNAME בוחנים גם שהיעד מפנה למפתח הנכון. הערכים צריכים להגיע מהתצורה של הדומיין אצל הספק, ולא מדוגמה כללית באינטרנט.
אפשר לבצע קריאה בלבד ב-PowerShell, תוך החלפת שם ההדגמה בשם שאיתרו בהודעה. שאילתה אינה משנה DNS ואינה מוכיחה שהחתימה עצמה עברה.
מה משמעות התוצאה
בדקו את Authentication-Results של שרת הקבלה המהימן. שדה כזה שנוסף על ידי גורם לא מוכר אינו ראיה מספקת. בדקו גם אם דומיין חתימה שעבר תואם ל-From לצורך DMARC.
| תצפית | מה עדיין צריך לבדוק |
|---|---|
| יש מפתח ב-DNS | האם המערכת באמת חותמת איתו |
| אין DKIM-Signature בהודעה | האם חתימה הופעלה במקור השליחה הנכון |
| יש חתימה אבל dkim=fail | שינוי בחלקים החתומים, מפתח או תצורה; דרוש אבחון |
| dkim=pass עבור דומיין הספק | האם קיימת התאמה לדומיין From |
| לא נמצאה רשומה בשם שנבדק | שגיאת העתקה, בורר אחר, מטמון או הגדרה חסרה |
איך מוודאים תיקון וסבב מפתחות
לאחר תיקון שולחים הודעה חדשה מאותו מקור ובוחנים את החתימה ואת תוצאת המקבל. הודעה ישנה עשויה להשתמש בבורר קודם. בעת החלפת מפתחות שומרים את תקופת החפיפה שהספק דורש ואינם מוחקים מפתח רק מפני שהוחלף הבורר הראשי.
אל תעבירו מפתח פרטי לטופס תמיכה או לפרסום ב-DNS. המפתח הציבורי מיועד לפרסום; המפתח הפרטי נשאר במערכת החתימה. אם הוא נחשף, יש לבצע החלפה בתיאום עם מנהל השירות.
