ตั้ง Cloudflare Email Routing: MX เดิมอาจทำให้อีเมลหยุดเข้า

หากต้องการส่งอีเมลที่จ่าหน้าถึงโดเมนของคุณไปยังกล่องที่ใช้อยู่ ให้บันทึก MX เดิมก่อน แล้วเปิด Cloudflare Email Routing ยืนยันที่อยู่ปลายทาง สร้างกฎส่งต่อ และทดลองส่งจากบัญชีอื่น ข้อกำหนดโดเมนของ Cloudflare ระบุว่าบริการต้องใช้ MX ของ Cloudflare และ MX ของผู้ให้บริการภายนอกอาจขัดกัน หากกล่องเดิมหยุดให้บริการแล้ว แต่ผู้ส่งยังส่งข้อความตาม MX เดิม อีเมลอาจไม่เข้ากล่องที่ตั้งใจไว้

ให้คิดว่าการเปลี่ยน MX เป็นการเปลี่ยนผู้รับอีเมลขาเข้าของโดเมน ไม่ใช่การเพิ่มสำเนาอีเมลให้ทุกกล่อง ระหว่างเปลี่ยนค่า ผู้ส่งแต่ละรายอาจเห็น DNS ต่างกัน จึงควรคงกล่องเดิมให้รับข้อความได้ ตรวจทั้งกล่องเดิมและกล่องใหม่ และถือว่าตั้งค่าสำเร็จเมื่อข้อความทดสอบใหม่เข้าปลายทางจริง กฎที่มองเห็นในแดชบอร์ดเพียงอย่างเดียว ยังบอกไม่ได้ว่าผู้ส่งภายนอกกำลังใช้ MX ใด

บันทึกเส้นทางเดิมก่อนแตะ DNS

เริ่มที่ DNS > Records ของโดเมน แล้วเก็บ MX ทุกระเบียนของชื่อโดเมนที่ต้องการย้าย บันทึกชื่อโฮสต์ปลายทาง ค่า priority และ TTL ตามที่แสดงจริง พร้อมเก็บสำเนาค่า TXT ที่เกี่ยวกับ SPF และ DKIM การมีค่าครบช่วยให้คืนเส้นทางเดิมได้ โดยไม่ต้องเดาว่า MX ของผู้ให้บริการรายเก่าชี้ไปที่ใด หรือระเบียนรับอีเมลถูกตั้งไว้ที่โดเมนหลักหรือโดเมนย่อย

ตรวจด้วยว่ากล่องที่รับอีเมลอยู่ในขณะนี้เป็นบริการใด และบัญชีของบริการนั้นยังเปิดใช้งานหรือไม่ ชื่อ MX อาจชี้ไปยังผู้ให้บริการที่ต่างจากผู้ให้บริการเว็บไซต์หรือผู้จดทะเบียนโดเมน หากไม่แน่ใจว่าใครดูแลกล่องเดิม ให้ตรวจจากการตั้งค่าของบริการอีเมลหรือผู้ดูแลระบบก่อนเปลี่ยนค่า การเก็บเพียงภาพหน้าจอของกฎส่งต่อใหม่ ไม่ช่วยกู้ MX เดิมที่ไม่ได้บันทึกไว้

ทำรายการที่อยู่บนโดเมนซึ่งต้องรับข้อความต่อ เช่น ที่อยู่ติดต่อ ที่อยู่รับคำสั่งซื้อ หรือที่อยู่ของพนักงานที่ยังใช้งานอยู่ จับคู่แต่ละชื่อกับกล่องปลายทางที่เปิดอ่านได้จริง และระบุว่าใครมีสิทธิ์ยืนยันกล่องนั้น การเปลี่ยน MX ที่โดเมนหลักมีผลต่อข้อความขาเข้าที่ส่งมาถึงโดเมนนั้น ไม่ได้จำกัดผลอยู่ที่ที่อยู่แรกที่ใช้ทดลอง หากมีที่อยู่เดิมซึ่งไม่ได้สร้างกฎไว้ การทดสอบที่อยู่เพียงชื่อเดียวจะไม่เปิดเผยช่องว่างนี้

• เก็บค่าระเบียนเดิมเป็นข้อความที่คัดลอกกลับได้ พร้อมระบุชื่อโดเมนที่แต่ละระเบียนใช้ อย่าสลับระเบียนของโดเมนหลักกับโดเมนย่อย
• ตรวจว่าผู้ให้บริการอีเมลเดิมยังรับข้อความได้ และเตรียมช่องทางเข้าถึงกล่องนั้นไว้ตลอดช่วงเปลี่ยนเส้นทาง
• เลือกกล่องปลายทางที่รับอีเมลได้โดยไม่ต้องอาศัย MX ที่กำลังย้าย หากปลายทางเป็นที่อยู่บนโดเมนเดียวกัน ให้ตรวจเส้นทางรับของที่อยู่นั้นก่อน
• เตรียมบัญชีผู้ส่งอีกบัญชีหนึ่ง ซึ่งไม่ใช่กล่องปลายทาง และเตรียมผู้ตรวจทั้งกล่องเดิมกับกล่องใหม่

การเลือกปลายทางที่อยู่บนโดเมนเดียวกับต้นทางต้องระวังเป็นพิเศษ หากกล่องนั้นเคยรับข้อความผ่าน MX เดิม การเปลี่ยน MX จะเปลี่ยนทางเข้าของข้อความที่ส่งหากล่องนั้นด้วย เส้นทางที่ดูเหมือนส่งต่อกลับไปยังกล่องเดิมจึงอาจพึ่งพาการตั้งค่าที่กำลังถูกแทนที่ กล่องปลายทางซึ่งรับข้อความได้อย่างอิสระจากโดเมนที่ย้าย ช่วยให้ผลทดสอบตีความได้ตรงกว่า

เปิดโดเมนและจัดการ MX ที่ขัดกัน

โดเมนต้องใช้ Cloudflare DNS ก่อนจึงจะใช้ Email Service ได้ ในแดชบอร์ดให้ไปที่ Compute > Email Service > Email Routing เลือก Onboard Domain แล้วเลือกโดเมน ตรวจรายการระเบียนที่ระบบจะเพิ่มก่อนกด Done ขั้นตอนเริ่มใช้ Email Routing ระบุว่าระบบเพิ่ม MX ที่โดเมนหลัก พร้อม TXT สำหรับ SPF และ DKIM และการกระจาย DNS ทั่วโลกอาจใช้เวลาสูงสุด 24 ชั่วโมง

หลังเปิดใช้ ให้เทียบ DNS > Records กับรายการที่บันทึกไว้ โดยสนใจ MX ของชื่อโดเมนที่กำลังย้ายเป็นหลัก ระเบียน MX บอกผู้ส่งว่าจะส่งอีเมลขาเข้าไปยังเซิร์ฟเวอร์ใด ส่วนกฎ Email Routing จะทำงานกับข้อความที่มาถึง Cloudflare แล้วเท่านั้น หาก MX เดิมของผู้ให้บริการอื่นยังอยู่ร่วมกัน อย่าคิดว่าข้อความทุกฉบับจะถูกส่งเข้าทั้งสองระบบ หรือว่ากฎใหม่จะครอบคลุมข้อความที่ไปถึงเซิร์ฟเวอร์เดิม

ค่า priority เป็นส่วนหนึ่งของวิธีเลือกเซิร์ฟเวอร์รับอีเมล จึงควรบันทึกไว้พร้อมชื่อ MX เดิม แต่การใส่ MX ของสองผู้ให้บริการไว้ด้วยกัน ไม่ใช่วิธีทำสำเนากล่องรับเพื่อทดสอบกฎส่งต่อ หากต้องการให้ Cloudflare รับข้อความของโดเมนหลัก ให้แก้ความขัดแย้งของ MX ตามรายการที่แดชบอร์ดกำหนด โดยยังเก็บค่าของผู้ให้บริการเดิมไว้สำหรับย้อนกลับ อย่าปิดกล่องเดิมทันที เพราะข้อมูล DNS ที่ผู้ส่งบางรายใช้อาจยังไม่เปลี่ยนตาม

ระเบียน SPF และ DKIM มีหน้าที่ต่างจาก MX จึงต้องตรวจแยกกัน SPF ของโดเมนหลักอาจมีค่าที่อนุญาตบริการส่งอีเมลเดิมอยู่แล้ว หาก Cloudflare เพิ่มค่า SPF สำหรับการส่งต่อ ให้รวมการอนุญาตที่จำเป็นไว้ในระเบียน SPF ของชื่อเดียวกัน แทนการปล่อยค่า SPF ที่เริ่มด้วย v=spf1 หลายระเบียน ส่วน DKIM ให้ดูชื่อ selector ก่อนแก้ไข เพราะกุญแจของบริการเดิมและของการส่งต่ออาจอยู่คนละชื่อ การแทนค่าระเบียนโดยคัดลอกจากโดเมนอื่น อาจทำให้การยืนยันอีเมลของระบบส่งเดิมเสียไป

แยกการรับและการส่งอีเมลออกจากกันด้วย MX ที่ Email Routing เพิ่มให้โดเมนหลักใช้รับข้อความ ส่วนระบบส่งอีเมลเดิมอาจยังต้องใช้ค่า SPF และ DKIM ของตนเพื่อส่งข้อความออก การตั้งกฎให้ข้อความขาเข้าไปถึงกล่องปลายทาง ไม่ได้สร้างกล่องส่งอีเมลในนามที่อยู่บนโดเมน หากต้องตอบกลับด้วยชื่อนั้น ให้ตรวจความสามารถและการตั้งค่าการส่งของผู้ให้บริการกล่องปลายทางต่างหาก

ยืนยันปลายทางแล้วสร้างกฎให้ครบ

ไปที่ Compute > Email Service > Email Routing > Destination Addresses เพิ่มกล่องที่จะรับข้อความ แล้วเปิดอีเมลยืนยันในกล่องนั้นเพื่อเลือก Verify email address คำอธิบายที่อยู่ปลายทางและกฎ ระบุว่ากฎที่ชี้ไปยังที่อยู่ซึ่งยังไม่ยืนยันจะคงสถานะปิดอยู่ หากอีเมลยืนยันไม่มาถึง ให้ตรวจกล่องสแปมและความถูกต้องของที่อยู่ หรือสั่งส่งอีเมลยืนยันอีกครั้งก่อนเดินหน้าทดสอบกฎ

เมื่อปลายทางมีสถานะยืนยันแล้ว ให้เลือกโดเมน เปิด Routing Rules และเลือก Create routing rule ใน Email pattern ใส่เฉพาะส่วนหน้าของที่อยู่ที่ต้องการรับ เช่น info สำหรับที่อยู่ info@โดเมนของคุณ แล้วเลือกโดเมนให้ถูกต้อง ตั้ง Action เป็น Send to an email เลือกที่อยู่ปลายทางที่ยืนยันแล้ว และกด Save หลังบันทึกให้ดูทั้งชื่อที่อยู่ต้นทาง ปลายทาง และสถานะ Active เพราะการสะกดส่วนหน้าอีเมลผิดเพียงตำแหน่งเดียวจะทำให้กฎไม่ตรงกับข้อความที่ต้องการ

สร้างกฎสำหรับที่อยู่ซึ่งใช้งานจริงตามรายการที่สำรวจไว้ หากหลายชื่อควรไปยังกล่องเดียวกัน ก็ยังต้องตรวจว่าแต่ละชื่อมีกฎที่ตรงกัน อย่าสมมติว่ากฎของ info จะรับข้อความที่ส่งถึง sales ด้วย หากสร้าง Email pattern ซ้ำกัน กฎที่ปรากฏก่อนในรายการของแดชบอร์ดจะเป็นตัวจัดการข้อความ จึงควรแก้รายการซ้ำก่อนทดสอบ เพื่อไม่ให้ผลขึ้นอยู่กับลำดับกฎที่ไม่ได้ตั้งใจ

กฎ Catch-all เป็นอีกทางเลือกหนึ่งเมื่อเจ้าของโดเมนต้องการรับข้อความที่ส่งถึงชื่อซึ่งไม่ได้กำหนดกฎเฉพาะไว้ แต่กฎนี้รวมถึงข้อความที่สะกดชื่อผิดด้วย จึงอาจนำข้อความที่ไม่ต้องการเข้าสู่กล่องปลายทาง การเปิด Catch-all ควรเป็นการเลือกอย่างตั้งใจหลังสำรวจที่อยู่เดิม ไม่ใช่วิธีชดเชยการลืมสร้างกฎให้ที่อยู่สำคัญ หากต้องการเพียงชื่อที่ใช้ทำงานจริง ให้สร้างกฎเฉพาะชื่อและทดสอบทีละชื่อ

อย่าลบที่อยู่ปลายทางที่ใช้งานอยู่เพื่อจัดระเบียบรายการโดยไม่ตรวจความเชื่อมโยงก่อน การลบปลายทางทำให้กฎที่ชี้ไปยังที่อยู่นั้นถูกปิด แม้ Email pattern จะยังอยู่ในรายการ เช่นเดียวกัน การปิดกฎด้วยสถานะ Disabled จะหยุดการส่งต่อของกฎนั้น จึงควรตรวจสถานะอีกครั้งหลังแก้ไขรายการหรือเปลี่ยนกล่องรับ

ทดสอบข้อความใหม่จากบัญชีอื่น

ส่งอีเมลใหม่จากบัญชีที่ต่างจากกล่องปลายทาง ไปยังที่อยู่บนโดเมนซึ่งเพิ่งสร้างกฎ ระบุหัวเรื่องที่จำได้และจดเวลาส่งไว้ แล้วตรวจว่าข้อความเดียวกันปรากฏในกล่องปลายทางพร้อมผู้ส่งและหัวเรื่องที่คาดไว้ การส่งจากกล่องปลายทางกลับเข้าหาตัวเองอาจให้ผลหลอก เพราะผู้ให้บริการบางรายจัดการข้อความที่ดูเหมือนส่งกลับเข้าบัญชีเดียวกันต่างจากข้อความทั่วไป

เริ่มจากที่อยู่สำคัญที่สุด แล้วทดลองชื่ออื่นตามรายการที่เตรียมไว้ หากมีหลายกล่องปลายทาง ให้ยืนยันว่าข้อความไปถึงกล่องที่จับคู่ไว้จริง อย่าใช้ผลสำเร็จของกฎหนึ่งรายการแทนข้อสรุปว่าทั้งโดเมนรับข้อความได้ครบ การทดสอบควรใช้ข้อความที่ส่งหลังเปลี่ยน DNS เพราะข้อความที่ส่งก่อนเปลี่ยนค่าอาจอยู่ระหว่างส่งตามเส้นทางเดิม

1. ตรวจกล่องปลายทางและโฟลเดอร์สแปม โดยเทียบหัวเรื่อง ผู้ส่ง และเวลาของข้อความทดสอบ
2. ตรวจกล่องเดิมในช่วงเปลี่ยนเส้นทาง หากข้อความไปถึงที่นั่น ให้ตรวจ MX ที่เผยแพร่ก่อนสรุปว่ากฎใหม่เสีย
3. ทดสอบทุกที่อยู่ที่ต้องใช้รับข้อความ และตรวจว่าผลตรงกับกล่องปลายทางที่กำหนดให้ชื่อนั้น
4. หากผู้ส่งได้รับข้อความตีกลับ ให้เก็บรายละเอียดข้อผิดพลาดไว้ เพื่อแยกปัญหาที่เส้นทางรับออกจากการปฏิเสธของกล่องปลายทาง

เมื่อข้อความไม่ปรากฏ ให้ไล่จากจุดที่ตรวจได้ง่ายที่สุดก่อน ดูว่า Destination Address เป็น Verified และกฎเป็น Active จากนั้นตรวจ Email pattern ชื่อโดเมน และ Action หากส่วนนี้ถูกต้อง ให้ตรวจ MX ที่เผยแพร่ของโดเมนจริง ไม่ใช่ดูเฉพาะรายการในแดชบอร์ด คำสั่ง dig MX ตามด้วยชื่อโดเมนช่วยแสดง MX ที่ตัวตรวจ DNS มองเห็น และช่วยเทียบกับค่าที่ตั้งใจให้ผู้ส่งภายนอกใช้

ผลทดสอบแต่ละแบบชี้ไปคนละปัญหา หากข้อความอยู่ในสแปม แสดงว่ามาถึงกล่องปลายทางแล้ว แต่การจัดหมวดหมู่ของกล่องยังต้องตรวจ หากข้อความอยู่เฉพาะกล่องเดิม ให้ดู MX และช่วงที่ DNS ยังเปลี่ยนไม่ทั่วถึง หากไม่เข้าทั้งสองกล่องและมีข้อความตีกลับ ให้ใช้รายละเอียดการตีกลับตรวจเส้นทางและการยอมรับข้อความ แยกผลเหล่านี้ก่อนแก้ DNS ซ้ำ เพราะการเปลี่ยนค่าหลายอย่างพร้อมกันจะทำให้ระบุสาเหตุยากขึ้น

ระหว่างการกระจาย DNS ให้เปิดตรวจทั้งกล่องเดิมและกล่องปลายทางต่อไป ข้อความจากผู้ส่งต่างรายอาจไม่ได้ใช้ข้อมูล DNS ชุดเดียวกันในเวลาเดียวกัน จึงไม่ควรปิดบัญชีอีเมลเดิมเพียงเพราะข้อความทดลองฉบับหนึ่งเข้ากล่องใหม่แล้ว สำหรับที่อยู่ที่รับคำสั่งซื้อหรือข้อความติดต่อสำคัญ ให้ตรวจข้อความใหม่จากผู้ส่งภายนอกตามการใช้งานจริง ก่อนถือว่าการเปลี่ยนเส้นทางเสร็จสิ้น

ย้อนกลับเมื่อเส้นทางใหม่รับข้อความไม่ได้

หากตรวจแล้วพบว่า MX ชี้ผิดที่ หรือยังทำให้ข้อความเข้าปลายทางไม่ได้ ให้ใช้ค่าที่บันทึกไว้คืน MX ของผู้ให้บริการเดิม โดยใส่ชื่อโฮสต์และ priority ให้ตรง ตรวจว่าบัญชีเดิมยังเปิดรับข้อความ แล้วส่งอีเมลใหม่จากบัญชีภายนอกเพื่อยืนยันผล การเห็น MX เดิมกลับมาในหน้า DNS ยังไม่เท่ากับการรับข้อความสำเร็จ ต้องเห็นข้อความใหม่เข้ากล่องเดิมจริง

ถ้าจะปิด Email Routing ให้จัดลำดับการเปลี่ยนค่าอย่างระมัดระวัง การปิดบริการจะหยุดประมวลผลข้อความขาเข้าและลบ MX, SPF และ DKIM ที่บริการเพิ่มให้โดเมน แม้ปลดล็อกระเบียนที่ Cloudflare สร้างแล้วแก้ให้ชี้ไปยังผู้ให้บริการอื่น ระเบียนนั้นยังคงผูกกับบริการและอาจถูกลบเมื่อปิด ให้สร้างระเบียนของผู้ให้บริการเดิมเป็นระเบียนของตนเอง ตรวจค่าที่เผยแพร่ แล้วจึงถอดเส้นทางที่ไม่ใช้

หลังย้อนกลับ ให้ตรวจทั้งกล่องเดิมและกล่องปลายทางต่อในช่วงที่ผู้ส่งอาจยังเห็นค่า DNS ต่างกัน หากมีข้อความเข้ากล่องใหม่ก่อนคืนค่า ให้จัดการข้อความเหล่านั้นแยกจากข้อความที่กลับมาเข้ากล่องเดิม วิธีนี้ช่วยไม่ให้พลาดงานที่มาถึงระหว่างเปลี่ยนเส้นทาง และทำให้ระบุได้ว่าการรับอีเมลกลับมาทำงานกับผู้ให้บริการเดิมเมื่อใด

อ่านเพิ่มเติม:

• ตั้ง DKIM ให้ Google Workspace: ส่งเมลได้ยังไม่แปลว่าลายเซ็นผ่าน