מפתח DKIM: אורך מומלץ, פרסום DNS והחלפה

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

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

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

מהו מפתח DKIM?

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

DKIM הוא קיצור של DomainKeys Identified Mail. המפתח הפרטי נשאר במערכת השליחה, והציבורי מפורסם ב-DNS תחת בורר כמו s1._domainkey.example.com.

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

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

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

באיזה אורך מפתח להשתמש?

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

הבסיס הרשמי הוא RFC 8301: חותמים חייבים להשתמש לפחות ב-1024 סיביות RSA, ומומלץ להשתמש לפחות ב-2048 סיביות. להמלצה הזאת יש משמעות תפעולית.

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

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

למה מפתח של 2048 סיביות נכשל ב-DNS?

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

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

הערך בתג p= למפתח RSA של 2048 סיביות עשוי לדרוש כמה מחרוזות במירכאות ברשומת TXT אחת. יישום אימות DKIM מחבר אותן; פותר DNS אינו חייב להפוך אותן למחרוזת אחת. פרסום שגוי עלול להכשיל אימות.

כשלים נפוצים:

• לוח DNS קוטע את הערך ב-255 אוקטטים.
• הלוח מוסיף רווחים או מעברי שורה למפתח.
• מפרסמים כמה רשומות TXT במקום רשומה אחת עם כמה מחרוזות.
• מסירים חלק מהתחילית v=DKIM1; k=rsa; p= בניסיון לקצר.

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

איך מפרסמים מפתח של 2048 סיביות נכון?

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

תחביר בקובץ אזור נראה כך:

s1._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
  "...rest_of_the_public_key_here...QAB"
)

ממשקי רשת רבים דורשים אותה רשומה בשורה אחת:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..." "...rest_of_the_public_key_here...QAB"

בדקו מבחוץ. אל תסתמכו רק על תצוגה מקדימה.

dig txt s1._domainkey.example.com +short

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

ב-TrekMail אפשר לעקוב אחר SMTP מנוהל של TrekMail ואשף DNS. החבילות בתשלום מתארות SMTP מנוהל וערך רשומת DKIM של הדומיין בלוח. מחיר Starter ההתחלתי המוצג הוא $3.50 לחודש, עם ניסיון של 14 יום המחייב כרטיס אשראי. Nano מוצגת כחבילה חינמית עם SMTP משלכם. בדקו את התנאים העדכניים.

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

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

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

תהליך זהיר:

1. צרו זוג מפתחות חדש של 2048 סיביות.
2. תנו לו בורר חדש כמו s2.
3. פרסמו s2._domainkey.example.com ב-DNS.
4. העבירו את תצורת השליחה ל-s2.
5. השאירו s1 לפחות כמה ימים, לפי התורים והמדיניות שלכם.
6. הסירו s1 אחרי שניתן מספיק זמן לדואר שנחתם קודם.

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

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

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

מתי להחליף מפתח DKIM?

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

הכלל המעשי: אם ייתכן שהמפתח הפרטי דלף, פעלו מיד לפי נוהל האירועים. אם הכול תקין, עדיין פעלו לפי לוח הזמנים.

סיבות להחלפה מוקדמת:

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

סיבות שאינן מצדיקות דחייה:

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

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

האם להשתמש ב-Ed25519 ל-DKIM?

Ed25519 נותן מפתח קצר יותר ומונע את ערכי TXT הארוכים של RSA-2048. השיקול הוא תאימות המקבל. הוא תוקנן ל-DKIM ב-RFC 8463, אך RSA-2048 הוא לרוב ברירת מחדל נפוצה יותר לתאימות רחבה.

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

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

לרוב המפעילים:

• השתמשו ב-RSA-2048 כברירת מחדל.
• השתמשו ב-Ed25519 רק אם אתם מבינים את התאימות ויכולים לבדוק.
• אל תעברו ל-Ed25519 בלבד רק כי הרשומה נראית קצרה יותר.

הגישה הישנה והחדשה לניהול DKIM בהיקף רחב

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

הגישה הישנה:

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

הגישה החדשה:

• תהליך אחד לדומיינים רבים.
• SMTP מנוהל חותם לפי התצורה.
• פחות אבחון חוזר של TXT ארוך ופערי אימות.

TrekMail מיועד לאחסון דואר למספר דומיינים בתעריף קבוע ולא לפי משתמש. התכונות המתוארות כוללות אחסון משותף, תיבות IMAP, הגירת IMAP מובנית, catch-all, העברה, BYO SMTP ב-Nano ו-SMTP מנוהל בחבילות בתשלום. הזמינות כפופה לתנאים. עם כללי העברה עשויים להופיע הבדלי אימות; קראו גם העברת דואר דומיין ל-Gmail.

לצוותים ולסוכנויות, הערך אינו קסם ב-DNS אלא פחות עבודה חוזרת ותמונה ברורה יותר. מחיר Starter ההתחלתי המוצג הוא $3.50 לחודש; בדקו מחירים ותנאי חיוב עדכניים.

לסיכום: מפתח DKIM

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

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