ตั้งค่า MX Record สำหรับ Email Hosting ทีละขั้นตอน

อยากใช้อีเมลในรูปแบบ [email protected] แทนที่จะเป็น Gmail หรือ Hotmail ส่วนตัว? ขั้นตอนแรกที่ขาดไม่ได้คือการตั้งค่า MX Record ใน DNS ของโดเมนให้ถูกต้อง บทความนี้อธิบายตั้งแต่ MX Record คืออะไร ไปจนถึงการตั้งค่า SPF, DKIM, DMARC เพื่อให้อีเมลถึงปลายทางโดยไม่ตก Spam

MX Record คืออะไร

MX Record (Mail Exchanger Record) คือ DNS Record ประเภทหนึ่งที่บอกว่า Mail Server ไหนรับผิดชอบจัดการอีเมลของโดเมนนั้น เมื่อใครส่งอีเมลมาที่ [email protected] Mail Server ของผู้ส่งจะ Query DNS ของ example.com เพื่อหา MX Record แล้วส่งอีเมลไปยัง Server ที่ระบุไว้

MX Record ต้องชี้ไปยัง Hostname (A Record) ไม่ใช่ IP Address โดยตรง และแต่ละ MX Record มีค่า Priority — ตัวเลขน้อยกว่าหมายถึงลำดับความสำคัญสูงกว่า

ทำไมต้องตั้ง MX Record

ถ้าโดเมนของคุณไม่มี MX Record หรือตั้งค่าผิด อีเมลที่ส่งมาจากภายนอกจะไม่มีที่ส่ง ผู้ส่งจะได้รับ Error เช่น 550 No such user here หรือ MX lookup failed ซึ่งหมายความว่าอีเมลของคุณใช้งานไม่ได้เลย

โครงสร้าง DNS ที่เกี่ยวข้องกับอีเมล

ในระบบ DNS มี Record หลายประเภทที่ทำงานร่วมกันเพื่อให้ระบบอีเมลทำงานได้อย่างสมบูรณ์ นอกจาก MX Record แล้ว ยังมี Record อื่นที่ขาดไม่ได้ดังนี้

MX Record ทำหน้าที่กำหนดว่าจะ "รับ" อีเมลที่ไหน ส่วน SPF, DKIM และ DMARC ทำงานด้าน "ส่ง" เพื่อยืนยันว่าอีเมลนั้นเชื่อถือได้จริง ทั้งสองฝั่งต้องครบถึงจะทำให้ระบบอีเมลทำงานได้อย่างมีประสิทธิภาพ

ค่า Priority ของ MX Record ส่งผลอย่างไร

ค่า Priority หรือ Preference ของ MX Record เป็นตัวเลขที่บอก Mail Server ผู้ส่งว่าควรลองส่งไปยัง Server ไหนก่อน ระบบจะเลือก Server ที่มีตัวเลข Priority น้อยที่สุด ก่อนเสมอ ถ้า Server นั้นไม่ตอบสนองหรือ Busy จึงจะลองอันถัดไป

# ตัวอย่าง MX Records พร้อม Priority
yourdomain.com.  3600  IN  MX  10 mail.yourdomain.com.   (Primary)
yourdomain.com.  3600  IN  MX  20 mail2.yourdomain.com.  (Secondary)
yourdomain.com.  3600  IN  MX  30 mail3.backup.com.      (Tertiary)

ในการตั้งค่าจริงสำหรับ Email Hosting ทั่วไป มักใช้ MX Record เพียงรายการเดียว (Priority 10) และใช้ High-Availability ในระดับ Server แทนการมีหลาย MX Record เพราะการตั้งหลาย MX ที่ชี้ไปต่างเซิร์ฟเวอร์โดยไม่ซิงค์ Mail Store จะทำให้อีเมลตกหาย

การแก้ปัญหาอีเมลตก Spam หลังตั้ง MX Record แล้ว

แม้จะตั้ง MX Record ถูกต้องแล้ว ปัญหาที่พบบ่อยคืออีเมลถูกส่งแล้วแต่ตก Spam ที่ปลายทาง สาเหตุหลักมักไม่ใช่เรื่อง MX Record แต่เป็นเรื่อง Email Authentication ที่ยังไม่ครบ ตรวจสอบตามลำดับดังนี้

• ตรวจ SPF Fail — ถ้า Mail Server ของคุณไม่ได้อยู่ใน SPF Record อีเมลจะถูก Soft-fail (~all) หรือ Hard-fail (-all)
• ตรวจ DKIM Signature ไม่ผ่าน — ถ้า Public Key ใน DNS ไม่ตรงกับ Private Key บน Server อีเมลจะ Fail DKIM Check
• ตรวจ Reverse DNS (PTR) — Mail Server หลายรายตรวจสอบว่า IP ที่ส่งอีเมลมีชื่อ PTR ตรงกับชื่อ Hostname บน SMTP หรือไม่ ถ้าไม่มี PTR อาจถูกมองว่าเป็น Spam
• ตรวจ Blacklist — ใช้ MXToolbox Blacklist Check ดูว่า IP หรือโดเมนติด Blacklist ไหน
• ตรวจ DMARC Report — ตั้ง rua=mailto:[email protected] แล้วรอ Report มาจาก Gmail/Outlook ภายใน 24 ชั่วโมง จะเห็นว่าอีเมลใด Fail ที่ขั้นตอนไหน

วิธีตั้งค่าใน DirectAdmin DNS Management

ถ้าโดเมนของคุณอยู่กับ AsiaGB และใช้ DirectAdmin ทำตามขั้นตอนนี้

1. Login เข้า DirectAdmin → DNS Management
2. เลือกโดเมนที่ต้องการแก้ไข
3. หาส่วน MX Records แล้วลบ Record เดิมออก (ถ้ามี)
4. เพิ่ม MX Record ใหม่ตามข้อมูลที่ผู้ให้บริการ Email Hosting ของคุณให้มา
5. ตั้งค่า TTL เป็น 3600 (1 ชั่วโมง) หรือตามที่ผู้ให้บริการแนะนำ
6. กด Save

ตัวอย่าง MX Record สำหรับ Email Hosting ที่ Server ของ AsiaGB เอง

# ใน DirectAdmin DNS Management
Type:     MX
Name:     @  (หรือชื่อโดเมนของคุณ)
Value:    mail.yourdomain.com
Priority: 10
TTL:      3600

ตรวจสอบ MX Record ด้วย dig / nslookup

หลังบันทึกแล้วรอ DNS Propagation สักครู่ แล้วตรวจสอบได้ด้วยคำสั่ง

# ใช้ dig (Linux / macOS)
dig MX yourdomain.com

# ใช้ nslookup (Windows)
nslookup -type=MX yourdomain.com

ผลลัพธ์ที่ถูกต้องควรแสดง MX Record ที่คุณเพิ่งตั้ง เช่น

yourdomain.com.  3600  IN  MX  10 mail.yourdomain.com.

หรือใช้เครื่องมือออนไลน์ เช่น MXToolbox (mxtoolbox.com) ตรวจสอบได้สะดวกจากเบราว์เซอร์

ตั้ง SPF, DKIM, DMARC ป้องกัน Spam

การตั้ง MX Record อย่างเดียวไม่พอ ต้องตั้งค่า Email Authentication Records เพิ่มเติมเพื่อป้องกันอีเมลตก Spam หรือถูก Spoof

SPF Record (Sender Policy Framework)

บอกว่า Mail Server IP ไหนได้รับอนุญาตส่งอีเมลในนามโดเมนของคุณ เพิ่มเป็น TXT Record

Type:  TXT
Name:  @ (หรือชื่อโดเมน)
Value: "v=spf1 mx a ip4:YOUR_SERVER_IP ~all"

DKIM Record (DomainKeys Identified Mail)

เพิ่ม Digital Signature ให้อีเมลทุกฉบับ ปลายทางสามารถตรวจสอบได้ว่าอีเมลนั้นส่งมาจากเซิร์ฟเวอร์ที่ถูกต้องจริง ค่า DKIM จะได้จากผู้ให้บริการ Email Hosting ของคุณ มีรูปแบบประมาณนี้

Type:  TXT
Name:  default._domainkey.yourdomain.com
Value: "v=DKIM1; k=rsa; p=MIGfMA0GCS...<public key>"

DMARC Record

กำหนด Policy ว่าจะทำอย่างไรกับอีเมลที่ผ่าน SPF/DKIM ไม่ได้ เริ่มต้นด้วย p=none เพื่อ Monitor ก่อน แล้วค่อยขยับเป็น quarantine หรือ reject

Type:  TXT
Name:  _dmarc.yourdomain.com
Value: "v=DMARC1; p=none; rua=mailto:[email protected]"

DNS Propagation ใช้เวลานานแค่ไหน

หลังจากบันทึก DNS Record แล้ว การเปลี่ยนแปลงจะไม่มีผลทันที เพราะ DNS Server ทั่วโลกต้องอัปเดต Cache ซึ่งใช้เวลา

• โดยทั่วไป: 15 นาที ถึง 1 ชั่วโมง
• กรณีที่ TTL สูง: อาจนานถึง 24–48 ชั่วโมง
• เคล็ดลับ: ตั้ง TTL ให้ต่ำ (เช่น 300 วินาที = 5 นาที) ก่อนเปลี่ยน เพื่อให้ Propagation เร็วขึ้น

ระหว่างรอ Propagate อีเมลบางส่วนอาจยังส่งไปยัง Server เดิม ซึ่งเป็นเรื่องปกติ

อีเมลโดเมนตัวเองกับการสร้างความน่าเชื่อถือทางธุรกิจ

นอกจากประโยชน์ด้านเทคนิค การใช้อีเมลในรูปแบบ [email protected] มีผลโดยตรงต่อความน่าเชื่อถือในการทำธุรกิจ

• ดูมืออาชีพ — ลูกค้าและพันธมิตรทางธุรกิจให้ความเชื่อถืออีเมลโดเมนตัวเองมากกว่า Gmail หรือ Hotmail สำหรับการติดต่อธุรกิจ
• สอดคล้องกับแบรนด์ — ชื่อโดเมนเดียวกันปรากฏบนเว็บไซต์และอีเมล ทำให้แบรนด์ดูสอดคล้องกัน
• ควบคุมได้เอง — ไม่ต้องพึ่งพา Free email provider เมื่อออกจากบริษัทหรือปิด account อีเมลยังอยู่กับโดเมนของคุณ
• ทำ Email Alias ได้ — เช่น [email protected], [email protected], [email protected] โดยส่งทุกอย่างมาที่ Mailbox เดียว
• Google Workspace / Microsoft 365 — ถ้าใช้บริการเหล่านี้ยิ่งต้องการ MX Record ที่ถูกต้องเป็นขั้นตอนแรกในการ Setup

AsiaGB มีบริการ Hosting ที่รวม Email Hosting ไว้แล้ว รองรับอีเมลโดเมนตัวเองพร้อมใช้งาน Webmail, IMAP/POP3 และ SMTP ตั้งค่า MX Record ได้ผ่าน DirectAdmin โดยไม่ต้องใช้บริการภายนอกเพิ่มเติม ทำให้การบริหารจัดการโดเมน DNS และอีเมลอยู่ในที่เดียวกัน

การตั้งค่า MX Record สำหรับระบบอีเมลองค์กร

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

การใช้หลาย MX Record เพื่อ Redundancy

ในระบบ Email Hosting ที่ผู้ให้บริการจัดการ Redundancy เองอยู่แล้ว การตั้ง MX Record หลายรายการอาจไม่จำเป็น แต่ถ้าบริหาร Mail Server เองและต้องการ Failover ต้องแน่ใจว่า Mail Store ของทั้ง 2 เซิร์ฟเวอร์ Sync กันอยู่ตลอดเวลา มิฉะนั้นอีเมลที่รับผ่าน Secondary Server จะมองไม่เห็นจาก Primary

การตั้งค่า TTL ที่เหมาะสม

TTL (Time-to-Live) ของ MX Record กำหนดว่า DNS Server ทั่วโลกจะ Cache ค่านี้ไว้นานแค่ไหนก่อนจะมาตรวจสอบใหม่ ค่าที่เหมาะสมขึ้นอยู่กับสถานการณ์ดังนี้

ลดค่า TTL อย่างน้อย 24 ชั่วโมงก่อนวันย้าย Mail Server เพื่อให้ DNS Cache เก่าหมดอายุทั่วโลกก่อน จากนั้นจึงเปลี่ยน MX Record ได้อย่างมั่นใจ

การทดสอบและ Monitor ระบบอีเมลหลัง Setup

หลังจากตั้งค่า MX Record และ Email Authentication Records ครบแล้ว ขั้นตอนต่อไปคือการทดสอบให้ครอบคลุมทุกด้านก่อนจะเริ่มใช้งานจริง เพราะปัญหาที่ตรวจพบหลังจากองค์กรใช้งานไปแล้วอาจกระทบภาพลักษณ์ธุรกิจได้

เครื่องมือทดสอบที่แนะนำ

• MXToolbox Email Health (mxtoolbox.com/emailhealth) — ตรวจ MX, SPF, DKIM, DMARC, PTR, Blacklist ในคลิกเดียว
• Google Admin Toolbox (toolbox.googleapps.com) — สำหรับผู้ใช้ Google Workspace ตรวจสอบ DNS records ได้ละเอียด
• Mail-Tester (mail-tester.com) — ส่งอีเมลทดสอบแล้วรับ Score พร้อมคำแนะนำ ได้คะแนน 10/10 หมายความว่าการตั้งค่าสมบูรณ์
• DMARC Analyzer — อ่าน DMARC Report XML ที่ส่งมาจาก Google/Outlook แสดงเป็น Dashboard อ่านง่าย

สิ่งที่ต้องตรวจสอบสม่ำเสมอหลัง Go-Live

• Blacklist Status — ตรวจอย่างน้อยเดือนละครั้ง โดยเฉพาะช่วงแรกที่เพิ่งเริ่มใช้ IP ใหม่
• DMARC Report — ทบทวน Aggregate Report ทุกสัปดาห์ ดูว่ามีผู้ไม่หวังดี Spoof โดเมนของคุณหรือไม่
• วันหมดอายุ DKIM Key — บางระบบต้องหมุน DKIM Key เป็นระยะ ตรวจสอบกับผู้ให้บริการ Email Hosting
• SPF Lookup Limit — SPF อนุญาต DNS Lookup สูงสุด 10 ครั้งต่อการตรวจสอบ ถ้ามี include มากเกินไปจะ Fail ให้ใช้ SPF Flattener เพื่อลดจำนวน Lookup

กรณีศึกษา: ปัญหา MX Record ที่พบบ่อยและวิธีแก้

ปัญหาที่ผู้ใช้งาน Email Hosting มักพบบ่อยที่สุด พร้อมแนวทางวินิจฉัยและแก้ไขอย่างเป็นระบบ

ปัญหา: ส่งอีเมลได้แต่รับไม่ได้

สาเหตุที่พบบ่อยที่สุดคือ MX Record ยังชี้ไปเซิร์ฟเวอร์เดิม หรือ TTL ยังไม่หมดอายุ ให้ตรวจสอบด้วยคำสั่ง dig MX yourdomain.com @8.8.8.8 เพื่อตรวจสอบว่า Google DNS เห็น MX ใหม่แล้วหรือยัง ถ้ายังเห็นเก่าอยู่ให้รอให้ TTL หมดก่อน

ปัญหา: อีเมลส่งออกได้แต่ถูก Reject ที่ปลายทาง

ตรวจสอบ SMTP Error Message ที่ได้รับกลับ ถ้าเห็น 550 5.7.1 SPF check failed แสดงว่า IP ที่ใช้ส่งไม่อยู่ใน SPF Record ถ้าเห็น 550 5.7.26 This message fails DMARC แสดงว่า DKIM ไม่ผ่านหรือ SPF Fail และ DMARC Policy ตั้งเป็น reject

# ตรวจสอบ SPF ด้วย dig
dig TXT yourdomain.com | grep spf

# ตรวจสอบ DMARC ด้วย dig
dig TXT _dmarc.yourdomain.com

# ตรวจสอบ DKIM (แทน selector ด้วยชื่อจริง เช่น default, google, mail)
dig TXT default._domainkey.yourdomain.com

ปัญหา: อีเมลส่งไปแต่ไม่มีตอบกลับมานาน

อาจเกิดจาก Greylisting ที่ปลายทาง ซึ่งเป็นเทคนิคป้องกัน Spam โดยปฏิเสธอีเมลครั้งแรกชั่วคราว Mail Server ที่ถูกต้องจะส่งซ้ำอัตโนมัติภายใน 5–30 นาที ตรวจสอบ Mail Queue บน Server ว่ามีอีเมลรอส่งซ้ำอยู่หรือไม่ ถ้าไม่มีใน Queue และยังไม่ถึงปลายทาง ให้ตรวจว่า IP ติด Blacklist หรือไม่

MX Record กับการย้ายผู้ให้บริการ Email Hosting

การย้าย Email Hosting จากผู้ให้บริการเดิมไปยังรายใหม่เป็นขั้นตอนที่ละเอียดอ่อน เพราะอีเมลที่อยู่ระหว่างส่งในช่วง Transition อาจสูญหายได้ถ้าไม่วางแผนให้ดี แนวทางที่แนะนำสำหรับการ Migration ที่ Downtime น้อยที่สุดมีดังนี้

1. ลด TTL ของ MX Record ให้เหลือ 300 วินาที อย่างน้อย 24 ชั่วโมงก่อนวันย้าย
2. Setup Mail Server ใหม่ให้พร้อมรับอีเมล บน Provider ใหม่ ทดสอบส่ง-รับบน Server ใหม่ก่อนเปลี่ยน MX
3. Export Mail Box เดิม ออกมาสำรองไว้ก่อน อาจใช้ IMAP Sync หรือ Export PST/Mbox
4. เปลี่ยน MX Record ชี้ไปยัง Server ใหม่ในช่วงเวลาที่อีเมลน้อยที่สุด (เช่น ช่วงดึก)
5. ตรวจสอบว่า MX ใหม่ Propagate แล้ว ด้วย dig MX @8.8.8.8 และ dig MX @1.1.1.1
6. อัปเดต SPF, DKIM, DMARC ให้ตรงกับ Server ใหม่ ห้ามลืม
7. Monitor อีเมลเข้า-ออกอย่างน้อย 48 ชั่วโมง หลัง Cutover เพื่อให้มั่นใจว่าไม่มีอะไรตกหาย