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

ระเบียนทรัพยากรเป็นองค์ประกอบข้อมูลพื้นฐานของระบบชื่อโดเมน (DNS) ระเบียน MX เป็นหนึ่งในนั้น และโดเมนอาจมีระเบียนเหล่านี้อย่างน้อยหนึ่งรายการที่ตั้งค่าไว้ ดังต่อไปนี้:

โดเมนTTL คลาสประเภทลำดับความสำคัญโฮสต์example.com. 1936 IN MX 10 onemail.example.com. example.com. 1936 IN MX 10 twomail.example.com.

ข้อมูลเพย์โหลดลักษณะเฉพาะของระเบียน MX ^{[ 1 ]}คือค่าลำดับความสำคัญ (ด้านบนมีป้ายกำกับว่า "ลำดับความสำคัญ") และชื่อโดเมนของเซิร์ฟเวอร์อีเมล ("โฮสต์" ด้านบน)

ฟิลด์ลำดับความสำคัญระบุว่าควรเลือกใช้เซิร์ฟเวอร์อีเมลใด ในกรณีนี้ค่าทั้งสองคือ 10 ดังนั้นอีเมลจึงคาดว่าจะไหลไปยังonemail.example.comและtwomail.example.com อย่างเท่าเทียมกัน ซึ่งเป็นการกำหนดค่าทั่วไป ชื่อโฮสต์ต้องแมปโดยตรงกับ ระเบียนที่อยู่หนึ่งรายการขึ้นไป(A หรือ AAAA) ใน DNS และต้องไม่ชี้ไปยังระเบียนCNAME ใดๆ ^{[ 2 ]}

เมื่อส่งข้อความอีเมลผ่านทางอินเทอร์เน็ตตัวแทนการถ่ายโอนอีเมล (MTA) ที่ส่งจะสอบถามระบบชื่อโดเมนสำหรับระเบียน MX ของชื่อโดเมน ของผู้รับแต่ละราย การสอบถามนี้จะส่งคืนรายการชื่อโฮสต์ของเซิร์ฟเวอร์แลกเปลี่ยนอีเมลที่ยอมรับอีเมลขาเข้าสำหรับโดเมนนั้นและการตั้งค่าต่างๆ จากนั้นตัวแทนที่ส่งจะพยายามสร้างการเชื่อมต่อ SMTP โดยลองใช้โฮสต์ที่มีค่า "ลำดับความสำคัญ" ต่ำที่สุดก่อน ระบบอนุญาต ให้สร้าง คลัสเตอร์เกตเวย์อีเมลที่มีความพร้อมใช้งานสูงสำหรับโดเมนเดียวหากจำเป็น^{[ 3 ]}

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

ตาม RFC 5321 บันทึกที่มีหมายเลขต่ำที่สุดถือเป็นที่ต้องการมากที่สุด^{[ 4 ]}วลีนี้อาจทำให้สับสน ดังนั้น บางครั้ง หมายเลขลำดับความสำคัญจึงถูกเรียกว่าระยะทาง : ระยะทางที่น้อยกว่าจะเหมาะสมกว่า RFC ฉบับเก่ากว่า RFC 974 ระบุว่าเมื่อหมายเลขลำดับความสำคัญเหมือนกันสำหรับเซิร์ฟเวอร์สองเครื่อง เซิร์ฟเวอร์เหล่านั้นจะมีลำดับความสำคัญ เท่ากัน ดังนั้นจึงใช้สองคำนี้แทนกันได้

หมายเลขการตั้งค่าเป็น ฟิลด์ 16 บิต ที่ไม่มีเครื่องหมาย ^{[ 5 ] [ 5 ] [ 6 ]}ดังนั้นค่าที่ถูกต้องจึงอยู่ในช่วงตั้งแต่ 0 ถึง 65535

ในกรณีที่ง่ายที่สุด โดเมนอาจมีเซิร์ฟเวอร์อีเมลเพียงตัวเดียว ตัวอย่างเช่น หาก MTA ค้นหาข้อมูล MX สำหรับexample.comและเซิร์ฟเวอร์ DNS ตอบกลับด้วย mail.example.com เท่านั้น โดยมีหมายเลขลำดับความสำคัญเป็น 50 MTA จะพยายามส่งอีเมลไปยังเซิร์ฟเวอร์ที่ระบุไว้ ในกรณีนี้ หมายเลข 50 อาจเป็นจำนวนเต็มใดๆ ก็ได้ที่ได้รับอนุญาตตามข้อกำหนด SMTP

เมื่อมีการส่งคืนเซิร์ฟเวอร์มากกว่าหนึ่งรายการสำหรับการสอบถาม MX เซิร์ฟเวอร์ที่มีหมายเลขลำดับความสำคัญน้อยที่สุดจะต้องถูกลองก่อน หากมีระเบียน MX มากกว่าหนึ่งรายการที่มีหมายเลขลำดับความสำคัญเดียวกัน จะต้องลองระเบียนเหล่านั้นทั้งหมดก่อนที่จะไปยังรายการที่มีลำดับความสำคัญต่ำกว่า ไคลเอนต์ SMTP จะต้องสามารถลอง (และลองใหม่) ที่อยู่แต่ละรายการที่เกี่ยวข้องในรายการตามลำดับ จนกว่าการพยายามส่งจะสำเร็จ^{[ 4 ]}

แนวทางมาตรฐานในการกระจายภาระของอีเมลขาเข้าไปยังเซิร์ฟเวอร์หลายตัวคือการส่งคืนหมายเลขลำดับความสำคัญเดียวกันสำหรับแต่ละเซิร์ฟเวอร์ในชุด เมื่อพิจารณาว่าควรส่งอีเมลไปยังเซิร์ฟเวอร์ใดที่มีลำดับความสำคัญเท่ากัน "ผู้ส่ง-SMTP ต้องสุ่มเลือกเซิร์ฟเวอร์เหล่านั้นเพื่อกระจายภาระไปยังตัวแลกเปลี่ยนอีเมลหลายตัวสำหรับองค์กรเฉพาะ" เว้นแต่จะมีเหตุผลที่ชัดเจนที่จะเลือกเซิร์ฟเวอร์ใดเซิร์ฟเวอร์หนึ่งเป็นพิเศษ^{[ 4 ]}

แนวทางอื่นคือการใช้ เซิร์ฟเวอร์ แบบมัลติโฮมโดยที่โฮสต์หนึ่งตัวจะส่งคืนที่อยู่ IP หลายรายการ^{[ 3 ]}วิธีนี้จะทำให้ภาระตกอยู่กับ DNS แทนที่จะเป็นผู้ส่ง SMTP ในการดำเนินการโหลดบาลานซ์ ซึ่งในกรณีนี้จะแสดงรายการที่อยู่ IP ตามลำดับที่กำหนดให้กับไคลเอนต์ที่สอบถามเรคอร์ด A ของตัวแลกเปลี่ยนอีเมล เนื่องจาก RFC กำหนดให้ผู้ส่ง SMTP ใช้ลำดับที่ให้ไว้ในการสอบถามเรคอร์ด A เซิร์ฟเวอร์ DNS จึงมีอิสระที่จะจัดการการบาลานซ์อย่างระมัดระวังตามวิธีการใดๆ ก็ได้ รวมถึงDNS แบบรอบโรบินโหลดเซิร์ฟเวอร์อีเมล หรือรูปแบบลำดับความสำคัญที่ไม่เปิดเผย

ผู้ส่งสแปมอาจจงใจส่งอีเมลไปยังเซิร์ฟเวอร์ MX สำรอง (ระยะไกล) ของโดเมนก่อน โดยสันนิษฐานว่าเซิร์ฟเวอร์ดังกล่าวจะมีตัวกรองสแปมที่มีประสิทธิภาพน้อยกว่า เทคนิคป้องกันสแปมที่เรียกว่าnolisting นั้น อิงตามสมมติฐานนี้

RFC SMTP ^{[ 4 ]}คลุมเครือเกี่ยวกับความล้มเหลวในการส่งมอบประเภทใดที่ต้องส่งผลให้มีการพยายามส่งมอบอีกครั้งผ่านระเบียน MX ที่อยู่ไกลออกไป (ระเบียนที่มีค่าลำดับความสำคัญสูงกว่า)

เมื่อเซิร์ฟเวอร์แสดงสัญญาณความล้มเหลวชั่วคราว ไม่ว่าจะโดยการส่งข้อผิดพลาด 4xx อย่างชัดเจน หรือโดยการยุติการเชื่อมต่อโดยไม่คาดคิด (ซึ่งต้องถือว่าเป็นข้อผิดพลาด 451 ตามมาตรา 3.8ของ RFC) มาตรา 4.5.4.1ระบุว่า:

ผู้ส่งต้องเลื่อนเวลาการลองส่งซ้ำไปยังปลายทางที่กำหนดหลังจากที่การส่งครั้งแรกไม่สำเร็จ

อย่างไรก็ตาม เมื่อผู้ส่งลองส่งอีกครั้ง RFC ไม่ได้ระบุว่าควรส่งไปยังเซิร์ฟเวอร์เดิมหรือระเบียน MX ที่ "ไกลออกไป" แต่ระบุไว้ในส่วนที่ 5.1ว่า:

เมื่อการค้นหาสำเร็จ การแมปอาจส่งผลให้ได้รายการที่อยู่จัดส่งทางเลือกหลายรายการแทนที่จะเป็นที่อยู่เดียว เนื่องจากมีระเบียน MX หลายรายการ การเชื่อมต่อหลายเส้นทาง หรือทั้งสองอย่าง เพื่อให้การส่งอีเมลมีความน่าเชื่อถือ ไคลเอนต์ SMTP ต้องสามารถลอง (และลองใหม่อีกครั้ง) ที่อยู่แต่ละรายการในรายการนี้ตามลำดับ จนกว่าการส่งจะสำเร็จ

เซิร์ฟเวอร์บางตัว (เช่นSendmailและPostfix 2.1 หรือเวอร์ชันที่ใหม่กว่า) ^{[ 7 ]}จะพยายามใช้เซิร์ฟเวอร์ MX ที่อยู่ไกลที่สุดถัดไปหลังจากความล้มเหลวในการส่งชั่วคราวบางประเภท เช่น ความล้มเหลวในการทักทาย^{[ 8 ]}เซิร์ฟเวอร์อื่นๆ (เช่นqmailและPostfix 2.0 หรือเวอร์ชันก่อนหน้า) จะใช้ระเบียน MX ที่อยู่ไกลกว่าก็ต่อเมื่อไม่สามารถติดต่อเซิร์ฟเวอร์ที่ระบุไว้ในระเบียน MX ที่มีระยะทางสั้นที่สุดได้เลย แม้จะมีความแตกต่างกัน แต่พฤติกรรมทั้งสองแบบนั้นก็ถูกต้อง เนื่องจาก RFC ไม่ได้ระบุเจาะจง

ในกรณีที่ไม่มีระเบียน MX ผู้ส่งอีเมลจะพยายามส่งไปยังระเบียนที่อยู่ เช่น example.com

ข้อมูลนี้อ้างอิงจาก RFC 5321 มาตรา 5.1 ซึ่งระบุไว้ว่า:

• ไคลเอนต์ SMTP ต้องค้นหาข้อมูลระเบียน MX;
• ถ้า ( และเฉพาะในกรณีที่ ) ไม่มีระเบียน MX สำหรับโดเมนนั้น ให้ถือว่าโดเมนนั้นมีระเบียน MX โดยใช้โดเมนที่กำหนดเป็นชื่อโฮสต์เป้าหมายและค่าความสำคัญเป็น 0
• ทำการค้นหาแบบ A หรือ AAAA ตามความจำเป็นเพื่อกำหนดที่อยู่ IPของชื่อโฮสต์เป้าหมาย

RFC 821 เผยแพร่ในปี 1982 โดยมีการกล่าวถึง DNS เพียงเล็กน้อย เนื่องจากในขณะนั้น การเปลี่ยนจากHOSTS.TXTไปใช้ DNS ยังไม่ได้เริ่มต้น RFC 883 ซึ่งเป็นคำอธิบายแรกของ DNS เผยแพร่หลังจากนั้นกว่าหนึ่งปี ในช่วงปลายปี 1983 โดยอธิบายถึงเรคอร์ด MD และ MF ซึ่งเป็นเรคอร์ดทดลองและใช้งานน้อย ตาม RFC 897 และ RFC 921 การเปลี่ยนไปใช้ DNS เริ่มต้นในปี 1983 แต่ HOSTS.TXT ยังไม่มีกำหนดการยกเลิกใช้งานจนถึงปลายปี 1985 และไม่ได้ถูกยกเลิกใช้งานอย่างสมบูรณ์จนกระทั่งปลายทศวรรษ 1990

ในเดือนมกราคม พ.ศ. 2529 RFC 973 และ RFC 974 ได้ยกเลิกเรคอร์ด MD และ MF แทนที่ด้วย MX และกำหนดการค้นหา MX โดยใช้ A เป็นตัวเลือกสำรอง RFC 974 แนะนำให้ไคลเอ็นต์ทำการค้นหาWKS ^{[ 9 ]}บนโฮสต์ MX แต่ละตัวเพื่อดูว่ารองรับ SMTP จริงหรือไม่ และทิ้งรายการ MX หากไม่รองรับ อย่างไรก็ตาม RFC 1123 ได้เปลี่ยนข้อความนี้โดยระบุว่าไม่ควรตรวจสอบ WKS

นั่นหมายความว่า SMTP ได้ถูกใช้งานมาอย่างน้อยหนึ่งปีโดยใช้ HOSTS.TXT จากนั้นอีกสองสามปีโดยใช้ A, MD และ MF ก่อนที่ MX จะเข้ามา MD และ MF นั้นใช้งานยาก ดังนั้นคนส่วนใหญ่จึงใช้เรคอร์ด A ในสถานการณ์เช่นนี้ MX ที่ไม่มีการสำรองข้อมูลไปยัง A จะไม่สามารถใช้งานได้เนื่องจากมีฐานเซิร์ฟเวอร์อีเมลจำนวนมากที่ใช้เรคอร์ด A การใช้งาน MX ในช่วงแรกนั้นเพื่อระบุเกตเวย์ไปยังเครือข่ายอื่น แต่ไม่ได้มีการใช้งานอย่างแพร่หลายจนกระทั่ง DNS ได้รับการจัดตั้งขึ้นอย่างดีในช่วงต้นทศวรรษ 1990 ^{[ 10 ]}

• RFC  1035 (1987), ชื่อโดเมน - การนำไปใช้และข้อกำหนด
• RFC  1912 (1996) ข้อผิดพลาดทั่วไปในการใช้งานและการกำหนดค่า DNS
• RFC  5321 (2008), โปรโตคอลการถ่ายโอนอีเมลแบบง่าย
• RFC  7505 (2015) ระเบียนทรัพยากร "Null MX" สำหรับโดเมนที่ไม่รับอีเมล

ล้าสมัย:

• RFC  974 (1986), การกำหนดเส้นทางอีเมลและระบบโดเมน (ถูกยกเลิกโดย RFC-5321)
• RFC  2821 (2001) โปรโตคอลการถ่ายโอนอีเมลแบบง่าย (ถูกยกเลิกโดยRFC-5321 )

• บันทึก SRV
• กรอบนโยบายผู้ส่ง
• รายการประเภทระเบียน DNS
• บันทึก
• ไม่แสดงรายการ