- 23
- มิถุนายน
SPF, DKIM และ DMARC คือ 3 มาตรฐานยืนยันตัวตนอีเมล (Email Authentication) ที่ทำงานร่วมกันเพื่อพิสูจน์ว่า "อีเมลที่อ้างว่ามาจากโดเมนของคุณ มาจากคุณจริง" — SPF บอกว่าเซิร์ฟเวอร์ไหนได้รับอนุญาตให้ส่งเมลแทนโดเมน, DKIM ลงลายเซ็นดิจิทัลกันการแก้ไขเนื้อหา, ส่วน DMARC คือกฎที่สั่งปลายทางว่าให้ทำอย่างไรถ้าเมลไม่ผ่านการตรวจ พร้อมส่งรายงานกลับมาให้เจ้าของโดเมน ทั้งสามตัวคือเกราะป้องกัน ความปลอดภัยข้อมูลองค์กร ชั้นแรกที่ทำงานคู่กับ การยืนยันตัวตนสองชั้น (2FA) และระบบ e-Tax Invoice ที่ส่งเอกสารผ่านอีเมล
สรุปง่ายๆ: ลองนึกภาพการส่งจดหมาย — SPF = รายชื่อบุรุษไปรษณีย์ที่ได้รับอนุญาตให้ส่งแทนคุณ, DKIM = ตราประทับครั่งกันเปิด/แก้จดหมาย, DMARC = คำสั่งที่ติดไว้ว่า "ถ้าไม่มีรายชื่อและไม่มีตราประทับ ให้ตีกลับหรือทิ้ง แล้วรายงานกลับมาด้วย" ตั้งแต่ ก.พ. 2567 Gmail และ Yahoo รวมถึง พ.ค. 2568 Microsoft Outlook บังคับให้ผู้ส่งจำนวนมากต้องมีครบทั้งสาม ไม่งั้นอีเมลตกถังสแปมหรือถูกปฏิเสธ
ทำไมต้องสนใจ "ตอนนี้"? — เพราะมันกลายเป็นข้อบังคับแล้ว
หลายองค์กรเคยมองว่า SPF/DKIM/DMARC เป็นเรื่อง "ทำก็ดี ไม่ทำก็ได้" แต่ตั้งแต่ปี 2567 เป็นต้นมา ผู้ให้บริการอีเมลรายใหญ่ของโลกเปลี่ยนมาเป็น "ไม่ทำ = ส่งไม่ถึง" โดยเฉพาะกับองค์กรที่ส่งอีเมลจำนวนมาก เช่น แจ้งเตือนจากระบบ ERP, ใบแจ้งหนี้, จดหมายข่าว หรืออีเมลการตลาด
| ผู้ให้บริการ | เริ่มบังคับ | ใครโดน & ต้องมีอะไร |
|---|---|---|
| Gmail + Yahoo | ก.พ. 2567 (2024) | ผู้ส่ง ~5,000 ฉบับ/วันขึ้นไปไปยังบัญชี Gmail ต้องมี SPF + DKIM + DMARC (อย่างน้อย p=none), one-click unsubscribe และคุมอัตราร้องเรียนสแปมไม่ให้เกิน 0.3% |
| Microsoft Outlook / Hotmail | พ.ค. 2568 (2025) | ผู้ส่ง 5,000+ ฉบับ/วัน ต้องมี SPF + DKIM + DMARC ครบ — ไม่ครบจะถูกส่งเข้า Junk และต่อมาถูกปฏิเสธด้วย error "550 5.7.515 Access denied" |
| ผู้ให้บริการอื่น | ทยอยตาม | Apple Mail และระบบกรองสแปมองค์กรส่วนใหญ่ใช้สัญญาณ SPF/DKIM/DMARC ประกอบการตัดสินใจส่งเข้า inbox หรือสแปม |
ประเด็นสำคัญคือ เกณฑ์ 5,000 ฉบับ/วันไม่ได้แปลว่าองค์กรเล็กไม่ต้องสน — เพราะแม้ส่งวันละไม่กี่ร้อยฉบับ การไม่มี DMARC ก็เปิดช่องให้คนปลอมโดเมนของคุณส่งอีเมลหลอกลูกค้าได้ และอีเมลถูกต้องของคุณเองก็มีโอกาสตกสแปมสูงขึ้น
SPF คืออะไร? — "ใครได้รับอนุญาตให้ส่งแทนฉัน"
SPF (Sender Policy Framework) คือเรคคอร์ด DNS แบบ TXT ที่ระบุว่าเซิร์ฟเวอร์ (IP address) ใดบ้างได้รับอนุญาตให้ส่งอีเมลในนามโดเมนของคุณ เมื่อเซิร์ฟเวอร์ปลายทางได้รับเมล มันจะเช็กว่า IP ผู้ส่งจริงอยู่ในรายชื่อที่โดเมนประกาศไว้หรือไม่ มาตรฐานนี้กำหนดไว้ใน RFC 7208
ตัวอย่างเรคคอร์ด SPF ที่อนุญาตให้ Google Workspace และ IP ของเซิร์ฟเวอร์องค์กรหนึ่งตัวส่งเมลได้:
example.com. IN TXT "v=spf1 include:_spf.google.com ip4:203.0.113.25 -all"
ส่วนสำคัญที่สุดคือตัวปิดท้าย ซึ่งกำหนดว่าจะจัดการกับเซิร์ฟเวอร์ที่ "ไม่อยู่ในรายชื่อ" อย่างไร:
-all(Fail / เข้มงวด) — เซิร์ฟเวอร์ที่ไม่อยู่ในรายชื่อ ให้ถือว่า "ไม่ผ่าน" → แนะนำสำหรับใช้งานจริง~all(SoftFail / ผ่อนปรน) — ไม่อยู่ในรายชื่อให้ "น่าสงสัย" แต่ยังรับไว้ → เหมาะช่วงเริ่มทดสอบ+all— อนุญาตทุกเซิร์ฟเวอร์ → ห้ามใช้เด็ดขาด เท่ากับไม่มี SPF
หมายเหตุข้อจำกัด: SPF มีเพดาน DNS lookup ได้ไม่เกิน 10 ครั้ง ต่อการตรวจหนึ่งครั้ง ถ้าใส่ include: ของผู้ให้บริการหลายเจ้าจนเกิน จะเกิดสถานะ "PermError" และ SPF ล้มทั้งเรคคอร์ด — เป็นข้อผิดพลาดที่พบบ่อยมากเมื่อองค์กรใช้หลายระบบส่งเมล (ERP, CRM, ระบบส่งจดหมายข่าว) พร้อมกัน
จุดอ่อนของ SPF ที่ DKIM และ DMARC มาเติมเต็ม: SPF ตรวจเฉพาะ "ที่อยู่ซองจดหมาย" (envelope / Return-Path) ไม่ได้ตรวจชื่อโดเมนใน From: ที่ผู้ใช้มองเห็น และ SPF จะ "พัง" เมื่ออีเมลถูกส่งต่อ (forward) เพราะ IP ผู้ส่งเปลี่ยนไป ด้วยเหตุนี้ SPF อย่างเดียวจึงไม่พอ
DKIM คืออะไร? — "ตราประทับครั่งกันแก้เนื้อหา"
DKIM (DomainKeys Identified Mail) คือการลงลายเซ็นดิจิทัลให้อีเมลด้วยการเข้ารหัสแบบกุญแจคู่ (RFC 6376) แนวคิดเดียวกับ ลายมือชื่ออิเล็กทรอนิกส์ คือ เซิร์ฟเวอร์ผู้ส่งใช้ กุญแจส่วนตัว (Private Key) เซ็นส่วนหัวและเนื้อหาอีเมล แล้วฝัง signature ไว้ในเฮดเดอร์ ส่วนปลายทางจะดึง กุญแจสาธารณะ (Public Key) จากเรคคอร์ด DNS ของโดเมนมาตรวจสอบ
ถ้าตรวจผ่าน แปลว่า 2 อย่างเป็นจริงพร้อมกัน: (1) อีเมลมาจากโดเมนที่อ้างจริง และ (2) เนื้อหาไม่ถูกแก้ไขระหว่างทาง ตัวอย่างเฮดเดอร์ DKIM-Signature และเรคคอร์ด public key ใน DNS:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; h=from:to:subject:date; bh=...; b=... selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ..."
คำว่า selector1 เรียกว่า "selector" — ทำให้โดเมนเดียวมีหลายกุญแจได้ (เช่น แยกกุญแจของ ERP, ของระบบจดหมายข่าว, ของ Google Workspace) และหมุนเปลี่ยนกุญแจ (key rotation) ได้โดยไม่กระทบกัน ข้อดีสำคัญคือ DKIM ไม่พังเวลา forward เพราะลายเซ็นติดไปกับตัวอีเมล ไม่ผูกกับ IP ผู้ส่ง
DMARC คืออะไร? — "กฎและรายงานที่มัดทุกอย่างเข้าด้วยกัน"
DMARC (Domain-based Message Authentication, Reporting & Conformance) คือชั้นนโยบายที่นั่งทับ SPF และ DKIM อีกที (RFC 7489) ทำหน้าที่ 3 อย่าง:
- Alignment (การจับคู่โดเมน) — บังคับว่าโดเมนใน
From:ที่ผู้ใช้เห็น ต้องตรงกับโดเมนที่ผ่าน SPF หรือ DKIM นี่คือหัวใจที่ปิดช่องโหว่ของ SPF/DKIM เดี่ยวๆ - Policy (นโยบาย) — สั่งปลายทางว่าให้ทำอย่างไรกับเมลที่ไม่ผ่าน
- Reporting (รายงาน) — ให้ปลายทางส่งรายงานสรุป (aggregate report) กลับมาให้เจ้าของโดเมนเห็นว่าใครส่งเมลในนามโดเมนเราบ้าง
ตัวอย่างเรคคอร์ด DMARC ที่ตั้งนโยบายเข้มงวดสุด (reject) พร้อมรับรายงาน:
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100; adkim=s; aspf=s"
ค่า p= คือระดับนโยบาย ซึ่งควรไล่จากเบาไปหนักทีละขั้นเพื่อไม่ให้เมลถูกต้องถูกบล็อกโดยไม่ได้ตั้งใจ:
| นโยบาย | ปลายทางทำอะไรกับเมลที่ไม่ผ่าน | เหมาะกับ |
|---|---|---|
| p=none | ไม่ทำอะไร แค่ส่งรายงานกลับ (โหมดสังเกตการณ์) | ช่วงเริ่มต้น — เก็บข้อมูลว่าใครส่งเมลในนามเราบ้าง |
| p=quarantine | นำเมลที่ไม่ผ่านเข้าถัง Junk / Spam | เมื่อมั่นใจว่าเมลถูกต้องผ่านครบแล้ว |
| p=reject | ปฏิเสธเมลที่ไม่ผ่านทันที (ไม่ส่งถึงผู้รับเลย) | เป้าหมายสูงสุด — กันการปลอมโดเมนได้จริง |
ส่วน adkim=s และ aspf=s คือโหมด alignment แบบเข้มงวด (strict) ที่ต้องตรงกันเป๊ะ ขณะที่ค่าเริ่มต้น r (relaxed) ยอมให้ตรงกันแค่ระดับโดเมนหลัก (เช่น mail.example.com ถือว่าตรงกับ example.com) — องค์กรส่วนใหญ่เริ่มจาก relaxed ก่อน
เทียบ SPF vs DKIM vs DMARC ในตารางเดียว
ทั้งสามไม่ใช่ "ตัวเลือกแทนกัน" แต่เป็น "ทีมที่ต้องทำงานร่วมกัน" — สรุปบทบาทของแต่ละตัว:
| หัวข้อ | SPF | DKIM | DMARC |
|---|---|---|---|
| ตรวจอะไร | IP เซิร์ฟเวอร์ผู้ส่งได้รับอนุญาตหรือไม่ | ลายเซ็นดิจิทัล + เนื้อหาไม่ถูกแก้ | โดเมน From ตรงกับ SPF/DKIM + นโยบาย |
| ดูที่ฟิลด์ | Return-Path (ซองจดหมาย) | DKIM-Signature header | From: (ที่ผู้ใช้มองเห็น) |
| พังเวลา forward? | พัง (IP เปลี่ยน) | ไม่พัง (ลายเซ็นติดไปกับเมล) | ผ่านได้ถ้า DKIM ผ่าน |
| มีรายงาน? | ไม่มี | ไม่มี | มี (aggregate / forensic) |
| มาตรฐาน | RFC 7208 | RFC 6376 | RFC 7489 |
คำเตือนความเข้าใจผิดที่อันตรายที่สุด: "มี SPF กับ DKIM แล้ว = ปลอดภัย" — ผิด เพราะถ้าไม่มี DMARC คนร้ายยังตั้งโดเมนของตัวเองให้ผ่าน SPF/DKIM ของ โดเมนตัวเอง แล้วใส่ From: เป็นชื่อบริษัทคุณได้ ผู้รับจะเห็นชื่อบริษัทคุณเต็มๆ ทั้งที่เมลไม่ได้มาจากคุณ — มีแต่ DMARC + alignment ที่ปิดช่องนี้ และต้องไปถึง p=quarantine หรือ p=reject จึงจะกันได้จริง (ค้างที่ p=none เท่ากับติดกล้องวงจรปิดแต่ไม่ล็อกประตู)
ทำไมเรื่องนี้สำคัญกับองค์กรที่ใช้ ERP
ระบบ ERP ในปัจจุบันส่งอีเมล "แทนคุณ" ตลอดเวลา ไม่ว่าจะเป็นใบเสนอราคา ใบแจ้งหนี้ ใบสั่งซื้อ ใบกำกับภาษีอิเล็กทรอนิกส์ หรืออีเมลแจ้งเตือนอนุมัติเอกสาร เมื่ออีเมลเหล่านี้ "เป็นเรื่องเงิน" มันจึงกลายเป็นเป้าหมายของมิจฉาชีพโดยตรง
กรณีที่อันตรายที่สุดคือ Business Email Compromise (BEC) — คนร้ายปลอมอีเมลในนามบริษัทคุณส่งไปหาลูกค้า แนบ "ใบแจ้งหนี้" ที่หน้าตาเหมือนของจริงทุกอย่างแต่เปลี่ยนเลขบัญชีปลายทาง ถ้าโดเมนคุณไม่มี DMARC แบบ reject ลูกค้าจะไม่มีทางรู้เลยว่าเมลนั้นปลอม นี่คือกลไกเดียวกับที่อธิบายไว้ในบทความ ระบบเจ้าหนี้และการป้องกันทุจริตใบแจ้งหนี้
| อีเมลจาก ERP | ถ้าไม่มี SPF/DKIM/DMARC | ถ้ามีครบ + DMARC reject |
|---|---|---|
| ใบเสนอราคา / ใบแจ้งหนี้ | เสี่ยงตกสแปม ลูกค้าไม่เห็น / ถูกปลอมเปลี่ยนเลขบัญชี | เข้า inbox + ปลอมในนามโดเมนไม่ได้ |
| อีเมลแจ้งเตือน / OTP อนุมัติ | ส่งช้า/ไม่ถึง กระทบ workflow | ส่งถึงตรงเวลา น่าเชื่อถือ |
| ชื่อเสียงโดเมน (domain reputation) | เสื่อมเมื่อถูกใช้ส่งสแปม/ฟิชชิง | ปกป้องแบรนด์ + ต่อยอด BIMI โชว์โลโก้ในกล่องเมลได้ |
พูดอย่างตรงไปตรงมา: SPF/DKIM/DMARC เป็นการตั้งค่าที่ระดับ โดเมนและเซิร์ฟเวอร์อีเมล ขององค์กร ไม่ใช่ฟีเจอร์ในตัวซอฟต์แวร์ ERP โดยตรง สิ่งที่ทีมงาน Grand Linux ทำได้คือ ตั้งค่าให้ระบบ ERP ส่งเมลผ่าน SMTP relay ที่ลงลายเซ็น DKIM ได้ถูกต้อง และให้คำแนะนำเรื่องการวางเรคคอร์ด SPF/DKIM/DMARC บน DNS ของโดเมนคุณให้สอดคล้องกัน — เพื่อให้อีเมลที่ออกจาก ERP ผ่านการตรวจทั้งสามชั้น
ขั้นตอนเริ่มทำให้ถูกต้อง (แบบไม่ทำเมลตัวเองพัง)
- สำรวจก่อนว่าใครส่งเมลในนามโดเมนคุณบ้าง — ERP, อีเมลพนักงาน (Google Workspace/Microsoft 365), ระบบจดหมายข่าว, ระบบ CRM ฯลฯ ทำรายการให้ครบ
- วาง SPF ให้ครอบคลุมทุกแหล่ง — ใส่
include:ของทุกผู้ให้บริการ ระวังเพดาน 10 DNS lookup - เปิด DKIM ทุกระบบที่รองรับ — แต่ละระบบมัก generate selector + public key ให้ เอาไปวางใน DNS
- เริ่ม DMARC ที่ p=none — เพื่อเก็บรายงาน (rua) ดูว่ามีแหล่งไหนส่งเมลที่ยังไม่ผ่าน alignment
- ไล่ขึ้น quarantine แล้วค่อย reject — เมื่อรายงานนิ่งและเมลถูกต้องผ่านครบ 100% แล้ว จึงค่อยเข้มนโยบาย
- ตรวจรายงานสม่ำเสมอ — DMARC report คือเรดาร์ที่บอกว่ามีใครพยายามปลอมโดเมนคุณหรือไม่
คำแนะนำสำคัญ: อย่ากระโดดไป p=reject ทันทีตั้งแต่วันแรก ถ้ายังไม่ได้ตรวจสอบจากรายงาน DMARC ว่าเมลถูกต้องของทุกระบบผ่าน alignment ครบแล้ว เพราะอาจทำให้ใบเสนอราคาหรือใบแจ้งหนี้ที่ออกจาก ERP ถูกปฏิเสธโดยไม่ได้ตั้งใจ — ทำทีละขั้นเสมอ
สรุป: องค์กรแบบไหน ควรทำระดับไหน
| องค์กร | ขั้นต่ำที่ควรมี | เป้าหมาย |
|---|---|---|
| SME ส่งเมลธุรกิจทั่วไป | SPF + DKIM + DMARC p=none | ไล่ถึง p=quarantine |
| องค์กรส่งเมลจำนวนมาก (5,000+/วัน) | ครบสามตัว + one-click unsubscribe | p=reject + คุมอัตราสแปม < 0.3% |
| องค์กรที่ส่งเอกสารการเงิน/ภาครัฐ | ครบสามตัว + alignment strict | p=reject + BIMI โชว์โลโก้ |
โดเมนอีเมลคือ "ลายเซ็นดิจิทัล" ของแบรนด์คุณ — การไม่ตั้ง SPF, DKIM และ DMARC ก็เหมือนเซ็นเช็คเปล่าทิ้งไว้ให้ใครก็ได้หยิบไปกรอกเอง การลงมือทำใช้เวลาไม่กี่ชั่วโมง แต่ป้องกันความเสียหายต่อความเชื่อมั่นที่ประเมินค่าไม่ได้
- ทีมงาน Saeree ERP
อยากให้อีเมลจากระบบ ERP ส่งถึง inbox ทุกฉบับ?
ปรึกษาผู้เชี่ยวชาญจาก Grand Linux Solution เรื่องการตั้งค่า SPF/DKIM/DMARC ให้โดเมนที่ใช้ส่งเมลจาก Saeree ERP
ขอคำปรึกษาฟรีโทร 02-347-7730 | sale@grandlinux.com
แหล่งอ้างอิง
- RFC 7208 — Sender Policy Framework (SPF): datatracker.ietf.org/doc/html/rfc7208
- RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures: datatracker.ietf.org/doc/html/rfc6376
- RFC 7489 — Domain-based Message Authentication, Reporting & Conformance (DMARC): datatracker.ietf.org/doc/html/rfc7489
- Google — Email sender guidelines (bulk senders, ก.พ. 2567): support.google.com/mail/answer/81126
- Yahoo — Sender Best Practices: senders.yahooinc.com/best-practices
- Microsoft — Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders (พ.ค. 2568): techcommunity.microsoft.com
