כשל DKIM אינו אזהרה קוסמטית אלא שגיאה באימות חתימה. הוא אומר ששרת הנמען לא הצליח לאמת חתימת DKIM, לא שההודעה כולה בהכרח אינה אמינה. עם זאת, הוא עשוי להשפיע על סינון וקבלת דואר. להגדרת הסביבה כולה, התחילו במדריך על דואר עסקי, כדי שהגדרות SPF, DKIM, DMARC, ניתוב ותיבות יתאימו זו לזו.
ההודעה נראית תקינה אצלכם, אבל Gmail, Microsoft או Yahoo מציגים dkim=fail. בהתאם לאימות נוסף ולמדיניות הנמען, הדואר עלול להגיע לספאם, להיות מוגבל זמנית או להידחות. הדבר עשוי להפחית תגובות ולהוביל לפניות תמיכה. מקור הבעיה יכול להיות DNS, מערכת השליחה או רכיב שמשכתב דואר בדרך.
טפלו בכך כתהליך אבחון המבוסס על ראיות: קראו את תוצאת האימות, סווגו את השגיאה, בדקו בורר ומפתח וחקרו אילו מערכות שינו את ההודעה אחרי החתימה. תקנו את הנקודה שהבדיקות זיהו.
מה בדיוק אומר dkim fail?
כשל DKIM פירושו שלא ניתן לאמת את החתימה הקריפטוגרפית של ההודעה. שינוי בנתונים החתומים או מפתח שאינו תואם הם סיבות אפשריות. מפתח DNS חסר או כשל בשאילתה עשויים להפיק שגיאה קבועה או זמנית; יש להבדיל בין אלה לבין כשל אימות.
RFC 6376 מגדיר את גיבוב הגוף ב-bh= ואת חתימת הכותרות ב-b=. אי-התאמה עלולה להכשיל את האימות. זו אינה הוכחה להתחזות: חתימה מוקדמת מדי, מפתח שגוי או שינוי בשלב הבא של הנתיב יכולים להסביר את הכשל.
אפשר להשוות את DKIM לחותם על חבילה. חותם לא תואם אומר שהבדיקה לא עברה, אך אינו מסביר לבדו מי שינה את החבילה או אם כל תוכנה אינו אמין.
התחילו בכותרת Authentication-Results של ההודעה המקורית. היא מסייעת לזהות את התוצאה ואת סוג הבעיה. הדוגמה הבאה ממחישה את אופן הרישום, אך משלבת תוצאות שבדרך כלל אינן צפויות יחד: SPF שעובר עם התאמה לאותו דומיין From אמור לרוב לאפשר ל-DMARC לעבור למרות כשל DKIM. אין לראות בצירוף הזה תחזית לתוצאה רגילה.
Authentication-Results: mx.google.com;
dkim=fail (body hash did not verify) header.i=@example.com header.s=tm1;
spf=pass smtp.mailfrom=example.com;
dmarc=fail header.from=example.comכדי לבדוק רשומות דומיין לפני שינוי השולח, השוו אותן לרשומות DNS הנדרשות של TrekMail.
סוגי בעיות DKIM נפוצים
חלוקה שימושית היא גיבוב גוף שאינו תואם, בורר או מפתח שגויים, מפתח DNS פגום או מקוצר ושינויים בהעברה או בממסר. סיווג נכון מצמצם החלפת מפתחות שלא היו מקור הבעיה.
| תוצאת האימות | משמעות אפשרית | מה לבדוק תחילה |
|---|---|---|
dkim=fail (body hash did not verify) | הגוף החתום אינו תואם לאחר קנוניזציה | ממסרים, הודעות משפטיות, שכתוב קישורים וקנוניזציה |
dkim=fail (signature did not verify) | מפתח לא תואם, כותרות חתומות ששונו או שגיאת אימות אחרת | רשומת הבורר, החלפת מפתחות, פלטפורמת השליחה וכותרות |
dkim=permerror (no key for signature) | לא נמצא מפתח ציבורי שמיש | שם מארח הבורר, תשובות DNS ופורמט הרשומה |
dkim=temperror | בעיה זמנית בשאילתת DNS או בעיבוד | DNS סמכותי, TTL וזמינות שרתי שמות |
זו חלוקה לאבחון ראשוני. יש להוכיח את הסיבה בפועל בבדיקות נוספות.
סוג כשל 1: גיבוב גוף שאינו תואם
אי-התאמה בגיבוב הגוף אומרת שהחלק החתום בגוף שהתקבל, לאחר קנוניזציה, אינו תואם לנתונים שגובבו בזמן החתימה. זו אינה השוואה של כל בייט בהודעה כולה, ואי אפשר להסיק ממנה ש-DNS תקין.
לפי RFC 6376, גיבוב מחושב מחדש שאינו תואם לערך bh= גורם לכשל אימות קבוע. בדקו שינויים בחלק החתום וגם את אופן החישוב והעיבוד בשני הצדדים.
סיבות אפשריות:
- Microsoft 365, Exchange או שערי אבטחה מוסיפים הודעה משפטית אחרי החתימה.
- Mimecast, Barracuda, Proofpoint ומסננים דומים משכתבים קישורים.
- ממסר משנה רווחים או סיומות שורה באופן שאינו מנוטרל על ידי הקנוניזציה שנבחרה.
- יישום חותם לפני ששער בהמשך משנה גבולות MIME או מוסיף באנר כגון
[External].
בדקו את c= בחתימה. מצב c=simple/simple רגיש יותר לשינויי עיצוב מסוימים. קנוניזציית גוף גמישה ב-RFC 6376 מתעלמת מרווחים בסופי שורות ומצמצמת רווחים חוזרים בתוך שורות, לפי כלליה. היא אינה מתקנת שינוי מהותי כגון טקסט נוסף או קישור משוכתב.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=tm1; h=from:to:subject:date:mime-version;
bh=...; b=...עדיף לחתום אחרי כל שינוי שאתם שולטים בו: תוספות תחתונות, קישורים, ניתוב ותוכן הנדרש לצורכי ציות. שלב השליחה האחרון שבניהולכם מתאים לעיתים לכך, אך אינו מונע שינויים במערכות חיצוניות בהמשך.
אם אתם מעבירים דואר, קראו על העברת דואר ועל העברת דואר מהדומיין ל-Gmail. נתיב אמיתי עם העברה עשוי לתת תוצאות שונות מבדיקת שליחה ישירה.
סוג כשל 2: בורר או מפתח לא תואמים
הבעיה נוצרת כשהודעה משתמשת בבורר X אך ב-DNS אין עבורו מפתח שמיש, או שהמפתח הציבורי אינו תואם למפתח הפרטי ששימש לחתימה. מפתח חסר עשוי להחזיר שגיאה קבועה; מפתח לא תואם עשוי להכשיל את האימות.
מצאו את הבורר והדומיין בכותרת החתימה:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...שאלו על הבורר המדויק:
dig txt k1._domainkey.example.com +shortתשובה ריקה יכולה להעיד על רשומה חסרה או שם שגוי, אך גם על מטמון או בעיית שאילתה אחרת. בדקו את התשובה המלאה. אם יש רשומה, השוו אותה למפתח שהשולח הפעיל דורש. בזמן מעבר או שימוש בכמה מערכות, אחת עשויה לעבור למפתח חדש בעוד אחרת ממשיכה לחתום במפתח הישן.
למשל, הודעות יישום דרך SES, תמיכה דרך Microsoft 365 וקמפיינים דרך ספק אחר. שינוי DNS יכול להשפיע רק על חלק מהשליחה. שקלו בוררים נפרדים לכל מערכת במקום שבו הדבר מתאים.
בנתיב המנוהל של TrekMail, עיינו בTrekMail SMTP מנוהל ובדקו היכן מתבצעת החתימה. ב-Nano או בשליחה חיצונית, ראו SMTP משלכם (BYO): TrekMail פועל כלקוח, ומערכת השליחה בפועל צריכה להיות מוגדרת לחתימת DKIM.
סוג כשל 3: פרסום שגוי של מפתח ארוך
מפתח של 2048 סיביות עלול להתפרסם באופן שגוי אם ממשק DNS אינו מטפל היטב בערך TXT. התוצאה עשויה להיות permerror, פורמט פגום או מפתח חלקי.
RFC 8301 דורש מפתחות RSA של לפחות 1024 סיביות וממליץ על לפחות 2048 סיביות. בדקו גם שממשק ה-DNS שומר ערכי TXT ארוכים ללא פגיעה.
קיצור המפתח או מירכאות שגויות עלולים לגרום לשגיאות גם כשהמפתח הפרטי תקין. הדוגמה הבאה ממחישה את המבנה; השתמשו במפתח האמיתי והמלא, מפוצל למחרוזות בתוך אותה רשומת TXT.
; Good DKIM TXT record pattern
k1._domainkey.example.com IN TXT (
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE..."
"restOfThePublicKeyContinuesHere..."
)בצעו שאילתה ובדקו את התשובה המלאה, לא רק את החלק הראשון:
dig txt k1._domainkey.example.com +shortבדקו זאת במיוחד אחרי החלפת ספק DNS, העברת אזור או העתקה ידנית של רשומות. היישום מחבר את המחרוזות באותה רשומה ללא רווחים נוספים.
סוג כשל 4: העברה, ממסרים ופערי התאמה
מערכת ביניים שמשנה נתונים חתומים בזמן העברה עלולה לשבור DKIM. גם SPF של השולח המקורי עשוי להיכשל. DMARC נכשל רק בהיעדר אימות אחר שעובר עם התאמה; דחייה תלויה במדיניות הנמען.
נניח ששלחתם מ-example.com למשתמש באוניברסיטה, והיא מעבירה את הדואר ל-Gmail. SPF עשוי להיכשל כי שרת ההעברה אינו השולח המקורי. DKIM יכול להישאר תקין אם הנתונים החתומים נשארים שלמים במידה הנדרשת לאימות. תוספת תחתונה, קישור ששוכתב או שינוי בנושא חתום עלולים להכשיל אותו. בלי אימות חלופי מותאם, גם DMARC עלול להיכשל.
Google דורשת משולחים כלליים לחשבונות Gmail אישיים SPF או DKIM; משולחים בתפוצה רחבה נדרשים שניהם, לצד DMARC ודרישות ההתאמה החלות. בנתיבי העברה ורשימות תפוצה מומלץ גם ARC, לפי העניין. הנמען מחליט אם לתת אמון ב-ARC ולהשתמש בו. לכן כשל DKIM בדרך אינו מוכיח שההגדרה הבסיסית שגויה.
SRS וניתוב זהיר יכולים לסייע בהעברה. בדקו אילו יכולות SRS זמינות בהגדרת TrekMail שלכם. SRS משכתב את שולח המעטפת ויכול לסייע ל-SPF של השולח החדש לעבור, אך אינו יוצר אוטומטית התאמה לדומיין From המקורי. הוא אינו תחליף ל-DKIM.
בסביבה עם כינויים רבים, קראו גם על העברת דואר באמצעות כינוי ועל יצירת דואר בדומיין משלכם. חקרו את נתיב ההעברה בפועל ולא רק את הגדרת הכינוי.
מה לבדוק כשמופיע dkim fail?
עבדו בסדר קבוע: תוצאת אימות, שאילתת בורר, נתיב חתימה והתאמה. כך מצמצמים שינויי DNS מיותרים כשהבעיה האמיתית היא שינוי אחרי החתימה.
- פתחו את ההודעה המקורית ומצאו
Authentication-Results. תעדו את תוצאת DKIM המדויקת. - מצאו את
d=,s=ו-c=בכותרתDKIM-Signature. - שאלו על הבורר באמצעות
digוודאו ששם המארח הואselector._domainkey.example.com. - זהו איזו פלטפורמה חותמת בפועל. כמה פלטפורמות עשויות להסביר תוצאות לא עקביות.
- בדקו אם שער, מסנן או שרת העברה משנים גוף או כותרות חתומות אחרי החתימה.
- בדקו התאמה בין הדומיין ב-
d=לבין הדומיין המוצג ב-From:, כדי ש-DKIM יעמוד בתנאי DMARC.
הדבקת קטעים בלבד לבודק חיצוני עלולה לייצר שגיאות גיבוב מטעות בגלל נתונים חסרים. בדקו את המקור המלא או קובץ שיוצא בפורמט .eml.
תהליך אבחון משולב עם TrekMail
שינויים נקודתיים ב-DNS, בממסרים ובתוספות תחתונות אצל ספקים שונים מקשים לזהות מי חתם ומתי. חתמו אחרי השינוי האחרון שבשליטתכם, אמתו DNS והפרידו במכוון בין שליחה מנוהלת ל-SMTP משלכם.
| תהליך מפוצל | תהליך משולב |
|---|---|
| שלבים פנימיים משנים הודעה אחרי חתימה | חתימה אחרי השינוי האחרון המנוהל |
| החלפת מפתחות ידנית בכמה כלים | ניהול מפתחות SMTP מנוהל לפי התהליכים הנתמכים |
| עריכות DNS שיוצרות SPF כפול או מארח DKIM שגוי | הליך מבוקר ואימות של כל רשומה |
| העברה ללא התחשבות ב-SRS או ARC | שימוש בתקנים מתאימים ושימור אימות כשאפשר |
במבנה המתואר כאן, Nano החינמי משתמש ב-SMTP משלכם. מסלולים בתשלום מתחילים ב-$3.50 לחודש וכוללים SMTP מנוהל; בדקו מחירים ויכולות עדכניים. אם רוצים ש-TrekMail יחתום, השתמשו בנתיב המנוהל הנתמך. אם SES, SendGrid או Mailgun חותמים, אבחנו DKIM אצל השולח החיצוני. למסלולים בתשלום עשויה להיות תקופת ניסיון של 14 יום שדורשת כרטיס אשראי. ראו תנאים במחירי TrekMail.
ההפרדה הזאת מגדירה את תחום הבדיקה. ב-BYO SMTP בדקו בורר, מפתח ושינויים בנתיב החיצוני, ואל תניחו ללא ראיות שתיבת TrekMail היא מקור הכשל.
רשימת בדיקה אחרונה לאירוע DKIM
טפלו ב-DKIM fail כשגיאת אימות מוגדרת, לא כבעיית מסירה מעורפלת. קראו את התוצאה, בדקו את הבורר וחקרו את נתיב החתימה לפני שינוי הגדרות.
לפני שינוי בייצור, בדקו:
- קראו את כותרת האימות המלאה, לא רק סיכום של הודעת החזרה.
- הבחינו בין שגיאת גיבוב גוף, כשל חתימה, permerror ו-temperror.
- שאלו על הבורר המדויק ב-DNS.
- ודאו שהמפתח מלא ומפורסם עם מירכאות תקינות.
- העבירו חתימה לאחר השינוי האחרון שבשליטתכם אם נדרש.
- שקלו
c=relaxed/relaxedאם הסביבה תומכת בו, אך זכרו שאינו מתקן שינויי תוכן מהותיים. - בדקו התאמת DMARC בין
d=לדומיין המוצג ב-From:.
אם dkim fail חוזר, אספו ראיות במקום רק להמתין. חקרו את מיקום החתימה, הבורר, המפתח והשינויים המאוחרים, ותקנו את הסיבה שהוכחה.
