בורר DKIM: הגדרה, חיפוש ואבחון תקלות

לרוב מבחינים בבורר DKIM רק כשהאימות נכשל, Gmail מתחיל לסווג הודעות כספאם או ספק מבקש רשומת TXT מוזרה כמו tm1._domainkey.example.com. הבורר נראה פרט קטן, אבל טעות בו עלולה להכשיל DKIM. אם אין גם SPF תקין ותואם, DMARC עלול להיכשל. זה עשוי לפגוע בהגעה לנמענים.

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

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

מהו בורר DKIM?

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

הבורר אינו המפתח עצמו, אלא מידע לחיפוש. בכותרת DKIM-Signature הוא מופיע בתג s=. הדומיין החותם מופיע ב-d=. המקבל משלב אותם בשם DNS כמו selector._domainkey.example.com ומקבל את המפתח מרשומת TXT.

RFC 6376 מגדיר זאת במפורש: המאמת משתמש בדומיין מ-d= ובבורר מ-s= כדי למצוא את רשומת המפתח. ללא בורר אי אפשר להרכיב את שם החיפוש; בורר שגוי עשוי להפנות למפתח חסר או אחר. כך אי אפשר לאמת את החתימה כתקינה.

אם הודעה כוללת d=example.com ו-s=tm1, המקבל מחפש tm1._domainkey.example.com.

מה הבורר עושה בפועל?

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

יש לכך שלוש משמעויות תפעוליות.

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

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

איפה מוצאים את הבורר?

בכותרות ההודעה או בהנחיות DNS של ספק השליחה. בדואר אמיתי הוא ערך s= בכותרת DKIM-Signature.

פתחו כותרות גולמיות של הודעה שהתקבלה וחפשו DKIM-Signature:. בדקו את שני התגים האלה:

• d= מציג את הדומיין החותם.
• s= מציג את הבורר.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=tm1;
 c=relaxed/relaxed; h=from:to:subject:date:message-id;
 bh=...; b=...

במקרה הזה הבורר הוא tm1. הרשומה לבדיקה היא:

tm1._domainkey.example.com TXT

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

איך מפרסמים בורר DKIM ב-DNS?

יוצרים רשומת DNS ב-selector._domainkey.yourdomain.com. בדרך כלל זו TXT עם המפתח, או אצל ספקים מסוימים CNAME שמפנה למפתח המנוהל שלהם.

שתי הצורות הנפוצות נראות כך.

DKIM מבוסס TXT:

Host: tm1._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...

DKIM מבוסס CNAME:

Host: tm1._domainkey
Type: CNAME
Value: tm1.example-com.dkim.vendor.net.

אל תמציאו שם בורר כאשר השולח נותן אחד. אם הספק מבקש s1, פרסמו s1._domainkey. אם TrekMail מציג dkim._domainkey למסלול השליחה המנוהל בדומיין, השתמשו בדיוק בשם ובערך האלה. עם ספק חיצוני ב-Nano, הבורר שלו הוא הקובע; מדריך SMTP מותאם אישית (BYO) מסייע בהגדרת המסלול.

איך בודקים שהבורר עובד?

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

התחילו משאילתת DNS ישירה:

dig +short TXT tm1._domainkey.example.com
nslookup -type=TXT tm1._domainkey.example.com

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

שלחו הודעה אמיתית ובדקו את הכותרות:

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

אלה הדברים לבדיקה:

• dkim=pass
• header.s=tm1 תואם לבורר שפורסם
• header.i מציג זהות חתימה, אך אינו קובע התאמת DMARC. התאמה באמצעות DKIM נקבעת לפי דומיין d= מול דומיין From

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

למה בורר DKIM נכשל?

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

אלה כשלים שכיחים בסביבת ייצור.

1. שם מארח שגוי. פרסמתם _domainkey.tm1 במקום tm1._domainkey.
2. דומיין שגוי. הדואר חתום עם d=mg.example.com, אבל הבורר פורסם תחת example.com.
3. טעות בתצורות DNS נפרדות. הרשומה נמצאת בקבוצת שרתי שמות שאינה הסמכותית לדומיין.
4. מפתח קטוע. ערך TXT נחתך בהעתקה ללוח DNS.
5. בורר ישן עדיין בשימוש. החלפתם מפתחות, אבל השולח עדיין חותם בבורר הקודם.
6. שינוי הודעה אחרי חתימה. שירותי העברה או שערים שינו כותרות חתומות או תוכן גוף.

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

איך בוחרים שם לבורר?

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

שמות חסרי הקשר כמו default, key1 ו-test עשויים לעבוד, אבל נעשים לא ברורים עם הזמן. דוגמאות טובות יותר:

• tm1 לשליחה מנוהלת של TrekMail
• ses2026q1 להחלפת מפתחות Amazon SES
• crm1 לפלטפורמת CRM
• mktg2026a לדואר שיווקי

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

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

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

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

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

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

איך TrekMail מטפל בבורר?

TrekMail מציג הנחיות DNS ובדיקות מצב, ותומך בשליחה מנוהלת בחבילות בתשלום וב-BYO SMTP ב-Nano לפי התנאים. זה עשוי לצמצם ניחוש לגבי מיקום הבורר ובריאות DNS.

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

• חבילות בתשלום יכולות להשתמש ב-TrekMail Managed SMTP, שחותם במפתח DKIM של הדומיין שלכם.
• Nano משתמשת ב-BYO SMTP, ולכן ספק השליחה החיצוני קובע את הבורר הפעיל ואת התנהגות החתימה.

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

רשימת אבחון לבעיות בורר

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

1. בדקו הודעה שהתקבלה בפועל ורשמו s= ו-d=.
2. שאלו ישירות את DNS על selector._domainkey.domain.
3. בדקו את שרתי השמות הסמכותיים, לא רק את לוח הרשם.
4. בדקו אם הספק דורש TXT או CNAME.
5. השוו את דומיין From לדומיין החותם לצורך התאמת DMARC.
6. בדקו מחדש אחרי העברה, שערים או תוכנת רשימות אם ההודעה משתנה בדרך.

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

לסיכום: מה לזכור על בורר DKIM?

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

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