שכתוב כתובת השולח SRS: תפקיד ומגבלות

אתם מגדירים העברה: contact@your-agency.com → you@gmail.com. בודקים והיא עובדת. כעבור שבועיים, חוזה מלקוח ארגוני לא מגיע, וגם אינו נמצא בספאם. בלוגים מופיע: 550 5.7.1 Unauthenticated email. או שמופיע 550 5.7.520 Access denied, שעשוי להעיד ב-Microsoft 365 על הגבלה של העברה חיצונית יוצאת. כל שגיאה דורשת אבחון נפרד. היעדר ההודעה אינו אומר שלא הייתה דחיית SMTP או הודעת כשל במסירה.

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

לתמונה המלאה, התחילו במדריך להגדרת העברת דוא״ל ולטיפול בתקלות נפוצות.

מהו Sender Rewriting Scheme ‏(SRS)?

מנגנון שכתוב כתובת השולח, SRS, משנה את שולח המעטפת ועשוי למנוע כשלי SPF שנגרמים בהעברת דוא״ל. לפני שהשרת שלכם מעביר הודעה, הוא מחליף את כתובת מעטפת SMTP ‏(MAIL FROM) בכתובת בדומיין ההעברה שלכם. הכתובת הזו אינה מופיעה בדרך כלל כשולח בממשק, אך אפשר לבדוק אותה בכותרות הגולמיות. הנמען בודק כעת SPF מול הדומיין שלכם. הבדיקה עשויה לעבור אם רשומת DNS מאשרת את מסלול השליחה בפועל ושאר ההגדרות תקינות. ללא שכתוב, הדומיין המקורי עשוי שלא לאשר את השרת שלכם. עם זאת, כשל SPF לבדו אינו מוכיח זיוף ואינו אומר ש-DMARC נכשל אוטומטית.

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

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

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

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

כאשר השרת שלכם מעביר הודעה, הוא פותח חיבור SMTP חדש ליעד ומוסיף תחנה למסלול. שולח המעטפת עדיין מופיע כ-alice@bank.com, אך כתובת ה-IP של החיבור היא כעת שלכם. SPF בודק את הכתובת מול הרשומה של bank.com. אם היא אינה מורשית, SPF נכשל. אם bank.com מפרסם DMARC p=reject, הנמען עשוי לדחות את ההודעה כאשר גם אין חתימת DKIM תקפה ומותאמת. ייתכנו שגיאת SMTP או הודעת כשל במסירה; הדחייה אינה תמיד שקטה.

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

איך Sender Rewriting Scheme ‏(SRS) משכתב את המעטפת

SRS מחליף את כתובת המעטפת MAIL FROM בכתובת בדומיין ההעברה שלכם לפני פתיחת חיבור SMTP חדש. הדבר עשוי לאפשר ל-SPF של הדומיין הזה לעבור. הכותרת From: שהנמען רואה נשארת כפי שהשולח המקורי הגדיר אותה.

# WITHOUT SRS - SPF fails downstream
Return-Path: <alice@bank.com>
Received-SPF: fail (IP not authorized for bank.com)

# WITH SRS - SPF passes on your domain
Return-Path: <SRS0=4fac=PM=bank.com=alice@your-domain.com>
Received-SPF: pass (IP authorized for your-domain.com)

בדוגמה, שרת היעד בודק SPF מול your-domain.com, שמאשר את השרת שלכם. SPF עובר בתנאי הזה. הנמען עדיין רואה From: alice@bank.com. SRS אפשר את בדיקת SPF המיידית, אך צריך להעריך בנפרד את ההתאמה לדומיין From המקורי.

פענוח המבנה של כתובת SRS

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

דוגמה: SRS0=4fac=PM=bank.com=alice@your-domain.com

המכשול השני: SRS אינו יוצר התאמת SPF

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

DMARC דורש התאמה של דומיין שאומת בהצלחה לדומיין הכותרת הגלויה From:. בדוגמה עם SRS פעיל:

• בדיקת SPF: PASS - כתובת ה-IP שלכם מורשית מטעם דומיין המעטפת your-domain.com
• התאמת SPF: FAIL - מעטפת your-domain.com ≠ כותרת bank.com

ללא התאמת SPF, מעבר DMARC תלוי בחתימת DKIM תקפה ומותאמת. אם השולח המקורי חתם כך והחלקים החתומים נשמרים לפי כללי הקנוניזציה שבהם נעשה שימוש, DMARC עשוי לעבור דרך DKIM. התראות כמו “External Email”, טקסט שמוסיף אנטי-וירוס בתחתית ההודעה או המרות MIME מקידוד 8 ביט ל-7 ביט עלולים לפסול את DKIM כשהם משנים תוכן חתום.

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

ARC כתוספת ל-Sender Rewriting Scheme SRS

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

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

המגבלה: הנמען מחליט אם לתת אמון בחותם ARC ובשרשרת. ב-Microsoft 365, מנהל מורשה יכול להגדיר חותמי ARC מהימנים באמצעות PowerShell עם Set-ArcConfig, כאשר הגדרות הדייר הנוכחיות תומכות בכך ומצריכות זאת. זה אינו שלב ידני חובה בכל סביבה. גם את האמון של Gmail אי אפשר לכפות ידנית.

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

אבחון בעיות SRS: רשימת בדיקה

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

1. בדקו את הכותרת Return-Path

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

# SRS inactive - SPF will fail
Return-Path: <original-sender@external.com>
Authentication-Results: spf=fail (IP not authorized for external.com)

# SRS active - SPF passes on your domain
Return-Path: <SRS0=xxxx=yy=external.com=sender@your-domain.com>
Authentication-Results: spf=pass (IP authorized for your-domain.com)

2. בדקו חסימות יוצאות ב-Microsoft 365

אם אתם מעבירים הודעות אל מחוץ ל-Microsoft 365 וההגבלה הבאה חלה, הן נחסמות לפני שהן עוזבות את הדייר. SRS בשרת מאוחר יותר במסלול אינו מתקן את החסימה הזו.

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

בדקו את מדיניות סינון הספאם היוצא בפורטל Defender. שנו אותה רק באישור הארגון ועם אמצעי הגנה מתאימים. SRS בשרת המקבל אינו פותר את ההגבלה ואינו אמור לשמש לעקיפתה.

3. בדקו לולאות ניתוב

אם A מעביר ל-B ו-B מעביר בחזרה ל-A, עלולה להיווצר שליחה חוזרת, בהתאם לכללים ולהגנה מפני לולאות. חפשו בלוגים סימנים כמו אלה:

554 5.4.14 Hop count exceeded
5.4.6 Routing loop detected

במקום להעביר, ארחו תיבות דוא״ל אמיתיות

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

במקום להעביר contact@client-domain.com ל-Gmail ולתחזק הגדרת SRS, אפשר לארח contact@client-domain.com כתיבת IMAP אמיתית ב-TrekMail. אפשר לגשת דרך לקוח דוא״ל תואם, כולל אפליקציית Gmail כאשר היא תומכת בשילוב הנדרש באמצעות IMAP. המסירה מתבצעת ישירות לתיבה. שלב ההעברה הנוסף ב-SMTP ושכתוב המעטפת שלו נעלמים, לא כל בעיות האימות. השוו את הגישות במדריך להעברת דוא״ל של דומיין ל-Gmail או בהשוואה בין כינוי לתיבת דוא״ל.

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

המסלולים המתוארים של TrekMail מתחילים ב-$3.50 לחודש עם תקופת ניסיון חינם של 14 ימים. בדקו את המחירים, המגבלות ותנאי הניסיון העדכניים. הגדירו תיבות דוא״ל אמיתיות כדי להימנע מהעבודה הנוספת של העברה.