DNS คืออะไร? เข้าใจ A, AAAA, CNAME, MX, TXT, SPF, DKIM และ DMARC

DNS (Domain Name System) คือระบบที่ช่วยค้นหาข้อมูลของชื่อโดเมน เพื่อให้ Browser และระบบอื่นรู้ว่าต้องเชื่อมต่อบริการใด การตั้ง DNS ของเว็บไซต์กับอีเมลเป็นคนละชุดงาน จึงเป็นไปได้ที่เว็บเปิดได้ตามปกติแต่อีเมลรับไม่ได้ หรืออีเมลใช้งานได้แต่หน้าเว็บเข้าไม่ได้

บทความนี้อธิบายคำศัพท์และ Records ที่เจ้าของธุรกิจพบในหน้าจอ DNS โดยใช้ชื่อและ IP ตัวอย่างเท่านั้น ไม่ใช่ค่าบัญชีของลูกค้าจริง หากกำลังจดโดเมนครั้งแรก อ่าน คู่มือจดโดเมน ก่อนก็ได้

DNS ทำงานอย่างไรในภาพรวม

เมื่อเปิด www.example.com เครื่องจะค้นข้อมูล DNS ตามกลไก Resolver และ DNS Cache เพื่อรู้ว่าจะเชื่อมต่อที่อยู่ปลายทางใด; หากส่งอีเมลไปยัง name@example.com Mail Server จะดู MX Record เพื่อหา Mail Server ที่รับข้อความสำหรับโดเมนนั้น

DNS ไม่ได้เป็นตัวให้เว็บทำงานหรือเก็บ Mailbox เอง มันเป็นระบบประกาศข้อมูลบริการ หากปลายทางเว็บล่ม A Record ที่ถูกต้องก็ไม่ทำให้เว็บกลับมาใช้ได้ และถ้า Mailbox ยังไม่ถูกสร้าง MX ที่ถูกต้องก็ไม่ได้สร้างกล่องเมลให้อัตโนมัติ

Nameserver กับ DNS Records ต่างกันอย่างไร

Nameserver เป็นเครื่องที่มีหน้าที่ตอบ DNS ของโดเมน ส่วน DNS Records เป็นข้อมูลที่อยู่ใน Zone ของโดเมนนั้น หาก Registrar ให้ตั้ง Nameserver เป็นผู้ให้บริการ DNS รายใหม่ คุณต้องตรวจว่าข้อมูล Zone ทั้งหมดถูกย้ายมาครบก่อนสลับ

การแก้ A Record ภายใน Zone เดิมต่างจากการเปลี่ยน Nameserver: แบบแรกเปลี่ยนปลายทางบางรายการ ส่วนแบบหลังอาจเปลี่ยนแหล่งข้อมูล DNS ที่ใช้ทั้งโดเมน กระทบเว็บไซต์ อีเมล Subdomain และการยืนยันบริการหลายชนิด

ตาราง Record ที่พบบ่อย

Record	ใช้เพื่อ	ตัวอย่างจำลอง/ข้อควรจำ
A	ชี้ Host ไป IPv4	www.example.com ไป 192.0.2.10
AAAA	ชี้ Host ไป IPv6	www.example.com ไป 2001:db8::10
CNAME	ตั้งชื่อ Host ให้เป็นชื่ออ้างอิงอื่น	shop.example.com ไป shop-host.example.net
MX	ระบุ Mail Exchanger สำหรับรับอีเมล	example.com ไป mail.example.net พร้อม Priority
TXT	เก็บข้อความสำหรับยืนยันหรือกำหนดนโยบาย	Domain Verification และ SPF
SPF	กำหนดผู้ส่งเมลที่อนุญาต ผ่าน TXT	v=spf1 …
DKIM	ให้ปลายทางตรวจลายเซ็นของเมล	Selector._domainkey อยู่บน TXT หรือ CNAME ตามระบบ
DMARC	กำหนดนโยบายเมื่อส่งเมลไม่ผ่านการยืนยันและรับรายงาน	_dmarc.example.com TXT

IP 192.0.2.0/24 และ 2001:db8::/32 เป็นช่วงที่ใช้ทำเอกสารตัวอย่าง ไม่ใช่ปลายทาง Hosting ที่นำไปใช้งานจริง ต้องแทนด้วยค่าที่ผู้ให้บริการกำหนด

ดูคำอธิบายชนิด Record จาก Cloudflare DNS Record Types ซึ่งมีข้อจำกัดและวิธีตั้งค่าที่ต่างตามผู้ให้บริการ

ตั้งเว็บไซต์: A, AAAA และ CNAME

หากเว็บอยู่ที่บริการที่ให้ IPv4 คุณอาจต้องสร้าง A Record สำหรับชื่อที่ต้องการ เช่น example.com ส่วน CNAME เหมาะเมื่อบริการให้ Hostname ปลายทางแทน IP เช่น www.example.com ชี้ไป Hostname ที่แพลตฟอร์มระบุ

บาง DNS Provider มีแนวทางพิเศษสำหรับ CNAME ที่ Root/Apex และระบบ Proxy อย่าคัดลอกวิธีของผู้ให้บริการอื่นมาใช้โดยไม่ตรวจข้อกำหนดของ DNS Provider ปัจจุบัน อีกทั้งการมีทั้ง A และ AAAA ที่ชี้คนละระบบโดยไม่ตั้งใจอาจทำให้ผู้ใช้บางรายเข้าเว็บคนละเวอร์ชัน

ก่อนเปลี่ยน Record ของเว็บ ตรวจว่าปลายทางใหม่ตอบ HTTPS, โดเมน และ Redirect ตามที่ต้องการแล้ว

ตั้งอีเมล: MX เป็นทางเข้า แต่ไม่ใช่ทั้งระบบ

MX บอกว่าระบบไหนรับอีเมลเข้ามาสำหรับโดเมน Priority ที่เลขน้อยมักมีลำดับความสำคัญสูงกว่า แต่ผู้ให้บริการแต่ละรายอาจใช้รูปแบบต่างกัน ให้คัดลอกค่าจาก Admin Console ของผู้ให้บริการอีเมลที่เลือก ไม่สมมติ Hostname เอง

การเปลี่ยน MX ไม่ได้ย้ายอีเมลเก่าไปยังกล่องใหม่ ข้อความเดิมยังอยู่ที่ผู้ให้บริการเก่าจนกว่าจะทำ Migration และการเปลี่ยน MX ที่มี Mailbox ไม่ครบอาจทำให้เมลใหม่ถูกตีกลับ

คู่มือ ตั้งค่าอีเมลบริษัทด้วยโดเมนตัวเอง อธิบายขั้นตอน Mailbox, Alias และการทดสอบหลังตั้งค่า

SPF, DKIM และ DMARC ช่วยอะไร

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

DKIM ใช้ลายเซ็นเข้ารหัสเพื่อตรวจว่าข้อความถูกลงนามโดยระบบส่งที่มีสิทธิ์ และเนื้อหาไม่ถูกแก้ไขระหว่างทาง การตั้งค่าต้องสร้างหรือเปิด Signing ฝั่งผู้ให้บริการก่อน แล้วใส่ Public Key หรือ CNAME ที่สัมพันธ์กับ Selector จริง

DMARC ตรวจความสอดคล้อง (Alignment) ระหว่างโดเมนใน From กับผล SPF หรือ DKIM และบอก Mail Receiver ว่าควรทำอย่างไรเมื่อไม่ผ่าน ควรเริ่มจากนโยบายสังเกตการณ์ เช่น p=none พร้อมตรวจรายงานและรายชื่อระบบส่งทั้งหมด ก่อนค่อยเพิ่มความเข้มเป็น quarantine/reject ตามความพร้อม เพราะตั้ง reject เร็วเกินไปอาจบล็อกเมลที่ถูกต้องของบริษัทเอง

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

TTL และการรอผล: ไม่ใช่ปุ่ม Propagate ทันที

TTL บอกระยะเวลาที่ Resolver อาจ Cache คำตอบ DNS การลด TTL ล่วงหน้าก่อน Cutover อาจช่วยให้ผู้ใช้จำนวนมากรับค่าใหม่เร็วขึ้น แต่ไม่ได้ล้าง Cache ทั้งหมดทันที การสลับ Nameserver ยังเกี่ยวข้องกับการมอบหมายชื่อจาก Registry และ Cache ของตัวกลางด้วย

หลังเปลี่ยน ควรตรวจจากหลายเครือข่ายและ DNS Resolver แยกจากการตรวจเว็บ/เมลจริง เพื่อรู้ว่าปัญหาอยู่ที่ DNS หรือ Application

วิธีเปลี่ยน DNS โดยไม่ทำอีเมลหาย

1. Export หรือคัดลอก Zone เดิม รวม Subdomain และ Records ที่เกี่ยวกับ Security, Verification และ Email
2. ระบุความรับผิดชอบของแต่ละ Record ว่าชี้ Website, Email, CRM, Marketing Tools หรือบริการอื่น
3. สร้าง Zone ใหม่ให้ครบและตรวจ Records เทียบกันก่อนเปลี่ยน Nameserver
4. ตรวจ DNSSEC/DS Records หากเปิดใช้งาน; การเปลี่ยน Provider โดยไม่จัดการ DS ตามขั้นตอนอาจทำให้ DNS Validation ล้มเหลว
5. วาง Change Window และ Rollback Plan ให้รู้ว่าใครตัดสินใจเปลี่ยนกลับ
6. เปลี่ยนทีละส่วนที่จำเป็น เก็บผลตรวจจาก Resolver และปลายทางจริง
7. ทดสอบเว็บ, SSL/TLS, Subdomain, Email ส่งรับ, SPF/DKIM/DMARC และอุปกรณ์/ระบบที่ใช้งาน

ตัวอย่างจำลอง: ต้องการย้ายเว็บจาก Hosting A ไป B แต่เก็บอีเมลที่ Email Provider C ไว้ ให้เปลี่ยนเฉพาะ Web Records ที่จำเป็น ไม่เปลี่ยน MX และไม่ย้าย Nameserver โดยไม่จำเป็น หากต้องย้าย DNS Provider ด้วย ให้คัดลอก Mail Records ก่อน

FAQ

ทำไมเว็บใช้ได้แต่อีเมลใช้ไม่ได้

เพราะเว็บกับเมลพึ่ง Record และระบบปลายทางคนละส่วน ให้ตรวจ MX, Mailbox, SPF/DKIM/DMARC และ Logs ของผู้ให้บริการอีเมล ไม่แก้ A Record ของเว็บแบบเดาสุ่ม

ใช้ Cloudflare แล้วต้องเปิด Proxy ทุก Record ไหม

ไม่ใช่ Records สำหรับรับอีเมลและการยืนยันโดเมนไม่ได้เป็น HTTP Traffic แบบเดียวกับเว็บ และมีข้อจำกัด Proxy ตามชนิด Record ให้ตรวจสถานะ Proxy สำหรับ Hostname เว็บโดยเฉพาะ

SPF, DKIM, DMARC ตั้งครั้งเดียวพอหรือไม่

ต้องทบทวนเมื่อเพิ่ม/ถอดบริการส่งเมล เปลี่ยนผู้ให้บริการ หรือมีรายงานว่าการยืนยันล้มเหลว และควรตรวจนโยบายที่บังคับใช้จริงเสมอ

Checklist ตรวจ DNS ก่อนขึ้น Production

• แยกรายการ Web Records กับ Email Records อย่างชัดเจน
• ตั้งค่าตรงคู่มือผู้ให้บริการ ไม่ใช้ IP ตัวอย่างในบทความ
• ตรวจ WWW, Apex, Subdomain, HTTPS และ Redirect
• มี MX, SPF, DKIM, DMARC ที่เหมาะกับระบบส่ง/รับจริง
• สำรอง Zone เดิมและตรวจ DNSSEC เมื่อเปลี่ยน Nameserver
• บันทึกผลทดสอบและมีแผน Rollback

แหล่งอ้างอิง: Cloudflare DNS Record Types, Cloudflare Change Nameservers, Cloudflare Email Security Records, Google Workspace DMARC ตรวจข้อมูล 3 พฤศจิกายน 2026