שלבים להעברת דואר אלקטרוני: לוח זמנים יומי ללא השבתה מיותרת
העברת דואר אלקטרוני אינה רק העתקת קבצים. זהו מעבר מצב בין שני מסדי נתונים פעילים בזמן שהמשתמשים משנים נתונים. אם שכבת הנתונים (IMAP) ושכבת הניתוב (DNS) אינן מתואמות, נוצר ניתוב מפוצל: חלק מהארגון מקבל דואר בשרת הישן וחלקו בשרת החדש.
מדריך זה מפרט את סדר הביצוע יום אחר יום, מ-T-7 עד T+1. לרקע הטכני קראו את המדריך המלא להגדרת דואר אלקטרוני.
שלוש השכבות שיש לנהל
כל העברת דואר כוללת שלוש שכבות. תקלה בכל אחת מהן עלולה לגרום להשבתה.
- שכבת הנתונים: דואר היסטורי (IMAP)
- שכבת הניתוב: רשומות DNS מסוג MX שקובעות לאן יגיע דואר חדש
- שכבת הזהות: הגדרות הלקוח ב-Outlook וביישומים ניידים שדרכם ניגשים לדואר
T-7 ימים: מיפוי וניקוי
אי אפשר להעביר את מה שלא ידוע שקיים. רשימת משתמשים אינה מצאי מלא. השלבים הראשונים האלה חושפים את התמונה כולה.
מיפוי של כל הרכיבים
- מפו כל סוג רכיב: תיבות דואר, כינויים, רשימות תפוצה ותיקיות ציבוריות.
- אתרו את התיבות הגדולות: חפשו תיבות שגודלן עולה על 20 GB. Google מגבילה הורדות IMAP לכ-2,500 MB/day. העברה של תיבה בנפח 50 GB עלולה להימשך שבועות, לא שעות. המדריך להעברת נתונים ב-Google Workspace מפרט את המגבלות האלה.
- נקו נתונים לא פעילים: עובדים לשעבר אינם זקוקים לתיבה פעילה. יצאו את הדואר שלהם לארכיונים מקומיים.
בהעברה מ-Exchange, השתמשו ב-PowerShell כדי לקבל את מספר הפריטים בפועל. הנפח ב-GB אינו בסיס אמין להשוואה בגלל דחיסה:
Get-Mailbox -ResultSize Unlimited | Get-MailboxStatistics | Select-Object DisplayName, ItemCount, TotalItemSize | Sort-Object TotalItemSize -Descending
T-2 ימים: סנכרון מקדים
אל תחכו לערב יום שישי. העבירו 90% מהנתונים ההיסטוריים בזמן שהמשתמשים עדיין עובדים. טעינה מקדימה זו מפחיתה משמעותית את הסיכון בזמן המעבר.
הפעלת הסנכרון
הגדירו את כלי ההעברה, או את imapsync, להעברת דואר שגילו עולה על 30 ימים. עקבו אחר שגיאות HTTP 429 (יותר מדי בקשות) ושגיאות Google 11001.
מגבלות קצב חשובות
| ספק | מגבלת הורדה | מגבלת העלאה |
|---|---|---|
| Google Workspace | ~2,500 MB ליום למשתמש | ~500 MB ליום למשתמש |
| Microsoft 365 | ~20 GB ליום למשתמש | משתנה |
| cPanel/Plesk | ללא מגבלה קשיחה, תלוי ברוחב הפס | ללא מגבלה קשיחה |
אזהרה לגבי Gmail: אל תעבירו את התיקייה All Mail לצד כל תווית כאילו הייתה תיקייה נפרדת. תוויות Gmail מפנות לאותן הודעות, ומיפוי שגוי של תוויות לתיקיות עלול ליצור כפילויות ביעד. מפו את התוויות בזהירות והחריגו את Gmail/All Mail בתרחיש הזה.
T-1 יום: הורדת TTL וכלל 300 השניות
רשומות DNS נשמרות לעיתים קרובות במטמון למשך 24 שעות (TTL 86,400). הורדת TTL היא אחד השלבים שהכי קל לדלג עליהם ולהצטער אחר כך. ללא הורדה מראש, פותרי DNS מסוימים עשויים להמשיך לנתב לשרת הישן לאחר שינוי ה-MX עד שתוקף המטמון שלהם יפוג.
- היכנסו לספק ה-DNS, כגון Cloudflare או Route53.
- אתרו את רשומות ה-MX.
- שנו את ה-TTL ל-300 שניות (5 דקות).
- אל תמחקו את הרשומות הישנות, אלא עדכנו רק את ה-TTL.
אמתו באמצעות dig:
dig +nocmd +noall +answer example.com MX
# Output should show 300 in the TTL column
T-0, ערב יום שישי: המעבר
המשתמשים הפסיקו לעבוד. כעת יש לבצע את השלבים הקריטיים ביותר בהעברה.
שלב 1: הקפאת שינויים
בקשו מהמשתמשים להפסיק לשלוח דואר. אם אפשר, נעלו את חשבונות המקור כדי למנוע הודעות מנותקות.
שלב 2: סנכרון דלתא
הפעילו שוב את כלי ההעברה. סבב זה מעביר את 30 הימים האחרונים ואת כל הפריטים החדשים. מאחר שרוב הנתונים כבר הועברו, הוא אמור להיות קצר מהטעינה המקדימה, אך משכו בפועל תלוי בנפח ובמגבלות הספק.
שימו לב לבעיות UIDVALIDITY: אם שרת המקור אינדקס מחדש את התיקיות, הכלי עלול להוריד הודעות כפולות. התחילו בהרצת ניסיון. IMAP RFC 3501 מסביר את המשמעות של UIDVALIDITY.
שלב 3: שינוי רשומות MX
עדכנו את רשומות ה-MX כך שיפנו לספק החדש. עבור TrekMail:
10 mx1.trekmail.net
20 mx2.trekmail.net
כאשר ה-TTL הוא 300 שניות, מטמונים שמכבדים אותו עשויים להתעדכן בתוך כ-5 דקות, אך המטמונים ופותרי ה-DNS קובעים את משך הזמן בפועל.
שלב 4: עדכון SPF ו-DKIM
פרסמו ואמתו ב-SPF את ההרשאה לכתובות ה-IP השולחות החדשות לפני שהספק החדש מתחיל לשלוח. השאירו מקורות שליחה ישנים מורשים כל עוד הם עדיין שולחים דואר. קראו את המדריך שלנו בנושא הגדרת אימות דואר בדומיין.
T+1, יום שני בבוקר: אימות
השלבים האחרונים עוסקים באימות. אל תניחו שההעברה הצליחה, ודאו זאת.
השוואת מספרי הפריטים
השוו את מספר הפריטים במקור וביעד. פער קטן מ-1% עשוי להיות מוסבר, לעיתים בגלל פריטי MIME פגומים. פער גדול מ-5% עשוי להצביע על בעיה מערכתית, כגון עומק תיקיות או מסנן שגוי. אלה ספי בדיקה תפעוליים ולא הבטחה לשלמות ההעברה.
הגדרה מחדש של לקוחות הדואר
יש להעביר את לקוחות הדואר לחשבון החדש. לפעמים אפשר להתאים בבטחה פרופיל קיים, ובמקרים אחרים אמין יותר למחוק אותו ולהוסיף מחדש את החשבון.
יומנים ואנשי קשר
TrekMail מספקת אירוח דואר מקצועי לעסקים ומארחת יומנים באמצעות CalDAV ואנשי קשר באמצעות CardDAV. עם זאת, העברת IMAP אינה מעבירה אותם, אלא רק דואר ותיקיות נתמכים. יצאו יומנים בפורמט .ics ואנשי קשר בפורמט .vcf מהספק הישן, ולאחר מכן יבאו אותם אל TrekMail. לבסוף ודאו את הסנכרון בכל מכשיר.
נקודות ביקורת להחלטת המשך או עצירה
| נקודת ביקורת | בדיקה | קריטריון הצלחה |
|---|---|---|
| Gate 1 (Pre-Sync) | האם תיבות בנפח >20 GB מסונכרנות ב-90% לפחות? | כן |
| Gate 2 (TTL) | האם ה-MX TTL נשאר למשך 24 שעות לפחות בערך 300s? | כן |
| Gate 3 (Delta) | האם סנכרון הדלתא האחרון תועד ללא שגיאות קריטיות? | כן |
| Gate 4 (Routing) | האם הודעת בדיקה חיצונית מגיעה לתיבה החדשה? | כן |
תוכנית החזרה לאחור
אם המערכת החדשה דוחה דואר או אם חסרים נתונים קריטיים:
- החזירו את ה-MX: הפנו את ה-MX בחזרה לספק הישן. עם TTL של 300s השינוי עשוי להיראות במהירות, אך 5 דקות אינן מובטחות.
- יצאו את הפער: השאירו את הספק החדש נגיש וחזרו על ההתאמה עד לפקיעת מטמוני DNS, ואז יצאו כל דואר שמגיע אליו בפורמט EML/MBOX ויבאו אותו לשרת הישן.
- אבחון: בדקו שגיאת
550 5.7.1(Relay Access Denied) וחסימות חומת אש לפני ניסיון נוסף.
TrekMail הופכת את שלבי ההעברה האלה לאוטומטיים
העברה ידנית כרוכה בסיכון. TrekMail הופכת חלקים מהתשתית לאוטומטיים כדי שתוכלו להתמקד בלקוחות.
לעסקים קטנים
כלי ההעברה המובנה מנהל את חיבור ה-IMAP, הניסיונות החוזרים ומגבלות הקצב עבור דואר ותיקיות נתמכים. הזינו את פרטי הכניסה, עקבו אחר העברת הדואר, ולאחר מכן בצעו התאמה סופית של המספרים מול המקור.
לסוכנויות ולספקי שירות מנוהל
הגדרה בכמות גדולה עבור 100+ דומיינים. אחסון משותף לכל הלקוחות במקום מגבלות לכל משתמש. SMTP מנוהל ללא תהליך עצמאי לחימום כתובות IP.
| תוכנית | מחיר | כלי העברה | שימוש מתאים |
|---|---|---|---|
| Free | $0 (no card) | כלול | בדיקות ושימוש אישי |
| Starter | $3.50/mo | כלול | צוותים קטנים |
| Pro | $10/mo | כלול | עסקים בצמיחה |
| Agency | $23.25/mo | כלול + פעולות בכמות גדולה | ספקי שירות מנוהל וסוכנויות |
כל התוכניות בתשלום כוללות תקופת ניסיון חינם של 14 ימים ודורשות כרטיס. תוכנית Nano אינה דורשת כרטיס.
סיכום
לוח הזמנים הזה פועל בסדר קבוע מפני שכל שלב תלוי בקודמו. אם מדלגים על הורדת ה-TTL, הניתוב עלול להישאר מפוצל עד 24 שעות. ללא טעינה מקדימה, חלון המעבר עלול להתארך הרבה מעבר לצפוי.
פעלו לפי לוח הזמנים, השוו את מספרי הפריטים ושמרו תוכנית החזרה מוכנה. זו תמצית השיטה.
מוכנים להתחיל? צרו חשבון TrekMail חינמי והשתמשו במנוע ההעברה המובנה כדי לצמצם את העבודה הידנית.
