نقل استضافة بريد النطاق: قائمة تحويل DNS

يمكن نقل استضافة بريد النطاق مع الاحتفاظ بالعناوين بعد إعداد الصناديق والأسماء البديلة في الهدف. قد يضر تعديل DNS خاطئ بالتدفق. نسخ البيانات وتحويل DNS مهمتان منفصلتان؛ سوء التنسيق قد يؤدي إلى الرفض أو الاستقبال في نظامين.

للتخطيط الشامل ابدأ بدليل البريد للأعمال. نركز هنا على استضافة نطاق تملكه وتديره، لا نقل تسجيل النطاق أو عنوان مزود شخصي. راجع MX وSPF وDKIM وDMARC مع استمرار العمل في المصدر.

جهز الصناديق ثم انسخ البيانات، واخفض TTL مبكرا وانشر المصادقة الجديدة قبل تحويل الاستقبال. تقل المخاطر بهذا الترتيب والتحقق، دون ضمان انعدام الانقطاع.

ما معنى نقل استضافة بريد النطاق؟

تحتفظ بالنطاق وتعيد إعداد العناوين المصرح بها على مستضيف جديد، ثم تغير الاستقبال ومصادقة الإرسال عند الحاجة. توقيت DNS والاعتماديات القديمة والمصادقة غير المطابقة للمرسل تحتاج فحصا مثل نسخ الصندوق.

توجد عادة ثلاث مهام:

1. نسخ البيانات إلى صناديق هدف منشأة مسبقا؛ لذا يجب تنفيذ إعداد الهدف في البند التالي قبل النسخ فعليا.
2. إعداد الصناديق والأسماء البديلة والتوجيه نفسها في الهدف والتحقق منها.
3. تحويل استقبال النطاق المدار عبر DNS إلى المزود الجديد.

لا تحول MX إلا بعد جاهزية الهدف وفحص النسخة. وإلا قد يرفض البريد أو يحفظ في المكان الخطأ. نسيان SPF أو DKIM يؤثر في المصادقة، لكن المعاملة النهائية يحددها المستقبل لا رفض تلقائي أو وصول للمزعج.

قسم العمل إلى إعداد وتحويل واستقرار. يصف TrekMail استيراد IMAP من Gmail وOutlook وYahoo وiCloud ومصادر أخرى في Starter وما فوق. ينسخ IMAP الرسائل والحالة المدعومة لا جهات الاتصال أو التقويمات أو قواعد الحساب. تحقق من الدعم والدخول المسموح الحاليين؛ المستورد المباشر لا يقدم OAuth تفاعليا، وكلمة مرور التطبيق تعتمد على التحقق وسياسة المزود، وقد تحتاج أداة أخرى مدعومة. للمزيد اقرأ imapsync.

المرحلة 1: الاستعداد قبل التحويل بـ 24-48 ساعة

أنشئ الهدف وانشر المصادقة واخفض TTL وانسخ مع استمرار المصدر. الفترة المذكورة مثال للتخطيط لا ضمان لتحديث كل ذاكرة مؤقتة.

1. خفض TTL لسجلات البريد الحالية

قد تناسب قيمة 300 ثانية إذا سمح المزود. نافذة 24-48 ساعة توضيحية؛ احسب TTL السابق والذاكرة الفعلية. التعديل قبل خمس دقائق لا يمحو الإجابات المخزنة.

dig example.com MX

dig example.com TXT

dig example.com TXT _dmarc.example.com

إذا كان TTL السابق 3600 أو 86400 فقد تبقى الإجابة حتى تنقضي صلاحيتها. ابدأ مبكرا لا يوم الجمعة عند 4:55 PM. الأمر الأخير ليس استعلام DMARC مستقلا موثوقا، وTXT الجذري لا يفحص محددات DKIM كلها. افحص الأسماء الصحيحة منفصلة في خوادم DNS المعتمدة للنطاق والمحللات ذات الصلة.

2. نسخ بيانات الصناديق قبل تغيير MX

شغل IMAP مع بقاء المصدر متاحا. تكتب أداة TrekMail الموصوفة في صندوق هدف موجود مسبقا في الخلفية. اختبر الدخول والحصة ونسخة تجريبية قبل التوسع.

أضف النطاق دون تحويل الاستقبال مبكرا وأنشئ الهدف ثم اتبع بدء الاستيراد في اللوحة. يوصف TrekMail بأنه IMAP دون POP3. POP ليس خطأ بذاته، لكن رسائله المحلية قد لا تكون في الخادم؛ احتفظ بنسخة منها أولا.

3. إعداد كل هويات الهدف

أنشئ الصناديق والأسماء البديلة والتوجيه وcatch-all قبل التحويل. افحص إذن المالك والسياسة والمسار الفعلي حتى للحالات النادرة.

مثال: billing@ وsupport@ وcareers@ وnoreply@ وصندوق catch-all وتوجيه قديم إلى Gmail المؤسس. قد لا يظهر نسيان أحدها حتى تصل رسالة إلى ذلك العنوان.

قد تفيد الإدارة المركزية للعلامات ونطاقات العملاء ضمن شروط الخطط. اقرأ استضافة البريد لعدة نطاقات إذا كان الحجم هو التحدي.

4. دمج خدمات SPF قبل النقل

قد تستمر أنظمة قديمة في إرسال ردود أو رسائل آلية مشروعة. احتفظ بتفويض الخدمات المستخدمة فعلا للهوية التي يختبرها SPF. وفق RFC 7208، الحد 10 يخص الآليات والمعدلات التي تستلزم DNS أثناء التقييم، بما فيها التداخل، لا كل حزم الشبكة أو عدد الإجابات المخزنة.

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

راجع المثال وفق مزوديك الفعليين؛ لا تفوض Google دون استخدام مشروع. توصف Free بـ SMTP خارجي والخطط المدفوعة بـ SMTP مدار، لكن تحقق من المسار والشروط. انشر سياسة SPF واحدة لكل اسم DNS، مع السماح بسجلات TXT غير المرتبطة بها.

5. نشر DKIM مبكرا وتقييم DMARC

اختر محددا جديدا وانشر المفتاح قبل توقيع النظام الجديد، دون استبدال القديم أثناء استمرار توقيعه. التخفيف المؤقت إلى p=none قرار مخاطرة يوافق عليه المالك فقط؛ يمكن إبقاء الإنفاذ إذا كانت المصادقة والمطابقة صحيحتين. سياسة المراقبة لا تضمن القبول ولا تلغي كل خطر.

انتبه للذاكرة السلبية: قد يخزن غياب محدد لم ينشر بعد وفق قواعد SOA الموضحة في RFC 2308. انشر مبكرا وافحص الإجابات؛ خفض TTL لسجل آخر لا يمحو ذلك الغياب المخزن.

المرحلة 2: تحويل استضافة البريد

تحقق من السجلات المعدة في DNS المعتمد للنطاق، ثم غير MX بعد جاهزية الهدف والنسخة. افحص محللات خارجية والاستقبال والإرسال الفعليين. المدة تعتمد على البيئة.

اقتصر على التغييرات اللازمة. تنظيف DNS غير المرتبط في الوقت نفسه قد يصعب التشخيص والرجوع.

1. التأكد من جاهزية المزود

افحص حالة النطاق والمصادقة الممكن نشرها قبل MX. Active والعلامات الخضراء لا تثبت تجربة بريد كاملة وقد لا تكتمل قبل التحويل. راجع إضافة نطاق إلى TrekMail. يعرض وصف مارس 2026 المثال الآتي؛ تحقق من قيم الحساب والسياسة الحالية:

MX   @              mail.trekmail.net.   priority 10
TXT  @              v=spf1 include:spf.trekmail.net -all
TXT  dkim._domainkey  [unique value from dashboard]
TXT  _dmarc         v=DMARC1; p=quarantine;

استبدل MX القديم لـ Google Workspace أو Microsoft 365 أو Zoho أو cPanel أو المسجل وقت التحويل المخطط. يعمل MX المختلط بالأولوية والبديل لا بتقسيم متساو ثابت؛ إذا قبل المستضيفان فقد تصل الرسائل إلى نظامين مختلفين.

2. تغيير MX مع إبقاء TTL منخفضا مؤقتا

استبدل مجموعة MX النشطة للنطاق المدار بالجديدة. قد تناسب قيمة 300 مؤقتا لكن الذاكرة السابقة وإعادة SMTP تظل مهمة. احتفظ باستقبال المصدر ومزامنة تغييرات متكررة.

dig @8.8.8.8 example.com MX

dig @1.1.1.1 example.com MX

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

3. مراجعة برامج IMAP

تحقق من الإعدادات الحالية: IMAP imap.trekmail.net على المنفذ 993 مع TLS، وSMTP smtp.trekmail.net على 465 مع TLS الضمني أو 587 مع STARTTLS. افحص سلسلة الشهادات واسم المضيف، واستخدم عنوان الصندوق الكامل وكلمة مروره لا كلمة مرور اللوحة. راجع إعدادات IMAP وSMTP للبرامج.

«أرسل ولا أستقبل» لا يثبت خطأ DNS. افحص الصندوق والأسماء البديلة والحصة والفلاتر وربط المجلدات والذاكرة والبرنامج والشبكة مع الاختبارات والسجلات.

المرحلة 3: مراقبة أول 72 ساعة بعد النقل

أول 72 ساعة مثال للرصد لا موعد اكتمال. تابع الاستقبال والمصادقة والطرق القديمة، وكرر التغييرات للرسائل المتأخرة بتواريخ قديمة والنقل بين المجلدات والعلامات المدعومة. أبق استقبال SMTP في الخادم القديم ومزامنة الإدارة والرجوع حتى الإنهاء المتحقق منه.

قد يبدو التحويل منتهيا بعد عشر دقائق وتظهر استثناءات بعد أيام. راجع أيضا المهام الأقل تكرارا.

1. البحث عن مرور عبر المزود القديم

قد تستمر CRM والماسحات ونماذج WordPress والفوترة والدعم في المسار القديم. افحص الرؤوس والسجلات وعدل الربط قبل تقليل التفويض أو تشديد السياسة.

2. مراقبة المصادقة والمطابقة

قبول الخادم لا يثبت نجاح المصادقة أو وصولا للوارد. افحص نتائج استقبال موثوقة لرسائل فعلية. قد يفشل SPF عند التوجيه ومع ذلك ينجح DMARC بتوقيع DKIM صحيح ومتوافق مع From الظاهر، أو SPF ناجح ومتوافق.

للتوجيه الخارجي المتبقي اقرأ توجيه بريد النطاق إلى Gmail وافحص أثره في مسارك.

3. إنهاء التداخل بعد التحقق

احذف تفويض SPF القديم عندما لا تعود الخدمة مرسلا مشروعا. أبق سجلات DKIM القديمة ما دامت الرسائل في الطوابير أو قيد التسليم أو المعاد توجيهها قد تحتاج مفاتيحها العامة للتحقق. يمكن رفع TTL إلى 3600 بعد الاستقرار. إذا اخترت p=none مؤقتا فراجع الإنفاذ بالجرد والاختبار وخطة الرجوع.

التنظيف جزء من النقل لكن انقضاء مدة ثابتة لا يثبت أمان حذف المصادقة القديمة.

مقارنة العمل التقليدي بالتحويل المضبوط

تغيير استضافة البريد ليس نقل تسجيل النطاق. جهز الهدف والنسخة ثم حول الاستقبال واختبر المصادقة. قد تساعد الأدوات في كشف الخطأ لكنها لا تغني عن التحقق.

يصف TrekMail نطاقات خاصة وIMAP وcatch-all وSMTP خارجيا على Nano أو متضمنا في الخطط المدفوعة وتوجيها ونقلا وAPI. السعر الموصوف Starter من $3.50 شهريا مع Free وStarter وPro وAgency وEnterprise. راجع الميزات والحدود والشروط الحالية في أسعار TrekMail؛ نموذج الخطة ليس توسعا غير محدود تلقائيا.

القائمة النهائية لنقل بريد النطاق

أنشئ الهدف واخفض TTL مبكرا وانسخ البيانات وادمج SPF وانشر DKIM. قيّم DMARC وحول MX عند الحاجة ثم اختبر البريد. نظف بعد التحقق ومزامنة التغييرات المتبقية.

1. استخدم 24-48 ساعة كمثال للتخطيط مع صلاحية الذاكرة القديمة.
2. انسخ IMAP إلى صناديق هدف منشأة ومختبرة مسبقا.
3. جهز الصناديق والأسماء والتوجيه وcatch-all وتحقق قبل التحويل.
4. ادمج الخدمات المستخدمة في سياسة SPF واحدة لكل اسم.
5. انشر محدد DKIM جديدا واختبر التوقيع.
6. اختر p=none مؤقتا فقط بإذن وحسب المخاطر؛ لا يلزم التخفيف التلقائي.
7. افحص حالة النطاق والاستقبال والإرسال الفعليين.
8. استبدل MX النشط للنطاق المدار في موعد التحويل.
9. اختبر الرسائل الواردة والصادرة وكرر مزامنة التغييرات.
10. بعد 72 ساعة راجع التقدم، لكن لا تحذف المصادقة أو تشدد السياسة إلا إذا دعم التحقق ذلك.

تعامل مع الانتقال كتغيير بنية مضبوط لا تعديل بسيط. يقل الخطر دون ضمان استمرارية مطلقة. لإدارة ما بعد النقل يمكنك مراجعة استضافة TrekMail متعددة النطاقات والتخزين المشترك وIMAP الموصوفة ضمن الشروط الحالية.