העברת דואר עם SRS: SPF, DMARC והמגבלות

מגדירים העברה: דואר ל-contact@yourdomain.com מועבר ל-Gmail. במשך שבוע היא עובדת, ואז חלק מהודעות הלקוחות אינן מגיעות. ביומנים מופיעים למשל 550 5.7.1 Unauthenticated email או 550 5.7.26 This message does not have authentication information. השגיאות האלה דורשות בדיקה ואינן מוכיחות לבדן כשל SRS. העברת דואר עם SRS מטפלת בבעיה נפוצה: השרת פותח חיבור SMTP חדש, אך השולח המקורי נשאר במעטפת. אם הדומיין שלו אינו מאשר את כתובת ה-IP שלכם, SPF עשוי להיכשל. עם DMARC ב-p=reject, הנמען עשוי לדחות אם לא SPF ולא DKIM הצליחו עם דומיין התואם ל-From הגלוי. דחיית SMTP יכולה ליצור הודעת אי-מסירה; הודעות אינן תמיד נעלמות בשקט.

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

מהי העברת דואר עם SRS?

העברת דואר עם SRS, כלומר Sender Rewriting Scheme, משכתבת את כתובת שולח המעטפת לפני העברת ההודעה ליעד חדש. הדומיין המקורי מוחלף בדומיין המעביר בנתיב החזרה הטכני. SPF עשוי להצליח אם הגדרת DNS העדכנית מאשרת את ה-IP ששולח בפועל. From הגלוי אינו משתנה. SRS פועל במעטפת ואינו הצפנה; משתמשים יכולים לקרוא Return-Path בכותרות המלאות.

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

מדוע העברה עלולה להיכשל: תחנת SMTP החדשה

העברה מוסיפה תחנת SMTP. SPF אינו נכשל בה בהכרח, אך שינוי ה-IP השולח עשוי להשפיע עליו. Header From לפי RFC 5322 הוא השולח הגלוי, למשל From: alice@client.com. שולח המעטפת לפי RFC 5321, MAIL FROM, הוא כתובת החזרה הטכנית וזהות SPF. הוא לרוב מוסתר בתצוגה הרגילה, אך נגיש בכותרות המלאות.

הרצף הבא מדגים כשל אפשרי, לא כלל גורף של מחיקה ללא הודעה:

1. Alice שולחת מ-alice@client.com. SPF שלה מאשר את השרת, והבדיקה מצליחה בקבלה בשרת שלכם.
2. השרת שלכם פותח חיבור חדש אל you@gmail.com. עכשיו ה-IP שלכם הוא מקור השליחה.
3. שולח המעטפת נשאר alice@client.com, אך client.com אינו מאשר את ה-IP של השרת שלכם בדוגמה.
4. Gmail בודק SPF עבור client.com. ללא הרשאה ל-IP שלכם, SPF נכשל.
5. אם client.com מפרסם מדיניות DMARC של p=reject וגם אין DKIM תקף עם התאמת דומיין, Gmail עשוי לדחות. התוצאה והודעות אפשריות תלויות במדיניות הנמען.

כיצד SRS מסייע ל-SPF

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

מרכיבי כתובת SRS

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

לפני SRS: MAIL FROM: <alice@client.com>
אחרי SRS: MAIL FROM: <SRS0=4fac=PM=client.com=alice@yourdomain.com>

בהעברה שנייה (A → B → C), עשוי לשמש SRS1. הייצוג המקונן תלוי במימוש ואינו מוגבל פשוט לערך הגיבוב ולחותמת הזמן. הוא מגביל צמיחה נוספת לעומת עטיפה חוזרת של מחרוזת SRS0 שלמה. עדיין צריך לבדוק את מגבלת 64 התווים לחלק המקומי לפי RFC 5321; אין הבטחה שכל כתובת תיכנס לתוכה.

מדוע SRS אינו מספיק: התאמת DMARC

מנהלים רבים מפעילים העברת דואר עם SRS ומצפים לפתרון מלא. אולם הצלחת SPF אינה מבטיחה התאמת דומיינים ב-DMARC. DMARC דורש SPF או DKIM תקף עם דומיין התואם ל-Header From. לאחר השכתוב, SPF עשוי להצליח עבור yourdomain.com, בעוד Header From נשאר client.com. הדומיינים השונים אינם תואמים בדוגמה. התאמה במצב relaxed יכולה לאפשר דומיינים שחולקים אותו דומיין ארגוני.

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

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

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

סיוע נוסף באמצעות ARC (Authenticated Received Chain)

ARC לפי RFC 8617 מאפשר למתווך לתעד ולהגן בחתימה על תוצאות האימות שנצפו בפועל, בין שהבדיקות הצליחו ובין שנכשלו. הוא משתמש בשלוש כותרות:

• ARC-Authentication-Results: מתעדת תוצאות SPF/DKIM/DMARC שנצפו בקבלה
• ARC-Message-Signature: חותמת כותרות נבחרות ואת הגוף בזמן החתימה; שינויים רלוונטיים מאוחרים עשויים לפסול אותה
• ARC-Seal: חתימה קריפטוגרפית המקשרת ומגינה על שרשרת ARC

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

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

הגדרת SRS לפי פלטפורמה

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

Postfix ב-Linux בניהול עצמי

שילוב נפוץ של Postfix משתמש בשירות postsrsd. יש לבדוק את דוגמת התקנת החבילה הבאה מול ההפצה והגרסה לפני יישום מורשה:

apt-get install postsrsd

דוגמת מפות TCP הבאה ב-/etc/postfix/main.cf היא דרך שילוב ותיקה. גבו הגדרות קיימות ושלבו בזהירות את המפות החדשות. בדקו גרסה, תחביר נתמך, יציאות, sockets, נתיבים והרשאות:

sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient

חשוב: המשתנה SRS_EXCLUDE_DOMAINS ב-/etc/default/postsrsd תלוי בגרסה. בדקו אילו דומיינים מקומיים ונתיבים צריך להחריג. החרגות חסרות עשויות לגרום לשכתוב לא רצוי או לתרום ללולאות בשילוב עם כללי ניתוב אחרים, אך אינן גורמות ללולאה בכל תצורה. בדקו קבלה, שליחה והודעות חזרה.

Microsoft 365

Microsoft 365 עשוי להחיל SRS בנתיבי יציאה נתמכים. בדקו התנהגות עדכנית בסביבות היברידיות ובמחברים. 550 5.7.520 Access denied, Your organization does not allow external forwarding מצביע על מדיניות העברה יוצאת, לא על כשל SRS מוכח.

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

Set-OutboundConnector -Identity "Outbound to Gateway" -SenderRewritingEnabled $true

Google Workspace

ל-Google Workspace התנהגות העברה משלו. בין תחומי הבדיקה נמצאים הבאים, שאינם ייחודיים רק לו:

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

אבחון תקלות בהעברת SRS

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

בדיקה 1: Return-Path

דוגמה ללא שכתוב SRS גלוי: Return-Path: <original@protonmail.com>
דוגמה עם שכתוב SRS: Return-Path: <SRS0=xxxx=yy=protonmail.com=original@yourdomain.com>

Return-Path שלא השתנה עשוי להצביע על שילוב חסר, שירות שאינו פעיל או החרגה מכוונת. הוא אינו מוכיח לבדו ש-postsrsd נכשל. בדקו את הנתיב שההודעה עברה בפועל.

בדיקה 2: Authentication-Results

חפשו spf=pass ואת הדומיין שנבדק. אם עדיין מופיע dmarc=fail, אין SPF או DKIM תקף עם התאמת דומיין. DKIM עשוי להיות חסר, לא תקף או להשתמש בדומיין לא תואם למרות חתימה תקפה. בדקו תוכן חתום, שינויים והתאמה, בלי להסיק אוטומטית שהגוף נפגם.

בדיקה 3: DNS

dig yourdomain.com TXT +short

בדקו SPF של דומיין המעביר ונגישות נתיב החזרה. MX נפוץ, אך בהיעדרו ייתכן נתיב משתמע דרך A/AAAA. חלק מהנמענים מתחשבים ביכולת לקבל הודעות אי-מסירה; MX קיים לבדו אינו מוכיח אותה.

בדיקה 4: יומני Postfix

grep "srs_forward" /var/log/mail.log

hash mismatch או timestamp expired עשויים להצביע על מפתחות שונים בין שרתים, החלפת מפתחות, בעיות זמן או הגדרה, עיכובים או שימוש חוזר בכתובות ישנות. הם אינם מוכיחים לבדם מתקפת replay. בדקו את ההקשר המלא.

מתי עדיף לבחור תיבה ישירה במקום העברה

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

השוו את שתי הגישות ואת דרישותיהן בפועל:

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

קבלה ישירה לתיבת TrekMail מסירה את תחנת ההעברה החיצונית הזאת; אין צורך להגדיר SRS ו-ARC לנתיב הקבלה הזה. נתיבים אחרים עשויים עדיין להזדקק להם. האשף המתואר מסייע ב-SPF, DKIM ו-DMARC, אך אינו מחליף הרשאה ובדיקות. שרת MX מוסמך לקבלה אינו שולח SMTP מורשה אוטומטית.

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

סיכום

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

ב-Postfix, SRS דורש שילוב מתאים לגרסה והחרגות שנבדקו. ב-Microsoft 365, התנהגות ושינויי מדיניות מורשים אפשריים תלויים בנתיב ובתמיכה העדכנית; דוגמת PowerShell אינה הוראה גורפת. ב-Workspace בדקו מכסות, ניתוב ויומנים בפועל, במקום להניח השעיה בכל מקרה.

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