העברת דואר לחשבון חדש: נתונים, הגדרות ו-DNS

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

הבעיה עשויה להופיע בהמשך: ביום שני בבוקר תשובות נדחות, סורק עדיין משתמש ב-SMTP הישן והעברה נסתרת להנהלת החשבונות חסרה. תיבת הדואר נראית ריקה כשההודעות בתיקיית IMAP אחרת. העתקה מוצלחת אינה בהכרח סביבת עבודה מוכנה.

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

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

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

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

כך מפרידים:

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

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

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

נקודות נסתרות שעלולות לשבש את המעבר

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

1. זהות תשובה ישנה. שיחות פנימיות ישנות ב-Microsoft עשויות להשתמש בנתוני כתובת מדור קודם במקום בכתובת SMTP הגלויה, ולכן תשובות עלולות להידחות. במעבר מ-Exchange או Microsoft 365 בדקו זהויות אלה ואת תמיכת היעד. כינוי SMTP רגיל אינו פתרון אוטומטי.

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

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

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

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

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

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

1. הכינו את היעד תחילה. צרו תיבה, בדקו כתובת מלאה וסיסמת תיבה ואמתו את הדומיין. הכינו SPF, DKIM ו-DMARC בלי לשנות MX מוקדם. סימון ירוק אינו בדיקת קבלה ושליחה מלאה. השתמשו בתיעוד סקירת העברת IMAP ו-רשומות DNS נדרשות העדכני.
2. מפו מה שאינו IMAP. רשמו כינויים, העברות, גישה משותפת, SMTP במכשירים, תוכנות בנייד ובמחשב, יומנים ואנשי קשר. אמתו הרשאות והגדרות שליחה בשם אחר.
3. בצעו העתקה מקדימה. העתיקו דואר ישן בזמן שהמשתמשים עובדים במקור. TrekMail מתארת ייבוא מ-Gmail, Outlook, Yahoo, iCloud ו-IMAP כללי במסלולי Starter ומעלה; בדקו תמיכה ותנאי מקור עדכניים. כלי הייבוא המתואר משתמש בפרטי IMAP ישירים ולא ב-OAuth אינטראקטיבי. Exchange Online עשוי לדרוש מסלול נתמך אחר. בדקו טיפול בכפילויות לפני הרצות חוזרות.
4. הפחיתו TTL מראש. צריך להמתין גם לפקיעת תשובות שנשמרו לפי ה-TTL הישן. אם משנים קבלה בדומיין שלכם, שנו MX רק לאחר הכנת היעד ובדיקת ההעתקה. בדקו שרתי DNS סמכותיים ופותרי שמות חיצוניים רלוונטיים.
5. סנכרנו שינויים אחרונים. חזרו על הסנכרון להודעות שהגיעו באיחור עם תאריך ישן ולתנועת הודעות בין תיקיות. שמרו קבלה במקור, סנכרון ניהולי ואפשרות חזרה כל עוד מטמונים וניסיונות SMTP חוזרים דורשים זאת.
6. חברו תוכנות ומכשירים מחדש. לפני מחיקת חשבון או פרופיל, גבו הודעות מקומיות שלא סונכרנו, טיוטות, אנשי קשר ויומנים. אחר כך הגדירו שרתי IMAP ו-SMTP ופרטי כניסה חדשים, ונקו הגדרות ישנות רק כשצריך.

שתי הבדיקות הבאות נותנות מידע מועיל אך מוגבל:

dig MX example.com +short

dig TXT example.com +short

בדיקת TXT בדומיין הראשי אינה בודקת אוטומטית בוררי DKIM או DMARC. הדוגמה הבאה מיועדת למנהל Exchange מורשה ומציגה העברה ברמת תיבה, לא כללי תיבת דואר, כללי תעבורה, האצלה או כינויים; בדקו אותם בנפרד:

Get-Mailbox -ResultSize Unlimited |
  Select-Object DisplayName, ForwardingAddress, ForwardingSmtpAddress |
  Where-Object { $_.ForwardingAddress -ne $null -or $_.ForwardingSmtpAddress -ne $null }

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

השוואת עבודה מסורתית לניהול מרכזי

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

ההצעה המתוארת כוללת Free ב-$0, Starter החל מ-$3.50/mo, ולאחר מכן Pro, Agency ו-Enterprise לצרכים אחרים. Nano מתואר כחינמי ללא כרטיס. הניסיון החינמי של 14 ימים למסלולים בתשלום דורש כרטיס לפי התיאור. אמתו מחירים, מגבלות ותנאים כיום. המודל עשוי להתאים למי שמרבה להעביר דואר לחשבונות חדשים בכמה דומיינים.

חיבור תוכנות, SMTP ו-DNS אחרי ההעתקה

בדקו הגדרות IMAP ו-SMTP ואימות שליחה, והסירו DNS ישן רק כשמסלולים שתלויים בו הסתיימו. שמרו הרשאת SPF לכל שירותי השליחה שעדיין פועלים, כולל ישנים. הגדרה שנותרה יכולה לשבש את החוויה בלי להעיד שכל ההעתקה נכשלה.

TrekMail מתוארת כשירות IMAP ללא POP3. בדקו הגדרות עדכניות: שרת IMAP imap.trekmail.net ביציאה 993 עם TLS, ושרת SMTP smtp.trekmail.net ביציאה 465 עם TLS מרגע יצירת החיבור או 587 עם STARTTLS. אמתו תעודות שרת והשתמשו בכתובת התיבה המלאה ובסיסמתה, לא בסיסמת לוח הבקרה. ראו הגדרות IMAP ו-SMTP.

DNS שגוי עשוי לפגוע בזרימת הדואר. בדקו:

• הסירו MX ישן לאחר השלמת המעבר ומסלולי הקבלה שנותרו.
• מזגו מדיניות SPF לכל שם במקום לפרסם שתיים. רשומות TXT שאינן SPF יכולות להתקיים לצידה.
• בדקו DNS, אך אל תכריזו על סיום לפי סימונים ירוקים בלבד.
• בדקו קבלה, שליחה, תשובה, העברה והודעה עם קובץ מצורף.

דומיינים בבעלותכם, IMAP, catch-all, SMTP חיצוני ב-Nano או כלול במסלולים בתשלום, העברה אוטומטית, כלי העתקה ו-API הם תכונות מתוארות. בדקו זמינות, מגבלות ועלויות כיום; תיבה נוספת אינה בהכרח חינמית או ללא מגבלות.

תשובות קצרות על העברה לחשבון חדש

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

האם IMAP מעביר אנשי קשר ויומנים?
לא. יצאו וייבאו אותם בנפרד אם צריך.

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

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

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

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

סיכום

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

TrekMail מתארת IMAP לדומיינים בבעלותכם, אחסון משותף, העתקת דואר, העברה אוטומטית, catch-all, SMTP חיצוני ב-Nano או מנוהל בתשלום, ותמחור מסלולים החל מ-$3.50/mo. ראו תנאים עדכניים ב-מחירי TrekMail. גישה זו ל-העברת דואר לחשבונות חדשים ב-2025-2026 עשויה להפחית תיקונים לאחר המעבר, אך אינה מבטיחה למנוע שבוע של עבודת ניקוי.