הגדרתם העברת דוא״ל. בדקתם אותה והיא עבדה. כעבור שבועיים, הודעה מלקוח עם חוזה לא מגיעה. היא לא בספאם, ואין הודעת שגיאה גלויה על כשל במסירה. היא פשוט חסרה. אתם פותחים את הלוגים ומוצאים: 550 5.7.1 Unauthenticated email from domain.com.
הגדרה חסרה או שגויה של מנגנון שכתוב כתובת השולח עשויה לתרום לבעיה, אבל לקוד הזה יש גם סיבות אחרות. אימות דוא״ל בודק, בין היתר, אם שרת השליחה מורשה מטעם הדומיין של שולח המעטפת. העברה עלולה לגרום לבדיקה הזו להיכשל ברמת הפרוטוקול. מנגנון שכתוב כתובת השולח מסייע לטפל בכך, אך גם ב-2026 אינו פתרון מלא בפני עצמו. חשוב להבין את מגבלותיו לא פחות מאשר את פעולתו.
המדריך מסביר מה מנגנון שכתוב כתובת השולח עושה, היכן הוא עלול להיכשל וכיצד לבנות שרשרת העברה תקינה. אם אתם בודקים גם בעיות מסירה רחבות יותר, כמו רשומות MX שגויות, כללי catch-all שהוגדרו לא נכון או שינויי DNS שפגעו בניתוב, התחילו במדריך להגדרת העברת דוא״ל ולתיקון תקלות.
למה SPF עלול להיכשל בעת העברת דוא״ל
בעת העברה, השרת המעביר שולח את ההודעה מכתובת ה-IP שלו, אך שולח המעטפת עשוי להישאר בדומיין המקורי. אם רשומת SPF של הדומיין אינה מאשרת את כתובת ה-IP הזו, SPF נכשל. עם מדיניות DMARC מסוג p=reject, השרת המקבל עשוי לדחות את ההודעה אם גם אין חתימת DKIM תקפה ומותאמת לדומיין השולח הגלוי. דחייה ב-SMTP נמסרת לשרת המעביר ועשויה להוביל להודעת כשל במסירה. עם זאת, הנמען עשוי להבחין רק בכך שההודעה חסרה, ללא התראה גלויה.
דוא״ל אינו עובר בצינור רציף אחד, אלא בשרשרת חיבורי SMTP עם לחיצת יד TCP חדשה בכל תחנה. הנה דוגמה למסלול שבו הכשל עשוי להתרחש:
alice@client.comשולחת אלcontact@your-agency.com- השרת שלכם מקבל את ההודעה: כתובת ה-IP של שרת השליחה של Alice מורשית ברשומת SPF של
client.com - השרת שלכם פותח חיבור SMTP חדש אל Gmail כדי להעביר את ההודעה
- Gmail מזהה שהחיבור מגיע מכתובת ה-IP שלכם
- שולח המעטפת עדיין מופיע כ-
alice@client.com - Gmail בודק את SPF של
client.com: כתובת ה-IP שלכם אינה מורשית - SPF נכשל. אם
client.comמשתמש ב-p=rejectואין חתימת DKIM תקפה ומותאמת לדומיין השולח הגלוי, Gmail עשוי לדחות את ההודעה
RFC 7208, מפרט SPF, מתייחס במפורש לבעיה המוכרת הזו בהעברה. SPF לבדו אינו משמר את ההרשאה המקורית בחיבור חדש. אחת הדרכים לטפל בבעיה היא לשנות את שולח המעטפת.
שתי זהויות השולח: מעטפת וכותרת
לדוא״ל יש שתי שכבות של זהות שולח. שולח המעטפת (RFC 5321, MAIL FROM, P1) משמש לבדיקות SPF ולניתוב הודעות כשל במסירה. הוא מיועד בעיקר לשרתים, אך אפשר לבדוק אותו גם בשדה Return-Path שבכותרות הגולמיות. השדה From בכותרת (RFC 5322, P2) הוא השולח המוצג ב-Gmail או ב-Outlook. העברה עשויה להפריד בין הזהויות האלה. מנגנון שכתוב כתובת השולח פועל בשכבת המעטפת בלי לשנות את השולח הגלוי.
| שכבה | שם טכני | RFC | מטרה | למי היא גלויה |
|---|---|---|---|---|
| שולח המעטפת | MAIL FROM / Return-Path | RFC 5321 (P1) | בדיקות SPF וניתוב הודעות כשל במסירה | בעיקר לשרתים; אפשר לבדוק בכותרות הגולמיות |
| From בכותרת | כותרת From: | RFC 5322 (P2) | השולח המוצג בתוכנות דוא״ל | למשתמשי הקצה |
בעת העברת דוא״ל, השדה From בכותרת נשאר alice@client.com. השרת שלכם יוצר עסקת SMTP חדשה, ו-SPF נבדק מול שולח המעטפת בתחנה החדשה. אם שרת השליחה החדש אינו מורשה מטעם הדומיין הזה, נוצרת הבעיה שתוארה.
מה מנגנון שכתוב כתובת השולח עושה בפועל
מנגנון שכתוב כתובת השולח משנה את כתובת שולח המעטפת (P1) לפני שהשרת המעביר פותח חיבור SMTP חדש. השדה From בכותרת, שהמשתמש רואה, נשאר ללא שינוי. הדומיין החדש במעטפת יכול לאשר את השרת המעביר באמצעות SPF. כך SPF עשוי לעבור ביעד כאשר ההגדרה תקינה, אך אין בכך הבטחה למסירה או להתאמת DMARC לדומיין From המקורי.
ההשוואה לדואר רגיל: בלי מנגנון שכתוב כתובת השולח, אתם מקבלים מכתב מ-Alice, מכניסים אותו לשק דואר חדש ומשאירים עליו את כתובת ההחזרה שלה. היעד רואה שאתם מוסרים את המשלוח, אבל כתובת ההחזרה מרמזת שהוא נשלח מ-Alice. הדבר עלול להביא לדחייה. עם מנגנון שכתוב כתובת השולח, אתם מחליפים את כתובת ההחזרה שלה בכתובת שלכם. מסלול ההחזרה מתאים כעת לכם כגורם המעביר. אם צריך להחזיר את השק, הוא מגיע אליכם, ואתם מנתבים אותו בחזרה ל-Alice.
| רכיב | לפני ההעברה | אחרי שכתוב SRS |
|---|---|---|
| From בכותרת (P2) | alice@client.com | alice@client.com (ללא שינוי) |
| שולח המעטפת (P1) | alice@client.com | SRS0=4fac=PM=client.com=alice@your-agency.com |
| כתובת ה-IP השולחת | השרת שלכם | השרת שלכם |
| תוצאת SPF בדוגמה | FAIL | PASS |
פענוח המבנה של כתובת SRS
כאשר מנגנון שכתוב כתובת השולח פעיל, הוא ממיר את שולח המעטפת לכתובת מקודדת לפני ההעברה. הדומיין שלה חייב להיות מוגדר בהתאם למסלול השליחה בפועל. הכתובת כוללת ערך בדיקה קריפטוגרפי לצורך אימות, חותמת זמן להגבלת התוקף ואת כתובת השולח המקורית לניתוב הודעות כשל במסירה. זו אינה מחרוזת אקראית אלא מידע מובנה. ההגנה בפועל תלויה במימוש.
דוגמה לכתובת ששוכתבה באמצעות SRS:
SRS0=4fac=PM=client.com=alice@your-agency.com- SRS0: ההעברה הראשונה.
SRS1עשוי להופיע כאשר ההודעה מועברת שוב בהמשך, ולהגביל את התארכות הכתובת במימושים שתומכים בכך - 4fac: ערך בדיקה לדוגמה המבוסס על HMAC-SHA1 במימוש הזה; האלגוריתם והאורך תלויים במימוש. הוא משמש לאימות הודעות כשל נכנסות; אפשר לדחות ערכים לא תקינים כדי להקשות על ניצול השרת לשליחת הודעות כשל לא רצויות, או backscatter
- PM: חותמת זמן. חלון תוקף שניתן להגדרה עשוי להיות, למשל, 7-21 ימים. אפשר לדחות כתובות שפג תוקפן, אך זו אינה הבטחה כללית להגנה מפני מתקפות שימוש חוזר
- client.com=alice: השולח המקורי בצורה מקודדת, המשמש לניתוב הודעות כשל במסירה בחזרה לכתובת הנכונה
מתי צריך מנגנון שכתוב כתובת השולח
מנגנון שכתוב כתובת השולח רלוונטי כשמעבירים דוא״ל אוטומטית בין דומיינים וכתובת ה-IP של השרת המעביר אינה מורשית ברשומת SPF של השולח המקורי. מדיניות DMARC מחמירה מגדילה את הסיכון בתשתית העברה ללא אמצעי אימות מתאימים. SRS מטפל ב-SPF של דומיין המעטפת המשוכתב, לא בכל בעיות המסירה.
דומיין אישי שמועבר ל-Gmail פרטי. אתם הבעלים של cool-startup.com ומעבירים את כל הדואר אל founder@gmail.com. SRS עשוי לסייע בבדיקת SPF במסלול הזה. ללא שכתוב, SPF עלול להיכשל בהודעות מבנקים, מגופים ממשלתיים ומשולחים אחרים בעלי מדיניות DMARC מחמירה. DMARC עדיין עשוי לעבור אם נשמרת חתימת DKIM תקפה ומותאמת לדומיין השולח הגלוי.
ספק שירותים מנוהלים או סוכנות עם אשכול דואר משותף. אתם מארחים 200 דומיינים של לקוחות שמגדירים שוב ושוב העברות לספקים שלהם, כמו Comcast, AT&T ו-Outlook. ספאם שמועבר דרככם עשוי להיות מיוחס לכתובת ה-IP השולחת שלכם, גם אם לא יצרתם אותו. בעיות בהרשאת SPF ושליחה לא רצויה עלולות לפגוע במוניטין ולתרום להכללה ברשימה של Spamhaus, ובתרחיש לא מוצלח הדבר עשוי לקרות בתוך שבועות ספורים. זה אינו בלתי נמנע, וזה אינו סיכון ש-SRS לבדו מבטל.
Microsoft 365 עם מחבר יוצא. M365 יכול להפעיל SRS פנימית במסלולי שליחה נתמכים. כשמנתבים תעבורה דרך מחבר יוצא, בדקו אם השכתוב אכן מתבצע לפני ההעברה אליו. הגדירו SenderRewritingEnabled רק כאשר הגרסה והמחבר תומכים בכך והשינוי מאושר. בדקו גם את מדיניות סינון הספאם היוצא לגבי חסימת העברה חיצונית עם 5.7.520: זו הגדרת מדיניות, לא הוכחה לכשל SRS.
למה מנגנון שכתוב כתובת השולח אינו מספיק
מנגנון שכתוב כתובת השולח עשוי לאפשר ל-SPF של דומיין המעטפת החדש לעבור, אך אינו יוצר אוטומטית התאמת דומיינים ב-DMARC ל-From המקורי. DMARC דורש אימות תקף ומותאם באמצעות SPF או DKIM. SRS משנה את דומיין המעטפת לדומיין המעביר, אך משאיר את From בכותרת בדומיין השולח המקורי. אם הדומיינים אינם מותאמים, חתימת DKIM תקפה ומותאמת צריכה להישמר לאורך המסלול כדי ש-DMARC יעבור.
שרתים מעבירים עלולים לפגוע בחתימות DKIM כאשר הם משנים חלקים חתומים באופן שכללי הקנוניזציה שבהם נעשה שימוש אינם משמרים:
- הוספת
[EXTERNAL]לנושא עשויה לפסול את DKIM אם הכותרת הזו חתומה - הוספת טקסט בתחתית ההודעה, כמו הודעת סריקת וירוסים או קישור להסרה מרשימת תפוצה, עשויה לשנות את ערך הגיבוב של הגוף החתום ולפסול את DKIM
- שכתוב MIME, למשל המרת קידוד מ-8 ביט ל-7 ביט, עשוי לשנות תוכן חתום ולפסול את DKIM
בתרחיש הכשל, SPF אינו מותאם לדומיין From המקורי והשינויים פוסלים את DKIM. לכן DMARC נכשל. הנמען עשוי לדחות את ההודעה בהתאם למדיניות שלו; ייתכנו דחיית SMTP או הודעת כשל במסירה.
אמצעי משלים הוא ARC (Authenticated Received Chain, RFC 8617). הוא מאפשר לשרת המעביר לתעד בשרשרת חתומה את תוצאות האימות שנצפו בפועל. מתווספות שלוש כותרות:
ARC-Authentication-Results: מתעדת את תוצאות SPF, DKIM ו-DMARC שנצפו בפועל בעת הקבלה, ולא בהכרח בדיקות שעברוARC-Message-Signature: חותמת על חלקים מההודעה במצבם בזמן יצירת חתימת ARC, ולא בהכרח במצבם המקורי בעת הקבלהARC-Seal: חתימה קריפטוגרפית שמקשרת את קבוצת ARC לשרשרת
נמען כמו Gmail יכול להעריך את ARC כאשר בדיקות האימות הנוכחיות של הודעה שהועברה נכשלות. הנמען מחליט אם לקבל את השרשרת ולתת בה אמון לצורך החלטת המסירה. ARC אינו מתקן את התאמת הדומיינים ב-DMARC. אי אפשר לכפות את האמון הזה או להבטיח אותו רק באמצעות מוניטין דומיין שנבנה לאורך זמן.
איך לבדוק שמנגנון שכתוב כתובת השולח עובד
שלחו הודעת בדיקה מחשבון חיצוני לכתובת שמוגדרת להעברה ובדקו את הכותרות הגולמיות ביעד. הכותרת Return-Path מראה אם שכתוב SRS גלוי בהודעה הזו או שכתובת השולח המקורית נשמרה. בדקו גם את תוצאות האימות.
שלב 1: בדיקת Return-Path ביעד
# SRS inactive - SPF is almost certainly failing:
Return-Path: <original-sender@protonmail.com>
# SRS active:
Return-Path: <SRS0=xxxx=yy=protonmail.com=sender@your-domain.com>שלב 2: בדיקת DNS של דומיין SRS
# Check SPF on your forwarding domain:
dig TXT your-domain.com | grep spf
# Check MX - bounces need a place to go:
dig MX your-domain.comדומיין SRS צריך הרשאת SPF מתאימה ומסלול נגיש לקבלת הודעות כשל במסירה. בדקו את הגדרת MX לצורך זה. היעדר רשומת MX אינו אומר אוטומטית שהמסלול אינו נגיש: בתנאים מסוימים מסירה יכולה להתבצע באופן משתמע דרך רשומות A או AAAA. מה שחשוב הוא שמסלול ההחזרה בפועל יעבוד; בעיות בו עשויות לתרום לדחיית הודעות.
שלב 3: בדיקת לוג הדואר ב-Linux
grep "srs_forward" /var/log/mail.logהודעות כמו hash mismatch או timestamp expired עשויות להצביע על מפתחות PostSRSd שאינם מסונכרנים, החלפת מפתחות, עיכובים, כתובות שנפגמו או ניסיון שימוש חוזר. הן אינן מוכיחות מתקפה. Postfix אינו כולל SRS מובנה; PostSRSd הוא אפשרות אחת לשילוב, ויש לבדוק את הגרסה ואת ההגדרות שלו. הגדירו SRS_EXCLUDE_DOMAINS בהתאם לדומיינים המקומיים ולכללי הניתוב שלכם, כדי להימנע משכתוב מיותר של דואר פנימי. אי-החרגת דומיין אינה גורמת בהכרח ללולאה, אך עלולה להקשות על האבחון.
החלופה הפשוטה יותר: להפסיק להעביר
מנגנון שכתוב כתובת השולח מטפל בבעיה שנוצרת בחיבור SMTP החדש בזמן העברה. תיבת IMAP אמיתית בדומיין שלכם יכולה לבטל את השלב הנוסף הזה. ההודעה מגיעה ישירות לתיבה, ותוכנת הדואר ניגשת אליה באמצעות IMAP. כך נמנעות בעיות האימות שנגרמות בשלב ההעברה הזה, אך לא כל הסיכונים של SPF, DKIM או DMARC. IMAP אינו מבטיח אימות מקצה לקצה.
העברה פופולרית מפני שאיש אינו רוצה לשלם לפי משתמש על תיבה שמקבלת חמש הודעות בחודש. לכן SRS הוא לפעמים חלק מפתרון לבעיית תמחור, לא רק לבעיה טכנית.
המודל המתואר של TrekMail מציע גישה אחרת: מסלולים החל מ-$3.50 לחודש, הכוללים כמה דומיינים עם מאגר אחסון משותף במחיר קבוע, ללא תשלום לפי משתמש. בדקו את המחירים, המגבלות והתכונות העדכניים של המסלול שבחרתם. אפשר להפעיל את sales@yourdomain.com כתיבת IMAP אמיתית ולגשת להודעות באמצעות תוכנות או שילובים נתמכים. חיבור ל-Gmail או ל-Outlook תלוי בתמיכה הזמינה. ללא העברה חיצונית, אין צורך להגדיר SRS ו-ARC עבור השלב הזה, אך שאר היבטי אימות הדוא״ל עדיין חשובים.
בסביבות עם כמה לקוחות, המדריך לאירוח דוא״ל בכמה דומיינים מסביר איך לנהל עשרות דומיינים באופן מרכזי ולצמצם עבודת ניהול חוזרת לכל דומיין. אם אתם מפעילים סביבה משולבת עם תיבות אמיתיות לצד העברות ותיקות, המדריך להעברת דוא״ל מכינויים עוסק בהגדרת מסלול הכולל SRS.
בין שאתם ממשיכים להעביר ובין שאתם עוברים לתיבות אמיתיות, הבינו מה מנגנון שכתוב כתובת השולח עושה, ודאו שהוא מופעל והשלימו עם ARC היכן שיש תמיכה והדבר מתאים. תשתית העברה שהוגדרה באופן חלקי עלולה לאבד הודעות לגיטימיות. זהו סיכון עסקי, לא רק פרט טכני מסקרן.
התחילו עם חשבון TrekMail בחינם ובדקו את התנאים העדכניים של ההצעה המתוארת, ללא כרטיס וללא תאריך סיום לתקופת הניסיון. כך תוכלו להתנסות בדוא״ל לכמה דומיינים בלי המורכבות הנוספת של העברה.
