העברת דוא״ל תוך צמצום אובדן נתונים והשבתה

איך להעביר דוא״ל בלי לאבד נתונים או לסבול השבתה

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

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

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

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

מטמון DNS: אם לא מורידים TTL לפני המעבר, דואר עשוי להגיע לשרתים הישן והחדש עד 24 שעות.
הגבלת קצב: ספקים כמו Google עשויים להגביל הורדות IMAP לכ-2,500 MB/יום. בהגעה למגבלה הסנכרון נעצר.
התרחבות היקף: IMAP מעביר דוא״ל בלבד. לוחות שנה ואנשי קשר משתמשים בפרוטוקולים אחרים כמו CalDAV/CardDAV ואינם עוברים אוטומטית.

שלב 1: ביקורת טכנית (T-minus 7 ימים)

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

מיפוי זהויות נסתרות

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

• כינויים: האם john@ מקבל גם דואר עבור sales@? אם הכינוי חסר במארח החדש, חלק מהדואר עלול לחזור.
• רשימות תפוצה: האם team@ ו-info@ הן תיבות משותפות או קבוצות העברה?
• העברות: בדקו כללים בצד השרת. כללים נסתרים לחשבונות Gmail אישיים יישברו אם לא יוקמו מחדש בבטחה.

זיהוי תיבות גדולות

חפשו תיבות מעל 10 GB. IMAP מרבה בתקשורת, ותיבה של 50 GB לא תסתיים בשעה. Microsoft 365 עשויה להגביל לאחר כ-20 GB/יום. סמנו משתמשים אלה לסנכרון מוקדם שמתחיל לפחות 5 ימים לפני המעבר. מדריך העברת הנתונים של Google Workspace מתעד מגבלות עדכניות.

בדיקת מציאות של דוא״ל בלבד

כלי העברה, כולל imapsync והמנוע המובנה של TrekMail, משתמשים בפרוטוקול IMAP ‏(RFC 3501). IMAP מעביר דוא״ל בלבד.

לוחות שנה ואנשי קשר אינם קיימים ב-IMAP. הם משתמשים בפורמטים או בפרוטוקולים כמו Exchange ו-CalDAV. הורו למשתמשים לייצא לוחות שנה כ-.ics ואנשי קשר כ-.vcf או .csv באופן מקומי לפני ביטול המנוי הישן, ובדקו יבוא בנפרד.

שלב 2: הכנת תשתית (T-minus 48 שעות)

אל תיגעו עדיין בנתונים. הכינו קודם את התשתית כדי שהיעד יהיה מוכן.

כלל 300 השניות ל-DNS TTL

לרשומות DNS יש Time To Live ‏(TTL) שמגדיר כמה זמן כתובת נשמרת במטמון. אם ברירת המחדל היא 86,400 שניות (24 שעות), שינוי ביום שישי עשוי להשאיר את השרת הישן במטמון עד שבת.

היכנסו לספק DNS כמו Cloudflare, GoDaddy או Route53 והגדירו TTL של רשומת MX ל-300 שניות. עשו זאת לפחות 24 שעות לפני המעבר אם הספק מאפשר.

הקמת היעד

צרו תיבות אצל הספק החדש. משתמשי TrekMail יכולים להגדיר דומיינים ומשתמשים בלוח הבקרה. בתוכנית Nano, בדקו יכולות עדכניות והגדירו מראש אישורי BYO SMTP עבור SES/Mailgun כדי להכין שליחה לאחר המעבר.

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

שלב 3: אסטרטגיית סנכרון מוקדם

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

צעד 1: מעבר היסטורי (T-minus 3 ימים)

הגדירו את הכלי לסנכרן דוא״ל ישן מ-7 ימים. הדבר עשוי להעביר כ-95% מהנפח בזמן שהמשתמשים עובדים. אם קובץ של 2 GB נכשל, יש ימים לחקור במקום שעות.

עקבו אחר HTTP 429 או שגיאות הגבלת משתמש. אם הן מופיעות, צמצמו העברות במקביל, למשל 5 משתמשים במקום 50, לפי מגבלות הספק.

צעד 2: הקפאה (T-zero, שישי בערב)

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

צעד 3: סנכרון דלתא

הפעילו שוב את הכלי. המעבר אוסף את 7 הימים האחרונים וכל מה שהשתנה בשלב המוקדם. מכיוון שכ-95% עשויים להיות כבר ביעד, הוא יכול להסתיים מהר יותר בהתאם לנפח ולמגבלות.

שלב 4: המעבר

החלפת רשומות MX

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

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

אימות SPF ו-DKIM

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

• SPF: עדכנו את רשומת TXT. דוגמה: v=spf1 include:spf.trekmail.net -all
• DKIM: צרו מפתחות בלוח הספק החדש והוסיפו את רשומות CNAME/TXT הנדרשות ל-DNS.

להדרכה מפורטת, ראו הגדרת דוא״ל בדומיין.

בדיקת המערכת הישנה

אם עוזבים Google Workspace אך שומרים חשבון עבור Drive/Docs, Google עשויה עדיין לתפוס דואר פנימי במקום לנתבו ל-MX החדש. השביתו Gmail למשתמשים הרלוונטיים או הגדירו split delivery לפי תיעוד עדכני.

שלב 5: אימות

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

מספר פריטים, לא רק גודל

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

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

היררכיית תיקיות

בדקו שלא בוצעה השטחה. עצים עמוקים כמו Clients/2024/Project A/Invoices/Paid עלולים להיחתך. שימו לב גם להבדלי namespace כמו INBOX.Sent מול Sent.

פתרון כשלים נפוצים

מנוע ההעברה המובנה של TrekMail

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

לעסקים קטנים (1-50 משתמשים)

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

לסוכנויות (100+ דומיינים)

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

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

סיכום: להעביר דוא״ל נכון

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

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