ตั้งค่าอีเมลบริษัทด้วยโดเมนตัวเองอย่างไร? MX, SPF, DKIM และ DMARC

การมีโดเมน example.com ยังไม่ทำให้มีอีเมล info@example.com ต้องเลือกบริการอีเมล สร้างผู้ใช้และ Mailbox แล้วกำหนด DNS ให้การรับและส่งข้อความทำงานถูกต้อง หลายคนตั้ง MX ได้แล้วแต่ส่งออกไม่ผ่าน SPF/DKIM หรือคิดว่า Forwarding คือ Mailbox ซึ่งเป็นคนละสิ่ง

บทความนี้เป็นขั้นตอนเชิงระบบสำหรับเจ้าของธุรกิจและผู้ดูแลเว็บไซต์ ไม่ใช่ค่าตั้งสำเร็จรูปของทุกผู้ให้บริการ เพราะ MX, DKIM Selector และวิธียืนยันโดเมนต้องอ่านจาก Admin Console จริง หากยังไม่เลือกบริการให้เริ่มจาก เปรียบเทียบ 4 ระบบอีเมลบริษัท ก่อน

ก่อนเริ่มต้องมีอะไรบ้าง

เตรียมสิทธิ์ Admin ของ Email Provider และสิทธิ์แก้ DNS Zone ของโดเมน ตรวจว่ามีบริการอีเมลเดิมใช้อยู่หรือไม่ ถ้ามีต้องวางแผน Migration ก่อนเปลี่ยน MX เพราะเมลเก่าไม่ได้ย้ายตาม DNS

ทำรายการผู้รับเมลจริง เช่น ceo@, sales@, billing@, support@ รวมทั้งฟอร์มเว็บไซต์ เครื่องมือ CRM และบริการส่งอีเมลอัตโนมัติที่ใช้โดเมนเดียวกัน สิ่งเหล่านี้เกี่ยวข้องกับ SPF/DKIM/DMARC และอาจถูกลืมเมื่อเปลี่ยนผู้ให้บริการ

อย่าเปิดเผยรหัสผ่าน Mailbox, Domain Verification Token หรือ Admin Session ในภาพหน้าจอและเอกสารสาธารณะ

Mailbox, Alias, Group และ Forwarding ต่างกัน

รูปแบบ	หน้าที่	ความเข้าใจผิดที่ควรเลี่ยง
Mailbox	กล่องจดหมายที่มีพื้นที่จัดเก็บและผู้ใช้งานตามสิทธิ์	ต้องสร้างบัญชี/สิทธิ์ให้ครบ ไม่เกิดจาก MX
Alias	ที่อยู่เพิ่มเติมที่ส่งเข้าปลายทางที่กำหนด	ไม่ใช่บัญชี Login แยกเสมอไป
Group/Distribution	ส่งเมลหาสมาชิกหลายคนตามระบบ	การตอบกลับและการเก็บประวัติขึ้นกับประเภท Group
Forwarding	ส่งต่อข้อความเข้าที่อยู่อื่น	อาจกระทบ SPF/DMARC หรือการจัดการข้อมูลส่วนบุคคล
Shared Mailbox	ผู้มีสิทธิ์หลายคนเข้าถึงกล่องร่วม	เงื่อนไข Licensing/Quota ต่างตามผู้ให้บริการ

ตัวอย่าง: sales@example.com อาจเป็น Shared Mailbox ที่ทีมขายเข้าถึงด้วยบัญชีรายบุคคล ส่วน hello@example.com อาจเป็น Alias ของ Mailbox เดียวกัน อย่าสร้างบัญชีกลางให้ทุกคนแชร์รหัสผ่านโดยไม่จำเป็น เพราะตรวจสอบว่าใครทำอะไรได้ยาก

ขั้นตอนที่ 1: ยืนยันโดเมนกับ Email Provider

ผู้ให้บริการอาจให้เพิ่ม TXT Verification Record ที่ DNS หรือวิธีอื่นเพื่อพิสูจน์ว่าองค์กรควบคุมโดเมนได้ หลังระบบตรวจพบ Records จึงให้เริ่มตั้งอีเมลสำหรับโดเมนนั้น

หากใช้ชื่อโดเมนที่คนอื่นกำลังใช้กับบริการเดิม ให้ระวังขั้นตอนยืนยันที่อาจกระทบการตั้งค่าอื่น อ่านหน้าจอ Admin ให้ครบก่อนกดยืนยัน และจดชื่อ DNS Provider ให้ตรงกับผู้ให้บริการที่ใช้งานจริง ไม่ใช่สันนิษฐานว่า DNS อยู่ที่ Registrar เสมอ

ขั้นตอนที่ 2: สร้างผู้ใช้และ Mailboxes ก่อนสลับ MX

สร้าง Mailbox สำหรับผู้รับที่ต้องมีตัวตนจริง กำหนด License/Quota, Recovery Options และ MFA แล้วทดสอบ Login บัญชีตัวอย่างให้ผ่านก่อน สำหรับทีมที่มี Alias หรือ Group ต้องตั้งปลายทางให้ครบ

ห้ามรีบเปลี่ยน MX ก่อนสร้างผู้รับทุกคน Microsoft ระบุในคู่มือ DNS ว่าเมื่อเปลี่ยน MX เมลใหม่จะส่งไปที่ Microsoft 365 แต่ข้อความเดิมยังอยู่ผู้ให้บริการเก่าจนกว่าจะทำ Migration Microsoft DNS Setup

ขั้นตอนที่ 3: ตั้ง MX เพื่อรับเมล

ใช้ Hostname และ Priority จาก Provider จริง ตัวอย่างจำลองนี้อธิบายรูปแบบเท่านั้น:

Type	Name	Content	หมายเหตุ
MX	example.com	mail.example.net	ค่าในแถวนี้ไม่ใช่ MX ของ Google/Microsoft
TXT	example.com	Verification Token จาก Provider	ใช้ค่าที่ระบบออกให้จริง

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

ตรวจ DNS Cache และการเปลี่ยนค่าจากหลายเครือข่ายหลังบันทึกการแก้ไข

ขั้นตอนที่ 4: ตั้ง SPF อย่างระมัดระวัง

SPF เป็น DNS TXT ที่ระบุว่า Server ใดส่งอีเมลแทนโดเมนได้ แต่ละโดเมน/ชื่อที่ตรวจไม่ควรเผยแพร่ SPF Records หลายรายการแยกกัน ให้รวมผู้ส่งที่ได้รับอนุญาตอย่างถูกวิธี เช่น Email Provider, Website Transactional Mail และ Marketing Platform

ตัวอย่างของ Google Workspace เมื่อ ใช้ Google เป็นผู้ส่งเพียงระบบเดียว คือ:

v=spf1 include:_spf.google.com ~all

ตัวอย่างข้างบนมาจาก Google Workspace SPF และไม่ควรคัดลอกเมื่อยังมีระบบส่งอื่นร่วมอยู่ ต้องตรวจการตั้งค่าและข้อจำกัด DNS Lookup จากผู้ให้บริการที่ใช้จริง

ขั้นตอนที่ 5: เปิด DKIM Signing

DKIM ต้องมีทั้งการเปิด Signing ใน Email Provider และ DNS Record ที่ใช้ตรวจ Public Key หรือ Selector หากตั้ง DNS แล้วแต่ยังไม่ได้เปิดการลงนาม เมลอาจยังไม่มี DKIM Signature

ชื่อ Selector และชนิด TXT/CNAME ขึ้นกับ Provider/แพ็กเกจ จึงควรใช้ค่าที่ Admin Console แสดง ไม่คัดลอก Key ตัวอย่างหรือใช้ Selector เดียวกับบริษัทอื่น ตรวจผลจาก Email Header ของข้อความที่ส่งออกจริง

ขั้นตอนที่ 6: ตั้ง DMARC และดูรายงาน

DMARC ตรวจ Alignment ระหว่าง Header From กับ SPF หรือ DKIM ไม่ใช่เพียงตรวจว่ามี Record หรือไม่ หากยังไม่รู้ทุกระบบที่ส่งเมลแทนบริษัท ควรเริ่มด้วยนโยบายสังเกตการณ์ เช่น

v=DMARC1; p=none; rua=mailto:dmarc@example.com

ตัวอย่างนี้ต้องสร้างผู้รับรายงานที่เข้าถึงได้จริงก่อน ข้อมูลรายงานอาจมีข้อมูลเกี่ยวกับระบบส่งจึงควรควบคุมสิทธิ์ผู้ดูแล เมื่อทราบว่าระบบที่ถูกต้องผ่าน Authentication แล้วจึงทยอยเพิ่มนโยบายเข้มงวดขึ้นตามความเหมาะสม ไม่ตั้ง p=reject ทันทีแล้วหวังว่าทุกระบบจะผ่าน

อ่านรายละเอียด Google Workspace DMARC และ Cloudflare Security Records

ขั้นตอนที่ 7: ทดสอบการส่งและรับจริง

ทดสอบอย่างน้อย 4 เส้นทาง: เมลจากภายนอกเข้าบริษัท, บริษัทส่งออกไปภายนอก, เมลระหว่างพนักงาน และเมลจากเว็บไซต์/CRM ที่ใช้ชื่อโดเมนเดียวกัน ทดลองส่งถึงผู้รับต่างผู้ให้บริการและตรวจ Folder Spam ด้วย

เปิดดู Email Header และผล Authentication ว่า SPF, DKIM, DMARC ผ่านหรือไม่ และ Alignment ตรงกับผู้ส่งจริง หากมี Bounce/Delay ให้อ่านรหัส Error, Mail Queue และ Log ก่อนแก้ DNS แบบเดา

ถ้าการ Forwarding ไปยังผู้ให้บริการอื่นทำให้ SPF ไม่ผ่าน อย่าแก้ด้วยการอนุญาตผู้ส่งทั้งหมด ให้ตรวจกลไก Forward, SRS, DKIM และ Routing ที่แพลตฟอร์มรองรับ

ตัวอย่างปัญหาที่เจอบ่อย

• รับได้แต่ส่งไม่ได้: ตรวจ SMTP/Auth, การเปิดบัญชี, SPF/DKIM, Quota และรหัสตีกลับ
• ส่งได้แต่รับไม่ได้: ตรวจ MX, Mailbox, Domain Verification, Spam Filter และ Routing
• Alias รับไม่ได้: ตรวจว่าผูกกับ Mailbox หรือ Group ที่มีอยู่จริง และนโยบายรับจากภายนอก
• ส่งออกจากฟอร์มเว็บแล้วติด Spam: ตรวจผู้ให้บริการที่ส่งแทนเว็บ, From Domain, DKIM และนโยบายผู้รับ ไม่ฝังรหัส SMTP ในโค้ดฝั่ง Browser

FAQ

MX ใช้ทำอะไรถ้าต้องการแค่ส่งอีเมลออก

MX ใช้ระบุทางรับเมล ส่วนการส่งออกต้องมี SMTP/Email API และ Authentication ที่เหมาะสม ผู้ส่งบางระบบอาจไม่ต้องใช้ MX ของโดเมนตัวเองเพื่อส่งออก แต่ต้องตั้ง SPF/DKIM/DMARC ตามแนวทาง Provider

ทำไมเพิ่ม SPF หลายแถวแล้วเมลเสีย

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

ใช้ Forwarding แทน Mailbox ได้เสมอไหม

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

Checklist ก่อนเริ่มใช้อีเมลบริษัทจริง

• ผู้ถือโดเมนและผู้ดูแล DNS เข้าถึงระบบได้
• สร้าง Mailboxes, Aliases, Groups พร้อมทดสอบ Login
• MX ตรงค่าผู้ให้บริการจริง
• SPF รวมทุกผู้ส่งที่ได้รับอนุญาต และเปิด DKIM
• DMARC มีนโยบายและผู้รับรายงานที่ดูแลได้
• ทดสอบส่งรับข้ามผู้ให้บริการ และข้อความจากเว็บไซต์
• บันทึกขั้นตอน Backup/Recovery และการเพิ่ม/ปิดผู้ใช้

หากกำลังเปลี่ยนระบบอีเมลเดิมไป Google Workspace หรือ Microsoft 365 ให้ทำ Email Migration Checklist ก่อนสลับ MX

อ้างอิง: Cloudflare DNS Records, Google SPF, Google DMARC, Microsoft 365 DNS Records ตรวจ 3 พฤศจิกายน 2026