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

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

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

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

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

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

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

המסלול: שרת A שולח לשרת ההעברה B, שפותח חיבור TCP חדש ליעד C. השרת C רואה את כתובת ה-IP של B. ‏SPF שואל את ה-DNS של דומיין המעטפה: "האם כתובת זו מורשית לשלוח בשם הדומיין?" אם שולח המעטפה המקורי נשמר ו-B אינו מורשה, SPF עלול להיכשל. זה אינו כשל מובטח בכל העברה.

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

שלושה סוגי כשלים שכדאי להכיר

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

1. חסימת דואר יוצא ב-Microsoft 365 ‏(550 5.7.520)

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

550 5.7.520 Access denied, Your organization does not allow external forwarding.

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

1. פתחו את Microsoft 365 Defender Portal.
2. עברו אל Email & collaboration → Policies & rules → Threat policies → Anti-spam.
3. ערכו את Outbound spam filter policy שטווח התחולה שלה מוגבל למשתמשים או לקבוצות שאושרו.
4. אם הדבר מאושר, הגדירו את Automatic forwarding בטווח זה בלבד ל-On - Forwarding is enabled.

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

2. היעדר תוצאת אימות מתאימה עבור DMARC

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

שינויים נפוצים שעלולים לשבור DKIM:

• תוכנת אנטי-וירוס שמוסיפה שורת סיום: "נסרק באמצעות [שם המוצר]"
• תגיות נושא שמוסיף שער היעד: [EXT] או [EXTERNAL], אם שדה Subject חתום
• אזהרות "שולח חיצוני" שמוזרקות לגוף ה-HTML
• תוכנת רשימות תפוצה שמשכתבת שדות כותרת חתומים או מוסיפה שורת הסרה מרשימת התפוצה

אם אין הצלחה של SPF או DKIM עם התאמת דומיין, תוצאת DMARC (RFC 7489) היא FAIL. ‏p=reject מבקש דחייה, אך הנמען מחליט על הטיפול בפועל. דחיית SMTP עשויה להוביל להודעת אי-מסירה, ואילו טיפול אחר עשוי שלא להפיק התראה גלויה. בדקו יומנים ותוצאות אימות במקום להניח מחיקה שקטה ודאית.

3. לולאות ניתוב (554 5.4.14)

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

גורמים נפוצים:

• משתמש A מעביר למשתמש B, ול-B יש כלל שמעביר בחזרה ל-A.
• A מעביר ל-B, ותשובת ההיעדרות האוטומטית של B נכנסת שוב למסלול ההעברה. החזרה תלויה בכללים ובמנגנוני מניעת לולאות; תשובות אוטומטיות תקינות בדרך כלל מונעות חזרה מתמשכת.
• כתובת catch-all מעבירה לתיבה שמעבירה שוב לכתובת שאינה קיימת באותו דומיין.

554 5.4.14 Hop count exceeded - possible mail loop

בדקו תמיד את מסלול הניתוב המלא, כולל תשובות אוטומטיות ויעדי catch-all, לפני הפעלת העברה בסביבת ייצור.

כלי הטיפול: SRS ו-ARC

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

SRS: מנגנון שכתוב שולח

SRS משכתב את שולח המעטפה (P1) לדומיין שבשליטתכם. במקום לשמור את alice@bank.com כשולחת המעטפה, אף שהשרת שלכם אולי אינו מורשה לשלוח עבור הדומיין שלה, שרת ההעברה יכול לשכתב את Return-Path לכתובת הבאה:

SRS0=Hash=Timestamp=bank.com=alice@your-forwarding-domain.com

SPF בודק כעת את הדומיין שלכם. אם הרשומה שלו מתירה את כתובת ה-IP היוצאת ושאר הבדיקה תקין, SPF יכול לעבור. עם זאת, אין בכך התאמת דומיין אוטומטית ל-From: המקורי המוצג.

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

ARC: שרשרת קבלה מאומתת

SRS עשוי לאפשר ל-SPF לעבור, אך אינו מתקן אוטומטית את התאמת הדומיינים בין המעטפה לכותרת המוצגת. גם ARC (RFC 8617) אינו מתקן התאמה זו. שרת ההעברה מוסיף מידע חתום על מצב האימות שראה בעת קבלת ההודעה.

Google ו-Microsoft עשויים להשתמש בשרשראות ARC תקפות של מתווכים מהימנים בהחלטת המסירה. שרשרת תקפה ומוניטין טוב אינם מבטיחים מסירה ב-Gmail או ב-Outlook. הנמען קובע באילו מתווכים לבטוח וכיצד לטפל בכשל DMARC.

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

Gmail ו-Microsoft 365 עשויים להוסיף חותמות ARC במסלולים נתמכים; בדקו את הכותרות במסלול שלכם. ללא ARC אין תיעוד כזה, אך DKIM מקורי תקף ומתאים עדיין יכול לאפשר ל-DMARC לעבור. היעדר ARC אינו כשל DMARC אוטומטי.

יישום: שני מסלולים

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

אפשרות A: ‏Postfix + postsrsd בניהול עצמי

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

# /etc/postfix/main.cf
sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient

תחומי האחריות שלכם בגישה זו:

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

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

אפשרות B: ‏TrekMail להעברה מנוהלת

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

ליזמים עצמאיים: אם אתם משלמים $6 לחודש לכל תיבה רק כדי להעביר את info@yourdomain.com לתיבה האישית, השוו גם פתרונות בתעריף קבוע. מחיר Starter שמוזכר כאן, $3.50 לחודש לעד 50 דומיינים ללא תשלום לפי משתמש, הוא נתון ייחוס ולא הבטחה לתנאים הנוכחיים. בדקו מחיר, הרשאות העברה ומגבלות. ראו כיצד עובדת העברת דואר מתיבה ב-TrekMail.

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

רשימת בדיקה לפני העברת דוא״ל לכתובת אחרת

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

1. SRS עובד במסלולים שבהם הוא נדרש. בדקו את Return-Path בהודעת ניסיון שנמסרה. במסלול עם SRS, הכתובת המשוכתבת צריכה להשתמש בדומיין ההעברה. בדקו גם את תוצאת SPF בפועל.
2. שמרו על התוכן החתום. הימנעו משורות סיום, מתגיות נושא ומאזהרות HTML שעלולות לשבור DKIM. אל תכבו סריקות אבטחה; שמרו על הגנות שקולות שאינן משנות את ההודעה החתומה. לא כל שינוי שובר DKIM: הקנוניקליזציה והשדות החתומים קובעים.
3. בדקו מניעת לולאות. בדקו כללי העברה חזרה, מסלולי catch-all ותשובות אוטומטיות. נסו את מנגנוני המניעה במקום להניח שכל הודעת היעדרות יוצרת לולאה.
4. בדקו מדיניות יציאה ב-M365. ב-Exchange Online אפשרו "Automatic Forwarding" רק למשתמשים או לקבוצות מאושרים באמצעות מדיניות מוגבלת בטווח התחולה בפורטל Defender. בדקו את המדיניות האפקטיבית ואת החסימות הנוספות.

מתי עדיף לא להעביר דוא״ל לכתובת אחרת

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

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

סיכום

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

הטיפול הוא ברמת השרת: SRS משכתב את שולח המעטפה ויכול לסייע ל-SPF לעבור עבור הדומיין שלכם; ARC מספק תיעוד חתום שהנמען רשאי להשתמש בו לפי שיקול דעתו. אף אחד מהם אינו מבטיח התאמת דומיינים או מסירה. אפשר ליישם אותם עצמאית או לבדוק את התמיכה בשירות מנוהל.

כדי לצמצם ניהול מפתחות SRS, הגדרת ARC וטיפול במוניטין, בדקו מה TrekMail מציע למסלול שלכם. יש להשוות את מחיר Starter המוזכר, $3.50 לחודש לעד 50 דומיינים בתעריף קבוע ללא תשלום לפי משתמש, לתנאים העדכניים. לכל התוכניות.