העברת דוא״ל עם דומיין משלכם: מדריך הגדרה (2026)

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

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

איך עובדת העברה בדומיין משלכם

הודעות לדומיין מנותבות לתיבה קיימת כמו Gmail או Outlook. לא תמיד דרושה תיבת משתמש מקומית, אך שרת הממסר עשוי לשמור הודעות זמנית בתור כשמסירה מתעכבת.

יש שני מודלים נפוצים. האמינות, העלות ועבודת הניהול תלויות ביישום בפועל.

ניתוב ברמת הספק (העברת MTA)

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

העברה באמצעות כלל בתיבה

משתמשים בתיבה של Google Workspace או Microsoft 365 ומגדירים כלל. המחיר $6-$30 לחודש למשתמש הוא דוגמת עבר; רישיונות ותיבות משותפות עשויים להיות שונים כיום. מדיניות ומצב הרישיון משפיעים, והמודל יכול להתאים לסינון ולשמירה.

שלבים להגדרת העברה בדומיין שלכם

עברו על ארבעת השלבים ואמתו DNS. המתנה של 15 דקות היא דוגמת תכנון בלבד; TTL ומטמונים עלולים להאריך אותה.

שלב 1: אימות שליטה בדומיין

הספק עשוי לבקש רשומת TXT לבדיקת שליטה, למשל:

trekmail-verify=abc123def456

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

שלב 2: הגדרת MX

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

@ MX 10 mx1.trekmail.net
@ MX 20 mx2.trekmail.net

שלב 3: יצירת מסלול ההעברה

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

info@yourdomain.com → yourname@gmail.com

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

שלב 4: בדיקת SPF לזהות הנכונה

רשומת SPF מתירה שרתי שליחה לזהות המעטפה שנבדקת. הוספת הספק ל־SPF של הדומיין שלכם אינה מתירה אוטומטית שולח מעטפה חיצוני מקורי. בדקו את תיעוד MAIL FROM ואת זהות SRS בפועל.

v=spf1 include:_spf.trekmail.net ~all

זו דוגמה. אמתו include ואחדו שולחים מורשים ברשומת SPF אחת. SPF לבדו אינו מונע ספאם או מבטיח יישור עם From המקורי.

5 מלכודות DNS בהעברת דוא״ל

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

1. ערבוב MX לא מתוכנן (“Split Brain”)

רשומה ישנה כמו ASPMX.L.GOOGLE.COM עשויה לקבל תעבורה לפי עדיפות וזמינות, ולא בהכרח בחלוקה אקראית. פעולה: התאימו את הרשומות למסלול המתוכנן והסירו רק יעדים שאינם מורשים או בשימוש אחרי מעבר מתואם.

2. SPF חסר או שגוי (“Softfail Trap”)

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

3. CNAME בשורש הדומיין

CNAME רגיל בשורש (@) אינו יכול להתקיים לצד רשומות נחוצות כמו SOA, NS ו־MX לפי RFC 1034. השתמשו ברשומות אתר ודואר מתאימות. ALIAS, ANAME ו־flattening אינם פרסום CNAME רגיל; בדקו את תשובת DNS בפועל.

4. ניתוב מקומי שנשאר

לאחר מעבר מאחסון משותף, Local Mail Exchanger ב־cPanel עלול לנתב דואר שנוצר מקומית לשרת הישן. הוא אינו מיירט אוטומטית דואר חיצוני שמחפש MX ציבורי. השוו בדיקות מקומיות וחיצוניות ובחרו Remote Mail Exchanger רק כשהוא מתאים למסלול האמיתי.

5. התנגשויות catch-all

העברת info@ לצד catch-all של *@ דורשת עדיפות ברורה ושרשרת ללא לולאה. לולאה עשויה לגרום ל־5.4.6 או ל־554 5.4.14 hop count exceeded. אמתו כינויים מפורשים והגבילו catch-all לצורך מתועד.

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

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

שלב 1: שולח חיצוני

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

שלב 2: בדיקת כתובת התשובה

תשובה נשלחת בדרך כלל לשולח המקורי, אך Reply-To תקין יכול לקבוע יעד אחר. אם מופיע info@yourdomain.com, השוו את הכותרות המקוריות והמועברות לפני קביעה שהשכתוב שגוי.

שלב 3: בדיקת כותרות

פתחו מקור גולמי ובדקו תוצאות מהשרת המהימן ב־Authentication-Results:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@original-sender.com;
  spf=pass (domain of SRS0=... designates ... as permitted sender)

SRS0 הוא רמז ל־Sender Rewriting Scheme, לא אימות מלא. במקרה של spf=softfail או dmarc=fail, חקרו זהות שנבדקה, חתימות, יישור ומסלול; DNS שלכם אינו בהכרח הסיבה.

למה העברה יכולה להיכשל

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

כש־SPF ו־DKIM אינם מספקים הצלחת DMARC

דוגמת אבחון #1: הודעה עם p=reject שבה SPF נכשל בגלל שינוי IP ו־DKIM נכשל אחרי שינוי תוכן חתום. DMARC נכשל אם אין SPF או DKIM שגם הצליח וגם מיושר ל־From הגלוי. מדיניות הנמען קובעת את ההמשך; הודעת כשל יכולה להופיע או לא.

חסימת שליחה ב־Microsoft 365 (5.7.520)

בהעברה מתוך תיבת M365, מדיניות יכולה לחסום עם 550 5.7.520 Access denied, your organization does not allow external forwarding. מנהל מורשה צריך לבדוק Outbound Spam Filter Policy ולאשר רק חריג מצומצם מתאים.

לולאות תשובות אוטומטיות

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

SRS ו־ARC: כלים לתמיכה בהעברה

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

SRS (Sender Rewriting Scheme)

SRS משכתב שולח מעטפה. למשל, alice@bank.com יכול להפוך ל־SRS0=hash=timestamp=bank.com=alice@forwarder.com. SPF בודק את דומיין הממסר שצריך הרשאה תקינה. שכתוב הפוך נתמך יכול להחזיר הודעות כשל לשולח המקורי.

ARC (Authenticated Received Chain)

SRS אינו מבטיח יישור DMARC עם From המקורי. ARC שומר תוצאות אימות קודמות בשרשרת חתומה. הנמען מחליט אחרי אימות אם לבטוח בממסר ולשנות את המדיניות המקומית בהתאם. RFC 8617 מתאר את המנגנון; שרשרת תקפה אינה מבטיחה DMARC-pass או קבלה.

סיכוני catch-all עם העברה

Catch-all של *@yourdomain.com יכול להעביר הרבה ספאם ל־Gmail או ל־Outlook. נפח ומדיניות עשויים להשפיע על התשתית שלכם ועל מוניטין הדומיין. רשימות חסימה ופגיעה בדואר תקין הן השלכות אפשריות, לא ודאות.

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

מתי עדיפה תיבה מלאה

העברה מנהלת קבלה, ולא כל תכונה של תיבה. שקלו תיבה מתארחת אם:

• צריך לשלוח בשם הדומיין. Gmail Send As יכול לעבוד עם SMTP מתאים ומורשה. בדקו אימות ותנאים והשוו לניהול תיבה עם SMTP.
• למשל, הנפח עולה על 500 הודעות ביום. זו דוגמת תכנון ולא מכסה אוניברסלית של Gmail או Outlook. בדקו מכסות, תורים ומדיניות בפועל.
• צריך לעמוד בדרישות רגולטוריות. בדקו זרימות נתונים, חוזים, תפקידים והגנות לפי HIPAA או GDPR. ממסר חיצוני אינו לבדו הוכחת הפרה או אחריות.

אם ההעברה מכסה אצלכם 90% מצורכי הקבלה הפשוטים, התאימו תיבות נוספות לתכונות החסרות. לא בהכרח צריך 10 רישיונות כדי להעביר info@, support@ ו־billing@ לאותו Gmail. בדקו כינויים, תכונות ותנאי רישוי בפועל.

TrekMail: העברה לדומיינים פרטיים

ניהול ידני דורש בדיקת MX, SPF, SRS וקודי כשל. ניהול מרכזי מתאים יכול להקל על העבודה.

TrekMail מתאר SRS, ARC, עזרת אימות, סינון catch-all ולוח רב־דומייני. אל תניחו מחיר זהה לדומיין אחד ולאלף. בדקו תכונות ומגבלות כיום; המספרים הבאים הם ערכי עבר לייחוס:

• Free Plan: $0 לחודש, 10 דומיינים, 5GB אחסון, BYO SMTP
• Starter: $3.50 לחודש, 50 דומיינים, 15GB אחסון
• Pro: $10 לחודש, 100 דומיינים, 50GB אחסון
• Agency: $23.25 לחודש, 1,000+ דומיינים, 200GB+ אחסון

בדקו שם, זכאות ודרישת כרטיס למודל Free/Nano החינמי המתואר. מודל Nano זה דורש SMTP חיצוני משלכם לכל הודעה יוצאת ולכל תשובה. הניסיון המתואר בתשלום הוא 14 ימים; בדקו תנאים והיקף כיום. בדקו את TrekMail והשוו עלות לשימוש שלכם.

סיכום: הגדירו העברה בקפידה

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

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