คำตอบสั้น ๆ: แผน MX Cutover ทีละช่วงตั้งแต่ T-14 ถึง T+30: สำรวจระบบเดิม ลด TTL ซิงก์อีเมลล่วงหน้า เปลี่ยน MX เก็บอีเมลตกค้าง และถอยกลับได้ถ้าระบบใหม่มีปัญหา
คู่มือนี้อธิบาย MX Cutover ทีละขั้นตอน พร้อมคำสั่งที่ใช้ได้จริงและปัญหาที่พบบ่อย
MX Cutover คือช่วงที่เปลี่ยนระเบียน MX ของโดเมนจากระบบอีเมลเดิมไปยังระบบใหม่ เช่น ย้ายจากเมลเซิร์ฟเวอร์บนโฮสติ้งไป Microsoft 365, Google Workspace หรือ Cloud Mail Server ช่วงนี้เป็นจุดที่อีเมลหายได้ง่ายที่สุด เพราะผู้ส่งภายนอกแต่ละรายจะเห็น MX ใหม่ไม่พร้อมกัน อีเมลบางฉบับจึงยังเข้าระบบเดิมหลังเปลี่ยนไปแล้วหลายชั่วโมงหรือหลายวัน
คู่มือนี้เป็นแผนงานสำหรับผู้ดูแลระบบหรือเจ้าหน้าที่ไอทีที่ต้องย้ายอีเมลทั้งบริษัท แบ่งเป็นช่วงเวลาตั้งแต่ T-14 (14 วันก่อนวันเปลี่ยน) ถึง T+30 เมื่อทำตามครบ คุณจะมีรายการสิ่งที่ต้องย้ายครบถ้วน ลด TTL ทันเวลา ซิงก์อีเมลเก่าไว้ล่วงหน้า เปลี่ยน MX แล้วเก็บอีเมลที่ตกค้างได้ครบ และมีแผนถอยกลับถ้าระบบใหม่มีปัญหา ส่วนวิธีย้ายข้อมูลในกล่องจดหมายให้ดูคู่มือ imapsync หรือ IMAP Migration Batch ประกอบ
สิ่งที่ต้องเตรียม
- สิทธิ์แก้ DNS ของโดเมนที่ผู้ให้บริการ DNS จริง (ตรวจด้วย
dig NS example.comว่า Name Server อยู่ที่ไหน ไม่ใช่ที่ผู้ขายโดเมนเสมอไป) - สิทธิ์ผู้ดูแลทั้งระบบเดิมและระบบใหม่ และโดเมนที่ยืนยันความเป็นเจ้าของในระบบใหม่แล้ว
- เครื่องมือย้ายข้อมูลที่ทดสอบแล้วกับกล่องจดหมายจริงอย่างน้อย 2 กล่อง พร้อมตัวเลขว่าใช้เวลากี่ชั่วโมงต่อ 1 GB
- ช่องทางสื่อสารกับพนักงานที่ไม่ใช่อีเมล เช่น กลุ่มแชตของบริษัท เพราะวันเปลี่ยนระบบอีเมลอาจใช้การไม่ได้ชั่วคราว
- วันและเวลาที่อีเมลเข้าน้อย เช่น เย็นวันศุกร์ หลีกเลี่ยงวันปิดงบหรือวันที่ต้องรับใบแจ้งหนี้จากคู่ค้าจำนวนมาก
ขั้นตอนที่ 1: สำรวจระบบเดิมและบันทึก DNS ก่อน MX Cutover (T-14)
MX Cutover ที่พลาดส่วนใหญ่ไม่ได้พลาดตอนเปลี่ยน MX แต่พลาดเพราะลืมของที่อยู่ในระบบเดิม ทำรายการต่อไปนี้ใน spreadsheet เดียว
- กล่องจดหมายทุกกล่อง ขนาด และจำนวนอีเมล รวมกล่องของคนที่ลาออกแต่ยังต้องเก็บ
- Alias, Forwarder, Distribution list และกล่องกลาง เช่น
sales@หรือap@ - อุปกรณ์และระบบที่ส่งอีเมลผ่าน SMTP ของระบบเดิม เช่น เครื่องพิมพ์สแกนส่งอีเมล ERP เว็บไซต์ และระบบแจ้งเตือน
- ระเบียน DNS ทั้งหมดที่เกี่ยวกับอีเมล
บันทึกค่า DNS ปัจจุบันเก็บไว้เป็นไฟล์ เพราะเป็นข้อมูลที่ต้องใช้ตอนถอยกลับถ้า MX Cutover มีปัญหา
{
dig +noall +answer example.com MX
dig +noall +answer example.com TXT
dig +noall +answer _dmarc.example.com TXT
dig +noall +answer autodiscover.example.com
dig +noall +answer mail.example.com A
} | tee dns-before-cutover.txtขั้นตอนที่ 2: ลด TTL ของ MX และเตรียม DNS ของระบบใหม่ (T-7)
TTL คือเวลาที่เซิร์ฟเวอร์ DNS ทั่วโลกจำค่า MX เดิมไว้ ถ้า TTL ปัจจุบันเป็น 86400 วินาที (1 วัน) แล้วทำ MX Cutover ทันที ผู้ส่งบางรายจะยังส่งไประบบเดิมได้นานถึง 1 วัน ให้ดู TTL จริงจาก Name Server ของโดเมนโดยตรง แล้วลดเหลือ 300 วินาทีอย่างน้อยหนึ่งรอบ TTL เดิมก่อนวัน MX Cutover รายละเอียดอยู่ใน คู่มือ TTL และการวางแผนย้าย DNS
dig +noall +answer example.com MX @ns1.example.netในวันเดียวกัน ให้เตรียมระเบียนของระบบใหม่ที่ไม่กระทบการรับอีเมล ได้แก่ DKIM ของระบบใหม่ (CNAME หรือ TXT ตามที่ระบบกำหนด) และ SPF ที่รวมทั้งสองระบบ เพื่อให้ส่งออกได้ทั้งก่อนและหลัง MX Cutover
example.com. 300 IN TXT "v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all"ค่าระเบียนที่ถูกต้องให้คัดลอกจากหน้าจัดการโดเมนของระบบใหม่เสมอ และอย่าเพิ่งแตะ MX และ Autodiscover ในขั้นตอนนี้
ขั้นตอนที่ 3: ซิงก์อีเมลเก่าล่วงหน้าก่อน MX Cutover (T-7 ถึง T-1)
ย้ายอีเมลเก่าทั้งหมดไปกล่องปลายทางก่อนวัน MX Cutover ขณะที่พนักงานยังใช้ระบบเดิมตามปกติ รอบแรกเป็น full sync ซึ่งใช้เวลานานที่สุด จากนั้นรันซ้ำวันละครั้ง (delta sync) ซึ่งคัดลอกเฉพาะอีเมลใหม่จึงเร็วมาก
- เริ่มจากกลุ่มนำร่อง เช่น ทีมไอที ย้ายครบทุกขั้นแล้วใช้งานจริงสัก 2–3 วัน เพื่อเจอปัญหาก่อนคนทั้งบริษัท
- เรียงกล่องใหญ่ไว้ก่อน เพราะกล่องขนาดหลายสิบ GB อาจใช้เวลาเป็นวัน
- บันทึกผลแต่ละกล่อง เช่น จำนวนข้อความต้นทางเทียบปลายทาง และข้อความที่ถูกข้าม
- ถ้าย้ายไป Google Workspace และต้องการให้ผู้ใช้บางคนลองระบบใหม่ก่อน ใช้ Dual Delivery ช่วยได้
ขั้นตอนที่ 4: ทำ MX Cutover ในวัน T-0
- แจ้งพนักงานทางช่องทางที่เตรียมไว้ว่าเริ่ม MX Cutover แล้ว และอีเมลอาจล่าช้าได้ระยะหนึ่ง
- รัน delta sync รอบสุดท้ายก่อน MX Cutover
- แก้ระเบียน MX เป็นค่าของระบบใหม่ และลบ MX เดิมออกทั้งหมด อย่าเก็บ MX เดิมไว้เป็นลำดับสำรอง เพราะผู้ส่งที่ต่อระบบใหม่ไม่ได้ชั่วขณะจะส่งไปเซิร์ฟเวอร์เดิมแทน
- เปลี่ยน CNAME ของ Autodiscover ให้ชี้ระบบใหม่ เพื่อให้ Outlook ตั้งค่าโปรไฟล์ใหม่ได้
- ตรวจผลจาก Name Server และจาก resolver สาธารณะ แล้วส่งอีเมลทดสอบจากบัญชีภายนอก เช่น Gmail ส่วนตัว
หลัง MX Cutover ให้เปิด log ของเซิร์ฟเวอร์เดิมดูไว้ เช่น tail -f /var/log/mail.log บน Postfix หรือ /var/log/zimbra.log บน Zimbra ปริมาณอีเมลที่เข้าเซิร์ฟเวอร์เดิมควรลดลงจนเกือบเป็นศูนย์ภายในช่วง TTL ที่ตั้งไว้ อีเมลที่ยังเข้ามาหลังจากนั้นมักมาจากเซิร์ฟเวอร์ผู้ส่งที่จำ DNS นานกว่าที่กำหนด หรืออีเมลที่ค้างในคิวของผู้ส่งแล้วส่งซ้ำ
