- الرئيسية
- الحلول
- لماذا Klytic
- الأدلة
- الأسعار
- الشركاء
- اتصل بنا
-
-
تعمل منصتان بالتوازي.
تأتي الثغرة المعتادة من تحويل سجل MX بينما النسخ غير مكتمل، أو من جهاز نسخ أو موقع ويب أو نظام CRM لا يزال يرسل بالمعرف القديم.
سجل MX هو سجل DNS: يحدد للخوادم المرسلة أين تسلم بريد نطاقكم. وتغيير البريد الإلكتروني المهني هو أولا تغيير عنوان التسليم هذا. أما الباقي (الحسابات، والسجل التاريخي، والأجهزة) فيحضر حوله.
يتحمل بروتوكول SMTP الحوادث القصيرة جيدا. فالخادم المرسل الذي يتلقى خطأ مؤقتا يحتفظ بالرسالة في قائمة الانتظار ويعيد المحاولة لاحقا. لذلك فإن تعذر الوصول إلى خادم لبعض الوقت لا يؤدي إلى فقدان البريد. في المقابل، يؤدي الخطأ النهائي (صندوق غير معروف، رسالة مرفوضة) إلى إعادة الرسالة إلى مرسلها، ولن تصل هذه الرسالة من تلقاء نفسها أبدا. الخطر الرئيسي في التحويل ليس العطل، بل المنصة الجديدة التي ترفض مستلما لأن اسما مستعارا أو قائمة لم يعد إنشاؤها.
يحدد TTL (مدة الصلاحية) المدة التي يمكن فيها لمحلل DNS أن يحتفظ بإجابة في ذاكرته. وخلال هذه المدة، يواصل جزء من المرسلين التسليم إلى المنصة القديمة. هذا أمر طبيعي، ولهذا يجب أن تظل المنصة القديمة قادرة على الاستقبال خلال المرحلة الانتقالية.
قبل أسبوعين. جرد صناديق البريد والأسماء المستعارة والقوائم والصناديق المشتركة، وجميع التطبيقات التي ترسل البريد. خفض قيمة TTL لسجل MX في DNS إلى قيمة قصيرة (غالبا 300 ثانية)، حتى ينتشر التغيير بسرعة يوم التحويل. إنشاء الحسابات على المنصة الهدف. النسخة الأولى من السجل التاريخي.
يخفض TTL مبكرا لأن المحلل الذي قرأ القيمة القديمة يحتفظ بها حتى انقضائها: فلا يسري TTL القصير إلا بعد انتهاء صلاحية الذاكرة المؤقتة القديمة. أما النسخة الأولى فهي الأطول؛ وإطلاقها مبكرا يتيح الوقت لاكتشاف الصناديق التي تطرح مشكلات.
قبل بضعة أيام. فحص عينة: عدد الرسائل، والمجلدات أو التصنيفات، والمواعيد، وجهات الاتصال. تصحيح الطريقة إذا فشلت العينة. إعداد أدلة الاستخدام للهواتف المحمولة وOutlook. اختبار الإرسال من المنصة الهدف إلى Gmail وOutlook.com، مع سجلات SPF وDKIM وDMARC صالحة مسبقا على المنصة الجديدة. ويمكن نشر هذه السجلات قبل سجل MX.
عمليا: سجل SPF واحد يأذن للمنصتين خلال المرحلة الانتقالية (فوجود سجلين منفصلين لـSPF يفشل التحقق)، ومفتاح DKIM للمنصة الجديدة منشور تحت محدده (selector) الخاص، إلى جانب المفتاح القديم، وسياسة DMARC تمت مراجعتها. يشترط DMARC أن تكون الرسالة موثقة عبر SPF أو DKIM باسم نطاق المرسل؛ فإذا كانت سياستكم صارمة ولم يؤذن بعد للمنصة الهدف، فإن مراسليكم سيرفضون رسائلكم.
عشية التحويل. التمريرة الثانية: نسخ ما وصل منذ النسخة الأولى فقط. تجميد تغييرات الأسماء المستعارة والقوائم.
يوم التحويل. تحويل سجل MX. تحقق خارجي فوري: يجب أن تصل رسالة مرسلة من صندوق شخصي خارجي إلى المنصة الجديدة في حدود مدة TTL. مراقبة قائمة الانتظار. إعادة ضبط التطبيقات المرسلة. دعم داخلي محدد، مع صلاحية إعادة سجل MX إلى وضعه السابق إذا فشل تدفق حرج.
غيروا في الوقت نفسه سجل autodiscover إن وجد: فهو الذي يستعلم عنه Outlook للعثور على خادمه. واحذفوا أيضا سجلات MX الثانوية التي قد لا تزال تشير إلى المنصة القديمة: فالمرسل الذي لا يتمكن من الوصول إلى سجل MX الرئيسي يجرب السجلات التالية.
الأيام التالية. المنصة القديمة في وضع القراءة. رفع الفروقات (مجلد مفقود، صندوق مشترك). تمريرة ثالثة موجهة عند الحاجة. ثم إغلاق الإرسال من المنصة القديمة، حتى لا يرد موظف من مكانين.
لهذه النقطة الأخيرة سبب تقني. فالمنصة القديمة لا تزال تعتبر نفسها مسؤولة عن نطاقكم: والرسالة المرسلة منها إلى زميل تسلم فيها محليا، دون الرجوع إلى سجل MX. ولن يراها الزميل أبدا في صندوقه الجديد.
| الخطر | ما يحدث | الحل |
|---|---|---|
| تحويل سجل MX مبكرا جدا | يصل البريد الجديد، ويغيب السجل التاريخي | التحويل بعد فحص العينة والتمريرة الثانية |
| نسيان اسم مستعار أو قائمة | ترفض المنصة الهدف هذه الرسائل نهائيا | الجرد، وتجميد الأسماء المستعارة عشية التحويل، واختبار العناوين الجماعية |
| سجلات SPF أو DKIM أو DMARC غير مكتملة | ترفض رسائلكم أو تصنف بريدا غير مرغوب فيه لدى المراسلين | النشر قبل يوم التحويل، والتحقق على رسالة حقيقية |
| تطبيق يرسل بالحساب القديم | لم تعد الفواتير أو التنبيهات أو المستندات الممسوحة ضوئيا ترسل | قائمة التطبيقات، وضبط خادم SMTP الجديد يوم التحويل |
| بقاء الإرسال مفتوحا على المنصة القديمة | تبقى رسائل داخلية في النظام القديم | إغلاق الإرسال فور اعتماد العينة |
| تراجع غير محضر | يعود سجل MX إلى وضعه السابق، لكن الرسائل المستلمة في الأثناء تبقى على المنصة الهدف | خطة مكتوبة، تشمل استعادة هذه الرسائل |
لنأخذ، على سبيل التوضيح، مكتبا من 40 شخصا. يختار التحويل يوم خميس في نهاية اليوم بدلا من يوم جمعة: ففي اليوم التالي يكون الفريق حاضرا لمعالجة الفروقات، ويكون أمام الدعم الداخلي يوم عمل كامل. ويعاد ضبط جهاز النسخ في الاستقبال، الذي يمسح المستندات ضوئيا ويرسلها بالبريد، في المساء نفسه. وإذا أبلغ صندوقان مشتركان عن مجلد مفقود، تكملهما تمريرة موجهة. في هذا السيناريو، لا تضيع أي رسالة، لكن عدة موظفين يضطرون إلى إعادة إعداد حسابهم على الهاتف: وهذا هو الجزء الظاهر الذي ينبغي الإعلان عنه.
يغيرون الخادم في Outlook أو على الهاتف المحمول. ويستغرق التحميل الأول لصندوق كبير وقتا. وقد تتكرر الرسائل المخزنة مؤقتا على الهاتف إذا لم يعد إنشاء الملف الشخصي بطريقة سليمة. خططوا لإجراء «حذف الحساب وإعادة إنشائه» بدلا من ترقيع إعدادات الخادم.
والسبب نفسه ينطبق على Outlook: فالملف الشخصي يحتفظ بذاكرة مؤقتة محلية مرتبطة بالخادم القديم. والملف الشخصي الجديد ينطلق من حالة نظيفة؛ أما الملف القديم المعدل فيخلط بين العالمين. وعلى الهاتف المحمول، يتغير أحيانا البروتوكول المستخدم (Exchange ActiveSync أو IMAP بحسب المنصة الهدف) مع المنصة، وهذا سبب إضافي لإعادة إنشاء الحساب.
يعاد ضبط القواعد على مستوى الخادم، والتوقيعات المركزية، وصلاحيات التفويض. أعلنوا ذلك. فهذا ليس انقطاعا للبريد. إنه عمل إداري.
تتطلب إعادة التوجيه هذه إعدادا صريحا: فالمنصة القديمة، التي لا تزال تعتقد أنها تستضيف الصناديق، يجب ضبطها لتمرير الرسائل إلى المنصة الجديدة بدلا من تسليمها لديها. وإلا فإن تمريرة استدراك موجهة تؤدي العمل نفسه.
الخصائص المتعلقة بكل نقطة انطلاق موصوفة في الترحيل من Microsoft 365 والترحيل من Google Workspace.
الوقت اللازم للتحقق من أنه لم يعد أي تدفق يستخدم المنصة القديمة، ومن معالجة الفروقات المبلغ عنها. ويتوقف ذلك على عدد الصناديق، والتطبيقات المرسلة، ووتيرة إعادة ضبط أجهزة العمل. الإغلاق المبكر جدا يمنع التصحيح؛ والإغلاق المتأخر جدا يترك موظفين يعملون في نظامين.
لا، إذا تم التحضير له. فخلال مدة TTL، يواصل جزء من المرسلين التسليم إلى المنصة القديمة، والجزء الآخر إلى الجديدة. كلتاهما تستقبلان، والتمريرة التالية تجمع بينهما. ولا يضيع البريد إلا إذا رفض، ومن هنا أهمية الأسماء المستعارة والقوائم.
في الغالب، لا: فالعناوين لا تتغير. لكن أخطروا الشركاء الذين يخضعون رسائلكم لتصفية صارمة أو الذين خصصوا لكم قاعدة معينة، وكذلك الذين يتبادلون معكم بريدا مشفرا، إذا تغيرت المفاتيح.
نعم، بإعادة سجل MX القديم، شريطة أن تكون المنصة القديمة لا تزال نشطة. ويجب حينئذ إعادة نسخ الرسائل التي استقبلتها المنصة الجديدة في الأثناء أو إبقاؤها قابلة للاطلاع. وتحدد خطة التراجع من يقرر، وفي أي مدة، وكيف تستعاد هذه الرسائل.
اسألوا المشغّل عما يضمنه: وصول الرسائل، أو استعادة السجل التاريخي، أو كليهما. فهذه التزامات مختلفة. واطلبوا أيضا خطة التراجع، مكتوبة، مع الشخص المخول بتفعيلها.
الضمان المتعلق بوصول الرسائل يشمل يوم التحويل والأيام التالية. والضمان المتعلق بالسجل التاريخي يشمل النسخ وفحصه. وقد يفي مزود خدمة بأحدهما دون الآخر؛ ويجب أن يحدد عرض السعر أيهما يتكفل به وكيف يتم التحقق منه.
لدى Klytic، تقدم النصائح والاقتراحات لتحضير ترحيل البريد الإلكتروني المهني مجانا، ولا تضيع أي رسالة. ويحدد الترحيل الذي تنفذه Klytic بناء على عرض سعر. والاشتراكات معروضة في صفحة الأسعار وتفوتر بشكل منفصل. وتفاصيل بنود التكلفة في كم تكلف عملية ترحيل Microsoft 365، وقائمة النقاط الواجب التحقق منها في قائمة التحقق. ولمقارنة المنصات الهدف، انظروا اختيار بريد إلكتروني مهني أوروبي.
تصف هذه الصفحة طريقة عمل. ويتوقف السير الفعلي على تدفقاتكم، وأحجامكم، والمنصة التي تغادرونها.
تمت مراجعتها في أكتوبر 2026.
استشارة مجانية، دون ضياع أي رسالة. يُحدَّد سعر الترحيل الذي تنجزه Klytic بعرض سعر بعد الجرد.
عرض الترحيب
عرض تجريبي دون التزام. سيتصل بك مستشار لفهم احتياجاتك وتجهيز مساحة Klytic الخاصة بك.
