העברת דואר מהדומיין ל-Gmail: הגדרה ובדיקה

הגדרתם את contact@yourdomain.com להעביר את דואר הדומיין ל-Gmail. לקוח שולח חוזה, ובנק שולח התראת אבטחה. אף אחת מההודעות אינה מופיעה.

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

הסיבה אינה בהכרח בעיה ב-Gmail עצמו; ייתכן שזה כשל אימות. כשאתם מעבירים דואר מהדומיין ל-Gmail, השרת שלכם משדר הודעה של צד אחר מכתובת ה-IP שלו. אם שולח המעטפת נשמר, Gmail בודק SPF עבור הדומיין המקורי, שבדרך כלל אינו מאשר את ה-IP שלכם. SPF נכשל. עם מדיניות DMARC מחמירה (p=reject) וללא חתימת DKIM תקפה עם דומיין תואם, Gmail עשוי לדחות את ההודעה עם 550-5.7.26. שרת ההעברה מקבל את שגיאת SMTP; דיווח אי-מסירה עשוי להגיע לשולח המקורי, בעוד שאתם לא תקבלו התראה.

שכתוב שולח המעטפת באמצעות SRS ‏(Sender Rewriting Scheme) ותיעוד האימות באמצעות ARC ‏(Authenticated Received Chain) יכולים לתמוך בהעברה ל-Gmail. שניהם רכיבי תשתית חשובים, אך אינם מבטיחים התאמת דומיינים ב-DMARC או מסירה. חתימת DKIM תקפה עם דומיין תואם שנשמרה בהעברה יכולה גם היא להעביר את בדיקת DMARC, אפילו כש-SPF נכשל.

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

מדוע Gmail עלול לדחות דואר מועבר

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

זהו רצף כשל אפשרי כשהודעה מ-client@bank.com מועברת אל you@gmail.com:

1. bank.com מוסר את ההודעה לשרת ההעברה שלכם
2. השרת שלכם מעביר אותה ל-Gmail
3. Gmail בודק SPF עבור שולח המעטפת: client@bank.com
4. רשומת SPF של bank.com אינה מאשרת את ה-IP שלכם → SPF FAIL
5. מדיניות DMARC היא p=reject; ללא DKIM תקף עם דומיין תואם Gmail עשוי להחזיר 550-5.7.26
6. ההודעה אינה נמסרת. ייתכן שלא תקבלו התראה; דיווח ל-bank.com תלוי בשרת ההעברה.

DKIM יכול להישאר תקף בהעברה אם החלקים החתומים לא משתנים. טקסט שמוסיף אנטי-וירוס בסוף ההודעה או שינוי בנושא חתום עלולים לפסול את החתימה. עם DKIM תקף ודומיין תואם, ההודעה יכולה לעבור את בדיקת DMARC ב-Gmail גם אם SPF נכשל. ההגדרה aspf=s נוגעת להתאמת SPF מחמירה ואינה משנה את התאמת DKIM. ‏SRS עשוי לעזור ל-SPF, אך לבדו אינו פתרון מובטח ל-DMARC או לבעיות מסירה.

שלוש דרכים להעביר דואר מהדומיין ל-Gmail

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

Catch-all עלול לפגוע במיוחד במסירת הדואר. מפיצי ספאם בודקים כתובות אקראיות כמו abc123@yourdomain.com ו-junk@yourdomain.com. השרת מקבל את ההודעות ומעביר אותן ל-Gmail. אם בתרחיש ההמחשה 90% מהתעבורה המועברת היא ספאם, Gmail עשוי להוריד את דירוג מוניטין ה-IP או לחסום אותו. גם הודעות לגיטימיות עלולות להגיע לספאם, ושיקום המוניטין עשוי להימשך שבועות. האחוז אינו נתון מדוד כללי או סף חסימה מובטח.

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

SRS: מדוע הוא חשוב בהעברה ל-Gmail

SRS ‏(Sender Rewriting Scheme) יכול לצמצם כשלי SPF ברמת המעטפת. הוא משכתב את שולח המעטפת, המשתקף ב-Return-Path ומשמש לדיווחי כשל, מהדומיין המקורי לדומיין שלכם. Gmail בודק אז SPF עבור הדומיין שלכם. אם ה-IP של השרת מורשה כראוי, SPF יכול לעבור. אין בכך הבטחת מסירה או אישור DMARC.

ללא SRS (תרחיש כשל):
שולח מעטפת SMTP: client@bank.com
IP שולח: 203.0.113.10 (שרת ההעברה שלכם)
בדיקת SPF: הרשומה של bank.com → FAIL (203.0.113.10 אינו מורשה)
DMARC: FAIL (p=reject), אם גם DKIM עם דומיין תואם חסר → דחייה אפשרית

עם SRS (SPF עובר בדוגמה):
שולח מעטפת SMTP: SRS0=HASH=TT=bank.com=client@yourdomain.com
IP שולח: 203.0.113.10 (שרת ההעברה שלכם)
בדיקת SPF: הרשומה של yourdomain.com → PASS (203.0.113.10 מורשה)
השולח בכותרת From: client@bank.com (ללא שינוי, רואים את השולח המקורי)

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

תשתית מוגדרת היטב יכולה להוסיף גם כותרות ARC ‏(Authenticated Received Chain). שרשרת החתימות הקריפטוגרפיות מתעדת את תוצאות האימות שנצפו בפועל בכל שלב. Google עשוי להתחשב בה כאשר הוא נותן אמון במעביר. ARC דורש הגדרת חתימה מתאימה משלו; חתימת DKIM רגילה אינה מחליפה אותו. בשירות מתארח, המימוש הוא באחריות הספק.

מפרט SPF מוגדר ב-RFC 7208. ‏ARC, המתעד את האימות לאורך כמה שלבי העברה, מוגדר ב-RFC 8617.

מניעת לולאות: ארבע בדיקות לפני ההפעלה

לולאות העברה עלולות לייצר שגיאות כמו 5.4.14 Hop count exceeded ולמנוע מסירה של הודעות אמיתיות. בדקו את ארבעת הנושאים האלה לפני שימוש בפועל.

1. ללא ניתוב מעגלי. ודאו שב-you@gmail.com אין מסנן שמעביר דואר בחזרה אל you@yourdomain.com. אם כתובת זו שוב מפנה ל-Gmail, נוצרת לולאה.
2. בקרה על תגובות אוטומטיות. בכתובת תפקיד (team@domain.com → כמה חשבונות Gmail), השביתו תגובות לא נחוצות או הגדירו הגנה מתאימה מלולאות. אפשר להתחשב בכותרות כגון Precedence: bulk, אך הן אינן הגנה מלאה בפני עצמן.
3. בדיקה מחשבון שלישי. Gmail עשוי להסתיר הודעות כפולות. בדיקה מחשבון היעד לכינוי שלכם עשויה להופיע רק בדואר שנשלח. בדקו גם מחשבון Yahoo או Outlook עצמאי.
4. מדיניות יציאה ב-M365. מדיניות הספאם היוצא ב-Microsoft 365 צריכה לאפשר העברה חיצונית אוטומטית. מנהל מורשה יכול לשנות את ההגדרה לאחר הערכת הסיכון. אחרת עשויה להופיע 550 5.7.520.

אלה גורמים נפוצים לבעיות בהגדרה ראשונית של העברה ל-Gmail. הודעות השגיאה לבדן לא תמיד מזהות את הסיבה במדויק.

העברת דואר מהדומיין ל-Gmail באמצעות TrekMail

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

לפי המקור, העברת דואר מתיבות זמינה בחבילות Pro ו-Agency, ולא ב-Free או Starter. בדקו את התנאים העדכניים לפני מעבר חבילה. השלבים מתוארים בתיעוד העברת הדואר מתיבות ב-TrekMail:

1. פתחו את תיבות הדואר בלוח הבקרה
2. לחצו על ניהול בתיבה הרצויה
3. הפעילו את הפעלת העברה
4. הזינו את כתובת Gmail בשדה העברה אל
5. הפעילו את שמירת עותק והשאירו את האפשרות פעילה בזמן ההגדרה הראשונית
6. לחצו על שמירת הגדרות העברה

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

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

השלמת השליחה: ״שליחת דואר בשם״ ב-Gmail

העברה מטפלת בדואר נכנס. ללא הגדרה מתאימה של ״שליחת דואר בשם״, תשובות עלולות לצאת מכתובת @gmail.com האישית במקום מהדומיין. הלקוח רואה Gmail במקום ceo@yourdomain.com.

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

ב-Gmail: הגדרות → חשבונות וייבוא → שליחת דואר בשם → הוספת כתובת דוא״ל נוספת. בדקו את ״התייחסות כאל כינוי״ בהתאם לתצורה; ביטול הסימון לבדו אינו מבטיח תוצאת אימות מסוימת.

הגדרות SMTP של TrekMail במקור (Starter, Pro, Agency):

SMTP Server:  smtp.trekmail.net
Port:         587
Security:     TLS (STARTTLS)
Username:     your-mailbox@yourdomain.com
Password:     Your mailbox password

Nano במקור: SMTP מספק שתבחרו (SES, SendGrid, Mailgun ועוד):

SMTP Server:  email-smtp.us-east-1.amazonaws.com  (Amazon SES example)
Port:         587
Security:     TLS
Username:     Your SMTP credentials from your provider

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

בדיקת התוצאה: קריאת כותרות האימות ב-Gmail

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

ב-Gmail: פתיחת ההודעה → תפריט שלוש הנקודות → הצגת המקור. חפשו את Authentication-Results.

תוצאות שעברו יכולות להיראות כך, אך הדוגמה לבדה אינה מוכיחה התאמת דומיינים ב-DMARC:

Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of SRS0=hash=tt=bank.com=client@yourdomain.com
    designates 203.0.113.10 as permitted sender)
    smtp.mailfrom=SRS0=hash=tt=bank.com=client@yourdomain.com;
  dkim=pass header.i=@yourdomain.com;
  arc=pass (i=1 spf=pass dkim=pass)

אם מופיע spf=softfail או spf=fail, בדקו את שכתוב SRS ואת אישור כתובת ה-IP בפועל ברשומת SPF. גם תקלות הגדרה אחרות אפשריות. arc=fail עשוי להצביע על שינוי תוכן חתום, חתימות לא תקפות או בעיות בשרשרת ARC, בין היתר. ההנחיות הרשמיות של Google להעברה ל-Gmail עוסקות בשימוש מתאים בשולח המעטפת. SRS הוא אחד המנגנונים לשכתובו.

ניהול עצמי או שירות מנוהל: השיקול האמיתי

בשרת Postfix בניהול עצמי אפשר למשל להתקין postsrsd, להגן על הקובץ srs_secret ולתכנן את החלפת הסוד, להגדיר OpenARC עם מפתחות חתימה מתאימים ולעקוב אחר המוניטין ב-Google Postmaster Tools כשיש נתונים זמינים. בעיות בתלויות, החלפה שגויה של מפתחות או מדיניות חדשה של שולחים עדיין עלולות לגרום לתקלות. אתם עלולים למצוא את עצמכם מנתחים כותרות אימות ב-11 בלילה.

המקור מתאר עיבוד SRS ו-ARC ברמת MTA ב-TrekMail אחרי הגדרת היעד. עדיין בדקו את התמיכה הנוכחית, את אימות הדומיין ואת תוצאות הבדיקות; מעקב שוטף נשאר חשוב.

איך מתחילים

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

המקור מציין תקופת ניסיון חינמית של 14 ימים לחבילות בתשלום, עם כרטיס אשראי נדרש. אפשר גם לבדוק ב-trekmail.net/pricing את התנאים הנוכחיים של Nano ושל החבילות בתשלום.

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

הגדירו, בדקו את הכותרות והמשיכו לעקוב אחר התוצאות בשימוש שוטף.