העברת אימייל בדומיין מותאם אישית מ-cPanel מעבירה תיבות דואר מספק cPanel בחבילה (Bluehost, HostGator, Hostinger או שירות דומה) לספק תיבות מתמחה, תוך ניסיון למנוע אובדן דואר נכנס בזמן המעבר. המפתח הוא קבלה מקבילה: מגדירים את הספק החדש בזמן שהישן עדיין מקבל, ואז מחליפים את רשומות MX עם DNS TTL נמוך כדי שחלון המעבר יימשך דקות ולא שעות.
רוב מדריכי ההעברה מדלגים על קבלה מקבילה ומתארים מעבר קר שעלול לאבד דואר במהלך התפשטות DNS. מעבר קר מאבד בדרך כלל 10-50 הודעות, בהתאם לנפח הנכנס. הגישה המקבילה שלהלן נועדה למנוע זאת. ההגדרה הנוספת נמשכת 30 דקות, ועשויה להיות משתלמת ביחס לאובדן שנמנע.
המדריך עובר על המעבר בשישה שלבים עם קטעי קוד של רשומות DNS. למסגרת הרחבה יותר, ראו העברת אימייל לספק חדש.
למה העברת cPanel מסודרת חשובה
העברה מסודרת חשובה משום שדואר שנמצא בתנועה בזמן התפשטות DNS יוצר סיכון ממשי להכנסות. במעבר קר עם התפשטות שנמשכת שעות, הודעות שמגיעות ל-MX הישן לאחר שהפסיק לקבל עלולות ללכת לאיבוד. רוב המפעילים מגלים את העלות רק כשלקוח מתלונן.
גישת ששת השלבים שלהלן נמנעת מחלון אובדן הדואר באמצעות קבלה מקבילה: הספק הישן והחדש מקבלים בו זמנית במהלך המעבר, והמפעיל מפעיל ידנית את ההשבתה רק לאחר שאישר שכל הדואר שבתנועה טופל. המשמעת הנוספת דורשת 30 דקות הגדרה ועשויה למנוע אובדן שקשה להעריך מראש.
המעבר בשישה שלבים במבט אחד
שישה שלבים מכסים את העברת האימייל מ-cPanel עם קבלה מקבילה. הסדר חשוב: הפלט של כל שלב מאפשר את הבא. הזמן הכולל מהנמכת TTL ועד השבתה מלאה הוא כשבוע; העבודה הפעילה היא כ-3-4 שעות הפרוסות על פני השבוע.
- הנמיכו DNS TTL 48 שעות מראש. כך זמן התפשטות MX במעבר מתקצר משעות לדקות.
- הכינו תיבות אצל הספק החדש. צרו תיבות תואמות אצל הספק החדש והשאירו את הישנות פעילות.
- העתיקו דואר היסטורי דרך IMAP. כלי העברה בצד השרת מעתיק דואר קיים מהתיבות הישנות לחדשות.
- החליפו את רשומות MX. עדכנו את DNS כך שיפנה לספק החדש; בזמן ההתפשטות שניהם מקבלים.
- אמתו אותנטיקציה ובדיקת הלוך ושוב. ודאו ש-SPF, DKIM ו-DMARC עוברים אצל שלושה נמענים.
- הוציאו את התיבות הישנות משימוש. המתינו 48-72 שעות לאחר החלפת MX וכבו אותן לאחר שהדואר שבתנועה טופל.
לכל שלב יש נקודת ביקורת, ואפשר לחזור לאחור באופן פשוט עד שלב 4. לאחר שלב 4, החלפת MX, עדיין אפשר לחזור אך העלות התפעולית גבוהה יותר משום שדואר מתחיל להצטבר אצל הספק החדש. אם שלבים 1-3 בוצעו כראוי, הסבירות לצורך בחזרה במעבר רגיל נמוכה.
שלב 1: הנמכת DNS TTL 48 שעות מראש
הנמיכו את DNS TTL ברשומות MX הקיימות 48 שעות לפני המעבר המתוכנן. ברירת המחדל היא בדרך כלל 3600 שניות (1 שעה) או 86400 (24 שעות). הגדירו 300 שניות (5 דקות), כדי שהחלפת MX בשלב 4 תתפשט בדקות ולא בשעות.
השינוי מתבצע בלוח הבקרה של ספק ה-DNS. ערכו את ערך TTL בכל רשומת MX ל-300 ושמרו. המתינו 48 שעות עד שתוקף ה-TTL הנוכחי יסתיים והערך הנמוך יתפשט. לאחר שלב 6, העלו את TTL חזרה ל-3600 לפעילות רגילה. דוגמה לשינוי רשומה ב-Cloudflare:
; before: MX record with default TTL
yourcompany.com. 3600 IN MX 10 mail.oldhost.example.com.
; after: MX record with low TTL for migration window
yourcompany.com. 300 IN MX 10 mail.oldhost.example.com.
שלב 2: הכנת תיבות אצל הספק החדש
הכינו תיבות תואמות אצל הספק החדש. הוסיפו את הדומיין ל-TrekMail, אמתו בעלות באמצעות רשומת TXT וצרו תיבה תואמת לכל כתובת אצל ספק cPanel הישן. בשלב זה התיבות אצל הספק החדש מוכנות, אך MX עדיין מפנה לישן.
הפיקו את ערכי SPF, DKIM ו-DMARC שמספק הספק החדש. אל תפרסמו אותם עדיין; זה יקרה בשלב 4 לצד החלפת MX. הפקה מראש מבטיחה שהערכים יהיו מוכנים בהגיע שלב 4. ההכנה המוקדמת היא שמאפשרת קבלה מקבילה בהמשך. לפרטים על כלי ההעברה, ראו העברת IMAP.
שלב 3: העתקת דואר היסטורי דרך IMAP
השתמשו בכלי העברת IMAP של הספק החדש כדי להעתיק דואר היסטורי מתיבות cPanel הישנות לחדשות. הכלי בצד השרת של TrekMail (Starter ומעלה) עושה זאת מלוח הבקרה: מספקים את פרטי הכניסה ל-IMAP של הספק הישן ומניחים לו להעתיק תיקייה אחר תיקייה במשך כמה שעות.
ההעברה פועלת ברקע בזמן ש-MX עדיין מפנה לספק הישן. הישן ממשיך לקבל דואר חדש, ולחדש יש עותק היסטורי. בסיום, לשניהם אותו מבנה תיקיות ואותן הודעות, בדיוק המצב הדרוש למעבר בקבלה מקבילה בשלב 4. לגיליון עבודה מסודר, ראו רשימת בדיקה להעברת אימייל.
שלב 4: החלפת רשומות MX
השלב הרביעי מעדכן את רשומות MX אצל ספק ה-DNS כך שיפנו לספק התיבות החדש. פרסמו את ערכי MX החדשים ואת רשומות SPF, DKIM ו-DMARC משלב 2. התפשטות DNS נמשכת כ-5 דקות בזכות TTL הנמוך משלב 1. במהלך החלון שני הספקים מקבלים במקביל.
; new MX records pointing at TrekMail
yourcompany.com. 300 IN MX 10 mx1.trekmail.net.
yourcompany.com. 300 IN MX 20 mx2.trekmail.net.
; published SPF, DKIM, DMARC TXT records
yourcompany.com. 300 IN TXT "v=spf1 include:_spf.trekmail.net ~all"
trekmail._domainkey.yourcompany.com. 300 IN TXT "v=DKIM1; k=rsa; p=..."
_dmarc.yourcompany.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com"
חלון הקבלה המקבילה נועד למנוע אובדן דואר. הודעה שנשלחת בזמן ההתפשטות מגיעה לספק הישן שעדיין פעיל או לחדש שזה עתה הופעל, וכך קטן הסיכוי להחזרה. השאירו את התיבות הישנות פעילות ונגישות לפחות 48 שעות לאחר החלפת MX כדי לקלוט דואר שנותר בתנועה.
שלב 5: אימות אותנטיקציה ובדיקת הלוך ושוב
אמתו את האותנטיקציה בדואר יוצא מהספק החדש. שלחו הודעות בדיקה מכל תיבה חדשה לחשבונות Gmail, Outlook.com ו-Yahoo. ודאו שבכותרות מופיעים SPF=PASS, DKIM=PASS ו-DMARC=PASS אצל שלושתם. כל FAIL משמעו שהרשומות שפורסמו בשלב 4 דורשות התאמה לפני שהמעבר ייחשב שלם.
ודאו גם שהדואר מגיע כראוי לספק החדש. שלחו הודעה מכתובת חיצונית לאחת התיבות החדשות ואשרו שהיא מגיעה לתיבת הדואר הנכנס החדשה בתוך כמה דקות. אם היא מגיעה לישן, התפשטות DNS טרם הסתיימה; המתינו עוד 10-15 דקות ובדקו שוב.
שלב 6: הוצאת התיבות הישנות משימוש
הוציאו את התיבות הישנות משימוש 48-72 שעות לאחר החלפת MX. בשלב זה התפשטות DNS אמורה להסתיים ברחבי העולם, ושולחים אינם אמורים לנתב עוד ל-MX הישן. השביתו את התיבות הישנות בלוח cPanel; אם האתר זקוק לכך, השאירו את תוכנית האחסון פעילה אך כבו קבלת דואר.
אם ספק cPanel מארח גם את האתר ואינכם רוצים להמשיך לשלם לו, זה הזמן להעביר את האתר לספק אחסון נפרד. ההעברה מסתיימת לאחר שהדואר הישן הושבת והספק החדש מקבל כראוי במשך כמה ימים. העלו את DNS TTL חזרה ל-3600 שניות לפעילות רגילה.
הצעדים הבאים
העברת אימייל בדומיין מותאם אישית מ-cPanel עם קבלה מקבילה נמשכת כשבוע ודורשת 3-4 שעות עבודה פעילה. המטרה היא מעבר מסודר לספק תיבות מתמחה, עם אותנטיקציה תקינה בכל הודעה יוצאת והפחתת הסיכון לאובדן דואר.
אפשר לחזור על מסגרת ששת השלבים: החילו אותה באותה דרך על כל דומיין cPanel נוסף, והתהליך עשוי להתקצר בכל חזרה.
אפשר לבדוק את TrekMail Nano בחינם דרך trekmail.net/pricing, ללא כרטיס. Starter במחיר $4 לחודש כוללת את כלי העברת IMAP בצד השרת שנדרש בשלב 3. הפלטפורמה מטפלת בעבודת התפעול של התיבות שבחבילת cPanel נותרה באחריותכם.
הערה תפעולית אחת: חלון הקבלה המקבילה בשלב 4 הוא הסיבה המבנית לכך שהגישה נועדה למנוע אובדן דואר. מעבר קר מאבד הודעות בגלל פער בין עצירת הספק הישן לתחילת קבלה עולמית אצל החדש, שבמהלכו הודעות חוזרות. קבלה מקבילה מצמצמת את הפער באמצעות שמירת שני הספקים פעילים בזמן ההתפשטות.
העברת אימייל בדומיין מותאם אישית מ-cPanel עשויה להיות פשוטה תפעולית מכפי שרוב המפעילים מצפים. החשש מתקלה בדואר מעכב לעיתים את המעבר בחודשים, בזמן שעלויות המסירה של ספק cPanel בחבילה עלולות להצטבר. גישת ששת השלבים מפחיתה את סיכון אובדן הדואר שגורם לעיכוב, ולכן מעבר נוסף עשוי להרגיש מוכר יותר.
למפעילים שמנהלים כמה דומיינים מותאמים אישית אצל ספקי cPanel, תבנית ההעברה חלה על כל דומיין: אותם שישה שלבים עם ערכי DNS שונים בכל פעם. תכננו מעברים בימים נפרדים ולא במקביל. תשומת הלב הנדרשת בכל העברה קטנה אך ממשית; מעברים בזה אחר זה יוצרים עומס קוגניטיבי מיותר ומגדילים את הסיכוי לדילוג על שלב.