מחולל מפתחות DKIM: יצירת מפתחות והגדרת DNS

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

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

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

מה עושה מחולל מפתחות DKIM?

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

אין כאן קסם. מחולל מפתחות DKIM מתאים מבצע את הפעולות הבאות:

1. יוצר מפתח פרטי שמערכת השליחה יכולה להשתמש בו.
2. מפיק את המפתח הציבורי התואם.
3. מעצב את המפתח הציבורי כרשומת DNS מסוג TXT לפרסום תחת selector._domainkey.example.com.

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

לפי RFC 6376, בוררים מאפשרים לפרסם כמה מפתחות ולהחליף אותם בצורה מסודרת. RFC 8301 דורש מפתחות RSA באורך של לפחות 1024 סיביות, ו-2048 סיביות הן בדרך כלל ברירת מחדל מתאימה יותר. אם מחולל מפתחות DKIM עדיין ממליץ על 512 סיביות או SHA-1, בחרו כלי אחר.

איך נראה הפלט הנדרש?

מחולל מפתחות DKIM שימושי מספק מפתח פרטי לחתימה ורשומת מפתח ציבורי בפורמט מתאים ל-DNS. הרשומה מתפרסמת בשם המארח של הבורר, לא בשורש הדומיין, והמפתח הציבורי נמצא בתג p=.

כך נראה המבנה הרצוי.

Host: tm2026._domainkey.example.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

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

openssl genrsa -out dkim-private.pem 2048
openssl rsa -in dkim-private.pem -pubout -out dkim-public.pem
openssl rsa -in dkim-private.pem -text -noout

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

awk 'NF {sub(/\r/, ""); printf "%s",$0;}' dkim-public.pem \
| sed 's/-----BEGIN PUBLIC KEY-----//; s/-----END PUBLIC KEY-----//g'

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

להמחשה: הבורר הוא שם שמצביע על המפתח, לא המפתח עצמו. אם בחתימה מופיע s=tm2026, שרת הנמען יחפש את tm2026._domainkey.yourdomain.com. אם הרשומה אינה קיימת, לא ניתן לאמת את DKIM.

בחירת הבורר ואורך המפתח

בחרו מחולל מפתחות DKIM שיוצר מפתח באורך 2048 סיביות ומאפשר שמות בוררים ברורים להחלפת מפתחות. מערכת השליחה היא שקובעת שימוש ב-RSA עם SHA-256, לא מחולל המפתחות. בוררים הם שמות תפעוליים, בדומה לתוויות גרסה, ולא קישוט אקראי.

השתמשו בשמות שמבהירים מתי ובאיזו מערכת המפתח משמש. דוגמאות מתאימות:

• tm2026
• app1q1
• marketing2026

דוגמאות פחות מתאימות:

• שימוש ב-default ללא החלפה לאורך זמן
• שימוש ב-test בסביבת ייצור
• שימוש חוזר ב-dkim בכל מערכות השליחה

RFC 8301 קובע מינימום של 1024 סיביות וממליץ על 2048 סיביות. הנחיות Google לשולחים בתפוצה רחבה דורשות DKIM ו-SPF, ולפחות אחד מהם צריך להיות מותאם לדומיין From בשליחה ישירה לחשבונות Gmail אישיים. בדקו את התנאים הרלוונטיים בשאלות הנפוצות על הנחיות לשולחים.

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

פרסום רשומת DNS בצורה מסודרת

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

טעויות נפוצות כוללות:

1. פרסום רשומת TXT תחת @ במקום selector._domainkey.
2. הדבקת מעטפת PEM כולה ב-DNS במקום המפתח בקידוד base64 בלבד.
3. הפעלת חתימה לפני שניתן לשלוף את הרשומה ב-DNS.
4. הגדרת בורר שגוי בפלטפורמת הדואר.

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

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

בדיקה שמפתח DKIM פועל בפועל

אחרי שימוש במחולל מפתחות DKIM ופרסום הרשומה, בדקו כותרות של הודעות אמיתיות. תוצאת DNS תקינה אינה מספיקה. חפשו dkim=pass ובדקו שההתאמה בין הדומיינים עומדת בדרישות DMARC בהודעות שאתם שולחים.

שלחו הודעה לתיבת Gmail ובחנו את כותרות המקור. תוצאה מוצלחת עשויה להיראות כך:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=tm2026 header.b=...
       spf=pass smtp.mailfrom=example.com
       dmarc=pass header.from=example.com

אם DKIM נכשל, בדקו לפי הסדר:

1. את הבורר s= בכותרת DKIM-Signature.
2. את שם המארח המדויק ב-DNS באמצעות dig.
3. שהמפתח הציבורי ב-DNS תואם למפתח הפרטי במערכת השליחה.
4. שמערכת השליחה משתמשת בדומיין החותם הנכון בשדה d=.
5. אם רשימת תפוצה, תוספת חתימה תחתונה או שרת ממסר שינו כותרות חתומות או את גוף ההודעה.

dig +short TXT tm2026._domainkey.example.com

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

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

כלי DKIM נפרדים מול תהליך תפעול מאוחד

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

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

ב-TrekMail אפשר להשתמש, בהתאם למסלול ולהגדרות, ביכולות הבאות:

• דומיינים מותאמים ותיבות IMAP באותו לוח בקרה.
• SMTP משלכם ב-Nano, או SMTP מנוהל כאשר הוא כלול במסלול בתשלום.
• מנגנון העברה מובנה למשיכת דואר קיים באמצעות IMAP.
• קליטה כוללת, העברת הודעות מתיבות וגישה ל-API כשהמסלול כולל אותן.
• תהליך הגדרת DNS ואימות שמביא בחשבון SPF, DKIM ו-DMARC יחד.

היתרון בולט יותר כשמנהלים כמה דומיינים. עבור סוכנויות וספקי שירות מנוהל, גם תמחור לפי משתמש וגם שגיאות אימות בדומיינים רבים עלולים להכביד. המחירים המתוארים כאן מתחילים ב-$3.50 לחודש ל-Starter, עם Nano חינמי ב-$0 עבור עד 10 דומיינים ו-5GB בשימוש ב-SMTP משלכם. בדקו את המחירים והמגבלות העדכניים. למסלולים בתשלום עשויה להיות תקופת ניסיון של 14 יום שדורשת כרטיס אשראי; לפי תנאי Nano המתוארים, הוא אינו דורש כרטיס.

אם צריך להעביר דואר קיים במקביל לתיקון האימות, תהליך העברת הדואר ב-IMAP של TrekMail יכול למשוך הודעות מ-Gmail, מ-Microsoft 365 או ממקורות IMAP אחרים לתיבת TrekMail. התוצאה תלויה בהרשאות המקור, בשיטת האימות ובנתונים הנתמכים.

החלפת מפתחות, ביטולם ותחזוקה שוטפת

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

אפשר להשתמש בתהליך הבא:

1. צרו מפתח חדש באורך 2048 סיביות עם בורר חדש.
2. פרסמו את המפתח הציבורי החדש ב-DNS.
3. העבירו את מערכת השליחה לחתימה עם הבורר החדש.
4. בדקו שבהודעות חדשות מופיע dkim=pass.
5. השאירו את הבורר הישן מפורסם עד שהודעות מושהות והודעות בתור יסיימו לעבור.
6. הסירו את המפתח הציבורי הישן לאחר תקופת המעבר.

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

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

סיכום: יצירת המפתח היא רק תחילת הדרך

מחולל מפתחות DKIM הוא נקודת ההתחלה. אחר כך צריכים הבורר, המפתח הציבורי ב-DNS והמפתח הפרטי במערכת השליחה להתאים, והודעות אמיתיות צריכות להציג dkim=pass עם התאמת DMARC הנדרשת.

התחילו במפתח של 2048 סיביות, בבורר עם גרסה וברשומת TXT נכונה, ובדקו כותרות אמיתיות. אם אתם מנהלים כמה ספקים ודומיינים, ריכוז התהליך עשוי להקל על המעקב. TrekMail מציע, בהתאם למסלול, דומיינים מותאמים, תיבות IMAP, אחסון משותף, העברת דואר ב-IMAP וניהול DNS ואימות. בדקו את היכולות ותנאי התמחור העדכניים, כולל חיוב לפי משתמש. אפשר לבחון את האפשרות החינמית ב-trekmail.net או להשוות מסלולים ב-trekmail.net/pricing.