ترحيل البريد من 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 لاستخراج البيانات وبناء خريطة توجيه كاملة. الأداة أقل أهمية من النتيجة: يجب أن يملك كل عنوان مكانا صريحا في نظام الوجهة قبل الترحيل.

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

أثناء ترتيب العناوين، قرر ما الذي ستصبح عليه كل هوية:

لإطار قرار سريع، اقرأ الاسم المستعار لنطاق البريد أم صندوق البريد. هنا تبدأ أخطاء كثيرة.

المرحلة 2: جهّز البيانات لأن Google يقيّد IMAP

يحتاج أي حجم حقيقي إلى مرحلة تمهيدية. توثق Google حدود عرض نطاق IMAP اليومية للسحب والرفع لكل حساب. لن تنتهي الصناديق الكبيرة في عطلة واحدة مهما كان التفاؤل.

تنشر Google الحدود التالية لحسابات Workspace: تنزيل IMAP بمقدار 2,500 MB يوميا ورفع 500 MB يوميا. هذه حدود تقنية وليست اقتراحا. قد يستغرق سحب تاريخ صندوق بحجم 50 GB أسابيع.

لذلك النمط الصحيح هو:

1. تجهيز البريد القديم بينما يعمل المستخدمون في Google.
2. تشغيل مزامنة الفروق في الأيام السابقة للتحويل.
3. نقل البريد الأحدث بعد تغيير DNS أو في النافذة الأخيرة.

للمستخدمين ذوي الصناديق الكبيرة، قسّم المهمة حسب التاريخ عندما تسمح الأداة. يدعم مسار TrekMail الاستيراد المرحلي، مما يجعل الترحيل على دفعات أكثر عملية من سحب التاريخ كله مرة واحدة.

مثال: إذا كان لدى المحاسبة صندوق بحجم 36 GB لكنها تحتاج إلى آخر 90 يوما فورا، فاستورد المجلدات الحديثة، وحوّل تدفق البريد، ثم أكمل الأرشيف بعد استقرار الإنتاج.

إرشادات Google الحالية بشأن الدخول مهمة أيضا. انتهت المصادقة الأساسية القديمة في معظم الحالات، وبقيت كلمات مرور التطبيقات استثناء رئيسيا في الإعدادات المدعومة. توصي وثائق TrekMail لمصادر Gmail باستخدام كلمة مرور تطبيق بدلا من العادية عندما تفرض سياسة 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 مرة واحدة، ثم تحقق باحتراف.