מדריך לאימות DNS עבור מיילים בלי שגיאות

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

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

למה אימות DNS למיילים הוא שכבת תשתית

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

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

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

מדריך לאימות DNS עבור מיילים: סדר עבודה נכון

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

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

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

SPF: מי רשאי לשלוח בשם הדומיין

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

`v=spf1 include:sender.example -all`

התחביר עצמו קצר, אבל המשמעות רחבה. המנגנון include מפנה למדיניות של שירות אחר, וניתן לשלב כמה הפניות, כתובות IP או מנגנוני אימות. בסוף הרשומה מופיעה מדיניות כישלון: `-all` מציין כישלון קשיח, בעוד `~all` מציין כישלון רך. בחירה בין השניים תלויה במידת הביטחון שלכם במיפוי השולחים.

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

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

DKIM: חתימה שמוכיחה שההודעה לא שונתה

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

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

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

לאחר הפרסום, אל תסתפקו בבדיקה שהרשומה קיימת. שלחו הודעת בדיקה ובחנו את כותרות המייל. חפשו תוצאת `dkim=pass` ובדקו שהדומיין החותם תואם לדומיין המופיע בשדה From, או לפחות עומד בתנאי היישור שהגדרתם ב-DMARC.

DMARC: המדיניות שמחברת את הכול

DMARC מפורסם כרשומת TXT תחת `_dmarc` ומאפשר לכם לפרסם מדיניות עבור הודעות שנכשלו ביישור SPF ו-DKIM. ערך התחלתי טיפוסי הוא:

`v=DMARC1; p=none; rua=mailto:[email protected]`

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

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

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

בדיקות אחרי פרסום: DNS אינו מתעדכן בלחיצה

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

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

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

תקלות שחוזרות שוב ושוב

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

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

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