יצירת רשומת DKIM: מדריך להגדרת DNS ולאימות

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

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

מהי רשומת DKIM?

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

יצירת רשומת DKIM ב-4 שלבים

שלב 1: יצירת זוג מפתחות DKIM

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

אם אתם משתמשים בשירות דואר מתארח כמו Google Workspace, Microsoft 365 או Zoho, הספק מספק בדרך כלל את נתוני המפתח והנחיות DNS. העתיקו את הרשומה שהוא נותן. ב-Google Workspace עברו אל מסוף הניהול > אפליקציות > Google Workspace > Gmail > אימות דואר ובחרו ״יצירת רשומה חדשה״.

אם אתם מפעילים שרת דואר משלכם עם Postfix, Exim או OpenDKIM, צרו את הזוג משורת הפקודה:

openssl genrsa -out dkim_private.pem 2048
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pem

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

בחרו גם בורר: שם שמזהה את המפתח המסוים. בוררים מאפשרים החלפת מפתחות או מפתח נפרד לכל שירות. שמות נפוצים הם google, s1, mail2026 או שם שירות כמו sendgrid.

שלב 2: הוספת המפתח הציבורי ל-DNS

כאן מפרסמים את רשומת DKIM ב-DNS של הדומיין. היכנסו לספק DNS שלכם, למשל Cloudflare, Route 53, GoDaddy או Namecheap, והוסיפו TXT לפי הנחיות מערכת השליחה. ספקים מסוימים דורשים CNAME במקום זאת.

שדה מארח/שם:

selector._domainkey.yourdomain.com

החליפו את selector בשם שבחרתם בשלב 1. אם הבורר הוא s1 והדומיין הוא example.com, השם המלא הוא:

s1._domainkey.example.com

שדה ערך:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2K4PavXoNY8eGK2u...truncated...base64encodedpublickey

התג p= מכיל את המפתח הציבורי המלא כמחרוזת base64. הסירו כותרות PEM כמו -----BEGIN PUBLIC KEY----- ואת מעברי השורה. נתוני המפתח צריכים להיות רציפים.

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

שלב 3: הפעלת חתימת DKIM בשרת הדואר

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

Google Workspace: בחרו ״התחלת אימות״ באותו לוח ניהול שבו יצרתם את המפתח.

OpenDKIM עם Postfix/Exim: ערכו את /etc/opendkim.conf:

Selector    s1
KeyFile     /etc/opendkim/keys/example.com/dkim_private.pem
Domain      example.com
Socket      inet:8891@localhost

הוסיפו אחר כך את ה-milter של Postfix ב-/etc/postfix/main.cf:

milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891

הפעילו מחדש את שני השירותים:

sudo systemctl restart opendkim
sudo systemctl restart postfix

שירותי שליחה חיצוניים כמו SendGrid, Mailgun ו-Amazon SES משתמשים כל אחד בתהליך הפעלה משלו. בדרך כלל הם נותנים CNAME או TXT לפרסום ב-DNS, ואז מפעילים אימות בלוח הספק.

שלב 4: אימות הרשומה

אל תניחו שההגדרה עובדת. בדקו מיד.

משורת הפקודה:

dig TXT s1._domainkey.example.com +short

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

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

Authentication-Results: mx.google.com;
    dkim=pass header.i=@example.com header.s=s1

אם מופיע dkim=pass, חתימת הודעת הבדיקה אומתה; בדקו גם התאמת DMARC. אם מופיע dkim=fail או dkim=neutral, בדקו את התצורה ואת הטעויות הנפוצות הבאות.

הסבר התחביר של רשומת DKIM

חשוב להבין את התחביר, במיוחד בהגדרה הראשונה. זה המבנה:

v=DKIM1; k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQE...

טעויות נפוצות ביצירת רשומות DKIM

אותן טעויות חוזרות כשהצוות מגדיר DKIM לראשונה.

1. מעברי שורה במפתח הציבורי. בעיה נפוצה. העתקת מפתח מקובץ PEM עם מעברי שורה לשדה DNS עלולה ליצור ערך לא תקין. הסירו מעברי שורה ורווחים מנתוני base64.

2. בורר שגוי בשם DNS. יצרתם מפתח עם הבורר s1, אך תצורת השרת משתמשת ב-default. המקבל מחפש default._domainkey.example.com ואינו מוצא את המפתח הדרוש. הבורר ב-DNS חייב להיות זהה לזה שבחתימה.

3. כמה רשומות DKIM עם אותו בורר. בניגוד ל-SPF, שדורש רשומה אחת לכל דומיין, DKIM מאפשר כמה בוררים. עם זאת, כל בורר חייב להיות חד-משמעי. שתי רשומות TXT עבור s1._domainkey עלולות ליצור פרסום מפתח לא תקין או עמום.

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

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

DKIM, SPF ו-DMARC: מערך האימות המלא

DKIM אינו פועל לבד; הוא אחד משלושה מרכיבי אימות.

SPF בודק אם כתובת IP של שרת השליחה מורשית מטעם הדומיין. בהעברת דואר הוא עלול להיכשל משום שכתובת השליחה משתנה. התחילו במדריך הגדרת SPF וקראו איך SPF עובד בדואר כדי להבין את מגבלת 10 הרכיבים שמפעילים DNS ואת שאר האילוצים.

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

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

שאפו ל-SPF ול-DKIM תקינים ותואמים, והפעילו p=reject רק אחרי אימות זרמי דואר לגיטימיים. זה מסייע להגנת הדומיין, אך אינו מבטיח מוניטין דומיין חזק או הגעה טובה יותר לתיבה.

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

איך TrekMail מסייע ב-DKIM?

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

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

• Nano ($0): BYO SMTP כמו Amazon SES או Mailgun. פעלו לפי הנחיות DKIM של הספק. החבילה מוצגת ללא דרישת כרטיס אשראי; בדקו את התנאים העדכניים.
• Starter ($3.50 לחודש): SMTP מנוהל ונתוני DKIM דרך TrekMail. בדקו את היקף התמיכה העדכני ביצירה ובהחלפת מפתחות. תקופת הניסיון המוצגת היא 14 יום ודורשת כרטיס.
• Pro ($10 לחודש): התמיכה בכמה דומיינים שולחים ובתצורות DKIM שלהם כפופה לתנאי החבילה. תקופת הניסיון המוזכרת היא 14 יום.
• Agency ($23.25 לחודש): מיועדת לניהול מרכזי של דומייני לקוחות. היקף 100+ הדומיינים ויכולות החלפת המפתחות והניטור המוזכרים תלויים בתנאים העדכניים. תקופת הניסיון המוצגת: 14 יום.

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

סיכום

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

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

אם אתם רוצים פחות ניהול DNS ידני, בדקו את החבילה החינמית של TrekMail והיעזרו בהנחיות האשף לשלבים הזמינים.