העברת דוא״ל דרך כינוי: סיכונים ופתרונות

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

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

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

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

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

כינוי דוא״ל הוא כלל ניתוב, ללא תיבת דואר נכנס, פרטי כניסה או מכסת אחסון משלו. כשמישהו כותב אל sales@yourdomain.com, שרת הדואר שלכם מקבל את ההודעה ומעביר אותה ליעד אחר, בדרך כלל חשבון Gmail או Outlook אישי. זהו פתרון מעשי נפוץ לכתובות תפקיד בעסקים קטנים. בהעברה חיצונית, עם זאת, הודעות עלולות ללכת לאיבוד בלי שהנמען יבחין בכך.

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

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

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

כש-client@bank.com כותב לכינוי שלכם sales@yourdomain.com, השרת של bank.com שולח את ההודעה. בדוגמה זו SPF עובר, משום ש-bank.com אישר את כתובות ה-IP של שרתי השליחה שלו.

כשהשרת שלכם מעביר את ההודעה אל founder@gmail.com, הוא פותח חיבור SMTP חדש. כעת השרת שלכם הוא שמתחבר. ללא שכתוב, שולח המעטפת המקורי נשאר ללא שינוי, ובכותרת עדיין מופיע client@bank.com.

Gmail בודק SPF עבור bank.com לפי כתובת ה-IP של השרת שלכם, ש-bank.com לא אישר. SPF נכשל. אם רשומת DMARC של bank.com כוללת p=reject וגם אין חתימת DKIM תקפה עם דומיין תואם, Gmail עשוי לדחות את ההודעה בהתאם למדיניות הקבלה שלו. אין פירוש הדבר בהכרח מחיקה מיידית ללא הודעה: דיווח כשל עשוי להגיע לשולח המקורי, בעוד שאתם, נמעני הכינוי, לא תקבלו התראה.

שלושה סוגי כשל בהעברה דרך כינוי

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

1. כשל SPF

SPF בודק אם כתובת ה-IP של חיבור SMTP מורשית לשלוח לפי רשומת DNS של הדומיין ב-MAIL FROM או ב-HELO. בחיבור החדש של ההעברה, היעד רואה את ה-IP שלכם במקום את כתובת השרת המקורי. אם שולח המעטפת נשאר ללא שינוי וה-IP שלכם אינו מורשה עבור הדומיין שלו, SPF ייכשל ביעד. כאן מתחילה בעיית האימות.

2. דחייה בשל DMARC

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

3. אובדן הודעה ללא התראה

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

קודי שגיאה לחיפוש ביומני SMTP

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

חסימה ב-Microsoft 365 ‏(5.7.520)

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

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

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

לולאת ניתוב ‏(5.4.14 / 5.4.6)

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

554 5.4.14 Hop count exceeded - possible mail loop

תיקון: בדקו את כללי התעבורה. סיכון נפוץ הוא catch-all עבור *@yourdomain.com שהיעד שלו משיב אוטומטית לכל הודעה נכנסת. יחד עם כללי החזרה לא מתאימים, השילוב עלול ליצור לולאה.

כשל אימות DMARC ‏(550 5.7.1)

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

550-5.7.1 Unauthenticated email from bank.com is not accepted due to domain's DMARC policy.

זו שגיאה אופיינית כשבדיקת DMARC נפגעת מהעברה. שינוי DNS לבדו לרוב אינו מספיק. בדקו את SRS ו-ARC בשרת הדואר ואת חתימת DKIM המקורית.

צעדי התיקון: SRS ו-ARC

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

SRS ‏(Sender Rewriting Scheme)

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

ללא SRS:
שולח מעטפת SMTP: client@bank.com
IP שולח: שרת ההעברה שלכם
תוצאת SPF בדוגמה: FAIL, ה-IP שלכם אינו ברשומה של bank.com

עם SRS:
שולח מעטפת SMTP: SRS0=Hash=TT=bank.com=client@yourdomain.com
IP שולח: שרת ההעברה שלכם
תוצאת SPF בדוגמה: PASS, ה-IP שלכם מורשה עבור yourdomain.com

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

ARC ‏(Authenticated Received Chain)

SRS יכול לאפשר ל-SPF לעבור ביעד, אך אינו משחזר את התאמת הדומיינים ב-DMARC עבור SPF. ‏DMARC משווה את הדומיין בשדה From: ‏(bank.com) לתוצאות האימות. לאחר SRS המעטפת מציגה yourdomain.com, בעוד שב-From: עדיין מופיע bank.com. הדומיינים אינם תואמים, ולכן התאמת SPF עבור DMARC נכשלת. חתימת DKIM תקפה עם דומיין תואם עדיין יכולה להעביר את בדיקת DMARC.

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

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

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

שתי מלכודות תפעוליות

גם כש-SRS ו-ARC פעילים, שתי תצורות נפוצות עדיין עלולות לגרום לבעיות.

חשיפת הכתובת האישית בתשובה

העברה פועלת בכיוון הקבלה בלבד. כשמקבלים הודעה מועברת ב-Gmail ולוחצים על תשובה, כתובת From עשויה להיות founder@gmail.com ולא sales@yourdomain.com. הלקוח רואה אז את הכתובת האישית במקום את העסקית.

פתרון עקיף: הגדירו ב-Gmail את האפשרות ״שליחת דואר בשם״ תחת הגדרות → חשבונות. הזינו את הכינוי ואת פרטי ההתחברות ל-SMTP היוצא של הדומיין, אם התצורה נתמכת. לאחר מכן בדקו שהשליחה עוברת בשרת הרצוי ושהתשובות מציגות את כתובת הדומיין. פרטי החיבור נמצאים בהגדרות SMTP המנוהל של TrekMail.

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

מלכודת ההעברה של catch-all

הימנעו מהעברה חיצונית של catch-all ‏(*@yourdomain.com). מפיצי ספאם בודקים חלקים מקומיים אקראיים בדומיינים מוכרים, למשל billing@, admin@ ו-noreply12345@. ה-catch-all מקבל את ההודעות האלה ועלול להעביר אותן החוצה.

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

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

העברה דרך כינוי או תיבת דואר אמיתית: במה לבחור?

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

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

איך TrekMail מטפל בהעברה

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

בתיאור היכולות שבמקור, העברת דואר מתיבות בחבילות Pro ו-Agency של TrekMail משתמשת בשכבת תעבורה עם OpenARC. התיאור כולל חתימת ARC אוטומטית להעברות הנתמכות, כשהיעד מוגדר בלוח הבקרה. העיבוד מתבצע ברמת MTA, ולא באמצעות שינוי DNS בלבד. בדקו את זמינות היכולת כיום ואת התמיכה המדויקת ב-SRS וב-ARC.

במקרים רבים התשובה הפשוטה יותר היא לוותר על העברה. מודל המחיר הקבוע של TrekMail המתואר במקור אינו גובה תשלום נפרד לכל משתמש או תיבה. במודל זה מחיר תיבת support@yourdomain.com אינו משתנה רק משום שאדם אחד או עשרה אנשים ניגשים אליה; עדיין צריך לעמוד במגבלות החבילה ולנהל גישה בטוחה. בתוך התנאים האלה נעלם התמריץ הכספי להעביר לחשבון Gmail אישי ולהגדיר ״שליחה בשם״ בכל דומיין חדש.

• עסקים קטנים ובינוניים: תנו ל-support@ פרטי כניסה משלו ל-IMAP. גישה ישירה מפשטת את הפרדת הזהויות. בדקו את כתובת התשובה בתוכנת הדואר; לעיתים אפשר כך להימנע מהגדרה נפרדת של ״שליחה בשם״.
• סוכנויות: צרו תיבות ייעודיות לכתובות התפקיד של הלקוחות במקום להעביר לחשבונות אישיים של חברי הצוות. עם הרשאות מתאימות ותוכנות מוגדרות כראוי, הצוות יכול לגשת ישירות ולהשיב מכתובת שולח עקבית.

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

השורה התחתונה

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

1. השולח המקורי משתמש ב-DMARC מחמיר (p=quarantine או p=reject) ואין אימות תקף עם דומיין תואם
2. שרת ההעברה אינו מיישם SRS, ולכן SPF עלול להיכשל ביעד אם שולח המעטפת לא השתנה
3. שרת ההעברה אינו מיישם ARC, ולכן תוצאות קודמות אינן מתועדות באמצעותו להערכת הנמען; SRS לבדו אינו משחזר את התאמת SPF עבור DMARC, אך DKIM תקף עם דומיין תואם עשוי להספיק
4. אתם מעבירים catch-all החוצה ועלולים להגביר הפצת ספאם
5. צריך להשיב מכתובת הכינוי, דבר שההעברה עצמה אינה מספקת

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

במקור, חבילת Pro של TrekMail מתחילה ב-$10 לחודש: עד 100 דומיינים, העברת דואר מתיבות עם חתימת ARC וללא תשלום נפרד לתיבה. תקופת הניסיון החינמית של 14 ימים המתוארת שם דורשת כרטיס אשראי; Nano אינה דורשת אותו. בדקו את המחירים, היכולות והתנאים העדכניים.