העברת דוא"ל מ-Google Workspace ללא אובדן

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

המלכודת פשוטה: מנהלים מתמקדים בהעתקת הודעות ישנות ושוכחים את הניתוב. לדואר לא אכפת שההעברה הושלמה ב-92%. ברגע ש-MX משתנה, הודעות חדשות מגיעות למקום כלשהו. אם כינויים, קבוצות, DNS ולקוחות אינם מוכנים באותו רגע, נוצרות שתי מציאויות של תיבת דואר. המשתמשים ממשיכים לשלוח, הלקוחות לענות וחצי מהדואר מגיע למקום הלא נכון.

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

מה פירוש העברת דוא"ל מ-Google Workspace?

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

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

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

שלב 1: מיפוי מקיף לפני שמעתיקים

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

התחילו בארבע רשימות:

1. משתמשים ראשיים ונפחי התיבות שלהם.
2. כל הכינויים הקשורים לכל משתמש.
3. Google Groups שעדיין מקבלות דואר נכנס אמיתי.
4. העברות, catch-all וכתובות שיצאו משימוש אך עדיין מופיעות בחשבוניות, טפסים או חתימות.

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

מנהלים משתמשים לעיתים ב-GAM או Admin SDK כדי להוציא נתונים מ-Google ולבנות מפת ניתוב מלאה. הכלי המדויק פחות חשוב מהתוצאה: לכל כתובת צריך להיות מקום מפורש במערכת היעד לפני ההעברה.

gam print users aliases > aliases.csv
gam print groups members > group_members.csv

בזמן מיון הכתובות, החליטו מה תהיה כל זהות באחסון החדש:

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

שלב 2: הכינו נתונים מראש כי Google מגבילה IMAP

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

Google מפרסמת את מגבלות Gmail הבאות לחשבונות Workspace: הורדת IMAP של 2,500 MB ביום והעלאת IMAP של 500 MB ביום. אלה תנאים טכניים, לא המלצה. הורדת כל ההיסטוריה של תיבת 50 GB יכולה להימשך שבועות.

לכן הדפוס הנכון הוא:

1. להכין מראש דואר ישן בזמן שהמשתמשים עובדים ב-Google.
2. להריץ סנכרוני הפרשים בימים שלפני המעבר.
3. להעביר את הדואר החדש לאחר שינוי DNS או בחלון האחרון.

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

דוגמה: אם להנהלת החשבונות יש תיבה של 36 GB אך דרושים מיד רק 90 הימים האחרונים, יבאו קודם את התיקיות החדשות, שנו את זרימת הדואר והשלימו את הארכיון לאחר התייצבות המערכת.

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

שלב 3: שנו DNS פעם אחת ובסדר הנכון

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

הסדר הנקי פשוט בכוונה. יומיים לפני המעבר, הנמיכו TTL של MX, SPF ו-DMARC ל-300 שניות. יום אחד לפניו, פרסמו DKIM עבור ספק היעד. במעבר החליפו את MX של Google בזה של TrekMail. לאחר מכן אמתו הפצה דרך פותר ציבורי ולא דרך מטמון המחשב.

; Transitional SPF while some devices still send through Google
v=spf1 include:_spf.google.com include:spf.trekmail.net -all

dig @1.1.1.1 example.com MX +short

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

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

שלב 4: תקנו את הלקוחות, לא רק את הסיסמה

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

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

השתמשו בהגדרות הישירות של TrekMail:

Incoming server: imap.trekmail.net
Port: 993
Security: SSL/TLS
Username: full email address
Password: mailbox password

ב-iPhone וב-Android הסירו את חשבון Google הישן והוסיפו את התיבה כ-Other או IMAP. ב-Outlook למחשב צרו פרופיל חדש במקום לתקן את הישן. מדריכי TrekMail מכסים הגדרות IMAP/SMTP, וניתן לשלב אותם עם מדריך imapsync למסלול ידני.

TrekMail היא אחסון IMAP המבוסס על תקנים. ללא POP3 ובלי להעמיד פנים שהיא Exchange. אם מכשיר או משתמש מתעקש על תהליך Google או Microsoft קנייני, תבזבזו זמן על הפרוטוקול הלא נכון.

שלב 5: אמתו לפי ספירות ושמרו על חזרה פשוטה

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

רשימת הבדיקה המינימלית:

1. ספירות התיקיות קרובות מספיק בכל תיבה קריטית.
2. בדיקות נכנסות מגיעות רק ל-TrekMail לאחר הפצת MX.
3. דואר יוצא עובר בדיקות SPF, DKIM ו-DMARC.
4. כינויים וכתובות משותפות מוסרים בדיוק ליעד הצפוי.
5. משתמשים נכנסים במחשב ובטלפון עם ההגדרות החדשות.

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

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

הדרך הישנה מול החדשה: מדוע מפעילים בוחרים TrekMail

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

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

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

כדי להעביר דוא"ל מ-Google Workspace בלי להפוך את סוף השבוע למצב חירום, התחילו בתמחור TrekMail. בנו קודם את היעד, הכינו את הדואר, שנו DNS פעם אחת ואז אמתו כמו מפעילים.