نقل صندوق بريد إلى مزود جديد: دليل تحويل DNS
عند نقل بيانات صندوق بريد بين مزودي البريد، تفصل استراتيجية DNS بين انتقال منظم وانقطاع قد يستمر 48 ساعة. قد يؤدي خطأ واحد في TTL أو نسيان include في SPF إلى ارتداد نهائي وخسارة أعمال.
ليست هذه مهمة إبداعية، بل سلسلة عمليات تقنية دقيقة. يشرح الدليل نقل محتوى الصندوق بأمان عبر إدارة توقيت الانتشار ودمج هويات SPF وDKIM وDMARC وتوجيه البريد إلى المزود الجديد مع تقليل خطر فقد الرسائل.
أما نقل الرسائل نفسها فتناوله دليل مزامنة IMAP الكامل.
لماذا لا ينتشر DNS فورا عند نقل بيانات الصندوق؟
DNS نظام تخزين مؤقت موزع. عند تغيير سجل تعتمد على تطبيق كل محلل تكراري لقيمة Time-To-Live (TTL)، من خوادم مزود الإنترنت و8.8.8.8 من Google إلى الموجهات المحلية.
إذا بقي TTL عند القيمة المعتادة 86,400 ثانية (24 ساعة)، فقد ينقسم التوجيه يوما كاملا، فتصل رسائل إلى الصندوق الجديد وأخرى إلى القديم.
الذيل الطويل والتخزين السلبي
هناك عاملان خفيان يعطلان عمليات النقل بانتظام:
- الذيل الطويل: حتى مع TTL منخفض، يتجاهل نحو 1-5% من المحللات العالمية القيم الأقل من 60 دقيقة. توقع بعض الحركة إلى المزود القديم لنحو ساعة بعد التحويل.
- التخزين السلبي (SOA): إذا استعلمت عن سجل قبل وجوده، مثل محدد DKIM جديد، يخزن رد NXDOMAIN وفقا لأدنى TTL في SOA، وغالبا 1 ساعة. وقد يظل السجل الصحيح مخفيا مؤقتا بعد نشره.
المرحلة 1: العد التنازلي لمدة 48 ساعة
لا تغير سجلات MX بعد. جهز البيئة لقبول التغيير أولا.
الخطوة 1: خفض TTL (قبل 48 ساعة)
حدد سجلات MX وSPF (TXT) وDMARC، واخفض TTL إلى 300 ثانية (5 دقائق).
يقلص ذلك نافذة الانتشار المتوقعة التي قد تبلغ 24 ساعة، لكنه لا يضمن تحديث كل المحللات خلال 5 دقائق.
dig yourdomain.com MX
# Look for 300 in the TTL column
الخطوة 2: دمج SPF (قبل 24 ساعة)
يمنح SPF (RFC 7208) عناوين IP صلاحية الإرسال باسم نطاقك. أثناء الانتقال يجب السماح للمزودين معا.
المشكلة: يقتصر SPF على 10 عمليات بحث DNS. وقد يؤدي دمج مزودين، مثل Google Workspace وTrekMail، إلى تجاوز الحد.
الحل: استبدل عبارات include: المتداخلة بآليات ip4: مباشرة فقط عبر وسيلة مدعومة تحافظ على تحديث العناوين، وإلا ستتقادم قيم IP.
مثال لسجل الانتقال:
v=spf1 include:_spf.google.com include:spf.trekmail.net -all
إذا كنت تستخدم BYO SMTP من TrekMail عبر Amazon SES أو SendGrid، فأدرج سجلات SPF الخاصة بالخدمة.
الخطوة 3: النشر المسبق لـ DKIM
يستخدم DKIM محددات مثل google._domainkey. أنشئ مفاتيح المزود الجديد بمحدد فريد مثل tm1._domainkey. لا تعد استخدام اسم محدد، إذ يمكن نشر المحدد الجديد قبل أيام من دون تعارض مع القديم.
الخطوة 4: تخفيف DMARC
إذا كانت سياسة DMARC هي p=reject أو p=quarantine، فغيرها إلى p=none قبل التحويل بما لا يقل عن 24 ساعة. قد تحدث أخطاء مصادقة في الساعات الأولى. يسجل p=none الأخطاء في تقارير RUA ولا يرفضها بناء على DMARC، لكنه لا يضمن تجاوز مرشحات التسليم الأخرى. يوضح دليل Google لإعداد DMARC الضبط الصحيح.
المرحلة 2: تنفيذ التحويل
بعد خفض TTL ودمج المصادقة، يحين نقل توجيه الصندوق إلى المضيف الجديد.
الخطوة 1: مقارنة الخادم الموثوق بالمحلل التكراري
تحقق من ظهور السجلات الجديدة على خادم الأسماء الموثوق قبل فحصها عالميا:
# Check authoritative nameserver
dig @ns1.provider.com yourdomain.com MX
# Check public recursive resolver
dig @8.8.8.8 yourdomain.com MX
الخطوة 2: تحديث سجلات MX
أضف سجلات MX الجديدة وتحقق منها قبل حذف القديمة إن أمكن، أو بدّلها في تعديل واحد. يستخدم عملاء TrekMail:
10 mx1.trekmail.net
20 mx2.trekmail.net
أبق TTL عند 300 ثانية ولا ترفعه بعد.
الخطوة 3: مسح الذاكرة والتحقق
امسح ذاكرة DNS المحلية باستخدام ipconfig /flushdns على Windows أو sudo dscacheutil -flushcache على macOS. شغل dig مجددا. هذا يمسح الذاكرة المحلية فقط ولا يسرع تحديث المحللات الخارجية.
المرحلة 3: الاستقرار بعد التحويل
راقب أخطاء إسناد المستأجر (550 5.7.64)
هذا فشل شائع عند النقل إلى Microsoft 365 أو خدمات مشابهة. إذا لم يجهز المزود الوجهة نطاقك بالكامل في دليله الداخلي، فقد يرفض البريد برسالة Relay Access Denied. تأكد قبل تبديل MX من أن حالة النطاق Verified أو Healthy.
راقب تقارير DMARC (72 ساعة)
تابع تقارير RUA مدة ثلاثة أيام:
- نجاح: تجتاز حركة عناوين IP للمزود الجديد SPF وDKIM.
- فشل: تفشل حركة شرعية من أنظمة الفوترة أو التسويق في المصادقة. حدّث SPF أو DKIM فورا.
التنظيف (بعد 72 ساعة)
بعد استقرار الحركة:
- أزل
include:للمزود القديم من SPF بعد التأكد من توقفه عن الإرسال. - أزل سجلات DKIM القديمة من CNAME/TXT بعد مهلة آمنة للتحقق من الرسائل الموقعة سابقا.
- ارفع TTL إلى 3,600s (1 ساعة) أو 86,400s (24 ساعة).
- أعد فرض DMARC باستخدام
p=quarantineأوp=reject.
ملخص قائمة نقل صندوق البريد
| التوقيت | الإجراء | نوع السجل |
|---|---|---|
| T-48h | خفض TTL إلى 300s | MX, SPF, DMARC |
| T-24h | دمج SPF والسماح للمزودين | TXT |
| T-24h | نشر محدد DKIM الجديد مسبقا | CNAME/TXT |
| T-24h | تخفيف DMARC إلى p=none | TXT |
| T-0 | نقل توجيه الصندوق بتبديل MX | MX |
| T-0 | إبقاء المزودين في SPF حتى يتوقف القديم عن الإرسال | TXT |
| T+72h | تنظيف DNS القديم بأمان وفرض DMARC | الكل |
يبسط TrekMail عملية نقل الصندوق
الإدارة اليدوية لـ DNS معرضة للأخطاء. خطأ صياغة واحد في TXT قد يبطل سياسة SPF كاملة.
للشركات الصغيرة
يقدم TrekMail فحص صحة DNS لحظيا. يستعلم النظام من خوادم الأسماء الموثوقة ويتحقق من MX وSPF وسجلات DKIM مقابل القيم المطلوبة. يمكنه كشف أخطاء الصياغة قبل أن تسبب ارتدادا، لكنه لا يضمن اكتمال الانتشار لدى كل محلل خارجي.
تعرف على إعداد البريد على نطاقك.
للوكالات
تتطلب إدارة 50+ نطاقا توحيدا. يتيح TrekMail تطبيق قالب DNS متسق على بيئات العملاء. في خطتي Starter وAgency، يدير Managed SMTP سمعة IP وترويسات التسليم، فلا يلزم لذلك المسار تسطيح SPF المعقد أو جدول إحماء IP خاص.
راجع استضافة البريد متعددة النطاقات للوكالات.
| الخطة | السعر | فحص صحة DNS | Managed SMTP |
|---|---|---|---|
| Free | $0 (no card) | نعم | خدمة خاصة فقط |
| Starter | $3.50/mo | نعم | مضمن |
| Pro | $10/mo | نعم | مضمن |
| Agency | $23.25/mo | نعم | مضمن + إدارة سمعة IP |
تأتي كل الخطط المدفوعة مع تجربة مجانية لمدة 14 يوما وتتطلب بطاقة. لا تحتاج خطة Nano إلى بطاقة.
الخلاصة
عند نقل بيانات صندوق البريد إلى مزود جديد، تقع المشكلات غالبا في تحويل DNS. اخفض TTL مبكرا، وادمج سجلات المصادقة، وبدل MX خلال نافذة صيانة، وراقب تقارير DMARC مدة 72 ساعة. هذا هو مسار العمل.
إذا فضلت تجنب إدارة DNS يدويا، جرب TrekMail مجانا ودع لوحة التحكم تتحقق من الإعدادات.
