העברת דוא״ל לא עובדת: אבחון ב-6 שלבים

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

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

עברו על הרשימה לפני שינוי DNS. המדריך המלא להגדרת העברות ולפתרון תקלות מסביר את SPF ואת תפקיד SRS ו־ARC. כאן נתמקד באבחון ראשוני של התקלה הנוכחית.

למה לפעמים אין שגיאה גלויה בהעברה

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

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

אבחון ב־60 שניות: קודם הגדירו את התסמין

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

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

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

שלב 1: בדקו את הספאם ביעד

בדיקה ראשונית  |  תסמין: אין הודעה או הודעת כשל

ההודעה עשויה להיות בספאם. בהעברה מ־client@gmail.com אל you@outlook.com, השרת האחרון עשוי לראות IP שרשומת SPF של שולח המעטפה המקורי אינה מתירה. התוצאה תלויה גם ב־DKIM, ב־DMARC ובמדיניות הנמען.

פעולה: היכנסו לתיבה הסופית ובדקו דואר זבל או ספאם.

המשך: סמנו הודעה שנמצאה כלא־ספאם כשמתאים. בדקו Sender Rewriting Scheme (SRS) לשכתוב שולח המעטפה. SRS מסייע ל־SPF של הזהות החדשה, אך אינו מבטיח יישור DMARC עם From המקורי או מסירה. חתימת DKIM תקפה ומיושרת שנותרה תקינה עשויה להספיק ל־DMARC גם בלי SRS.

שלב 2: קראו את הודעת הכשל וקודי NDR

קראו את פרטי השגיאה  |  תסמין: השולח מקבל הודעת אי־מסירה

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

שלב 3: בדקו יישור DMARC

בדיקת אימות ל־Gmail, ל־Yahoo ול־Outlook  |  תסמין: אין מסירה גלויה או יש דחייה

לא כל כשל העברה נובע מ־DMARC. גם עם p=reject, הטענה שהעברה בלי SRS או ARC נכשלת ב־100% מהמקרים אינה נכונה. DMARC יכול לעבור עם חתימת DKIM תקפה שמיושרת עם From הגלוי. SPF או DKIM חייב להצליח וגם להיות מיושר.

בדקו את מדיניות הדומיין המקורי במסוף:

dig _dmarc.originalsender.com TXT +short

p=reject הוא בקשת מדיניות, ולא הוכחה שהודעה זו נדחתה. SPF משתמש בזהות המעטפה ו־DKIM בדומיין החתימה. DMARC משווה כל מנגנון ל־From הגלוי, ולא את שולח המעטפה לחתימת DKIM.

המשך: בדקו ממסר עם SRS ותמיכת ARC לפי הצורך. ARC שומר תוצאות אימות קודמות בשרשרת חתומה; הנמען מחליט אם לבטוח בשרשרת התקפה. אין בכך הבטחת DMARC-pass או מסירה. הפניות cPanel פועלות בשרת; כללי Gmail ו־Outlook משתנים לפי היישום. בדקו את שרת ההעברה בפועל.

שלב 4: בדקו מדיניות העברה חיצונית ב־Microsoft 365

בדיקת מדיניות Office 365  |  תסמין: 550 5.7.520 NDR

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

1. פתחו כמנהל מורשה את Microsoft 365 Defender
2. בדקו Email & collaboration → Policies & rules → Threat policies → Anti-spam; שמות המסכים יכולים להשתנות
3. בדקו Anti-spam outbound policy (Default) ואת המדיניות הממוקדת שחלה בפועל
4. פתחו כשמורשה Edit protection settings
5. בדקו Automatic forwarding rules ובחרו רק אחרי אישור ובהיקף מתאים On - Forwarding is enabled

אפשרות מושבתת עשויה לנבוע מהרשאות או ממדיניות. פנו למנהל הדייר לחקירה; הגדרת משתמש אינה מבטלת מדיניות ארגונית.

שלב 5: חפשו לולאות ניתוב

בדיקת המסלול  |  תסמין: שגיאת 5.4.14 או עותקים מרובים

לולאה נוצרת כששרת A מעביר ל־B ו־B מחזיר ל־A. מגבלת קפיצות יכולה לעצור אותה. לדוגמה, catch-all בדומיין A שולח ל־B וכלל ב־B מחזיר כתובות מסוימות ל־A. לעותקים כפולים יכולות להיות גם סיבות אחרות.

בדקו כותרות אלה בהודעה שהתעכבה או הוכפלה:

• X-Loop
• X-MS-Exchange-Inbox-Rules-Loop
• Delivered-To שחוזר עם אותה כתובת

מדריך catch-all לדומיין מסייע בתכנון ניתוב. שרשרת יכולה לכלול כינויים, אך היא צריכה להיות מוגבלת ולהגיע לתיבה סופית בלי לולאה.

שלב 6: אמתו את יעד Gmail

בדיקת הפעלה  |  תסמין: הכלל קיים אבל אינו מעביר

ב־Gmail אישי ייתכן שחסר אישור היעד. בדקו שהאימות הושלם ושההעברה אכן הופעלה לאחר מכן. כלל שקיים אינו לבדו הוכחת העברה פעילה.

פעולה: חפשו ביעד הודעת אישור של Gmail Team, גם בספאם. בדקו שולח ויעד מבוקש לפני אישור הקישור. אם צריך, בקשו אימות חדש דרך הגדרות Gmail → העברה ו־POP/IMAP, ואז בדקו את הגדרת ההעברה הפעילה.

קריאת כותרות לאבחון תקלות העברה

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

איך מציגים כותרות:

• Gmail: פתיחת הודעה → תפריט שלוש נקודות → הצגת המקור
• Outlook: קובץ → מאפיינים → כותרות אינטרנט; בדקו מסלול לפי גרסה

קטע כותרת להמחשת SRS ו־ARC, לא תחביר ARC מלא או קנוני. בדקו את כותרות ARC והאימות בפועל; הקטע לבדו אינו מוכיח שרשרת תקינה:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sender.com;
  spf=pass (google.com: domain of SRS0=ABCD=XY=sender.com@forwarder.com
            designates 1.2.3.4 as permitted sender)
  dmarc=pass (p=REJECT) dis=NONE header.from=sender.com
  arc=pass (i=1 spf=pass dkim=pass)

קידומת SRS0= ב־Return-Path היא רמז לשכתוב SRS, לא הוכחת תצורה תקינה לחלוטין. היעדרה אינו שולל שכתוב אחר או מוכיח כשל DMARC. בדקו כותרות ושרת בפועל. הכללים ש־Google חיזקה מאז 2024 בשליחה ל־Gmail אישי אינם חלים באותו אופן על כל ספק וכל דומיין עסקי.

כשכשל העברה הופך לבעיה עסקית

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

חקירה ידנית קשה יותר כשמתרבים דומיינים ומשתנה מדיניות. כשל אימות אינו מייצר אוטומטית תלונת ספאם. Google Postmaster Tools מספק נתונים מצטברים בתנאים מסוימים על שליחה ל־Gmail אישי, בכפוף לזמינות, עיכוב ונפח. הוא אינו עוקב אחר כל הודעה מועברת.

צמצמו חקירה חוזרת

תשתית שמיישמת SRS ו־ARC כראוי יכולה לעזור בבעיות חוזרות. המשיכו לבדוק מדיניות, אימות ומסירה בפועל; הרשימה אינה מתייתרת לצמיתות.

ניהול נפרד: כללי Gmail או cPanel, חקירת SPF לכל דומיין, בדיקת מדיניות M365 ומעקב אחר שינויים.

מודל TrekMail המתואר: מסלולים מרכזיים עם SRS ו־ARC ברמת MTA כשנתמך. בדקו יישום לכל מסלול; הנמען עדיין מחליט על קבלה.

TrekMail מתאר העברה ברמת Postfix עם שכתוב מעטפה ב־SRS וחתימת ARC. התוכן המכוסה בחתימת DKIM מקורית צריך להישאר תקין כדי שהחתימה תאומת. ARC שומר תוצאות קודמות ואינו מחליף את החתימה המקורית. בדקו תמיכה ועיבוד נוכחיים בכל מסלול. Gmail, Outlook ו־Yahoo יכולים לסנן גם אחר כך.

לסוכנויות שמנהלות עשרות דומיינים, בקרה מרכזית יכולה לצמצם חקירה ב־30 לוחות נפרדים. הגדירו ובדקו כל מסלול והרשאותיו. מדריך ניהול דוא״ל לקוחות עוזר להימנע מלולאות A→B→A שבשלב 5.

התיאור ההיסטורי מציין Pro ב־$10 לחודש (100 דומיינים, 50GB) ו־Agency ב־$23.25 לחודש (1,000+ דומיינים), עם ניסיון של 14 ימים. בדקו תמיכת SRS/ARC כיום, מגבלות, דרישת כרטיס והיקף ניסיון: השוו מסלולים ב־trekmail.net/pricing.

נהלו תקלות העברה חוזרות באופן שיטתי. בדקו תמיכת TrekMail ב־SRS וב־ARC ואת האפשרויות הנוכחיות.