רשומת DKIM: בוררים, החלפת מפתחות ואבחון

ירידה בפתיחות אינה הוכחה לתקלת DNS: פרטיות ומעקב משפיעים גם הם. לצד נושא וקהל, בדקו אימות ובפרט את רשומת DKIM.

SPF בודק כתובת שליחה עבור זהות מעטפת. DKIM, כלומר DomainKeys Identified Mail, דומה לחותם: הוא מאמת דומיין חתימה ושלמות של תוכן מכוסה, לא את זהות האדם וכל ההודעה. מאז 2024 מחילות Google ו-Yahoo דרישות נוספות על קבוצות מסוימות של שולחים בהיקף גדול. כשל DKIM עשוי להשפיע על סינון, אך אינו מעלים אוטומטית כל הודעה או שולח אותה לספאם.

למייסד יחיד ההגדרה יכולה להיראות כמשימה של עשר דקות, בלי הבטחת משך. לספק שירותים עם 500 דומיינים, בוררים, החלפות ותחביר DNS מחייבים ניהול שוטף; תקלה יכולה להתגלות ביום שישי ב-9 בערב.

זהו מדריך תפעולי לרשומת DKIM: פעולת DNS, מגבלת 255 אוקטטים למחרוזת TXT ואבחון כאשר סימון האימות ב-ESP אינו תואם לשליחה בפועל.

מהי רשומת DKIM?

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

המפתח מתבקש ב-selector._domainkey.yourdomain.com, כאשר selector מזהה אותו. הדוגמה מקוצרת ואינה מיועדת לפרסום:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC...

v=DKIM1 מזהה גרסה, k=rsa מציין סוג מפתח ו-p= מכיל מפתח ציבורי בקידוד base64. המפתח הפרטי נשמר בתשתית שליחה מוגנת ולא ב-DNS. המדריך ליצירת רשומת DKIM מפרט את התחביר והשדות.

על מה DKIM חותם ומדוע זה חשוב

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

השרת בוחר כותרות כגון From, Subject, Date, To ו-Message-ID ואת הגוף שבתחום החתימה. From חייב להיות חתום; שאר הבחירה תלויה בתצורה. בדרך כלל משתמשים ב-SHA-256 ובמפתח פרטי, ומוסיפים DKIM-Signature. התצורה קובעת כיסוי וקנוניזציה בפועל.

Gmail, Outlook ומקבלים אחרים מבצעים בדיקות ובהן:

1. קריאת DKIM-Signature לזיהוי בורר ודומיין.
2. שליפת מפתח ציבורי ב-selector._domainkey.yourdomain.com מתוך DNS.
3. אימות קריפטוגרפי של החתימה במפתח הציבורי, לא פענוח ההודעה.
4. חישוב ערכי גיבוב מחדש מתוך התוכן המכוסה לאחר קנוניזציה.
5. בדיקת התאמה ושאר תנאי המפתח והחתימה לקביעת הצלחה או כישלון.

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

העברה ותנאי שימור DKIM

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

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

אל תסתמכו רק על SPF. שלבו DKIM עם הגדרת SPF מתאימה; מדריך SPF לדוא״ל מסביר את הבסיס. DMARC יכול להצליח דרך אחת משתי שיטות מיושרות, בלי הבטחת מסירה.

TrekMail מתארת העברה עם SRS (Sender Rewriting Scheme), שיכול לשכתב מעטפת עבור SPF של שירות ההעברה, לא לשחזר יישור From מקורי. בדקו אם DKIM פעיל במסלולי SMTP מנוהלים או חיצוניים כיום, ולא כהנחת ברירת מחדל מובטחת לכל תצורה.

בוררים לניהול כמה מפתחות DKIM

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

SPF משתמש במדיניות אחת לכל שם DNS נבדק. DKIM יכול להשתמש בבוררים שונים ב-selector._domainkey.yourdomain.com. אפשר למשל לנהל עשרה בו-זמנית, אחד לכל שירות, בכפוף למגבלות ספק ו-DNS בפועל. זו אינה הבטחה לרשומות בלתי מוגבלות.

מדוע כמה בוררים מועילים

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

• Google Workspace: בורר יכול להיות google ומפתח ב-google._domainkey.yourdomain.com.
• Mailchimp: יכולה להשתמש ב-k1 או k2. בדקו TXT או CNAME נדרשים ל-k1._domainkey.yourdomain.com.
• TrekMail: דוגמה היא tm1 ב-tm1._domainkey.yourdomain.com. השתמשו בתצורת TXT או CNAME הנתמכת בפועל.

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

טעות שם קלאסית

מתכוונים ל-google._domainkey.yourdomain.com, אך הממשק מוסיף שוב את הדומיין ויוצר google._domainkey.yourdomain.com.yourdomain.com. השם המיועד יכול להחזיר NXDOMAIN, וסטטוס ESP עשוי להיות ישן. בדקו שם ותשובות אמיתיים בעזרת מדריך בדיקת מצב DNS ושאילתה ממוקדת.

אורך מפתח ומדיניות החלפה

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

העדפת מפתחות של 2048 סיביות

RSA באורך 1024 סיביות היה נפוץ שנים. Google עדיין מציינת מינימום וממליצה על 2048 סיביות לתצורה חזקה יותר; בדקו בנפרד הנחיות Yahoo עדכניות. תצורת cPanel או Postfix עם 1024 סיביות מלפני 2019 דורשת בדיקה, לא הנחה שכל חתימה בהכרח נכשלת.

מפתח של 512 סיביות אינו מספיק לדרישות מודרניות. עם dkim=perm_fail וסיבה "weak key" או "policy", קראו את ההסבר המלא. בחנו זוג חדש של 2048 סיביות ומעבר מדורג; דליפה דורשת תגובה דחופה. ראו הנחיות Google לשולחים.

תדירות החלפה

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

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

מגבלת 255 האוקטטים ב-DNS והפתרון

מעבר ל-2048 סיביות יכול להפתיע באורך. מפתח ציבורי של 2048 סיביות בקידוד base64 הוא כ-400 תווים. DNS TXT מגביל כל מחרוזת ל-255 אוקטטים. ממשקים יכולים לפצל, לדחות או לטפל שגוי בערך ארוך; אין כלל שרובם קוטעים אותו בשקט.

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

דוגמה מקוצרת שאינה לפרסום; טיפול בקלט ארוך תלוי בספק:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7bq3...

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

( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7bq3"
  "...rest_of_key_here..." )

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

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

בדיקת ההגדרה

"Verified" ב-ESP עשוי להתבסס על נתונים מלפני שעות או ימים. בדקו DNS עדכני בשרתים סמכותיים ובפותרים רלוונטיים, וגם הודעת ניסיון חתומה. גם שאילתה יכולה להיות ממטמון, ו-DNS לבדו אינו מוכיח חתימה תקינה בשרת.

צעד 1: בדיקת קיום השם

השתמשו במסוף Linux או macOS. ב-Windows אפשר להפעיל nslookup:

# macOS / Linux
dig txt selector._domainkey.yourdomain.com +short

# Windows
nslookup -q=txt selector._domainkey.yourdomain.com

החליפו selector בבורר בפועל ו-yourdomain.com בדומיין שלכם.

ערך יכול להתחיל ב-v=DKIM1, אך תג הגרסה אינו חובה בכל רשומת מפתח תקינה. חקרו NXDOMAIN אם מופיע. תשובת NXDOMAIN מצביעה על שם חסר בתשובה הרלוונטית: בדקו בורר, פרסום ומטמונים. ניסיון נוסף אחרי 30 דקות הוא דוגמה, לא זמן DNS קבוע.

צעד 2: בדיקת תוכן המפתח

אם הרשומה קיימת והכשל נמשך, בדקו פלט גולמי:

dig txt selector._domainkey.yourdomain.com +short

שימו לב לשני דברים:

• קיטוע: ערך base64 קצר מ-200 תווים למפתח שאמור להיות של 2048 סיביות מצדיק בדיקת המפתח המפוענח המלא, אך אינו מוכיח שהספק קטע אותו.
• טיפול בתווים: בדקו שורות, רווחים ותווי מילוט בתוך base64. לא כל שינוי חזותי משנה מפתח. השוו את הערך שפורסם ופוענח למפתח הציבורי המיועד.

צעד 3: הודעת ניסיון וכותרות

שלחו ל-Gmail שבשליטתכם ובחרו הצגת מקור מתפריט שלוש הנקודות. חפשו Authentication-Results וסמכו רק על תוצאות שהמקבל הוסיף, לא על כותרות שולח. זו דוגמה:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@yourdomain.com header.s=selector header.b=AbCdEfGh;
  spf=pass (...);
  dmarc=pass (...)

dkim=pass מאשר הצלחה בבדיקה הזאת. קראו fail, neutral, perm_fail ו-temperror לפי הסיבה והמימוש; neutral אינו תמיד שגיאה. מדריך ההגדרה מספק פרטים, וגם רשימת ההגדרה הראשונה של TrekMail מסייעת לבדיקת האימות הקשור.

כשלי DKIM: שלושה תרחישים

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

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

תרחיש 1: "Body Hash Did Not Verify"

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

גורמים אפשריים:

• אזהרת שולח חיצוני: שער דואר עשוי להוסיף "דוא״ל חיצוני: זהירות". שינוי בגוף המכוסה לפני אימות, מעבר לנרמול מותר, יכול להכשיל DKIM. בדקו גם כללי זרימת דואר ב-Microsoft 365.
• הודעה משפטית בתחתית: שער מוסיף הודעה משפטית בת 15 שורות אחרי ששרת התיבה חתם, וגיבוב הגוף עלול להשתנות. חתמו על הגרסה הסופית במסלול היוצא שבשליטתכם.
• שכתוב קישורים: Mimecast, Proofpoint ו-Defender for Office 365 יכולים לשנות google.com ל-protect.mimecast.com/s/.... שינוי הגוף המכוסה עלול לפסול חתימה לפי תזמון וכיסוי.

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

תרחיש 2: יישור

חתימה תקינה יכולה להתקיים יחד עם כשל DMARC. למשל:

dkim=pass (signature was valid)

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

DMARC משווה דומיין חתימה ב-d= לדומיין Header From. יישור מחמיר דורש התאמה מדויקת; מקל יכול להשתמש בדומיין ארגוני משותף. די בחתימת DKIM תקינה ומיושרת אחת או ב-SPF מצליח ומיושר.

דוגמה להמחשה:

Header From:        ceo@yourcompany.com
DKIM d= tag:        sendgrid.net

החתימה תקינה עבור sendgrid.net. מדיניות DMARC שייכת לדומיין השולח הגלוי yourcompany.com, לא לדומיין המקבל. sendgrid.net != yourcompany.com. חתימה זו אינה מיושרת; DMARC נכשל רק אם אין שיטה מיושרת אחרת שעוברת.

בדקו אימות דומיין או חתימה מותאמת אצל ה-ESP. מפתח DKIM משלכם עשוי להגדיר d= כ-yourcompany.com במקום sendgrid.net, היכן שנתמך. יכולות משתנות בין ספקים ותוכניות. הבינו יישור DMARC ובדקו מסלולים בפועל.

תרחיש 3: מפתחות ישנים או חלשים

עם dkim=perm_fail וסיבה "policy" או "weak key", מפתחות של 512 או 768 סיביות עשויים להיות קשורים, אך יש גם גורמים אחרים. בדקו את המפתח וההסבר. אורכים ישנים עשויים לא לעמוד בדרישות, והסימון לבדו אינו מוכיח אורך מסוים.

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

הערכת בטיחות יצירת מפתחות

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

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

השוואת דרכי יצירה

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

# Generate the private key
openssl genrsa -out dkim-private.key 2048

# Extract the public key
openssl rsa -in dkim-private.key -pubout -out dkim-public.key

# View the public key for DNS (strip headers, format as single line)
cat dkim-public.key

הגנו על המפתח הפרטי. ב-DNS מפרסמים תוכן נכון של המפתח הציבורי ללא מעטפת PEM; פקודת התצוגה אינה מסירה כותרות בעצמה. אל תשלחו מפתח פרטי בדוא״ל לצורך "אימות", ובדקו בקשות דרך ערוץ מהימן.

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

ניהול ידני לעומת אוטומציה

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

דוגמת החלפה שנתית ידנית לכל דומיין

1. צרו זוג RSA עם בורר חדש כגון s2026.
2. פרסמו את המפתח הציבורי ב-s2026._domainkey.yourdomain.com.
3. הדוגמה מקצה 48 שעות ל-DNS; קבעו המתנה בפועל לפי TTL, מטמונים ובדיקות.
4. עברו לחתימה במפתח הפרטי החדש ובדקו.
5. הדוגמה שומרת שני בוררים 7 ימים; התאימו חפיפה לתורים, לתוקף חתימות ולסיכון.
6. הסירו בורר ציבורי ישן לאחר תקופה מתאימה, אלא אם אירוע דורש ביטול מהיר יותר.
7. השמידו את המפתח הפרטי הישן בבטחה לפי מדיניות שמירה.

בדוגמה יש 7 צעדים לשנה לכל דומיין. עבור 50 דומיינים אלה 350 פעולות, לא נפח עבודה קבוע בפועל. דילוג על צעד 5 עלול לפגוע באימות הודעות שבדרך; שכחת צעד 6 יכולה להשאיר מפתח יותר מהמתוכנן. שלבו אוטומציה ובדיקות.

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

ניהול DKIM ב-TrekMail

TrekMail מיועדת לניהול כמה דומיינים, ממייסד עם חמישה פרויקטים צדדיים ועד ספק עם 800 דומיינים של לקוחות. בחנו תצורה עדכנית למסלולים שלכם.

האצלת פרסום עם CNAME

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

tm1._domainkey.yourdomain.com  CNAME  tm1._domainkey.trekmail.net

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

דוגמת Pro במחיר $8 לחודש עבור 100 דומיינים משווה ל-700 פעולות ידניות שנתיות. זו המחשה חשבונית של השגרה שנבחרה, לא חיסכון מובטח או מחיר עדכני.

אשף DNS מונחה

האשף המתואר מסייע ב-MX, SPF, DKIM ו-DMARC ובבדיקה. אמתו יכולות עדכניות, DNS סמכותי ומטמונים וגם הודעה חתומה. סימון אינו אימות מלא לכל מסלול. ראו רשומות DNS נדרשות.

תמחור פלטפורמה

המקור מציג Starter במחיר $3.50 לחודש עם 50 דומיינים ו-100 משתמשים לדומיין, Pro במחיר $8 עם 100 דומיינים ו-300 משתמשים לדומיין ו-Agency עם 1,000+ דומיינים. אחסון מתואר כמשותף. בדקו מחירים, מגבלות ויכולות עדכניים; הוספת תיבות אינה חינמית בכל מצב.

DKIM מתואר כחלק מהגדרת DNS. אמתו איזה אימות נתמך כיום בכל תוכנית ומסלול, כולל SMTP חיצוני.

ניהול רשומת DKIM: עצמאי או מואצל

סיכום

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

התחילו במפתח מתאים כגון RSA של 2048 סיביות, בורר נכון, TXT מלא ויישור עם Header From. הוסיפו החלפה מבוקרת, מדיניות DMARC וניטור, למשל ב-Google Postmaster Tools, לפי זמינות נתונים.

השוואת SPF, DKIM ו-DMARC מסבירה תפקידים. בתקלת מסירה פעילה, מדריך צמצום הגעת הודעות לספאם מסייע לתעדוף, תוך התאמה לשגיאות אמיתיות.

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