אם חיפשתם מחולל רשומות DKIM בעקבות כשלי אימות ב-Gmail או ב-Google Postmaster Tools, בדקו תחילה את ההגדרות הבסיסיות. המדריך ליצירת דואר בדומיין משלכם מכסה MX, SPF, DKIM, DMARC ושגיאות DNS שעלולות לפגוע במסירת הודעות.
כלי אינטרנט רבים אינם מסבירים מספיק של-DKIM יש שני חלקים: מפתח ציבורי ב-DNS ומפתח פרטי במערכת שחותמת על ההודעות. אם אתר יוצר את שניהם, ייתכן שלשירות הייתה גישה למפתח הפרטי. בדקו אם היצירה נעשית רק בדפדפן באופן שניתן לבדיקה. המפתח מאפשר חתימה בשם הדומיין, אך אינו מאמת לבדו את זהות השולח המוצגת.
המדריך מציג דרכים מתאימות להשתמש במחולל רשומות DKIM בשנים 2025-2026: יצירה מקומית של מפתחות באמצעות OpenSSL לשרת בניהול עצמי, או עבודה לפי הוראות ספק השליחה בפועל, כגון TrekMail, Amazon SES, SendGrid, Mailgun או Google Workspace.
מהו מחולל רשומות DKIM?
מחולל רשומות DKIM מספק את נתוני ה-DNS הדרושים ל-DomainKeys Identified Mail. הוא יכול ליצור זוג מפתחות RSA לרשומת TXT, או לספק רשומות CNAME של ספק שמפנות למפתח הציבורי של DKIM המפורסם במקום אחר. לא כל ספק משתמש ב-CNAME.
DKIM חותם על הודעות יוצאות באמצעות מפתח פרטי. שרתי הנמען שולפים את המפתח הציבורי התואם מ-DNS ומאמתים את החתימה. כך נבדקות חתימה בשם הדומיין החותם ושלמות החלקים החתומים לפי כללי הקנוניזציה שהוחלו.
לפי RFC 8301, בחתימות RSA יש להשתמש ב-rsa-sha256 ובמפתחות RSA באורך של לפחות 1024 סיביות, ומומלץ להשתמש בלפחות 2048 סיביות. לכן מחולל רשומות DKIM מתאים צריך להתבסס על RSA 2048 כברירת מחדל, ולא על 1024.
הסיכונים במחוללים מקוונים לא מוכרים
לפני שימוש באתר שמייצר מפתחות DKIM, בדקו היכן נוצר המפתח הפרטי ומי יכול לגשת אליו. יצירה ניתנת לבדיקה בצד הלקוח בלבד יכולה לצמצם חשיפה לשירות, אך אין להניח שכך פועל כלי לא מוכר. מפתח שדלף עלול לאפשר שימוש לרעה בחתימות הדומיין.
DKIM אינו רק עיצוב של רשומת DNS, אלא חתימה קריפטוגרפית בשם דומיין. שמרו את המפתח הפרטי במערכות שזקוקות לו לצורך חתימה והגבילו את הגישה. אם אתר חיצוני יוצר, מתעד או שומר אותו, הוא עשוי להיות מסוגל לחתום בשם הדומיין בעתיד.
המפתח הציבורי ב-DNS; המפתח הפרטי במערכת החתימה. אם טופס מקוון מספק את שניהם, בדקו היכן נוצר המפתח הפרטי ואם לשירות הייתה גישה אליו.
זו בדיקה חשובה לכל מחולל רשומות DKIM: היכן נוצר המפתח הפרטי ומי יכול היה לגשת אליו? אתר לא מוכר אינו בסיס מספיק לאמון במפתח שישמש בייצור.
יצירת מפתחות מקומית באמצעות OpenSSL
OpenSSL במחשב שלכם או בשרת החותם יכול לצמצם את חשיפת המפתח הפרטי לשירותי אינטרנט. זהו מחולל רשומות DKIM שימושי כשמנהלים היטב את אבטחת המארח, הרשאות הקבצים והגישה. יצירה מקומית כשלעצמה אינה מבטיחה אבטחה.
השיטה מתאימה לסביבה בניהול עצמי עם Postfix, Exim, Exchange, OpenDKIM או תוכנה דומה. צרו את המפתח מקומית, התקינו את המפתח הפרטי במארח החותם ופרסמו ב-DNS רק את המפתח הציבורי.
צרו זוג מפתחות RSA באורך 2048 סיביות:
openssl genrsa -out private.key 2048
openssl rsa -in private.key -pubout -out public.keyהקובץ public.key ייראה בדומה לדוגמה הבאה; הטקסט המקוצר הוא להמחשה ואינו מפתח שמיש:
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr...
-----END PUBLIC KEY-----כעת הכינו אותו לפרסום:
- הסירו את השורות
BEGIN PUBLIC KEYו-END PUBLIC KEY. - הסירו את כל מעברי השורה.
- הוסיפו את תגי DKIM.
רשומת TXT ידנית נראית בדרך כלל כך; החליפו את הטקסט להמחשה במפתח הציבורי המלא שלכם:
default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."טקסט המפתח לבדו אינו מספיק. מחולל רשומות DKIM מציין בדרך כלל v=DKIM1, תג אופציונלי עם ערך ברירת מחדל, שחייב להיות הראשון אם הוא נכלל. הרשומה כוללת את התג המחייב p=. יש גם תגים אופציונליים כגון s=email או t=s, שלרוב אינם נחוצים בהגדרה בסיסית.
מגבלת DNS של 255 אוקטטים למחרוזת
DNS מגביל את האורך של כל מחרוזת ברשומת TXT, ולכן שדה קלט לא מתאים עלול להתקשות בפלט של מחולל רשומות DKIM. מפתח RSA ציבורי באורך 2048 סיביות הוא ארוך, ולעיתים צריך לפצל אותו למחרוזות במירכאות בתוך אותה רשומה.
ממשקי DNS ישנים עלולים לדחות את הרשומה, לקצר אותה או לשמור רק חלק מהמפתח. הדבר עשוי לגרום ל-permerror, לשגיאת פורמט מפתח או לכשל בבדיקת DKIM אף שהבורר קיים.
אם ממשק ה-DNS אינו מטפל אוטומטית בערך הארוך, פצלו אותו לכמה מחרוזות במירכאות בתוך רשומת TXT אחת:
default._domainkey.example.com. IN TXT (
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArFirstPart"
"SecondPartOfTheSamePublicKey"
)מאמת DKIM או היישום מחבר את המחרוזות ללא רווחים נוספים ומתייחס אליהן כערך לוגי אחד. אין לפרסם אותן כרשומות TXT נפרדות. מחולל רשומות DKIM שימושי מסביר מתי נדרש פיצול וכיצד ממשק ה-DNS מטפל בו.
ניהול מפתחות אצל ספק השליחה
לעסקים רבים, מחולל רשומות DKIM של ספק השליחה מעשי יותר מניהול עצמאי של מפתחות. חלק מהספקים מספקים CNAME ואחרים TXT. הם שומרים את המפתחות הפרטיים ועשויים לנהל את החלפתם, אך האוטומציה והצורך בשינויי DNS משתנים לפי השירות.
אם אתם שולחים דרך TrekMail, Amazon SES, Google Workspace, SendGrid או Mailgun, פעלו לפי הוראות נתיב השליחה שלכם. בהאצלה באמצעות CNAME מפרסמים את בוררי CNAME שסופקו, והספק מפרסם את מפתח DKIM הציבורי בשם המארח שאליו הם מפנים. בהגדרת TXT מפרסמים את ערך TXT שהספק מספק.
| נושא | ניהול עצמאי | ניהול אצל הספק |
|---|---|---|
| יצירת מפתחות | אתם יוצרים ושומרים מפתחות RSA | הספק מנהל את המפתחות |
| רשומת DNS | ערך TXT ארוך | CNAME או TXT לפי הוראות הספק |
| החלפת מפתחות | ידנית ודורשת תכנון תחזוקה | לפי יכולות הספק |
| גורמי כשל | שגיאות תחביר, קיצור ערכים ומפתחות ישנים | שגיאות DNS, רשומות חסרות או הגדרות שליחה |
| מתאים ל | מערכות MTA בניהול עצמי | פלטפורמות דואר ו-SMTP מתארחות |
TrekMail יכול לרכז הגדרות דומיין ובדיקות אימות בתהליך אחד. היקף ניהול המפתחות שנדרש מכם תלוי בנתיב השליחה. בהוספת דומיין, התחילו בהוראות DNS העדכניות שבהוספת דומיין.
הגדרת TrekMail תלויה באופן השליחה. Nano משתמש ב-SMTP משלכם לדואר יוצא. לפי מבנה המחירים המתואר כאן, מסלולים בתשלום כוללים SMTP מנוהל, החל מ-$3.50 לחודש ב-Starter. ייתכן שמוצעת תקופת ניסיון של 14 יום שדורשת כרטיס אשראי. לפי התנאים המתוארים, Nano אינו משתמש בתקופת ניסיון ואינו דורש כרטיס. בדקו את המחירים והתנאים העדכניים.
עבור משתמשי TrekMail, מחולל רשומות DKIM המתאים תלוי בנתיב השליחה:
- אם TrekMail חותם באמצעות SMTP מנוהל, השתמשו ברשומות DNS שמופיעות בלוח הבקרה.
- בשימוש ב-SMTP משלכם, הגדירו ואמתו חתימת דומיין אצל ספק הממסר, ואז פרסמו את רשומות DKIM שהוא מספק.
- אם הספק מספק בוררי CNAME, השתמשו בהם. אל תהפכו אותם לרשומות TXT רק כי מאמר הסביר רק TXT.
אם אתם בוחרים בין העברה, כינויים ותיבות אמיתיות, קראו על כינוי דואר בדומיין מול תיבת דואר ועל העברת דואר באמצעות כינוי. הבחירה משפיעה על המערכת ששולחת בפועל, ולכן גם על הגדרת DKIM הנדרשת.
היכן מפרסמים את הבורר?
מחולל רשומות DKIM אינו מספק רשומה לשורש הדומיין. מפתחות DKIM נשלפים בשם מארח של בורר, כגון default._domainkey, google._domainkey או tm1._domainkey.
ממשקי DNS שונים מצפים לקלט שונה. חלקם דורשים רק את תווית המארח ואחרים את שם המארח המלא. אם הממשק מוסיף בעצמו את שם האזור ותזינו גם את הדומיין המלא, עלולה להיווצר רשומה כגון default._domainkey.example.com.example.com. רשומה בשם השגוי לא תימצא בשאילתה לבורר המקורי.
דוגמאות נפוצות:
default._domainkey
selector1._domainkey
tm1._domainkeyבניהול דומיינים רבים ללקוחות, אותה שגיאה יכולה לחזור שוב ושוב. לכן עדיפים תהליכי DNS עקביים וניתנים לבדיקה על תיקונים נקודתיים. המדריך על אירוח דואר למספר דומיינים מרחיב על ניהול קבוצות דומיינים גדולות.
אימות הפלט של מחולל רשומות DKIM
אל תסתפקו בסימון תקין בלוח הבקרה; בדקו גם את תשובת DNS משורת הפקודה. אפשר לבדוק תוצאה של מחולל רשומות DKIM באמצעות שאילתה ישירה לבורר עם dig וקריאת התשובה.
התחילו בשאילתה ישירה:
dig txt default._domainkey.example.com +shortאם פורסמה רשומת TXT, אמורים להופיע ערך DKIM או המחרוזות במירכאות. אחרי שינוי DNS אפשר לשאול גם שרת DNS ציבורי. הדבר מראה את תשובתו, לא שכל מטמוני DNS בעולם התעדכנו:
dig txt default._domainkey.example.com @8.8.8.8 +shortשימו לב לנקודות הבאות:
- אין תשובה: ייתכן שהבורר או שם המארח שגויים, שיש השפעת מטמון או בעיית שאילתה אחרת. בדקו את התשובה המלאה.
- תשובה שנראית חלקית: ייתכן שזהו אופן התצוגה או פיצול TXT. השוו את הערך המלא לפני שקובעים שהרשומה קוצרה.
- כמה רשומות DKIM TXT סותרות תחת אותו בורר: תקנו זאת לפני בדיקה נוספת.
- DNS תקין אך אימות הדואר נכשל: בדקו כותרות ושהשולח משתמש בבורר ובמפתח הפרטי התואמים.
הנחיות Google לשולחים בתפוצה רחבה דורשות SPF, DKIM ו-DMARC. שגיאות DKIM עשויות לתרום להגבלת קצב או לדחיית הודעות בהתאם לתנאים החלים. עם זאת, כישלון DKIM אינו בהכרח כישלון DMARC אם SPF עובר עם התאמה. ראו את הפרטים העדכניים בשאלות הנפוצות על הנחיות לשולחי דואר.
משתמשי TrekMail צריכים לבדוק גם את נתיב השליחה. המסמך על הגדרות IMAP ו-SMTP מתאר SMTP משלכם ב-Nano ואת אפשרויות TrekMail SMTP במסלולים בתשלום. אם הודעות מגיעות לספאם למרות DNS תקין, עברו על ההודעות שלי מגיעות לספאם.
סיכום: התאימו את DKIM למבנה מערכת הדואר
מחולל רשומות DKIM המתאים תואם למבנה מערכת הדואר שלכם. לשרתים בניהול עצמי מתאימה בדרך כלל יצירה מקומית של מפתחות. בפלטפורמות מתארחות פעלו לפי הוראות TXT או CNAME של הספק ובדקו כיצד מנוהלת החלפת המפתחות.
אם אתם מנהלים MTA בעצמכם, השתמשו ב-OpenSSL מקומית והגנו על המפתח הפרטי כמו על פרטי גישה לייצור. אם אתם משתמשים ב-TrekMail, ב-SES או בספק שליחה אחר, השתמשו ברשומות שהוא מספק. אל תדביקו מפתחות אקראיים מטופס מקוון לא מוכר רק כדי להעלים אזהרה.
תהליך מאוחד עם אימות ברור עשוי לצמצם התערבות ידנית ב-DNS והזדמנויות לשגיאות. הדבר חשוב במיוחד עם כמה מותגים, דומיינים של לקוחות או העברת דואר שכבר מתבצעת. אם אתם עדיין בונים את הסביבה, קראו על העברת דואר מהדומיין ל-Gmail לפני הגדרת העברה, ואז השוו את מסלולי TrekMail.
מחולל רשומות DKIM לא צריך להיות קופסה שחורה, אלא שלב נשלט במערכת דואר שאתם מבינים.
