הגדרת DKIM לדומיינים מותאמים אישית: מדריך מעשי

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

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

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

מה הגדרת DKIM עושה בפועל?

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

DKIM משתמש בהצפנה אסימטרית. מערכת השליחה מחזיקה במפתח הפרטי ו-DNS מפרסם את הציבורי. הודעה יוצאת מקבלת כותרת DKIM-Signature עם דומיין חותם (d=) ובורר (s=). שרת המקבל מחפש את הבורר ב-DNS ומאמת את החתימה מול תוכן ההודעה. המנגנון מוגדר ב-RFC 6376.

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

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

לפני שנוגעים ב-DNS

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

שאלו תחילה: מי שולח את הדואר היוצא של הדומיין?

1. אם Google Workspace שולחת, צרו את מפתח DKIM ב-Google Admin.
2. אם Microsoft 365 שולחת, הפעילו שם DKIM.
3. אם SendGrid, Mailgun או Amazon SES שולחים, אמתו את הדומיין אצל אותו ספק.
4. אם TrekMail Managed SMTP שולח, השתמשו בערכי DKIM שמוצגים ב-TrekMail.
5. אם TrekMail מנהל תיבות אבל אתם משתמשים ב-SMTP חיצוני, פעלו לפי הנחיות החתימה של ספק SMTP ואז הגדירו SMTP ב-TrekMail לפי הצורך.

TrekMail תומך בשני המסלולים. Nano משתמשת ב-BYO SMTP, ובחבילות בתשלום ניתן להשתמש ב-SMTP מנוהל בהתאם לתנאים. התיעוד של Bring Your Own SMTP מציג דוגמאות של SES, SendGrid ו-Mailgun. התיעוד לפתרון בעיות הגעה מציין גם ש-Managed SMTP חותם במפתח DKIM של הדומיין שלכם. זה עשוי לסייע ל-DMARC בהעברה ובממסרים אם התוכן החתום אינו משתנה והחתימה נשארת תקינה ותואמת.

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

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

סוגי רשומות DKIM: TXT לעומת CNAME

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

הגדרת DKIM רגילה משתמשת ברשומת TXT בכתובת:

selector._domainkey.example.com

הערך נראה כך:

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

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

המלכודת היא שדה שם המארח. אם הדומיין הוא example.com והבורר הוא k1, שם המארח הוא בדרך כלל:

k1._domainkey

ולא:

k1._domainkey.example.com

לוחות DNS רבים מוסיפים את הדומיין הראשי אוטומטית. אם תזינו שם מלא בלוח כזה, תפרסמו בסופו של דבר k1._domainkey.example.com.example.com. הרשומה לא תהיה במקום שבו שרתי המקבלים מחפשים אותה.

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

הגדרת DKIM ב-DNS שלב אחר שלב

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

פעלו לפי הנוהל הזה.

1. פתחו את ספק השליחה וצרו או הציגו את רשומת DKIM.
2. העתיקו את הבורר בדיוק. אל תשנו את שמו אלא אם הספק תומך בכך.
3. צרו את רשומת DNS ב-selector._domainkey.
4. הדביקו את ערך TXT המלא או את יעד CNAME בדיוק כפי שסופקו.
5. הגדירו TTL ל-3600, אלא אם יש סיבה לבחור ערך אחר.
6. המתינו להפצת העדכון.
7. אמתו באמצעות dig או nslookup לפני שליחת דואר בייצור.
8. הפעילו חתימה אצל הספק אם הממשק כולל מתג הפעלה אחרון.

דוגמת DKIM מבוססת TXT:

; DNS record
k1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

דוגמה מבוססת CNAME:

; DNS record
s1._domainkey.example.com. 3600 IN CNAME s1.domainkey.u123456.wl.provider.net.

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

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

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

Google ממליצה על מפתחות של 2048 סיביות כאשר יש תמיכה, ועל 1024 סיביות כחלופה למארחים שאינם מטפלים ברשומות ארוכות. הבעיה המעשית אינה בדרך כלל DNS עצמו, אלא לוח הניהול שלפניו.

בעיות DKIM עם מפתח של 2048 סיביות נראות לרוב כך:

1. הלוח מקצר את הערך בלי להתריע.
2. הלוח דורש חלקים במירכאות ולא מסביר זאת.
3. הלוח מוסיף מעברי שורה למפתח base64.
4. הלוח מבצע escaping לתווים באופן שהספק לא ציפה לו.

אם מארח DNS דורש מחרוזות מפוצלות, פרסמו כך:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
"restOfTheKeyContinuesHereWithoutAddingSpacesInsideTheBase64Data"

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

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

אימות DKIM באמצעות DNS ודואר אמיתי

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

התחילו משורת הפקודה.

# macOS / Linux
dig txt k1._domainkey.example.com +short

# Windows
nslookup -type=txt k1._domainkey.example.com

אתם רוצים לראות את רשומת v=DKIM1 המלאה או חלקים במירכאות שמתחברים למפתח מלא. אם התוצאה ריקה, בדקו לפי הסדר:

1. הבורר נכון.
2. הדומיין אינו כפול בשדה שם המארח.
3. סוג הרשומה תואם למה שהספק ביקש.
4. הערך מלא ולא קטוע.
5. הרשומה הישנה אינה עדיין במטמון.

שלחו אחר כך הודעת בדיקה ל-Gmail או לתיבה שבה תוכלו לבדוק כותרות. חפשו את תוצאות האימות ואת שורת חתימת DKIM.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...
Authentication-Results: ... dkim=pass header.d=example.com ...

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

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

DKIM ומלכודת ההתאמה

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

דוגמה נפוצה:

From: ceo@example.com
חותם DKIM: d=sendgrid.net
תוצאה: DKIM עשוי לעבור, אבל התאמת DMARC באמצעותו עלולה להיכשל משום שהדומיין החותם אינו תואם ל-example.com.

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

הספק עשוי לקרוא להגדרות האלה אימות דומיין, white-labeling או return-path מותאם אישית. return-path משפיע על התאמת SPF, ולא משנה לבדו את דומיין חתימת DKIM. עבור DKIM, הגדירו אימות דומיין כדי שהחתימה הסופית תיראה כך:

DKIM-Signature: ... d=example.com; s=s1; ...

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

הגישה הישנה והחדשה להגדרת DKIM

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

TrekMail מתאים למודל הזה. היכולות המתוארות כוללות ניהול כמה דומיינים מותאמים אישית מלוח אחד, אחסון משותף במקום תשלום לכל תיבה, הגירת תיבות ב-IMAP ובחירה בין BYO SMTP ל-SMTP כלול בהתאם לחבילה. המחיר ההתחלתי המוצג לחבילות בתשלום הוא $3.50 לחודש; בדקו את תנאי החיוב העדכניים. הפלטפורמה מיועדת לצוותים, עסקים קטנים, סוכנויות ו-MSP שרוצים לצמצם ניהול תשתיות דואר.

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

רשימת הבדיקה הסופית ל-DKIM

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

1. אשרו איזו מערכת חותמת על הדואר היוצא.
2. פרסמו בדיוק את הבורר וסוג הרשומה של הספק.
3. השתמשו ב-selector._domainkey בשדה שם המארח, אלא אם מארח DNS מבקש במפורש שם מלא.
4. שמרו על מפתחות 2048 סיביות בשלמותם. פצלו מחרוזות במירכאות רק אם לוח DNS דורש זאת.
5. אמתו באמצעות dig או nslookup.
6. שלחו בדיקה ובדקו בכותרות dkim=pass ו-header.d תואם.
7. בדקו תוצאות DMARC אחרי העלייה לאוויר.

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