העברת דוא״ל: הגדרה, אבחון תקלות ופתרון

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

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

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

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

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

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

כששרת A שולח הודעה לשרת שלכם, שרת B שמעביר אותה, ושרת B מוסר אותה ליעד הסופי, שרת C, מתרחש שינוי זהות מהותי. שרת היעד רואה את כתובת ה-IP של שרת B ולא של שרת A. זהו המקור לכמעט כל תקלת העברה.

מעטפה מול כותרת: שתי הזהויות של הודעת דוא״ל

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

• המעטפה (P1): השכבה שבה שרתי הדואר משתמשים כדי לנתב את ההודעה בפועל. היא מכילה את Return-Path, ו-SPF מאמת אותה.
• הכותרת (P2): השכבה שלקוח הדוא״ל מציג ככתובת ״מאת״. בדיקות היישור של DKIM ו-DMARC משתמשות בה.

כך נוצרת התקלה. כשהשרת שלכם מעביר הודעה, הוא פותח חיבור SMTP חדש אל היעד. SPF בודק את כתובת ה-IP השולחת מול רשומת SPF של השולח המקורי, אך ה-IP של שרת ההעברה שלכם אינו מורשה שם. בדיקת SPF נכשלת. אם השולח המקורי מפעיל מדיניות DMARC מחמירה (p=reject) ולא יישמתם SRS, שרת היעד דוחה את ההודעה לחלוטין.

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

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

העברה, כינויים וכתובת Catch-all: חשוב להכיר את ההבדל

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

העברת דוא״ל

העברה לוקחת הודעה שנשלחה לכתובת אחת ומוסרת אותה לשרת אחר לגמרי, למשל מ-contact@startup.com אל founder@gmail.com. מתרחש מעבר ברשת, ושרשראות האימות נשברות אם לא מטפלים בהן במפורש. השיטה מתאימה לריכוז כמה דומיינים בתיבת דואר אחת. סיכון: גבוה ללא טיפול תקין ב-SRS וב-ARC. קראו את הניתוח המעמיק שלנו על השיקולים בשילוב כינוי דוא״ל והעברה.

כינויי דוא״ל

כינוי הוא שם נוסף לתיבת דואר קיימת באותו שרת. הודעות אל support@company.com מגיעות לאותה תיבה כמו הודעות אל admin@company.com. אין מעבר ברשת ואין שינוי באימות. השיטה מתאימה לאדם אחד שממלא כמה תפקידים. סיכון: נמוך. להשוואה מפורטת של המצבים שבהם כינויים אינם מספיקים ונדרשת תיבת דואר מלאה, עיינו במדריך הבחירה בין כינוי לתיבת דואר.

Catch-all (ניתוב תווים כלליים)

הגדרה זו מקבלת כל הודעה שנשלחת לכתובת שאינה קיימת בדומיין שלכם, כלומר *@domain.com. היא שימושית ללכידת שגיאות הקלדה או כתובות חד-פעמיות לקמפיינים. סיכון: קריטי אם היא מופנית ישירות ל-Gmail. כל הודעת ספאם שמגיעה לדומיין תנחת בתיבה שלכם, ו-Gmail עלול עם הזמן להתייחס לשרת ההעברה כמקור ספאם. אם אתם משתמשים ב-Catch-all, יש לבודד אותו. השיקולים המלאים מופיעים במדריך להגדרת דוא״ל עסקי.

דפוסי הגדרה: הטוב, הבעייתי והשבור

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

1. ניתוב בצד הספק (הדרך הנכונה)

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

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

2. כללי תיבת דואר (השיטה הישנה)

מקימים חשבון משתמש מלא, משלמים $6-$30/month על רישיון שלא באמת נחוץ, נכנסים לחשבון ויוצרים כלל בתיבה: ״אם מתקבלת הודעה, העבר אל X״.

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

3. העברה בצד הלקוח (מומלץ להימנע לחלוטין)

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

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

רשימת בדיקה להגדרה בטוחה

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

1. בדיקת לולאה

ודאו שכתובת היעד אינה מעבירה בחזרה למקור. A→B→A היא לולאה אינסופית. שרתים מודרניים מזהים זאת באמצעות מגבלות מספר מעברים ומחזירים NDR מסוג 5.4.14 hop count exceeded, אך בשלב הזה מוניטין השליחה כבר עלול להיפגע. מפו את המסלולים לפני ההפעלה.

2. בדיקת כותרות

שלחו הודעת בדיקה מחשבון חיצוני, כגון Gmail פרטי, Yahoo או כל חשבון מחוץ לדומיין, אל הכתובת המועברת. ביעד, פתחו את כל כותרות ההודעה ואתרו את Authentication-Results. התוצאה הרצויה היא spf=pass בעקבות שכתוב SRS או dkim=pass. אם מופיע dmarc=fail, הגדרת ההעברה עדיין אינה מוכנה לייצור.

3. בדיקת Reply-To

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

4. בדיקת מדיניות דואר יוצא

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

תקלות נפוצות

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

1. חסימה שקטה עקב DMARC

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

זהו התרחיש: בנק, מעבד תשלומים או ספק SaaS שולח לדומיין שלכם הודעה עם מדיניות DMARC מחמירה p=reject. אתם מעבירים אותה ל-Gmail. כתובת ה-IP של שרת ההעברה גורמת ל-SPF להיכשל. אם השרת גם משנה את גוף ההודעה, למשל מוסיף כתב ויתור, או את שורת הנושא באמצעות [External], גם DKIM נשבר. כשל SPF + כשל DKIM = כשל DMARC. Gmail עלול לדחות את ההודעה.

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

2. חסימת Microsoft מסוג 550 5.7.520

התסמין: השולח המקורי מקבל NDR עם הקוד 550 5.7.520 Access denied, your organization does not allow external forwarding.

זהו מסנן הספאם היוצא של M365 שמבצע את תפקידו: חסימת העברה אוטומטית לכתובות חיצוניות. התיקון מחייב מעבר אל פורטל Microsoft Defender → Email & Collaboration → Policies & Rules → Threat policies → Anti-spam policies → Edit the outbound policy → Set "Automatic forwarding rules" to "On - forwarding is enabled."

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

3. לולאת הודעת היעדרות

משתמש A מעביר למשתמש B. משתמש B מגדיר תשובה אוטומטית. משתמש A שולח הודעה למשתמש B. התשובה האוטומטית של משתמש B חוזרת למשתמש A. השרת של משתמש A מעביר את התשובה למשתמש B, והשרת של משתמש B משיב שוב.

שרתי דואר מודרניים משתמשים בכותרות כמו X-Loop ו-X-Auto-Response-Suppress כדי לזהות ולעצור זאת. מערכות ישנות או שגויות עדיין עלולות ליצור אלפי הודעות בתוך דקות. בדקו את הגדרות התשובה האוטומטית בעת יצירת העברה בין חשבונות.

4. שבירת DKIM עקב שינוי

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

אם מופיע dkim=fail (body hash did not verify) בכותרות של הודעה מועברת, זו כמעט תמיד הסיבה.

תהליך אבחון: מהתסמין לתיקון

למה העברה נשברת בסביבת ייצור: הסבר על SRS ו-ARC

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

SRS: Sender Rewriting Scheme

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

לפני SRS:

MAIL FROM: alice@bank.com

אחרי שכתוב SRS:

MAIL FROM: SRS0=hash=timestamp=bank.com=alice@forwarder.com

שרת היעד מריץ SPF מול forwarder.com, והבדיקה עוברת מפני שהשרת שלכם מורשה. הודעות החזרה עדיין מנותבות אל alice@bank.com דרך הכתובת המקודדת. SPF מתקבל בלי לשבור את נתיב ההחזרה.

SRS הוא רכיב חיוני. בלעדיו, הודעות מועברות משולח בעל SPF מחמיר עלולות להיכשל באימות ביעד. להסבר מלא על פעולת SRS בשרשראות העברה, עיינו במדריך המפורט להגדרת דוא״ל עם הדומיין שלכם. אם אתם מנתבים במיוחד לתיבת Gmail, קראו את המדריך המדורג כיצד להעביר דוא״ל מהדומיין אל Gmail בבטחה עם SRS ו-Send Mail As.

ARC: Authenticated Received Chain

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

Google ו-Microsoft מתחשבות בחותמות ARC של שרתי ביניים מהימנים. כשחותמת מהימנה קיימת, ספקים אלה עשויים לקבל את ההודעה גם אם בדיקות SPF או DMARC המקוריות נכשלו בגלל מעבר ההעברה. זהו למעשה תיעוד שרשרת משמורת עבור אימות דוא״ל.

ARC מוגדר בRFC 8617 והוא התקן הנוכחי לשמירת אימות בתרחישי העברה לגיטימיים. ללא ARC, מדיניות DMARC מחמירה מסוג p=reject אצל השולח המקורי עלולה לחסום הודעות מועברות אצל ספקים גדולים, אפילו אם SRS קיים.

אזור הסכנה של Catch-all

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

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

המקום של TrekMail בתהליך

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

משלמים ל-Google או ל-Microsoft סכום של $6/user/month, זקוקים ל-10 כתובות העברה, ועלולים לשלם על 10 משתמשים שאינם בשימוש. לחלופין מגיעים למגבלות הכינויים ומתחילים לאלתר פתרונות עוקפים. זו עלות מיותרת על ניתוב.

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

עבור מייסד יחיד, הדבר עשוי לאפשר ניתוב אמין של hello@yourdomain.com אל Gmail בתוך פחות מחמש דקות כשההגדרה מתאימה, בלי להקים שרת דואר מלא. עבור צוות, שינויי הניתוב יכולים להתבצע בלוח הבקרה בלי חפירות DNS. עבור סוכנות שמנהלת 100+ דומיינים של לקוחות, אפשר לנהל את הכללים במרוכז ולהחילם בעקביות, באופן שעשוי לצמצם כשלי אימות שהופכים להסלמות תמיכה ב-6pm ביום שישי.

לפי המחירון שהיה בתוקף בעת הכנת המאמר, תוכנית Pro ($10/month, או $8/month בחיוב שנתי) כוללת Catch-all חיצוני והעברת תיבת דואר. תוכנית Agency ($29/month) מוצגת עבור 1,000+ דומיינים וכוללת גישת API לניהול מסלולים בכמות גדולה. התוכניות בתשלום מוצעות עם 14-day free trial (נדרש כרטיס).

מידע על אופן הטיפול של TrekMail בהעברה בכל היקף זמין בtrekmail.net.

סיכום

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

המסקנות המעשיות: השתמשו בהעברה בצד השרת עם SRS ו-ARC, ולעולם לא בכללים בצד הלקוח. בדקו כותרות לפני ההפעלה, שימו לב לחסימת המדיניות היוצאת ב-M365 ושמרו על Catch-all מבודד. אם אתם מנהלים העברה בכמה דומיינים, אין סיבה לשלם לכל משתמש רק כדי לנתב דואר.

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