העברת דוא״ל בדומיין: אבחון עם SRS ו-ARC

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

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

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

מדוע העברת דוא״ל בדומיין עלולה להכשיל SPF

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

זהו רצף כשל אפשרי:

1. alice@bank.com שולחת אל info@yourdomain.com. רשומת SPF של הבנק מתירה את שרתי הדואר שלו.
2. השרת שלך שולח מחדש אל you@gmail.com. Gmail רואה את כתובת ה-IP שלך, אך Return-Path עדיין מפנה אל bank.com.
3. כתובת ה-IP שלך אינה ברשומת SPF של bank.com. בדוגמה הזאת SPF נכשל.
4. הוספת תחתית לתוכן חתום או שינוי נושא חתום עלולים לפגוע גם ב-DKIM. אם אין אימות מתואם שעובר, DMARC נכשל והנמען עשוי להחיל מדיניות דחייה.

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

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

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

3 דפוסים לשיפור אמינות העברת הדוא״ל בדומיין

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

1. שיטת שכתוב השולח (SRS)

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

לפני SRS:

MAIL FROM: <alice@bank.com>

אחרי SRS:

MAIL FROM: <SRS0=hash=TT=bank.com=alice@forwarder.com>

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

2. שרשרת קבלה מאומתת (ARC)

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

ARC-Authentication-Results: i=1; forwarder.com; spf=pass; dkim=pass; dmarc=pass
ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.com; ...
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=forwarder.com; ...

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

האמון תלוי במדיניות הנמען ובמוניטין של הגורם המתווך. דומיין חתימה חדש או כתובת IP חדשה אינם זוכים אוטומטית לאמון ב-ARC.

3. מעבר שקוף (שימור DKIM)

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

תקלות העברה שקשה לאבחן נובעות לעיתים משינויי הודעה. מסנן ספאם עשוי להוסיף לגוף "ההודעה נסרקה על ידי MailGuard", בלי סימן ברור ביומני השליחה. אם יש גישה לכותרות אצל הנמען או לעותק אבחון, dkim=fail (body hash did not verify) בתוך Authentication-Results עשוי להיות הרמז.

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

כיצד ספקים גדולים מטפלים בתקלות העברה

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

Microsoft 365 (Exchange Online)

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

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

Google Workspace / Gmail

דוגמה לדחייה מפורשת היא 550-5.7.1 Unauthenticated email from domain.com is not accepted due to domain's DMARC policy. היא עשויה להופיע עם p=reject כאשר אין אימות מתואם שעובר ואין חריג מדיניות אצל הנמען. היעדר SRS או ARC לבדו אינו התנאי המכריע לדחייה.

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

Yahoo / AOL

Yahoo עשוי לדחות דואר עם אימות חסר בקוד 550, אך לא כל הודעה מועברת נדחית כבר בניסיון הראשון. הוספת [FWD] או [External] עלולה לשבור DKIM אם הנושא חתום. כישלונות SPF ו-DKIM מעלים את הסיכון לכישלון DMARC, אך טענה לדחייה של 100% מההודעות מחייבת ראיות לגבי ההודעות והמדיניות. גם תצורות ישנות דורשות אבחון לפי מסלול.

רשימת אבחון להעברה

כשהעברת הדואר נכשלת, עבור על השלבים הבאים לפני שינוי הגדרות:

1. קרא את כותרת Authentication-Results אצל הנמען ("הצגת המקור" ב-Gmail, או מקור ההודעה ב-Outlook).

   Authentication-Results: mx.google.com;
     spf=fail (domain of bank.com does not designate 198.51.100.1 as permitted)
     dkim=fail (body hash did not verify)
     dmarc=fail (p=REJECT)

   spf=fail → בדוק את דומיין המעטפת, כתובת ה-IP ו-SPF; היעדר SRS או הגדרה שגויה הם סיבה אפשרית.
   dkim=fail (body hash) → חפש שינויים בגוף החתום או פגיעה בתוכן בעת ההעברה.
   אם אין בדיקת SPF או DKIM מתואמת שעוברת, DMARC נכשל; הנמען קובע דחייה וחריגי ARC לפי מדיניותו.
2. בדוק לולאות ניתוב. 5.4.14 Hop count exceeded מציין חריגה ממגבלת הקפיצות; קרא את ההקשר המלא. שרטט את השרשרת ובדוק לולאה כמו A→B→C→A.
3. בדוק את התנהגות Reply-To. תשובה משתמשת בדרך כלל ב-Reply-To אם הוא קיים, ואחרת ב-From. אם התשובה מגיעה במפתיע לשירות ההעברה, בדוק את שתי הכותרות; הדבר אינו מוכיח לבדו ש-From שוכתב.
4. בדוק כל רכיב שמעבד את ההודעה. מסנני ספאם, סורקי וירוסים, תוכנות רשימות תפוצה וכלי מניעת דיוג עשויים לשנות תוכן חתום. לא כל שינוי שובר DKIM; בדוק את השדות החתומים וכללי הקנוניזציה.
5. בדוק את נפח ההעברה מכתובת האיסוף הכולל. נפח ספאם גבוה עשוי לפגוע במסירה ב-Gmail, גם כשהודעות מסוימות עוברות אימות.

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

תשתית ההעברה של TrekMail

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

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

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

המסלולים המוזכרים הם Pro ($10 לחודש) ו-Agency ($23.25 לחודש), עם העברת תיבת דואר וניסיון חינם למשך 14 ימים המחייב כרטיס אשראי. Nano ($0, ‏10 דומיינים, SMTP משלך) ו-Starter ($3.50 לחודש, ‏50 דומיינים) מוזכרים ללא העברה. לפני רכישה, בדוק מחירים, יכולות ומגבלות עדכניים בהשוואת המסלולים המלאה ב-trekmail.net/pricing.

סיכום

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

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

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