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

העברת דואר למארח חדש תוך צמצום ההפרעה

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

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

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

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

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

לוח זמנים בן 4 שלבים להעברת דואר

שלב	מועד	פעולה	מטרה
הכנה מוקדמת	T-7 ימים	סנכרון הודעות שגילן עולה על 30 יום דרך IMAP	העברת 90% מהאחסון בלי עומס חריג על רוחב הפס
הנמכת TTL	T-48 שעות	הנמכת TTL של MX ו-SPF ל-300 שניות	צמצום משך מטמון DNS המקובל סביב המעבר
מעבר	זמן T (שישי בערב)	עדכון רשומות MX למארח החדש	ניתוב דואר נכנס חדש לשרת החדש
סנכרון שינויים	T+1 שעה	סנכרון פריטים אחרונים (30 הימים האחרונים)	קליטת דואר שהגיע לשרת הישן במהלך המעבר

שלב 1: הפצת DNS וכלל 300 השניות

ניתוב מפוצל, שבו חלק מהשולחים מגיעים לשרת הישן ואחרים לחדש, נגרם מערכי TTL ארוכים ברשומות DNS. פותרנים רקורסיביים שומרים רשומות MX במטמון לפי TTL, אם כי מטמונים מסוימים עשויים להתנהג אחרת. ערך TTL נפוץ הוא 86,400 שניות (24 שעות). אם מחליפים את רשומות MX בלי להנמיך אותו מראש, דואר עלול להמשיך להגיע לשרת הישן זמן רב לאחר המעבר. לכן יש להכין תחילה את TTL לפני שמעבירים דואר למארח חדש.

התהליך פשוט: בודקים את ערך TTL הנוכחי, מנמיכים את TTL של MX ושל SPF ל-300 שניות, ואז ממתינים במשך ערך TTL המקורי לפני שעושים דבר נוסף. דילוג על ההמתנה משאיר סיכון שרשומות ישנות עדיין שמורות במטמון. ערך זה הוא גבול עליון מנחה למטמונים שמכבדים TTL, ולא הבטחה שכל פותרן בעולם יתעדכן בתוך 5 דקות.

מלכודת 10 הבדיקות של SPF

במהלך ההעברה ייתכן שתרצו להוסיף את הוראת include של ספק SPF החדש לצד הישנה. יש להיזהר. RFC 7208 מגביל את SPF ל-10 בדיקות DNS. שילוב של כמה ספקים, למשל Google, Outlook והמארח החדש, עובר לעיתים קרובות את הגבול ועלול לגרום ל-PermError ולכשלי מסירה. יש לשטח את רשומת SPF רק אם קיים מנגנון אמין לעדכן אותה בכל שינוי בטווחי IP נתמכים. אחרת, אפשר להסיר זמנית כלי שיווק שאינם חיוניים במהלך המעבר. להסבר נוסף קראו את המדריך להגדרת SPF.

שלב 2: סנכרון נתונים ב-IMAP

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

בעיית תיבת הרפאים של Gmail

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

הגבלת קצב וקודי שגיאה

במהלך העברת הדואר למארח החדש יש לצפות לכך ששרת המקור יגביל חיבורים או תעבורה. Google עשויה להחזיר שגיאות חיבור 11001/11002 כאשר גישת IMAP מושבתת או חסומה בחומת אש. שגיאות HTTP 429 מצביעות בדרך כלל על הגבלת קצב. ספקים מסוימים עשויים להחיל סף כגון 2 GB/hour/user, אך המגבלה בפועל משתנה בין שירותים וחשבונות. השתמשו בכלי העברה עם השהיה מעריכית שמזהה הגבלות ועוצר אוטומטית.

שלב 3: ההשפעה על תוכנות הדואר

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

אי התאמה בתעודה: אם Outlook נשאר פתוח בזמן החלפת DNS, הוא עשוי להתחבר אל mail.yourdomain.com, שמצביע כעת למארח החדש, באמצעות פרטי הכניסה הישנים. בעקבות זאת עלולות להופיע אזהרות על תעודת SSL/TLS. מומלץ להנחות את המשתמשים להפעיל מחדש את תוכנת הדואר ביום שני בבוקר ולבדוק את הגדרות השרת אם האזהרה נמשכת.

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

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

חזרה לאחור: תוכנית הגנה ל-15 הדקות הראשונות

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

כיצד TrekMail מפשטת את המעבר

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

תוכנית	מחיר	מתאימה במיוחד עבור
Free	$0	בדיקות ודומיינים אישיים (ללא צורך בכרטיס)
Starter	$3.50/mo	עסק קטן ודומיין יחיד
Pro	$10/mo	כמה דומיינים ומשתמשים מתקדמים
Agency	$23.25/mo	ספקי שירות מנוהל שמעבירים 50+ דומיינים של לקוחות עם אחסון משותף

כל התוכניות בתשלום כוללות תקופת ניסיון של 14 יום (נדרש כרטיס). תוכנית Nano אינה דורשת כרטיס כלל.

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

לסוכנויות שמעבירות בקביעות עשרות דומיינים בבת אחת למארח דואר חדש, TrekMail מציעה אחסון משותף (הקצאת 200 GB בין כל הדומיינים), SMTP מנוהל עם מוניטין IP שהוכן מראש, והקמה מתבניות שמאפשרת להחיל במהירות הגדרות DNS והעברה על עד 100 דומיינים.

סיכום: העברת דואר ללא חור שחור

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

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