כשל DMARC בהעברה: סיבות ודרכי טיפול

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

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

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

מה כשל DMARC אומר בפועל

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

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

1. SPF עובר והדומיין שלו תואם לדומיין Header From.
2. DKIM עובר ודומיין החתימה תואם לדומיין Header From.

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

• אימות: האם SPF או DKIM עברו?
• התאמת דומיינים: האם דומיין הבדיקה שעברה מתאים לדומיין Header From?
• עמידות בהעברה: האם הנתונים החתומים נשארו תקינים אחרי שלב הביניים?

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

למה העברה גורמת לעיתים קרובות לכשל DMARC

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

מסלול נפוץ נראה כך:

1. השולח שולח דואר מ-sender.com.
2. תיבת דואר או שער ביניים מקבלים אותו.
3. המערכת מעבירה אותו אוטומטית ל-Gmail, ל-Outlook או ליעד אחר.

בשלב הזה הנמען הסופי רואה את כתובת ה-IP של השרת המעביר כלקוח SMTP, ולא את כתובת השולח המקורי.

כאן עלול להתחיל כשל DMARC.

SPF מושפע ראשון

SPF מוגדר ב-RFC 7208. הוא בודק אם כתובת ה-IP המתחברת רשאית לשלוח בשם דומיין שולח המעטפה.

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

המסלול המקורי: sender.com שולח מ-IP A ו-SPF עובר.
המסלול המועבר: גורם ביניים שולח מ-IP B. הנמען בודק את sender.com מול IP B, ו-SPF נכשל אם הכתובת אינה מורשית.

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

DKIM יכול לשמר מסלול אימות

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

הדבר דורש את שני התנאים הבאים:

1. החתימה עדיין תקינה אחרי ההעברה.
2. דומיין d= תואם לדומיין From הגלוי.

אם אחד התנאים חסר ואין מסלול אימות תואם אחר, עלול להתרחש כשל DMARC.

מערכות העברה עשויות לשנות הודעות בדרכים שפוגעות בחתימה:

• הוספת [EXTERNAL] לנושא
• הוספת הצהרת אחריות או טקסט משפטי בתחתית ההודעה
• שכתוב גבולות MIME
• שינוי שבירת שורות או רווחים

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

מלכודת ההתאמה גם בלי העברה

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

זו מלכודת הגדרה שקל לפספס בתפעול.

לדוגמה:

• From: billing@yourcompany.com
• Return-Path: bounce.vendor-mail.com
• DKIM: d=vendor-mail.com

SPF יכול לעבור עבור vendor-mail.com וגם DKIM יכול לעבור עבור vendor-mail.com. עדיין מתקבל כשל DMARC, משום שאף זהות מאומתת אינה תואמת ל-yourcompany.com.

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

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

איך מאבחנים כשל DMARC בכותרות

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

בקשו מהנמען את הכותרות המלאות וחפשו תוצאה כמו זו:

Authentication-Results: mx.google.com;
       spf=fail smtp.mailfrom=sender.com;
       dkim=pass header.i=@sender.com header.s=mail;
       dmarc=pass header.from=sender.com

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

הגרסה הבאה דורשת בירור נוסף:

Authentication-Results: mx.google.com;
       spf=fail smtp.mailfrom=sender.com;
       dkim=fail header.i=@sender.com;
       dmarc=fail header.from=sender.com

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

איך מצמצמים כשל DMARC בהודעות מועברות

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

1. נהלו DKIM בכל זרמי השליחה

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

דומיין החתימה צריך להתאים ל-From הגלוי. אם ההודעה מציגה yourdomain.com, חתמו ב-yourdomain.com או בתת-דומיין התואם לפי המצב שנבחר. התאמה מסוג relaxed מתבססת על הדומיין הארגוני, ו-strict מחייבת התאמה מדויקת של הדומיין.

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

2. השתמשו בקנוניקליזציה מתאימה מסוג relaxed

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

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

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

3. בדקו התאמת דומיינים אצל ספקים

אם CRM, מערכת תמיכה או כלי דיוור חותמים ב-d=vendor.com, בדקו אם קיימת חתימת DKIM נוספת תקינה ותואמת או מסלול SPF שעובר בהתאמה. בלי מסלול כזה עלול להתרחש כשל DMARC גם לפני העברה. הגדירו אימות מתאים לדומיין שלכם. return-path מותאם ו-DKIM מותאם ממלאים תפקידים שונים; DMARC אינו דורש תמיד את שניהם, אך פתרון התלוי רק ב-SPF עלול להיפגע בהעברה.

4. השאירו את SPF בתוך מגבלות הבדיקה

SPF נכשל לא רק בהעברה. שירותים ישנים ו-includes מקוננים עלולים להפוך את הרשומה למורכבת מדי. RFC 7208 מגביל ל-10 מנגנונים ומשנים הגורמים לפניות DNS בזמן בדיקה, כולל מסלולים מקוננים רלוונטיים. חריגה עלולה להחזיר permerror ולמנוע מ-SPF לספק מעבר DMARC.

dig +short TXT example.com

dig +short TXT _dmarc.example.com

אם Google, Microsoft, Mailgun, SendGrid, Zendesk וספקים ישנים נמצאים ברשומה אחת, מפו מה עדיין פעיל. הסירו מקורות לא נחוצים והשתמשו בתת-דומיינים במקומות מתאימים. flattening עשויה לדרוש תחזוקה כשכתובות הספק משתנות.

5. הבינו מה SRS ו-ARC יכולים לעשות

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

הנחיות Google הנוכחיות מבחינות בין דואר ישיר למועבר וממליצות על ARC בשירותי העברה. אין פירוש הדבר שהתנאים הטכניים של התאמת DMARC נעלמים בהעברה. ב-2025 וב-2026 דואר עקיף נשאר תחום חשוב לבדיקה; בדקו את תחולת הכללים העדכנית אצל הספק.

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

הגישה הישנה והחדשה לניהול דומיינים רבים

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

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

מה לעשות כשמגיעה פנייה על כשל DMARC

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

1. קבלו מהנמען את הכותרות המלאות.
2. בדקו אם SPF נכשל כי כתובת החיבור שייכת למעביר מוכר.
3. בדקו אם DKIM עבר או נכשל ואיזה דומיין d= חתם.
4. בדקו אם דומיין החתימה תואם ל-From הגלוי.
5. חפשו arc=pass והעריכו את השרשרת אם ההודעה עברה אצל מתווך מהימן.
6. בדקו עומס פניות DNS ו-includes ישנים ב-SPF.

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

סיכום: כשל DMARC דורש בדיקה של התכנון

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

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

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

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