چگونه ایمیل‌ها را هنگام تغییر HOST منتقل کنیم؟

پرونده‌ای که این مقاله را به من الهام داد، فروشگاهی ووکامرسی با چند ده هزار سفارش بود که صاحبش با اطمینان گفت فقط فایل‌ها را منتقل کنیم. دو روز بعد تماس گرفت که از صبح هیچ ایمیلی نمی‌آید. مشکل جای دیگری بود؛ نه در فایل‌ها، نه در دیتابیس، بلکه در یک رکورد MX که سال‌ها پیش در پنل قدیمی به‌جای دامنه اصلی روی یک زیردامنه تنظیم شده بود. آن روز یک قاعده در ذهنم تثبیت شد: انتقال ایمیل هنگام تغییر هاست، به‌مراتب حساس‌تر از خود مهاجرت سایت است، چون ایمیل برخلاف فایل و دیتابیس یک داده زنده است که در لحظه، هم در سرور قدیم و هم در سرور جدید ممکن است خوانده یا نوشته شود.

چرا انتقال ایمیل از مهاجرت فایل‌ها حساس‌تر است؟

وقتی سایت را به هاست جدید منتقل می‌کنید، معمولاً دو نوع داده دارید: فایل‌های استاتیک و دیتابیس. هر دو را می‌توان با یک بکاپ کامل به سرور جدید منتقل کرد، و پس از آن هر چه کاربر می‌بیند همان چیزی است که در سرور جدید نشسته. اما ایمیل این‌طور نیست. ایمیل یک سیستم توزیع‌شده است که در آن چند لایه هم‌زمان نقش بازی می‌کنند: سرور فرستنده، رکورد MX دامنه، سرور گیرنده، صندوق پستی کاربر و در نهایت کلاینت (Outlook، Thunderbird یا webmail). هر یک از این لایه‌ها می‌توانند منبع خرابی باشند و اگر هم‌زمان با مهاجرت هاست به‌درستی مدیریت نشوند، پیام‌ها در یک بازه‌ی مشخص گم می‌شوند یا به صندوقی می‌روند که دیگر کسی آن را نمی‌بیند.

چیزی که کار را پیچیده‌تر می‌کند این است که برخلاف مهاجرت دیتابیس، در مورد ایمیل نمی‌توان یک بکاپ ساده گرفت و روی سرور مقصد ریستور کرد. فایل‌های صندوق پستی هر سرور، ساختار داخلی خودشان را دارند؛ Maildir در یک سرور با ساختار پیش‌فرض cPanel با Maildir سرور دیگر، حداقل در سطح متادیتا متفاوت است. به همین دلیل، روش‌های استاندارد انتقال ایمیل تقریباً همیشه از لایه‌ی پروتکل IMAP (Internet Message Access Protocol) استفاده می‌کنند، نه از لایه‌ی فایل. همین موضوع، مهاجرت ایمیل را به یک فرایند شبکه‌ای و زمان‌بندی‌شده تبدیل می‌کند که باید با دقت برنامه‌ریزی شود.

در عمل، سه آسیب کلاسیک در مهاجرت‌های بی‌دقت تکرار می‌شود. نخست، بازه‌ی پروپاگیشن DNS: بین لحظه‌ای که رکورد MX را تغییر می‌دهید تا لحظه‌ای که تمام سرورهای DNS دنیا نسخه‌ی جدید را می‌بینند، ممکن است بین چند دقیقه تا چهل‌وهشت ساعت طول بکشد. در این بازه، فرستنده‌ها به‌صورت تصادفی به سرور قدیم یا سرور جدید ایمیل می‌فرستند. اگر هر دو صندوق آماده نباشند، بخشی از پیام‌ها از دست می‌رود. دوم، SPF و DKIM که پس از تغییر سرور نیاز به بازتنظیم دارند؛ در غیر این صورت ایمیل‌های خروجی سایت شما به پوشه اسپم گیرندگان می‌رود. سوم، نبود بکاپ قابل‌بازگردانی از پنل قدیمی، که در صورت بروز مشکل، هیچ راهی برای جبران باقی نمی‌گذارد.

به همین دلیل است که پیش از هر اقدامی، تهیه‌ی یک نسخه بکاپ کامل از صندوق‌ها را توصیه می‌کنم؛ چیزی که در راهنمای پشتیبان‌گیری از ایمیل و فایل‌های هاست به‌تفصیل باز کرده‌ام و اگر هاست شما cPanel دارد، مسیر سریع‌ترش را در بکاپ‌گیری از cPanel توضیح داده‌ام. این بکاپ، بیمه‌نامه‌ی شما در برابر تمام سناریوهای بدی است که در ادامه همین مقاله مرور می‌شوند.

ایمیل برخلاف فایل، در لحظه‌ی مهاجرت یک داده‌ی زنده است؛ هر تصمیم اشتباه در بازه‌ی پروپاگیشن DNS، پیام‌هایی را می‌سوزاند که دیگر بازنمی‌گردند.

آناتومی ایمیل در سرور: چه داده‌هایی باید منتقل شوند؟

بیشتر کاربران تصور می‌کنند ایمیل فقط همان صندوق پستی است که در Roundcube یا Horde می‌بینند. اما در واقعیت، یک حساب ایمیل سازمانی مجموعه‌ای از چند موجودیت مستقل است که هرکدام به‌نوعی در مهاجرت نقش دارند. اگر ندانید این اجزا چه هستند، احتمالاً نیمی از آن‌ها را از قلم می‌اندازید و بعد از مهاجرت، تازه متوجه می‌شوید چیزی کم است.

۱) صندوق پستی (Mailbox) و ساختار پوشه‌ها

صندوق پستی شامل پوشه‌های استاندارد INBOX، Sent، Drafts، Trash و Junk به‌همراه پوشه‌های سفارشی است که کاربر خودش ساخته. هر پیام در این پوشه‌ها سه ویژگی مهم دارد که همه باید منتقل شوند: بدنه و پیوست‌ها، فلگ‌های وضعیت (خوانده‌شده، پاسخ‌داده‌شده، علامت‌دار) و زمان دقیق دریافت. انتقال بدون فلگ‌ها یعنی صندوق پس از مهاجرت، صدها پیام «خوانده‌نشده» نشان می‌دهد که تجربه کاربری آزاردهنده‌ای می‌سازد.

۲) فورواردها (Forwarders) و اتوریسپاندرها (Autoresponders)

هر فورواردی که در پنل ایمیل ساخته‌اید، در دیتابیس سرور به‌عنوان یک قاعده ثبت شده. اتوریسپاندرها هم که برای پیام‌های تعطیلات یا پاسخ خودکار استفاده می‌شوند، همین‌طور. اگر صندوق‌ها را منتقل کنید ولی این قواعد را یادتان برود، مشتری شما بعد از مهاجرت متوجه می‌شود که پیام‌های info@ دیگر به دستش نمی‌رسد یا پاسخ خودکار تعطیلات کار نمی‌کند. مسیر ساخت و بازیابی این قواعد را در ساخت ایمیل در cPanel دیده‌اید؛ همان مسیر، برای انتقال دستی این تنظیمات هم به‌کار می‌آید.

۳) فیلترها و قواعد پردازش (Filters)

فیلترهای سرور، پیام‌های ورودی را بر اساس فرستنده، موضوع یا کلمات کلیدی به پوشه‌های خاص هدایت می‌کنند. یک حساب فروش ممکن است ده‌ها فیلتر داشته باشد که هرکدام برای یک دسته سفارش یا یک مشتری ویژه تنظیم شده. این فیلترها در بیشتر پنل‌ها قالب استاندارد ندارند و باید دستی بازسازی شوند.

۴) لیست‌های ایمیل و آدرس‌های catch-all

اگر آدرس catch-all دارید که تمام ایمیل‌های یک دامنه را به یک صندوق هدایت می‌کند، این تنظیم هم باید عیناً در سرور جدید بازسازی شود. همچنین لیست‌های ایمیل (Mailman، Majordomo) که در برخی cPanel ها نصب می‌شوند، خودشان یک موجودیت مستقل دارند و باید از بکاپ پنل قدیمی بازیابی شوند.

۵) رکوردهای DNS مرتبط با ایمیل

سه رکورد DNS که مستقیماً به ایمیل مربوط‌اند باید پس از مهاجرت بازتنظیم شوند: MX که سرور دریافت ایمیل را مشخص می‌کند، SPF (Sender Policy Framework) که فهرست سرورهای مجاز ارسال را تعیین می‌کند و DKIM (DomainKeys Identified Mail) که امضای دیجیتال پیام‌های خروجی را تعریف می‌کند. به این‌ها DMARC (Domain-based Message Authentication, Reporting and Conformance) را هم اضافه کنید که سیاست برخورد با پیام‌های نامعتبر را تعیین می‌کند. هر چهار مورد در بخش جداگانه‌ای در ادامه باز می‌شوند.

تجربه‌ی تکرارشده‌ی من این است: نیمی از مشکلات بعد از مهاجرت ایمیل، نه از صندوق‌ها، بلکه از فراموش‌شدن فورواردها و فیلترها می‌آید.

سه استراتژی انتقال ایمیل و انتخاب درست

سه راه اصلی برای منتقل کردن صندوق‌های پستی از یک هاست به هاست دیگر وجود دارد و انتخاب بین آن‌ها به سه فاکتور بستگی دارد: حجم صندوق‌ها، پهنای باند و کیفیت شبکه، و مدت زمانی که می‌توانید سایت و ایمیل را در حالت نیمه‌فعال نگه دارید. در جدول زیر، سه استراتژی را کنار هم گذاشته‌ام تا انتخاب سریع‌تر شود.

روش اول: مهاجرت از طریق ابزارهای cPanel

اگر هر دو هاست cPanel دارند، سریع‌ترین گزینه استفاده از ابزار Transfer Tool در WHM است که هم فایل‌ها، هم دیتابیس و هم صندوق‌های ایمیل را در یک عملیات منتقل می‌کند. این روش برای صندوق‌های زیر چند گیگابایت جواب می‌دهد و چون همه‌چیز در همان عملیات کپی می‌شود، نیاز به بازسازی دستی ساختار Maildir ندارید. اما یک نکته‌ی مهم: Transfer Tool در WHM فقط بین دو سروری کار می‌کند که دسترسی root دارند؛ اگر هاست مبدأ یا مقصد یک هاست اشتراکی است، این روش از دسترس خارج می‌شود. تجربه‌ی من این است که برای مهاجرت به VPS اختصاصی، این روش نسبت به بقیه، یک مرحله کمتر و خطای انسانی کمتری دارد.

روش دوم: imapsync و انتقال پروتکل‌محور

imapsync یک اسکریپت پرل است که دو سرور IMAP را به‌هم متصل می‌کند و تمام پوشه‌ها، فلگ‌ها و پیام‌ها را از مبدأ به مقصد کپی می‌کند. این روش مزیت بزرگی دارد: مستقل از نوع سرور و مستقل از نوع پنل است. اگر هاست قدیمی cPanel و هاست جدید Plesk یا DirectAdmin باشد، imapsync همچنان کار می‌کند چون از IMAP استفاده می‌کند، نه از API پنل. همچنین چون می‌توانید آن را چندین بار اجرا کنید، در بازه‌ی مهاجرت چندین پاس می‌زنید تا اختلاف پیام‌های میانی هم منتقل شود.

روش سوم: دانلود دستی با کلاینت ایمیل

اگر تعداد صندوق‌ها کم و حجم هرکدام زیر یک گیگابایت است، می‌توانید صندوق‌ها را با IMAP در Thunderbird یا Outlook اضافه کنید، به‌صورت محلی sync کنید و سپس روی حساب جدید در سرور مقصد آپلود کنید. این روش برای فریلنسرها و کسب‌وکارهای خیلی کوچک به‌صرفه است، اما برای فروشگاه‌ها و سازمان‌های چندکاربره به‌هیچ‌وجه توصیه نمی‌شود، چون پتانسیل گم شدن پیام‌های میانی بالاست.

انتخاب روش با توجه به شرایط شما متفاوت است. اگر کسب‌وکار شما به‌سمت رشد رفته و در حال انتقال از هاست اشتراکی به زیرساخت اختصاصی هستید، مسیر امن‌تر همان است که در راهنمای انتقال از هاست اشتراکی به VPS توضیح داده‌ام و می‌توانید همان اصول را برای ایمیل هم اجرا کنید.

آماده‌سازی‌های حیاتی قبل از مهاجرت

بیشتر مهاجرت‌های موفق، پیش از آن‌که اولین بایت را جابه‌جا کنید، در ذهن شما کامل شده‌اند. سه کار پیش‌نیازی که در تمام پرونده‌های واقعی، بین مهاجرتِ بی‌درد و فاجعه تفاوت ایجاد کرده‌اند، این‌ها هستند:

۱) تهیه فهرست کامل صندوق‌ها و تنظیمات

در پنل هاست قدیمی، فهرست تمام آدرس‌های ایمیل، حجم هرکدام، فورواردها، اتوریسپاندرها و فیلترها را به‌صورت یک برگه یادداشت جمع کنید. اگر پنل شما cPanel است، این اطلاعات در بخش Email Accounts قابل مشاهده است. این فهرست، تبدیل به چک‌لیست مهاجرت می‌شود و مانع از این می‌شود که یک حساب که ماهی یک بار استفاده می‌شود، از قلم بیفتد.

۲) بررسی ظرفیت هاست جدید

اگر مجموع حجم صندوق‌های قدیمی ۳۰ گیگابایت است، هاست جدید باید حداقل دو برابر آن فضای خالی داشته باشد؛ چون در بازه انتقال، ایمیل‌ها هم‌زمان در هر دو سرور نگه داشته می‌شوند و کپی موازی ساخته می‌شود. همچنین بررسی کنید که محدودیت inode یا سهمیه فضای هاست جدید کمتر از حجم ایمیل‌های شما نباشد. انتخاب هاست مناسب را سال‌ها پیش در راهنمای انتخاب هاست مناسب باز کرده‌ام؛ همان معیارها امروز هم پابرجاست، فقط حساسیت روی فضای دیسک برای مهاجرت ایمیل اضافه می‌شود.

۳) برنامه‌ریزی زمان‌بندی با کاربران

به کاربران نهایی اطلاع دهید که در یک بازه‌ی مثلاً شش‌ساعته، ممکن است پیام‌های ارسالی با تأخیر برسند یا ایمیل‌های خروجی‌شان موقتاً در Outbox بماند. این اطلاع‌رسانی از ترس و تماس‌های پرسش‌گرانه در ساعات مهاجرت جلوگیری می‌کند. بهترین زمان برای مهاجرت، شبانگاه یا آخر هفته است، نه ساعت کاری پرترافیک.

گام‌به‌گام: انتقال ایمیل بین دو هاست cPanel

روشی که در ادامه می‌آید، همان پروتکلی است که در پروژه‌های خودم برای انتقال بین دو cPanel استفاده می‌کنم. تعداد گام‌ها کم است، اما هر گام نقش مشخصی در جلوگیری از گم شدن پیام‌ها بازی می‌کند.

گام ۱: کپی اولیه در بازه‌ی سرد

قبل از هر تغییر DNS، با imapsync یک کپی کامل از سرور قدیم به سرور جدید بگیرید. این پاس اولیه ممکن است چند ساعت طول بکشد، اما چون هنوز MX تغییر نکرده، هیچ پیام جدیدی در خطر نیست. دستور پایه‌ی imapsync این شکل است:

imapsync 
  --host1 old.example.com 
  --user1 user@example.com 
  --password1 'OLDPASS' 
  --host2 new.example.com 
  --user2 user@example.com 
  --password2 'NEWPASS' 
  --automap 
  --usecache 
  --skipsize 
  --addheader

سوییچ --automap پوشه‌های استاندارد را با نگاشت خودکار منتقل می‌کند و --addheader یک هدر رهگیری به پیام‌های منتقل‌شده اضافه می‌کند که در تشخیص نسخه‌ی تکراری به شما کمک می‌کند.

گام ۲: کاهش TTL رکوردهای DNS

حداقل ۴۸ ساعت قبل از مهاجرت، مقدار TTL رکورد MX و A را به ۳۰۰ ثانیه کاهش دهید. این کار باعث می‌شود در لحظه‌ی مهاجرت، پروپاگیشن سریع‌تر انجام شود و بازه‌ی حساس کوتاه‌تر. اگر مطمئن نیستید TTL چطور کار می‌کند، مقاله‌ی DNS چیست و چگونه کار می‌کند را یک بار مرور کنید؛ همین مفهوم ساده، در روزِ مهاجرت تفاوت محسوسی ایجاد می‌کند.

گام ۳: پاس دلتا در روز مهاجرت

چند ساعت قبل از تغییر MX، دوباره imapsync را اجرا کنید تا تنها پیام‌های تازه منتقل شوند. چون سرور مقصد اکثر پیام‌ها را از قبل دارد، این پاس بسیار سریع‌تر تمام می‌شود. اگر حجم صندوق بزرگ است، می‌توانید دو پاس دلتا بگیرید: یکی صبح روز مهاجرت و یکی نیم ساعت قبل از تغییر MX.

گام ۴: تغییر رکورد MX

در پنل DNS دامنه، رکورد MX را از سرور قدیم به سرور جدید سوئیچ کنید. اگر رکورد MX چندگانه دارید (مثلاً با اولویت‌های ۱۰ و ۲۰)، همه را به نسخه‌ی جدید تغییر دهید. اگر از سرویس‌های واسط ایمیل مثل Google Workspace استفاده می‌کنید، این گام مسیر متفاوتی دارد که در بخش MX و SPF به آن می‌رسیم.

گام ۵: پاس نهایی و پایش

پس از دوازده تا بیست‌وچهار ساعت، یک پاس imapsync دیگر اجرا کنید و سپس پنل قدیم را حداقل تا یک هفته در حالت فقط-خواندنی نگه دارید تا اگر پیامی به سرور قدیم رسید، بتوانید دستی بازیابی کنید. تجربه‌ی من این است که در شش ماه گذشته، تنها در یک پرونده کوچک، پیامی پس از مهاجرت به سرور قدیم رسید؛ همان یک مورد، با نگه داشتن پنل قدیمی در حالت read-only قابل بازیابی بود. اگر بعد از این همه دقت، بازهم می‌خواهید مهاجرت هاست اصلی را با وسواس بیشتری انجام دهید، پروتکل انتقال سایت وردپرسی به هاست جدید همان چارچوب را برای سایت باز می‌کند و می‌توانید مراحل را موازی اجرا کنید.

تنظیم MX و پیکربندی SPF، DKIM و DMARC

سه رکورد DNS به‌طور مستقیم سرنوشت ایمیل شما را در روزهای پس از مهاجرت تعیین می‌کنند و یک رکورد چهارم، سیاست برخورد سرورهای گیرنده با پیام‌های نامعتبر را مشخص می‌کند. اکثر مشکلاتی که پس از مهاجرت به‌عنوان «ایمیل نمی‌رسد» یا «ایمیل‌ها به اسپم می‌رود» گزارش می‌شوند، ریشه در همین چهار رکورد دارند و نه در صندوق پستی.

MX Record: نشانی سرور دریافت‌کننده

رکورد MX تعیین می‌کند که پیام‌های ورودی دامنه‌ی شما به کدام سرور هدایت شوند. هر MX یک مقدار اولویت دارد و سرور فرستنده ابتدا با کم‌ترین عدد اولویت تماس می‌گیرد. اگر می‌خواهید مهاجرت را به‌صورت تدریجی انجام دهید، می‌توانید مدت کوتاهی هر دو سرور را در MX نگه دارید تا ریسک قطعی کاهش یابد. انواع مختلف رکوردهای DNS و کاربردشان را در رکوردهای DNS فهرست کرده‌ام؛ آن‌جا تفاوت MX با CNAME و A Record هم آمده است.

SPF: فهرست سرورهای مجاز ارسال

رکورد SPF یک متن ساده است که در آن فهرست سرورهایی که اجازه دارند به‌نام دامنه‌ی شما ایمیل بفرستند، تعریف می‌شود. اگر پس از مهاجرت، رکورد SPF را به‌روز نکنید، سرورهای گیرنده ممکن است پیام‌های شما را به‌عنوان جعل‌شده تلقی کنند. نمونه‌ی استاندارد بعد از مهاجرت به یک سرور جدید:

v=spf1 +a +mx +ip4:198.51.100.42 include:_spf.example.com ~all

هر رکورد SPF باید تنها یک بار در DNS وجود داشته باشد. داشتن دو رکورد SPF، خطایی است که تقریباً همیشه منجر به رد شدن پیام‌های خروجی می‌شود. راهنمای عملی تنظیم رکوردهای مختلف DNS را در پیکربندی DNS دامنه آورده‌ام؛ همان ساختار، برای این رکورد هم صدق می‌کند.

DKIM: امضای دیجیتال پیام‌های خروجی

DKIM یک کلید خصوصی روی سرور و یک کلید عمومی در DNS ایجاد می‌کند. اگر هاست مقصد از cPanel استفاده می‌کند، در بخش Email Deliverability یک گزینه‌ی Generate DKIM Key وجود دارد که کلیدها را می‌سازد. مهم است که هر سرور کلید مستقل خودش را داشته باشد؛ انتقال کلید از سرور قدیم به سرور جدید معمولاً بی‌دلیل است و توصیه نمی‌شود.

DMARC: سیاست برخورد با پیام‌های جعلی

رکورد DMARC به سرورهای گیرنده می‌گوید که اگر پیامی SPF و DKIM را پاس نکرد، چه رفتاری داشته باشند: هیچ کاری نکن (p=none)، در پوشه اسپم بگذار (p=quarantine) یا کاملاً رد کن (p=reject). برای دوره‌ی پس از مهاجرت، پیشنهاد من این است که ابتدا با p=none شروع کنید، از طریق آدرس rua گزارش‌ها را دریافت کنید و پس از چند هفته که از صحت SPF و DKIM مطمئن شدید، به p=quarantine و سپس p=reject ارتقا دهید.

در تنظیم SPF و DKIM، ترتیب حرکت مهم است: اول گزارش بگیر، بعد سختگیر شو. سختگیری زودهنگام در روزهای اول مهاجرت، پیام‌های مشتریان شما را به اسپم می‌فرستد.

ابزارهای حرفه‌ای: imapsync، rclone و اسکریپت سفارشی

برای حجم‌های بالا و پروژه‌های تکراری، ابزارهای آماده پاسخ کافی نمی‌دهند و بهتر است یک اسکریپت کوچک دور آن‌ها بنویسید. تجربه‌ی شخصی‌ام می‌گوید که ترکیب imapsync با یک اسکریپت پارامتری، در پروژه‌های سازمانی چندین برابر زمان آزاد می‌کند.

imapsync: قلب عملیات

imapsync یک اسکریپت پرل تک‌فایلی است که تمام پوشه‌ها، فلگ‌ها و پیام‌ها را با پروتکل IMAP منتقل می‌کند. نسخه‌ی رایگان آن برای اکثر پروژه‌های کوچک و متوسط کافی است و در نسخه‌های تجاری، قابلیت‌های گزارش‌گیری و همگام‌سازی چندصندوقه اضافه می‌شود.

rclone: انتقال روی فضای ابری

rclone بیشتر برای فایل و فضای ابری طراحی شده، اما می‌تواند به‌عنوان لایه‌ی پشتیبان در سناریوهایی که هاست شما بکاپ خودکار در Google Drive یا S3 دارد هم به‌کار بیاید. اگر می‌خواهید بکاپ ایمیل قبل از مهاجرت را روی فضای ابری نگه دارید، این ترکیب مفید است.

اسکریپت پارامتری برای چند صندوق

برای یک فروشگاه با بیست صندوق، اجرای دستی imapsync بیست بار، فرسایشی و خطاپذیر است. یک اسکریپت Bash کوچک که یک فایل CSV با ستون‌های user، oldpass، newpass را می‌خواند، همه‌چیز را خودکار می‌کند:

while IFS=, read -r user oldpass newpass; do
  imapsync 
    --host1 old.example.com --user1 "$user" --password1 "$oldpass" 
    --host2 new.example.com --user2 "$user" --password2 "$newpass" 
    --automap --usecache --skipsize --addheader 
    --logdir /var/log/imapsync
done < accounts.csv

ترکیب این اسکریپت با cron روزانه، به شما امکان می‌دهد در بازه‌ی مهاجرت هر شب یک پاس دلتا بزنید و صبح، تنها پیام‌های تازه منتقل شده باشند. همین لایه ساده، در تجربه‌ی من، بین مهاجرت بی‌درد و مهاجرت همراه با سؤال‌های پشت‌سرهم تفاوت ایجاد کرده است. اگر می‌خواهید کنترل کامل‌تری روی سرور داشته باشید و به‌جای تکیه بر API پنل، همه‌چیز را از خط فرمان اجرا کنید، cPanel و کاربردهای آن نقطه‌ی شروع مناسبی است تا دسترسی‌های لازم را بشناسید.

خطاهای رایج و ریشه‌یابی فنی

حتی با رعایت تمام موارد بالا، بازهم چند خطای مشخص وجود دارد که ممکن است در روزهای پس از مهاجرت ظاهر شود. این‌ها را در ده‌ها پرونده دیده‌ام و هرکدام الگوی تشخیص مشخصی دارند.

خطای اول: پیام‌ها هم‌زمان به دو سرور می‌روند

این اتفاق زمانی می‌افتد که رکورد MX هنوز در برخی نقاط DNS کش شده و به سرور قدیم اشاره می‌کند، در حالی که در برخی نقاط دیگر به سرور جدید. راه‌حل، اجرای یک پاس دلتای نهایی پس از بیست‌وچهار ساعت است، به‌همراه پایش لاگ هر دو سرور برای چند روز. اگر این مشکل زیاد تکرار می‌شود، مقدار TTL را دوباره بررسی کنید؛ گاهی تنظیم TTL در کنار رکورد MX به‌صورت اشتباه روی دامنه‌ی اصلی اعمال شده و رکورد MX همچنان TTL قدیمی خودش را دارد.

خطای دوم: ایمیل‌های خروجی به اسپم می‌روند

این مشکل معمولاً ریشه در SPF نادرست یا نبود DKIM دارد. با ابزارهای تشخیصی مثل MXToolbox می‌توانید رکورد SPF را اعتبارسنجی کنید. اگر SPF معتبر است و همچنان پیام‌ها به اسپم می‌رود، سراغ DKIM و DMARC بروید و بررسی کنید که DNS Propagation در حال تکمیل است؛ در بازه‌ی انتقال، هر دو حالت ممکن است رخ دهد.

خطای سوم: خطای احراز هویت در کلاینت‌ها

پس از مهاجرت، کاربران باید رمز صندوق را در Outlook یا Thunderbird به‌روز کنند، چون هاست مقصد ممکن است سیاست رمز جدید داشته باشد. این ظاهراً ساده است اما در سازمانی با چندین کاربر، تبدیل به یک موج پشتیبانی می‌شود. اگر پنل شما امکان تولید رمز اختصاصی برای هر دستگاه را دارد (مثل App Passwords در Google یا Microsoft)، استفاده از آن هم امنیت را بالا می‌برد و هم مدیریت را ساده‌تر می‌کند.

اگر در ریشه‌یابی رفتار DNS گیر کردید، چک‌لیست عیب‌یابی مشکلات DNS را مرحله‌به‌مرحله اجرا کنید؛ اکثر الگوهای تکرارشونده در همان‌جا فهرست شده‌اند.

پرسش‌های پرتکرار درباره مهاجرت ایمیل

در این بخش، به پرتکرارترین پرسش‌هایی که در مکاتبات و جلسات پیش می‌آید، پاسخ کوتاه و کاربردی می‌دهم. این ساختار، خودش یکی از بهترین شکل‌های بهینه‌سازی برای موتورهای پاسخ‌ده (Answer Engine Optimization) است، چون همان شکلی که کاربر سؤال می‌پرسد، پاسخ را برمی‌گرداند.

آیا می‌توانم ایمیل‌ها را بدون تغییر MX منتقل کنم؟

بله، اگر هر دو سرور به‌صورت موازی در دسترس باشند و با پروتکل IMAP صحبت کنند. می‌توانید پاس اولیه را انجام دهید و MX را برای مدتی دست نزنید. اما تا زمانی که MX به سرور جدید منتقل نشود، پیام‌های جدید همچنان در سرور قدیم جمع می‌شوند و باید هر شب پاس دلتا بگیرید.

چه مدت طول می‌کشد تا مهاجرت کامل شود؟

برای صندوق‌های کوچک (زیر ۵ گیگابایت)، معمولاً بین یک تا سه ساعت. برای صندوق‌های بزرگ بالای ۵۰ گیگابایت، می‌تواند تا چند روز طول بکشد و بهتر است به‌صورت پاس‌های دلتا انجام شود، نه یک انتقال یک‌باره.

آیا لازم است تمام صندوق‌ها را یک‌جا منتقل کنم؟

خیر. حتی بهتر است به دو دسته تقسیم شوند: صندوق‌های حیاتی مانند info@، sales@ و support@ ابتدا منتقل شوند و صندوق‌های شخصی کارکنان با کمی تأخیر. این تفکیک، ریسک را توزیع می‌کند و به شما امکان می‌دهد در صورت بروز مشکل، تیم پشتیبانی را بی‌وقفه نگه دارید.

اگر بعد از مهاجرت متوجه شدم پیامی گم شده چه کنم؟

اول سراغ بکاپ اولیه بروید که پیش از مهاجرت گرفته‌اید. اگر بکاپ پیام را دارد، می‌توانید آن را دستی روی سرور جدید آپلود کنید. اگر بکاپ هم ندارد، آخرین امید، پنل قدیمی است که امیدوارم در حالت فقط-خواندنی نگه داشته باشید. به همین دلیل است که در گام آماده‌سازی، نگه داشتن پنل قدیم برای یک هفته را اصرار کردم.

آیا DKIM را هم باید از سرور قدیم منتقل کنم؟

خیر. کلید DKIM را در سرور جدید بازتولید کنید. انتقال کلید خصوصی، سطح دسترسی را بیشتر می‌کند و بی‌دلیل است. SPF را همیشه پس از تغییر سرور، بازنویسی کنید و آن را در برابر رکوردهای قدیمی چک کنید که به‌طور کامل جایگزین شده باشد.

جمع‌بندیِ کارِ ناتمام: چه چیزی را نباید فراموش کنید

انتقال ایمیل هنگام تغییر هاست، یک پروژه‌ی زمان‌بندی‌شده است، نه یک عملیات لحظه‌ای. چیزی که تجربه‌ی من در طول سال‌ها کار روی پروژه‌های مهاجرت نشان داده این است که هر عملیات موفقی، سه ویژگی مشترک داشته: پیش‌آماده‌سازی کامل از فهرست صندوق‌ها، برنامه‌ریزی زمان TTL و MX، و بیمه‌نامه‌ای که همان بکاپ قبل از شروع است. هرچه این سه را جدی‌تر بگیرید، بازه‌ی قطعی کوتاه‌تر و ریسک گم‌شدن پیام نزدیک‌تر به صفر می‌شود.

اگر امروز می‌خواهید مهاجرت ایمیل خود را شروع کنید، ترتیبی که در این راهنما آمده را دقیقاً رعایت کنید: اول بکاپ، بعد فهرست‌برداری، سپس پاس اولیه imapsync، کاهش TTL، پاس دلتا، تغییر MX، و در نهایت پایش سه روزه. در هر گام، به‌جای اتکا به حافظه، از یادداشت و لاگ استفاده کنید. همین انضباط ساده، معمولاً بین مهاجرتی که در چند ساعت با موفقیت تمام می‌شود و مهاجرتی که یک هفته محل نزاع است، تفاوت ایجاد می‌کند. ✉️

اگر در یکی از این گام‌ها به مورد خاصی برخوردید، مثلاً هاست قدیمی‌تان از یک پنل خاص غیر cPanel استفاده می‌کند یا با فورواردهای پیچیده سروکار دارید، تجربه‌تان را در دیدگاه‌ها بنویسید. روش‌هایی که در پرونده‌های مختلف به‌کار رفته‌اند، برای خواننده‌ی بعدی معمولاً ارزشمندتر از هر مستند رسمی‌اند. 🛠️