DMARC, SPF และ DKIM: ตั้งค่าอย่างไรให้ถูกต้อง

การตั้งค่า DMARC, SPF และ DKIM คือการประกาศข้อมูลบน DNS (ระบบที่เหมือนสมุดโทรศัพท์ของอินเทอร์เน็ต เก็บข้อมูลประจำชื่อเว็บและชื่ออีเมลขององค์กร) ว่าระบบใดมีสิทธิ์ส่งอีเมลในนามองค์กร และผู้รับควรทำอย่างไรกับอีเมลที่ตรวจไม่ผ่าน ระบบนี้มีสามส่วน คือ SPF (รายการระบบที่ได้รับอนุญาตให้ส่ง) DKIM (ลายเซ็นดิจิทัลบนอีเมล) และ DMARC (กฎที่รวมผลของสองอย่างแรก แล้วบอกผู้รับว่าต้องทำอย่างไร) ตั้งผิดลำดับอาจทำให้อีเมลจริงถูกปฏิเสธ บทความนี้จึงอธิบายทีละส่วนด้วยภาษาง่าย แล้วให้ลำดับเปิดใช้ที่ปลอดภัย คือเฝ้าดูก่อน แล้วจึงบังคับใช้ (enforce)

ผู้รับอีเมลตรวจอะไรบ้าง

อีเมลหนึ่งฉบับเหมือนจดหมายในซอง บนซองมีที่อยู่ผู้ส่งที่ระบบอีเมลใช้ส่งต่อระหว่างเซิร์ฟเวอร์ เรียกว่า envelope sender หรือ MAIL FROM ส่วนจดหมายข้างในมีชื่อผู้ส่งที่ผู้ใช้เห็นในช่อง From โดเมน (domain) คือส่วนหลังเครื่องหมาย @ ของที่อยู่อีเมล เช่น example.com ที่อยู่บนซองกับที่อยู่ในช่อง From อาจมีโดเมนต่างกันได้ SPF กับ DKIM ไม่ได้ตรวจช่อง From โดยตรง ผู้โจมตีจึงปลอมชื่อในช่อง From ได้ DMARC ถูกสร้างมาเพื่อผูกผลตรวจของสองอย่างแรกเข้ากับช่อง From

• SPF: ตรวจ “ซอง” ผู้รับดูโดเมนที่อยู่บนซอง แล้วเปิด DNS ของโดเมนนั้นดูรายการ IP ที่ได้รับอนุญาต ถ้าเครื่องที่ส่งมามี IP อยู่ในรายการ ผลคือผ่าน
• DKIM: ตรวจ “ตราประทับบนจดหมาย” ผู้ส่งเซ็นอีเมลด้วยกุญแจลับ ผู้รับตรวจลายเซ็นด้วยกุญแจที่เปิดเผยไว้ใน DNS ถ้าเนื้อหาถูกแก้ระหว่างทาง ลายเซ็นจะไม่ผ่าน
• DMARC: ตรวจว่าโดเมนในช่อง From ตรงกับโดเมนที่ผ่าน SPF หรือ DKIM (เรียกว่า alignment) แล้วทำตามนโยบายที่โดเมนประกาศไว้ และส่งรายงานกลับไปให้เจ้าของโดเมน

DMARC ผ่านเมื่อ SPF หรือ DKIM อย่างน้อยหนึ่งอย่างผ่าน และโดเมนที่ผ่านนั้นตรงกับโดเมนในช่อง From เหตุผลคือใครก็ประกาศ SPF ให้โดเมนของตัวเองและผ่านได้ จึงต้องดูว่าตรงกับช่อง From หรือไม่ RFC 9989 แนะนำให้ทำให้ทั้ง SPF และ DKIM ตรงกับช่อง From ถ้าทำได้

SPF: ประกาศว่าใครส่งอีเมลแทนโดเมนได้

SPF คือรายการ IP address (หมายเลขประจำเครื่องบนเครือข่าย) และระบบที่ได้รับอนุญาตให้ส่งอีเมลในนามโดเมน เก็บไว้เป็น record (รายการข้อมูลหนึ่งรายการ) ประเภท TXT (ข้อความ) ใน DNS ของโดเมนนั้น ตัวอย่างต่อไปนี้ใช้โดเมนสมมติ example.com

example.com.  IN  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.mailprovider.example -all"

v=spf1 บอกว่าเป็น record ของ SPF ส่วน ip4:203.0.113.10 คือ IP ของเซิร์ฟเวอร์อีเมลขององค์กรเอง include: ให้รวมรายการของผู้ให้บริการส่งอีเมลภายนอก ส่วนท้ายสุดบอกว่าถ้าไม่ตรงรายการให้ทำอย่างไร -all หมายถึง IP อื่นทั้งหมดไม่ได้รับอนุญาต (fail) ส่วน ~all หมายถึงน่าจะไม่ได้รับอนุญาต แต่ไม่ถึงขั้นยืนยันหนักแน่น (softfail)

• มีได้ record เดียวต่อโดเมน: ถ้าพบ SPF มากกว่าหนึ่ง record ผลคือ permerror (ข้อผิดพลาดถาวร ตรวจให้เสร็จไม่ได้) ให้รวมเป็น record เดียว
• ค้นหา DNS ได้ไม่เกิน 10 ครั้ง: include, a, mx, ptr, exists และ redirect นับรวมกัน ถ้าเกิน 10 ผลคือ permerror ส่วน ip4, ip6 และ all ไม่นับ เมื่อใช้ผู้ให้บริการภายนอกหลายราย ควรนับจำนวนก่อนเพิ่มรายการใหม่
• ไม่ควรใช้ ptr: RFC 7208 ระบุว่าไม่ควรประกาศคำสั่ง ptr นี้ใน record
• การส่งต่อ (forwarding) ทำให้ SPF ไม่ผ่านได้: เซิร์ฟเวอร์ที่ส่งต่อมี IP คนละตัวกับที่โดเมนประกาศไว้ RFC 9989 จึงกำหนดว่าโดเมนที่ใช้ reject (นโยบาย DMARC ที่ให้ผู้รับปฏิเสธอีเมลที่ตรวจไม่ผ่าน) ต้องมี DKIM ด้วย ห้ามพึ่ง SPF อย่างเดียว

DKIM: ลายเซ็นดิจิทัลบนอีเมล

DKIM ใช้กุญแจสองดอกที่เป็นคู่กัน กุญแจส่วนตัว (private key) เป็นความลับ อยู่บนเซิร์ฟเวอร์ที่ส่งอีเมล ใช้เซ็นอีเมลแต่ละฉบับ กุญแจสาธารณะ (public key) เปิดเผยได้ ผู้ส่งประกาศไว้ใน DNS เพื่อให้ผู้รับตรวจว่าลายเซ็นมาจากกุญแจส่วนตัวคู่นี้จริง ถ้าเนื้อหาถูกแก้ภายหลัง ลายเซ็นจะไม่ตรงและตรวจไม่ผ่าน

ชื่อ record บอกที่อยู่ของกุญแจสาธารณะ โดยใช้รูปแบบ selector._domainkey ตามด้วยชื่อโดเมน selector คือชื่อป้ายที่ใช้แยกกุญแจแต่ละดอก ทำให้โดเมนเดียวมีกุญแจได้หลายดอก เช่น หนึ่งดอกต่อผู้ให้บริการหนึ่งราย

selector1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY"

ฝั่งผู้ส่ง ระบบส่งอีเมลจะเพิ่มส่วนหัวของอีเมล (header) ชื่อ DKIM-Signature ตัวอย่างย่อด้านล่างมี d= คือโดเมนที่เซ็น และ s= คือ selector ผู้รับนำสองค่านี้ไปประกอบเป็นชื่อ record ข้างต้น ค่า d= ต้องจับคู่กับโดเมนในช่อง From ตามกติกาด้านบน จึงจะนับเป็น DKIM ที่ผ่านสำหรับ DMARC

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; h=from:to:subject:date; bh=BODY_HASH; b=SIGNATURE

• ใช้ rsa-sha256: RFC 8301 ห้ามใช้ rsa-sha1 เซ็นอีเมล
• กุญแจ RSA (ชนิดกุญแจเข้ารหัสที่ DKIM ใช้) ยาวอย่างน้อย 1024 บิต แนะนำ 2048 บิตขึ้นไป: RFC 8301 กำหนดเช่นนี้ และ Google ระบุว่าการส่งถึง Gmail ส่วนบุคคลต้องใช้กุญแจ 1024 บิตขึ้นไป
• ผู้ให้บริการแต่ละรายใช้คู่กุญแจของตัวเอง: NIST แนะนำให้แยกกุญแจต่อผู้ให้บริการที่ส่งแทนองค์กร และเมื่อเลิกสัญญาให้ลบ record หรือเว้นค่า p= ให้ว่างเพื่อเพิกถอนกุญแจ
• เก็บกุญแจส่วนตัวให้ปลอดภัย: NIST ระบุว่าควรให้เฉพาะซอฟต์แวร์ส่งอีเมลอ่านกุญแจนี้ได้
• เมื่อเปลี่ยนคู่กุญแจ ให้เซ็นด้วยกุญแจใหม่ทันที: RFC 6376 แนะนำให้เก็บกุญแจสาธารณะเดิมไว้อีกช่วงหนึ่ง เพื่อให้ผู้รับที่ตรวจช้าตรวจได้
• ลายเซ็นมักยังใช้ได้เมื่อส่งต่อ แต่ไม่ผ่านถ้ามีการแก้เนื้อหา: เช่น ระบบกลางที่เติมข้อความท้ายอีเมล

กุญแจ DKIM ต้องมีเจ้าของและแผนเปลี่ยนเหมือนใบรับรองดิจิทัล แนวคิดเดียวกันอยู่ใน Certificate Lifecycle Management เมื่อใบรับรองเหลือ 47 วัน

DMARC: นโยบายและรายงาน

DMARC เพิ่มสามอย่างจาก SPF และ DKIM คือการจับคู่ชื่อ (alignment) นโยบายที่บอกผู้รับว่าต้องทำอย่างไร และรายงานที่ส่งกลับมาหาเจ้าของโดเมน การจับคู่มีสองแบบ แบบผ่อนปรน (relaxed ซึ่งเป็นค่าเริ่มต้น) ยอมให้ชื่อที่อยู่ใต้โดเมนหลักเดียวกันตรงกัน เช่น โดเมนที่ผ่านการตรวจคือ foo.example.com ส่วนช่อง From คือ news.example.com ก็นับว่าตรงกัน แบบเข้มงวด (strict) ต้องเป็นชื่อเดียวกันทุกตัวอักษร

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

• v=: ระบุเวอร์ชัน ค่าเดียวที่ใช้ได้คือ DMARC1 และต้องเป็นแท็ก (tag คือแต่ละรายการในรูป ชื่อ=ค่า) แรกของ record ถ้าไม่ใช่ ผู้รับจะเมินทั้ง record
• p=: นโยบายของโดเมน ค่าที่ใช้ได้คือ none, quarantine และ reject
• rua=: ที่อยู่ที่ขอให้ผู้รับส่งรายงานสรุป (aggregate report) มาให้ ถ้าไม่ใส่ ผู้รับจะไม่ส่งรายงาน
• sp= และ np=: sp คือนโยบายของโดเมนย่อยที่มีอยู่จริง np คือนโยบายของโดเมนย่อยที่ไม่มีอยู่จริง (np เพิ่มใน RFC 9989) ถ้าไม่ระบุ จะใช้ค่า p
• adkim= และ aspf=: เลือกการจับคู่แบบ relaxed (r) หรือ strict (s) สำหรับ DKIM และ SPF ตามลำดับ ค่าเริ่มต้นคือ r
• t=y: โหมดทดสอบ ขอให้ผู้รับใช้นโยบายต่ำลงหนึ่งขั้น เช่น reject จะถูกใช้เป็น quarantine

ค่าของ p มีสามระดับ none คือไม่ขอให้ผู้รับทำอะไรเป็นพิเศษกับอีเมลที่ตรวจไม่ผ่าน ใช้เฝ้าดูและรับรายงาน quarantine คือถือว่าอีเมลน่าสงสัย แต่อาจเป็นอีเมลจริง reject คือถือว่าการใช้ชื่อโดเมนนี้ไม่ถูกต้อง ผู้รับไม่ได้ถูกบังคับให้ทำตามเสมอไป RFC 9989 กำหนดให้ผู้รับดูปัจจัยอื่นด้วย ไม่ปฏิเสธเพียงเพราะเห็น p=reject อย่างเดียว

DMARC ฉบับที่คู่มือส่วนใหญ่อ้างถึงคือ RFC 7489 ซึ่งตอนนี้ถูกแทนที่แล้ว RFC 9989 (มาตรฐานหลัก) RFC 9990 (รายงานสรุป) และ RFC 9991 (รายงานรายข้อความ) ออกเมื่อพฤษภาคม 2026 และระบุว่าแทน RFC 7489 record ยังขึ้นต้นด้วย v=DMARC1 เหมือนเดิม แต่แท็ก pct, rf และ ri ถูกถอดออก และมีแท็ก np กับ t เพิ่มเข้ามา

แท็ก pct เดิมใช้ตั้งสัดส่วนอีเมลที่ถูกบังคับใช้นโยบาย เช่น pct=25 RFC 9989 อธิบายว่าผู้รับแต่ละรายทำตามค่าอื่นนอกจาก 0 และ 100 ไม่ตรงกัน จึงถอด pct แล้วใช้ t=y แทนช่วงทดสอบ ถ้าเห็น pct ในตัวอย่างเก่า ให้ใช้ t=y หรือเลื่อนนโยบายทีละขั้นตามบทความนี้

ลำดับเปิดใช้ที่ปลอดภัย: เฝ้าดูก่อน แล้วค่อยบังคับใช้

RFC 9989 อธิบายลำดับไว้ชัดเจน เริ่มจาก p=none เพื่อให้รายงานช่วยตรวจว่ามีระบบหรือผู้ให้บริการภายนอกที่ถูกลืมหรือไม่ แล้วจึงเข้มขึ้นทีละขั้น ข้อสำคัญคือต้องแก้อีเมลจริงที่ยังไม่ผ่านให้เรียบร้อยก่อนใช้ quarantine หรือ reject

ไม่ใช่ทุกโดเมนต้องไปถึง reject ทันที CISA แนะนำให้ตั้ง reject สำหรับอีเมลที่ส่งออก แต่ RFC 9989 เตือนว่า reject อาจสร้างปัญหากับเมลลิงลิสต์ (mailing list คือกลุ่มอีเมลที่ระบบส่งต่อข้อความให้สมาชิกทุกคน) อีเมลที่ถูกส่งต่อ และชื่ออีเมลกลางที่ส่งต่อให้คนอื่น (alias) โดเมนที่พนักงานใช้ส่งอีเมลทั่วไปจึงควรใช้ p=none อย่างน้อยหนึ่งเดือน ตามด้วย p=quarantine นานเท่ากัน แล้วเทียบผลก่อนตัดสินใจ ถ้าเลือก reject ควรแจ้งผู้ใช้ว่าการโพสต์ในเมลลิงลิสต์อาจมีปัญหา

อ่านรายงาน และแก้ปัญหาที่พบบ่อย

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

• ผู้ให้บริการภายนอกส่งในนามโดเมนขององค์กร แต่ไม่ได้ตั้งให้ตรงกับโดเมนนั้น: SPF ผ่านเฉพาะโดเมนของผู้ให้บริการ ซึ่งไม่ตรงกับช่อง From ต้องตั้งให้ผู้ให้บริการเซ็น DKIM ด้วยโดเมนขององค์กร
• SPF ค้นหา DNS เกิน 10 ครั้ง หรือมีหลาย record: SPF ทั้งชุดให้ผล permerror
• การส่งต่อและเมลลิงลิสต์: SPF มักไม่ผ่านเมื่อมีการส่งต่อ ส่วน DKIM ไม่ผ่านถ้าระบบกลางแก้เนื้อหา

ข้อกำหนดของผู้ให้บริการกล่องจดหมายรายใหญ่

ผู้ให้บริการบางรายกำหนดขั้นต่ำสำหรับผู้ส่ง ข้อมูลด้านล่างอ่านจากหน้าของผู้ให้บริการเอง และอาจเปลี่ยนได้

• Google (Gmail): ผู้ส่งทุกรายต้องตั้ง SPF หรือ DKIM อย่างน้อยหนึ่งอย่าง ผู้ส่งที่ส่งมากกว่า 5,000 ข้อความต่อวันไปยังบัญชี Gmail ต้องมีทั้ง SPF, DKIM และ DMARC โดยตั้งนโยบายเป็น none ได้ และชื่อในช่อง From ต้องตรงกับโดเมนของ SPF หรือ DKIM
• Yahoo: ผู้ส่งทุกรายต้องมี SPF หรือ DKIM อย่างน้อยหนึ่งอย่าง ผู้ส่งแบบ bulk (ส่งปริมาณมาก) ต้องมีทั้งสองอย่าง และต้องมี DMARC อย่างน้อย p=none ที่ผ่านการตรวจ โดยแนะนำอย่างยิ่งให้ใส่ rua หน้าของ Yahoo ไม่ระบุตัวเลขปริมาณที่นับเป็น bulk
• ข้อสรุป: p=none เป็นเพียงขั้นต่ำที่ผู้ให้บริการยอมรับ ไม่ได้ป้องกันการปลอมโดเมน เมื่อรายงานสะอาดแล้วควรขยับต่อ

ข้อผิดพลาดที่พบบ่อย

• เปิด reject ตั้งแต่วันแรก: อีเมลจริงจากระบบที่ถูกลืมจะถูกปฏิเสธ
• ตั้ง DMARC โดยไม่ใส่ rua หรือไม่อ่านรายงาน: เหมือนปิดตา ไม่รู้ว่าใครส่งในนามโดเมน
• สร้าง SPF หลาย record: ผลคือ permerror ต้องรวมเป็น record เดียว
• ใส่ include จนเกิน 10 การค้นหา DNS: SPF ทั้งชุดใช้ไม่ได้
• ค้างอยู่ที่ p=none ตลอดไป: ผ่านเกณฑ์ขั้นต่ำของผู้ให้บริการ แต่ยังไม่กันการปลอมโดเมน
• พึ่ง SPF อย่างเดียวเมื่อใช้ reject: การส่งต่อทำให้ SPF ไม่ผ่าน RFC 9989 กำหนดให้โดเมนที่ใช้ reject ต้องมี DKIM ด้วย
• ให้ผู้ให้บริการหลายรายใช้กุญแจ DKIM ดอกเดียวกัน หรือลืมถอนกุญแจเมื่อเลิกสัญญา: NIST แนะนำให้แยกกุญแจต่อผู้ให้บริการและเพิกถอนเมื่อเลิกใช้
• ทำตามคู่มือเก่าที่อ้าง RFC 7489 โดยไม่ตรวจมาตรฐานใหม่: เช่น ใช้ pct ซึ่งถูกถอดออกแล้ว

ขั้นแรกที่ทำได้ทันที

• ดู record SPF, DKIM และ DMARC ที่มีอยู่ของทุกโดเมน: รวมโดเมนที่ไม่ได้ใช้ส่งอีเมลด้วย
• ทำบัญชีรายการผู้ส่ง: ถามทุกฝ่ายว่ามีระบบหรือผู้ให้บริการใดส่งอีเมลในนามโดเมน
• เตรียมที่รับรายงาน แล้วเปิด DMARC เป็น p=none พร้อม rua: ใช้กล่องจดหมายเฉพาะหรือบริการแปลผลรายงาน
• นัดทบทวนรายงานทุกเดือน: ขยับนโยบายเมื่อผู้ส่งจริงทุกรายผ่านและตรงกับช่อง From
• ตรวจความยาวกุญแจ DKIM และรายชื่อผู้ให้บริการที่ยังมีกุญแจอยู่: ความยาวอย่างน้อย 1024 บิต แนะนำ 2048 บิต และถอนกุญแจของผู้ให้บริการที่เลิกใช้แล้ว
• อ่านภาพรวมการป้องกันอีเมลทุกชั้น: ดู Email Security: ป้องกันฟิชชิงและ BEC หลายชั้น

ถ้าอยากรู้ว่าการป้องกันอีเมลขององค์กรอยู่ตรงไหนเมื่อเทียบกับแนวปฏิบัติที่ดี ลองใช้ แบบประเมินตนเอง

ขอบเขตและความแม่นยำ

เนื้อหาของ DMARC อ้างอิงตัวเอกสาร RFC 9989 ที่อ่านเมื่อ 22 ตุลาคม 2026 ผู้ให้บริการอีเมลแต่ละรายอาจปรับให้ตรงกับมาตรฐานใหม่ไม่พร้อมกัน จึงควรตรวจเอกสารของผู้ให้บริการที่ใช้อยู่ ข้อกำหนดของ Google และ Yahoo อ่านจากหน้าของผู้ให้บริการเอง ไม่ได้รวม Microsoft เพราะอ่านหน้าของผู้ให้บริการไม่ได้ ตัวอย่าง record ใช้โดเมนสมมติ example.com และที่อยู่ IP ที่สงวนไว้สำหรับเอกสารตัวอย่าง ต้องแทนด้วยค่าจริงขององค์กรก่อนใช้ และทดสอบในโดเมนทดลองก่อน

แหล่งอ้างอิงและข้อมูลเพิ่มเติม

• RFC 9989: DMARC: มาตรฐานหลักของ DMARC ฉบับปัจจุบัน (พฤษภาคม 2026) แทน RFC 7489
• RFC 9990: DMARC Aggregate Reporting: รูปแบบรายงานสรุปที่ผู้รับส่งให้เจ้าของโดเมน
• RFC 7208: Sender Policy Framework (SPF): กติกา SPF รวมถึงขีดจำกัด 10 การค้นหา DNS
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures: กติกา DKIM ฉบับหลัก
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM: ห้ามใช้ rsa-sha1 และกำหนดความยาวกุญแจ
• NIST SP 800-177 Rev. 1: Trustworthy Email: คำแนะนำด้านการจัดการกุญแจ DKIM และ DMARC
• Google: Email sender guidelines: ข้อกำหนดผู้ส่งของ Gmail
• Yahoo: Sender best practices: ข้อกำหนดผู้ส่งของ Yahoo
• Phishing Guidance: Stopping the Attack Cycle at Phase One (CISA, NSA, FBI, MS-ISAC): คำแนะนำให้ตั้ง DMARC เป็น reject สำหรับอีเมลที่ส่งออก