เมื่อส่งอีเมลไม่ถึงผู้รับ หรือรับอีเมลไม่ได้ สาเหตุหนึ่งที่พบบ่อยคือ MX Record ตั้งค่าผิดหรือ Propagate ไม่สมบูรณ์ MXToolbox คือเครื่องมือฟรีที่นักพัฒนาและผู้ดูแลเซิร์ฟเวอร์ใช้ตรวจสอบ Email DNS ในทุกมิติ ตั้งแต่ MX, SPF, DKIM, Blacklist ไปจนถึง SMTP ทดสอบจริง
MX Record คืออะไร ทำงานอย่างไร
MX Record (Mail Exchanger) คือ DNS Record ที่บอกว่า "อีเมลที่ส่งมายังโดเมนนี้ให้ส่งไปยัง Server ไหน" เมื่อใครส่งอีเมลถึง [email protected] Mail Server ผู้ส่งจะ Lookup MX Record ของ company.com เพื่อหาที่อยู่ Server รับอีเมล ถ้า MX Record ผิดหรือหาย อีเมลจะ Bounce กลับทันที
วิธีใช้ MXToolbox ตรวจสอบ MX Record
- เข้าเว็บ mxtoolbox.com
- พิมพ์โดเมนของคุณในช่อง เช่น
company.com - เลือก MX Lookup และกด Enter
- ระบบจะแสดง MX Record ทั้งหมด พร้อม Priority ของแต่ละ Server
- ตรวจว่า Hostname ถูกต้อง Priority ต่ำ = รับอีเมลก่อน
ตรวจ MX ด้วยคำสั่ง (dig MX, nslookup) นอกจาก MXToolbox
นอกจากเว็บ MXToolbox คุณตรวจ MX Record ได้ตรงจาก Terminal ของคุณเองโดยไม่ต้องพึ่งเว็บภายนอก เหมาะเวลาต้องการความเร็ว หรือต้องการ Query DNS Server เฉพาะตัว คำสั่งหลักคือ dig (Linux/macOS) และ nslookup (Windows/ทุกระบบ) ทั้งสองให้ผลเหมือนการ Lookup บน MXToolbox แต่ทำงานในเครื่องของคุณ
ตรวจ MX Record ด้วย dig แบบสั้นเห็นเฉพาะค่าที่ต้องการ:
dig MX company.com +short
# ผลลัพธ์ตัวอย่าง:
# 10 mail.company.com.
# 20 mail2.company.com.ดูรายละเอียดเต็มรวม TTL และ Section ทั้งหมด:
dig MX company.com
;; ANSWER SECTION:
company.com. 3600 IN MX 10 mail.company.com.
company.com. 3600 IN MX 20 mail2.company.com.บน Windows หรือเครื่องที่ไม่มี dig ใช้ nslookup แทนได้:
nslookup -type=mx company.com
# หรือระบุ DNS Server เองเพื่อ Bypass cache:
nslookup -type=mx company.com 8.8.8.8อยากตรวจให้ลึกกว่านั้น สั่ง dig ถาม Authoritative Nameserver ตรงๆ เพื่อเลี่ยงค่า cache ที่ยังเก่า:
dig MX company.com @ns1.yourhost.comอ่านผล MX อย่างไร (Priority, หลาย Record, Fallback)
เมื่อ MX Lookup คืนค่ามาหลายบรรทัด ตัวเลขหน้า Hostname คือ Priority (หรือ Preference) ค่ายิ่งน้อยยิ่งถูกเลือกก่อน ตัวอย่างด้านบน 10 mail.company.com จะรับอีเมลก่อน ส่วน 20 mail2.company.com เป็น Backup ที่จะรับเมื่อ Server แรก Offline หรือเต็ม
- Priority ต่ำสุด = Server หลัก — Mail Server ผู้ส่งจะลองส่งไปที่นี่ก่อนเสมอ
- Priority สูงกว่า = Fallback — ใช้เมื่อ Server หลักตอบไม่ได้ ช่วยให้อีเมลไม่หายระหว่าง Maintenance
- Priority เท่ากันหลายตัว — ระบบจะกระจายโหลด (Load Balance) แบบสุ่มระหว่าง Server เหล่านั้น
- มี MX เดียว — ใช้ได้ปกติแต่ไม่มี Fallback ถ้า Server ล่ม อีเมลจะค้างใน Queue ผู้ส่งจนกว่าจะกลับมา
เคล็ดลับสำคัญ: Hostname ใน MX Record ต้องเป็น A/AAAA Record ที่ Resolve เป็น IP จริง ห้ามชี้ไปยัง CNAME เพราะ RFC ห้าม MX ชี้ไป CNAME — เป็นสาเหตุยอดฮิตที่ทำให้บาง Server ปฏิเสธอีเมล
อีกจุดที่หลายคนเข้าใจผิดคือ คิดว่าตัวเลข Priority ยิ่งมากยิ่งสำคัญ แต่จริงๆ แล้วกลับกัน ตัวเลขเป็นเพียง "ลำดับการลอง" ของฝั่งผู้ส่ง ไม่เกี่ยวกับคุณภาพของ Server แต่อย่างใด เวลาคุณวางแผนระบบอีเมลที่มีหลายเครื่อง ควรกำหนดให้ Server ที่แรงและเสถียรที่สุดมี Priority ต่ำสุด เพื่อรับโหลดหลัก ส่วนเครื่องสำรองตั้งค่าให้สูงขึ้นตามลำดับ และอย่าลืมว่าทุก Hostname ที่ใส่ใน MX จะต้องเปิดพอร์ต 25 และพร้อมรับอีเมลจริง มิฉะนั้น Fallback จะไม่เกิดประโยชน์ การตรวจสอบเป็นประจำหลังตั้งค่าจึงสำคัญ เพราะค่าที่เคยถูกอาจเพี้ยนได้เมื่อย้าย Hosting เปลี่ยน IP หรือเผลอแก้ Zone ผิด การรัน MX Check ซ้ำเป็นระยะช่วยให้คุณจับความผิดพลาดได้ก่อนที่ลูกค้าหรือคู่ค้าจะร้องเรียนว่าอีเมลส่งไม่ถึง
ปัญหาที่ MX Check ช่วยจับได้ (Blacklist, Reverse DNS/PTR, SPF, Open Relay)
การตรวจ MX อย่างครบถ้วนไม่ได้บอกแค่ว่า Record ถูกหรือผิด แต่ยังช่วยขุดปัญหาเบื้องหลังที่ทำให้อีเมลตก Spam หรือถูกปฏิเสธได้หลายอย่าง ปัญหาส่วนใหญ่ที่ทำให้อีเมลธุรกิจส่งไม่ถึงผู้รับมักไม่ได้เกิดจาก MX Record โดยตรง แต่เกิดจากสุขภาพโดยรวมของระบบส่งอีเมลที่ไม่ได้รับการดูแล เครื่องมือตรวจสอบที่ดีจึงควรรายงานทั้งหมดนี้ในที่เดียว เพื่อให้คุณเห็นภาพรวมและไล่แก้ได้เป็นลำดับ ไม่ต้องเดาทีละจุด ต่อไปนี้คือปัญหาหลักที่การตรวจ MX และ Email Health ช่วยจับได้:
IP ติด Blacklist (RBL/DNSBL)
ถ้า IP ของ Mail Server อยู่ใน Blacklist เช่น Spamhaus หรือ Barracuda อีเมลจะถูก Reject หรือเข้า Junk ทันที MX Check จะรายงานว่าติดกี่รายการ และให้ลิงก์ขอ Delist
Reverse DNS / PTR ไม่ตรง
Server รับอีเมลปลายทางมักเช็คว่า IP ผู้ส่งมี PTR Record ที่ตรงกับ Hostname (FCrDNS) ถ้าไม่มีหรือไม่ตรง อีเมลจะถูกหักคะแนนความน่าเชื่อถือ ตรวจด้วย dig -x YOUR.IP +short
SPF ไม่ครอบคลุมหรือผิด Syntax
SPF ที่ขาด IP ผู้ส่ง หรือมีหลาย Record ซ้อนกัน ทำให้ Receiver มองว่า Spoof MX Check จะเตือนเมื่อ SPF มี +all หลวมเกิน หรือเกิน 10 DNS Lookup (PermError)
Server เป็น Open Relay
SMTP Test ช่วยตรวจว่า Server ยอมรับและส่งต่ออีเมลให้คนนอกโดยไม่ Authentication หรือไม่ Open Relay เสี่ยงถูกใช้ส่งสแปมและติด Blacklist เร็วมาก ต้องปิดทันที
ขั้นตอนแก้เมื่อ MX ผิด
เมื่อ MX Check ชี้ว่ามีปัญหา อย่ารีบแก้แบบสุ่ม เพราะการแก้ผิดจุดอาจทำให้อีเมลล่มทั้งระบบและกู้คืนยากกว่าเดิม ให้ทำตามขั้นตอนต่อไปนี้อย่างเป็นลำดับ ตั้งแต่ยืนยันค่าที่ถูกต้อง ไปจนถึงการตรวจสอบซ้ำหลัง Propagation เสร็จ วิธีนี้ช่วยให้คุณแก้ได้ตรงจุดและลดความเสี่ยงที่อีเมลจะหายระหว่างทาง:
- ยืนยันค่าที่ถูกต้องก่อน — ดูจากผู้ให้บริการอีเมล/Hosting ว่า MX ที่ถูกคือ Hostname และ Priority อะไร (ของ AsiaGB คือ
mail.yourdomain.comPriority10) - เข้า DNS Management — DirectAdmin → DNS Management หรือที่ Nameserver จริงที่โดเมนใช้อยู่ (ตรวจด้วย
dig NS company.comว่าใครคุม Zone) - ลบ MX เก่าที่ผิด แล้วเพิ่มใหม่ให้ Hostname Resolve เป็น A Record จริง ไม่ใช่ CNAME
- ปรับ SPF ให้ครอบคลุม —
v=spf1 +a +mx +ip4:YOUR.IP ~allและตรวจว่ามี SPF เพียง Record เดียว - ลด TTL ชั่วคราว เป็น 300 วินาทีก่อนแก้ เพื่อให้ค่าใหม่ Propagate เร็ว แล้วค่อยตั้งกลับเป็น 3600 เมื่อทุกอย่างนิ่ง
- รอ Propagation แล้วตรวจซ้ำ — รัน
dig MX company.com +shortจากหลายเครือข่าย หรือใช้ DNS Propagation Check จนได้ค่าตรงกันทั่วโลก
ฟีเจอร์อื่นของ MXToolbox ที่ควรใช้
Email Health Check
ตรวจสอบทุกอย่างครั้งเดียว: MX, SPF, DKIM, DMARC, Blacklist, Reverse DNS — แนะนำให้รันก่อน Go-Live ทุกครั้ง
Blacklist Check
ตรวจสอบว่า IP ของ Server อยู่ใน Blacklist กี่รายการ ถ้าติด Blacklist อีเมลจะถูก Reject หรือตก Spam
SMTP Test
ทดสอบการเชื่อมต่อ SMTP Server จริง แสดง Banner, EHLO, STARTTLS — ใช้ Debug ได้เมื่อส่งอีเมลไม่ได้
DNS Propagation Check
ตรวจว่า MX Record ที่แก้ไขใหม่ Propagate ไปถึง DNS Server ทั่วโลกแล้วหรือยัง ใช้หลังเปลี่ยน Nameserver
ปัญหาที่พบบ่อยและวิธีแก้
MX Record ไม่มีหรือค่าว่าง
เข้า DirectAdmin → DNS Management → เพิ่ม MX Record ค่าปกติสำหรับ Hosting AsiaGB คือ mail.yourdomain.com Priority 10
MX ชี้ไปผิด Server
ตรวจสอบว่า Hostname ใน MX Record Resolve เป็น IP ของ Server ที่ถูกต้อง (ตรวจด้วย A Lookup บน MXToolbox)
SPF Record ไม่ครอบคลุม IP
เพิ่ม IP ของ Server ลงใน SPF: v=spf1 +a +mx +ip4:YOUR.IP ~all
เคล็ดลับ: หลังแก้ไข DNS Record ใดก็ตาม รอ Propagation 24-48 ชั่วโมงก่อนทดสอบซ้ำ ค่า TTL ที่ต่ำ (เช่น 300 วินาที) ช่วยให้ Propagation เร็วขึ้น แต่ก็เพิ่ม Query Load บน DNS Server
ทางเลือกอื่นนอกจาก MXToolbox
- dnschecker.org — ตรวจ DNS Propagation จากหลายประเทศ
- mail-tester.com — ทดสอบ Spam Score พร้อมตรวจ SPF/DKIM
- Google Admin Toolbox — ตรวจ DNS Records ผ่าน Google
- dig (command line) —
dig MX company.comบน Terminal
คำถามที่พบบ่อย (FAQ)
ตรวจ MX Record ฟรีได้จากที่ไหนบ้าง
ตรวจฟรีได้หลายทาง: เว็บ MXToolbox (mxtoolbox.com), dnschecker.org, Google Admin Toolbox หรือใช้คำสั่ง dig MX yourdomain.com +short บน Linux/macOS และ nslookup -type=mx yourdomain.com บน Windows ทั้งหมดไม่มีค่าใช้จ่ายและให้ผลตรงกัน
MX Record ควรมีกี่ตัว
อย่างน้อย 1 ตัวก็ใช้งานได้ แต่แนะนำมี 2 ตัวขึ้นไป โดยตั้ง Priority ต่างกัน (เช่น 10 และ 20) เพื่อให้มี Backup รับอีเมลเมื่อ Server หลัก Offline ป้องกันอีเมล Bounce ระหว่าง Maintenance หรือ Server ล่ม
แก้ MX Record แล้วต้องรอนานแค่ไหนถึงใช้งานได้
ขึ้นกับค่า TTL ของ Record เดิม โดยทั่วไปรอ Propagation 24–48 ชั่วโมงให้ครอบคลุมทั่วโลก ถ้าตั้ง TTL ต่ำ (300 วินาที) ไว้ก่อนแก้ จะ Propagate ภายในไม่กี่นาที ตรวจความคืบหน้าได้ด้วย DNS Propagation Check
ทำไมอีเมลยัง Bounce ทั้งที่ MX Record ถูกแล้ว
มักเกิดจากปัญหาอื่นที่ไม่ใช่ MX โดยตรง เช่น IP ติด Blacklist, Reverse DNS/PTR ไม่ตรง, SPF ไม่ครอบคลุม IP ผู้ส่ง หรือ Hostname ใน MX ชี้ไป CNAME ลองรัน Email Health Check เพื่อหาสาเหตุที่แท้จริง
ปัญหาอีเมล Hosting ให้ AsiaGB ช่วยได้
ทีมงาน AsiaGB ช่วยตรวจสอบ MX Record และ DNS สำหรับลูกค้า Hosting ทุกแผน ติดต่อผ่าน Ticket ได้ตลอด 24 ชั่วโมง
ส่ง Support Ticket