หยุดเดา DNS ของคุณ: พาทัวร์ MX, SPF, DKIM และ DMARC แบบเป็นมิตรกับนักพัฒนา

ทำไมระเบียน DNS สำหรับอีเมลจึงสำคัญในตอนนี้

การยืนยันตัวตนอีเมลเคยเป็นเรื่องทางเลือก ในปี 2026 มันกลายเป็นสิ่งจำเป็นพื้นฐานแล้ว ทั้ง Gmail และ Outlook บังคับใช้ SPF และ DKIM สำหรับผู้ส่งอีเมลจำนวนมาก และ DMARC กำลังกลายเป็นข้อกำหนดอย่างรวดเร็วสำหรับทุกโดเมนที่ส่งอีเมลธุรกรรม หากระเบียน DNS ของคุณผิด อีเมลของคุณจะไม่ถึงปลายทาง—ไม่มี bounce ไม่มีคำเตือน มีเพียงความเงียบ

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

คู่มือนี้จะพาไปดู MX, SPF, DKIM และ DMARC ตามลำดับที่คุณจะเจอจริง พร้อมรายละเอียดพอสำหรับกำหนดค่าให้ถูกต้อง และบริบทพอสำหรับดีบักเมื่อมันมีปัญหา

ระเบียน MX: อีเมลขาเข้าจะไปที่ไหน

ระเบียน MX บอกอินเทอร์เน็ตว่า mail server ใดรับอีเมลสำหรับโดเมนของคุณ ระเบียนนี้เรียบง่ายที่สุดในบรรดาทั้งสี่รายการ แต่ก็เป็นรายการที่กำหนดค่าผิดได้ง่ายที่สุดเช่นกัน

ระเบียน MX มีสองส่วน: หมายเลข priority และ hostname หมายเลข priority ที่ต่ำกว่าจะถูกลองก่อน หากคุณใช้ Google Workspace ระเบียน MX ของคุณอาจมีหน้าตาแบบนี้:

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

จุดท้ายบรรทัดมีความสำคัญ—มันบอกว่า hostname นั้นเป็นชื่อแบบ fully qualified ผู้ให้บริการ DNS ส่วนใหญ่เติมให้โดยอัตโนมัติ แต่ไม่ใช่ทุกราย

ข้อผิดพลาดที่พบบ่อย: ชี้ระเบียน MX ไปที่ระเบียน A แทนที่จะเป็น hostname, ตั้ง priority ทั้งหมดเป็นเลขเดียวกัน (ซึ่งทำให้การมีเซิร์ฟเวอร์สำรองหมดความหมาย), หรือลืมลบระเบียน MX เก่าเมื่อย้ายผู้ให้บริการ ระเบียน MX ที่ค้างอยู่ไม่ได้แค่นั่งอยู่เฉย ๆ อย่างไม่มีพิษภัย—มันอาจทำให้เกิด mail loop หรือทำให้การส่งถูกแบ่งไปสองกล่องจดหมาย

หากคุณดูแลฟอร์มติดต่อเองและต้องการหลีกเลี่ยง spam โดยไม่พึ่งบริการภายนอก การเข้าใจว่าฟอร์มกลายเป็นช่องทางของ spam ได้อย่างไร เป็นจุดเริ่มต้นที่มีประโยชน์

SPF: เซิร์ฟเวอร์ใดได้รับอนุญาตให้ส่งในนามของคุณ

SPF (Sender Policy Framework) คือระเบียน TXT ที่ระบุ IP address และโดเมนที่ได้รับอนุญาตให้ส่งอีเมลในนามโดเมนของคุณ นี่เป็นการตรวจสอบแรก ๆ ที่ mail server ส่วนใหญ่ทำเมื่อได้รับข้อความที่อ้างว่าส่งมาจากคุณ

ระเบียน SPF พื้นฐานมีหน้าตาแบบนี้:

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

แยกส่วนออกมาได้ดังนี้:

• v=spf1 ประกาศเวอร์ชันของ SPF
• include:_spf.google.com มอบหมายให้ใช้ระเบียน SPF ของ Google
• ~all คือ soft fail—ปฏิเสธอีเมลจากแหล่งที่ไม่ได้ระบุไว้ แต่อย่าเข้มงวดเกินไป

คุณยังสามารถใช้ ip4: หรือ ip6: เพื่อ whitelist address เฉพาะ หรือใช้ a และ mx เพื่ออ้างอิงระเบียน A และ MX ของโดเมนคุณได้ กลไก all ท้ายระเบียนควบคุมว่าจะเกิดอะไรขึ้นกับอีเมลจากแหล่งที่คุณไม่ได้ระบุ: -all คือ hard fail (ปฏิเสธ), ~all คือ soft fail (ทำเครื่องหมายว่าน่าสงสัย), ?all คือ neutral (ไม่แสดงความเห็น), และ +all คือเปิดเสรีให้ทุกอย่าง (อย่าใช้แบบนี้)

SPF มีจุดคมอยู่สองอย่าง อย่างแรก มันพังเมื่ออีเมลถูก forward เพราะเซิร์ฟเวอร์ที่ forward ไม่ได้อยู่ในระเบียน SPF ของคุณ อย่างที่สอง ระเบียน SPF มีขีดจำกัดการ lookup ที่สิบ DNS query หากคุณ include บริการภายนอกมากเกินไป คุณจะเกินขีดจำกัดและ SPF จะหยุดทำงาน วิธีแก้คือ flatten ระเบียน SPF ของคุณ—แทนที่ directive include: ด้วยช่วง IP จริง—แต่ต้องมีการดูแลเมื่อผู้ให้บริการเปลี่ยน IP

DKIM: หลักฐานเชิงเข้ารหัสของตัวตนผู้ส่ง

DKIM (DomainKeys Identified Mail) เพิ่มลายเซ็นดิจิทัลให้กับอีเมลขาออกของคุณ เซิร์ฟเวอร์ผู้รับจะตรวจลายเซ็นเทียบกับ public key ที่เผยแพร่ไว้ใน DNS ของคุณ หากลายเซ็นถูกต้องและข้อความไม่ถูกแก้ไข DKIM จะผ่าน

ต่างจาก SPF, DKIM ยังคงใช้ได้แม้อีเมลถูก forward เพราะลายเซ็นเดินทางไปพร้อมกับข้อความ นอกจากนี้ยังยืดหยุ่นกว่า—คุณสามารถมี DKIM key หลายชุดสำหรับบริการส่งอีเมลต่าง ๆ โดยแต่ละชุดมี selector ของตัวเอง

ระเบียน DNS สำหรับ DKIM มีหน้าตาแบบนี้:

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

selector (default ในตัวอย่างนี้) ตั้งได้ตามต้องการ—ผู้ให้บริการอีเมลของคุณเป็นผู้เลือก ค่า p= คือ public key ซึ่งมักเป็นสตริง base64 ที่ยาว ผู้ให้บริการอีเมลของคุณจะสร้าง private key และใช้มันลงลายเซ็นข้อความขาออก

การตั้งค่า DKIM แทบจะถูกจัดการโดยผู้ให้บริการอีเมลเสมอ งานของคุณคือคัดลอกระเบียน TXT ที่พวกเขาให้มา แล้ววางลงใน DNS ของคุณ ส่วนที่ยุ่งยากคือผู้ให้บริการ DNS บางรายจัดการระเบียน TXT ยาว ๆ ได้ไม่ดี—อาจตัดข้อความทิ้ง หรือบังคับให้คุณแยกค่าออกเป็นหลายสตริงในเครื่องหมายคำพูด

หากต้องการตรวจว่า DKIM ทำงานอยู่ ให้ส่งอีเมลทดสอบไปยังที่อยู่ Gmail แล้วตรวจ headers มองหา dkim=pass ใน header Authentication-Results

DMARC: การบังคับใช้นโยบายและการรายงาน

DMARC (Domain-based Message Authentication, Reporting and Conformance) เชื่อม SPF และ DKIM เข้าด้วยกัน และบอกเซิร์ฟเวอร์ผู้รับว่าควรทำอะไรเมื่อการยืนยันตัวตนล้มเหลว นอกจากนี้ยังเปิดใช้การรายงาน เพื่อให้คุณเห็นว่าใครกำลังส่งอีเมลในนามโดเมนของคุณ—ทั้งที่ถูกต้องและที่ปลอมแปลง

ระเบียน DMARC ขั้นต่ำมีหน้าตาแบบนี้:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none หมายถึงเฝ้าดูเท่านั้น—อย่าปฏิเสธหรือ quarantine ข้อความที่ไม่ผ่าน
• rua=mailto:[email protected] ระบุว่าจะส่ง aggregate reports ไปที่ใด

เมื่อคุณมั่นใจว่า SPF และ DKIM ทำงานแล้ว คุณสามารถปรับนโยบายให้เข้มขึ้นเป็น p=quarantine (ส่งรายการที่ล้มเหลวไปยัง spam) หรือ p=reject (ตีกลับทันที) ได้ คุณยังสามารถตั้งนโยบายสำหรับ subdomain ด้วย sp= และระบุเปอร์เซ็นต์ของข้อความที่จะนำไปใช้นโยบายด้วย pct=

รายงาน DMARC เป็นไฟล์ XML ที่ผู้รับรายใหญ่ส่งทุกวัน มันละเอียดและอ่านแบบ raw ยาก แต่จะบอกคุณอย่างชัดเจนว่าข้อความใดผ่านหรือไม่ผ่านการยืนยันตัวตน และเพราะเหตุใด หากคุณเห็นอีเมลที่ถูกต้องถูกปฏิเสธ รายงานจะชี้ให้เห็นว่า SPF หรือ DKIM check ใดล้มเหลว

จุดที่มักพลาด: DMARC ต้องการ alignment สำหรับ SPF โดเมนใน header Return-Path ต้องตรงกับโดเมนใน header From (หรือเป็น subdomain) สำหรับ DKIM โดเมน d= ในลายเซ็น DKIM ต้องตรงกับโดเมน From หากคุณใช้บริการส่งอีเมลภายนอก บริการนั้นต้องรองรับ custom return paths หรือการลงลายเซ็น DKIM ด้วยโดเมนของคุณ ไม่ใช่โดเมนของพวกเขา

วิธี audit การตั้งค่าปัจจุบันของคุณ

ปัญหา DNS ส่วนใหญ่มองไม่เห็นจนกว่าจะก่อปัญหา นี่คือวิธีตรวจระเบียนของคุณก่อนที่บางอย่างจะพัง:

1. Query ระเบียน MX ของคุณ: dig MX example.com ควรคืนค่า hostname และ priority ของ mail server ของคุณ ตรวจว่าตรงกับเอกสารของผู้ให้บริการอีเมล

1. ตรวจ syntax ของ SPF: dig TXT example.com แล้วมองหาระเบียน v=spf1 นำไปผ่าน SPF validator เพื่อจับ syntax error และการละเมิดขีดจำกัด lookup

1. ตรวจสอบ DKIM keys: ส่งอีเมลทดสอบและตรวจ header DKIM-Signature ดึง selector และโดเมนออกมา จากนั้น query dig TXT selector._domainkey.example.com เพื่อยืนยันว่ามี public key อยู่

1. ตรวจนโยบาย DMARC: dig TXT _dmarc.example.com ควรคืนค่าระเบียน DMARC ของคุณ ตรวจให้แน่ใจว่า rua= ชี้ไปยัง address ที่คุณติดตามจริง

1. ทดสอบ end-to-end: ใช้บริการอย่าง mail-tester.com หรือส่งไปยังที่อยู่ Gmail แล้วตรวจ headers แบบเต็ม มองหา spf=pass, dkim=pass, และ dmarc=pass ใน header Authentication-Results

หากคุณกำลังดีบักว่าทำไมอีเมลไม่ถึงปลายทาง headers คือเครื่องมือที่ดีที่สุดของคุณ mail client ส่วนใหญ่ให้ดู raw headers ได้—ใน Gmail ให้เปิดข้อความ คลิกจุดสามจุด แล้วเลือก 'Show original' header Authentication-Results จะบอกคุณอย่างชัดเจนว่า check ใดล้มเหลวและเพราะอะไร

เมื่อใดควรใช้นโยบาย subdomain

หากคุณส่งอีเมลจากหลาย subdomain—เช่น newsletter.example.com สำหรับการตลาด และ app.example.com สำหรับอีเมลธุรกรรม—คุณสามารถตั้งนโยบาย DMARC แยกตาม subdomain ได้ วิธีนี้ช่วยให้คุณบังคับใช้นโยบายเข้มงวดกับ subdomain ที่คุณควบคุม ขณะยังคงนโยบายที่ผ่อนคลายกว่าบนโดเมนหลัก

ข้อแลกเปลี่ยนคือความซับซ้อน แต่ละ subdomain ต้องมีระเบียน SPF, DKIM และ DMARC ของตัวเอง และคุณต้องติดตามว่าบริการส่งอีเมลใดได้รับอนุญาตสำหรับ subdomain ใด สำหรับทีมขนาดเล็กส่วนใหญ่ โดเมนเดียวที่กำหนดค่าดีจะง่ายกว่าและปลอดภัยพอ ๆ กัน

ควรทำอย่างไรเมื่อการยืนยันตัวตนพัง

รูปแบบความล้มเหลวที่พบบ่อยที่สุดคือการเพิ่มบริการส่งอีเมลใหม่โดยไม่อัปเดต DNS หากคุณเริ่มใช้ผู้ให้บริการอีเมลธุรกรรมรายใหม่ คุณต้องเพิ่ม SPF include หรือช่วง IP ของพวกเขา กำหนดค่า DKIM signing ด้วยโดเมนของคุณ และตรวจสอบ DMARC alignment

ปัญหาที่พบบ่อยอันดับสองคือการ forwarding หากผู้ใช้ forward อีเมลของคุณไปยังอีก address หนึ่ง SPF จะล้มเหลวเพราะเซิร์ฟเวอร์ที่ forward ไม่ได้อยู่ในระเบียน SPF ของคุณ DKIM มักยังคงผ่านเมื่อมีการ forwarding ดังนั้นตราบใดที่ DKIM ผ่านและนโยบาย DMARC ของคุณอนุญาต partial alignment ข้อความก็ควรถูกส่งได้อยู่ หากคุณเห็นอีเมลที่ถูก forward ถูกปฏิเสธ ให้ตรวจนโยบาย DMARC—p=reject พร้อม strict alignment จะทำให้ forwarding พัง

ปัญหาอันดับสามคือ DNS propagation การเปลี่ยนแปลงระเบียน DNS อาจใช้เวลาหลายชั่วโมงในการ propagate และ mail server ต่าง ๆ cache ระเบียนไว้นานไม่เท่ากัน หากคุณเพิ่งอัปเดตระเบียนและมันยังไม่ทำงาน ให้รอสองสามชั่วโมงแล้วทดสอบอีกครั้ง คุณสามารถตรวจ propagation ได้ด้วยเครื่องมืออย่าง whatsmydns.net

ประเด็นสำคัญ

• ระเบียน MX route อีเมลขาเข้า; SPF, DKIM และ DMARC ยืนยันตัวตนอีเมลขาออก ทั้งหมดแก้ปัญหาคนละอย่าง และคุณต้องมีทั้งสี่รายการ
• SPF พังเมื่อมีการ forwarding และมีขีดจำกัดสิบ lookup DKIM ยังคงใช้ได้เมื่อ forwarding แต่ต้องกำหนดค่าแยกตามบริการ DMARC เชื่อมทั้งสองเข้าด้วยกันและเปิดใช้การรายงาน
• เริ่มด้วย p=none ใน DMARC เฝ้าดูรายงานสักสองสามสัปดาห์ แล้วค่อยปรับเข้มเป็น p=quarantine หรือ p=reject เมื่อคุณมั่นใจว่าอีเมลที่ถูกต้องผ่านแล้ว
• ข้อผิดพลาด DNS เงียบมาก ทดสอบการกำหนดค่าด้วยอีเมลจริงและตรวจ headers เพื่อยืนยันว่า SPF, DKIM และ DMARC ผ่าน
• หากการยืนยันตัวตนพังหลังเพิ่มบริการส่งอีเมลใหม่ ให้ตรวจ SPF includes, DKIM selectors และ DMARC alignment headers จะบอกคุณว่า check ใดล้มเหลว

FAQ

Q: ฉันมีระเบียน SPF หลายรายการได้ไหม?

A: ไม่ได้ ระเบียน SPF หลายรายการจะทำให้ทั้งหมดถูกเพิกเฉย หากคุณต้องอนุญาตหลายบริการ ให้ใช้ directive include: ภายในระเบียน SPF เดียว หรือระบุช่วง IP โดยตรง ระวังขีดจำกัดสิบ lookup

Q: ฉันต้องใช้ DMARC ไหมถ้าส่งอีเมลแค่ไม่กี่ฉบับต่อวัน?

A: ต้องใช้ DMARC ไม่ได้เกี่ยวกับปริมาณ—แต่เกี่ยวกับการพิสูจน์ว่าคุณเป็นคนที่คุณอ้างว่าเป็น แม้แต่โดเมนขนาดเล็กก็ได้ประโยชน์จาก DMARC เพราะช่วยป้องกันการ spoofing และให้คุณเห็นปัญหาการส่ง เริ่มด้วย p=none และ address สำหรับรายงาน

Q: จะเกิดอะไรขึ้นถ้า DKIM และ SPF ล้มเหลวทั้งคู่ แต่อีเมลดูถูกต้อง?

A: ขึ้นอยู่กับนโยบาย DMARC ของคุณ หาก p=none อีเมลจะถูกส่งพร้อมคำเตือน หาก p=quarantine จะไปอยู่ใน spam หาก p=reject จะถูก bounce นี่คือเหตุผลที่คุณควรเฝ้าดูรายงาน DMARC ก่อนบังคับใช้นโยบายเข้มงวด—คุณอาจมีผู้ส่งที่ถูกต้องซึ่งคุณไม่เคยรู้มาก่อน

Q: ฉันใช้ DKIM key เดียวกันกับหลายโดเมนได้ไหม?

A: ในทางเทคนิคทำได้ แต่ไม่ควร แต่ละโดเมนควรมี DKIM key pair ของตัวเอง การใช้ key ร่วมกันทำให้การ rotate ยากขึ้น และเพิ่มผลกระทบหาก private key ถูก compromise

Q: ควร rotate DKIM keys บ่อยแค่ไหน?

A: ไม่มี नियमสากล แต่ปีละครั้งถือว่าสมเหตุสมผลสำหรับโดเมนส่วนใหญ่ หากคุณสงสัยว่า key ถูก compromise ให้ rotate ทันที ตรวจให้แน่ใจว่าได้เผยแพร่ public key ใหม่ใน DNS ก่อนเริ่มลงลายเซ็นด้วย private key ใหม่ และคง key เก่าไว้ใน DNS อีกสองสามวันหลัง rotation เพื่อรองรับอีเมลที่ล่าช้า

<!-- tool-cta:start -->

💡 ลองทำสิ่งนี้: ตรวจสอบนโยบายที่เผยแพร่ของโดเมนใดก็ได้ด้วย DMARC Lookup เพื่อดูว่าเรคคอร์ด MX, SPF และ DMARC ทำงานร่วมกันอย่างไรในทางปฏิบัติ

<!-- tool-cta:end -->

Sources

• RFC 7208: Sender Policy Framework (SPF) — ข้อกำหนด SPF รวมถึงกฎ syntax และขีดจำกัดสิบ lookup
• RFC 6376: DomainKeys Identified Mail (DKIM) — ข้อกำหนด DKIM ครอบคลุมการสร้างและการตรวจสอบลายเซ็น
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — ข้อกำหนด DMARC รวมถึง syntax ของนโยบายและรูปแบบ aggregate reporting
• Google Workspace: Prevent spoofing and spam — แนวทางเชิงปฏิบัติในการกำหนดค่า SPF, DKIM และ DMARC สำหรับโดเมน Google Workspace