ما الذي يتعطل فعلياً عند ترحيل Google Workspace (وكيف تفحصه قبل يوم الانتقال)

معظم مشاريع Workspace التي تسوء لا تفشل عند أداة الترحيل. تفشل لأن توجيه البريد ومصادقة النطاق والهوية عولجت كقائمة في اللحظة الأخيرة. فيما يلي التسلسل الذي نراجعه مع مسؤولي تقنية المعلومات في دبي والمملكة المتحدة وأفريقيا قبل نقل أي صندوق بريد.

وجّه MX إلى Google كما توثّقه Google اليوم

سجل MX الحالي لـ Google Workspace هو smtp.google.com بأولوية 1. الأدلة القديمة ما زالت تذكر aspmx.l.google.com والنسخ الاحتياطية ASPMX2 وASPMX3. ما زالت تعمل، لكن البيئات الجديدة يجب أن تتبع مقالة مساعدة المشرف الحالية. خفّض TTL على سجلات MX القائمة قبل 24 إلى 48 ساعة من النافذة حتى لا ينتظر التراجع تخزيناً مؤقتاً لساعات.

• انشر SPF بالصيغة include:_spf.google.com مع الإبقاء على أي مرسلين خارجيين ما زلت تستخدمهم.
• فعّل DKIM في وحدة تحكم المشرف واستخدم مفتاح 2048 بت. Google ما زالت تقبل 1024 بت، و2048 هو ما توصي به.
• ضع سياسة DMARC يمكنك العيش معها في اليوم الأول. p=none مناسبة للمراقبة. لا تنتقل إلى p=reject قبل أسبوع من التقارير.

الهوية قبل صناديق البريد

حدّد مصدر الحقيقة: دليل Google السحابي أو Microsoft Entra ID أو نظام HR/LDAP آخر. إذا كنت تزامن من Entra فاختبر وحدة تنظيمية غير إنتاجية أولاً. أكّد البريد الأساسي والأسماء المستعارة والمجموعات ومحركات الأقراص المشتركة قبل الموجة الأولى. حسابات المشرف الاحتياطية يجب أن تبقى خارج مسار المزامنة حتى لا يحبسك انقطاع الدليل خارج وحدة التحكم.

تعايش مشترك، لا أمل في انتقال دفعة واحدة

إذا بقي Exchange أو نظام بريد آخر أسبوعاً أو أكثر، يجب تصميم التسليم المزدوج أو إعادة التوجيه. إعادة التوجيه غير المصادق عليها طريقة شائعة لإفشال SPF والوصول إلى البريد المزعج. قسّم المستخدمين حسب الإدارات لا حسب من يتطوّع. صناديق البريد الكبيرة والمفوّضون وتقويمات الموارد تستحق موجة مستقلة بوقت اختبار إضافي.

اكتب خطة التراجع على الورق

احتفظ بقيم MX السابقة وTTL واسم من يستطيع تغيير DNS في ملاحظة واحدة. إذا لم يصل البريد بعد الانتقال يجب أن تستطيع الرجوع خلال دقائق لا بالبحث في المحادثات. يحتاج المستخدمون صفحة أسئلة شائعة: عنوان الويب الجديد وخطوات الجوال وأين يطلبون المساعدة. هذا المستند يمنع نصف تذاكر اليوم الأول.