ทำไมอีเมลของคุณเข้าถังขยะ — SPF, DKIM, DMARC และทุกอย่างที่ต้องตั้งให้ครบ

ระบบของเราส่งอีเมลออกไปหาลูกค้าทุกวัน — ยืนยันตัวตน กู้รหัสผ่าน แจ้งเตือน ใบกำกับภาษี

อีเมลที่ส่งไม่ถึงไม่ได้แค่ “ไม่สะดวก” แต่แปลว่าลูกค้าสมัครไม่สำเร็จ กู้รหัสไม่ได้ และไม่ได้รับเอกสารทางภาษี โดยที่ไม่มีใครรู้ว่าเกิดอะไรขึ้น เพราะฝั่งเราเห็นว่า “ส่งแล้ว”

บทความนี้รวบรวมทุกอย่างที่ต้องตั้งค่าให้ครบ พร้อมอธิบายจุดที่คนพลาดบ่อยที่สุด

ทำไมเรื่องนี้เปลี่ยนไปตั้งแต่ปี 2024

เมื่อก่อน SPF และ DKIM เป็นเรื่อง “ตั้งไว้ก็ดี” — ไม่ตั้งก็ยังส่งถึงอยู่ แค่มีโอกาสเข้าถังขยะมากขึ้น

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

• ต้องยืนยันตัวตนของผู้ส่งด้วย SPF และ DKIM
• ต้องมี DMARC อย่างน้อยในระดับเฝ้าดู
• ต้องมีวิธียกเลิกรับข่าวสารด้วยคลิกเดียวสำหรับอีเมลเชิงการตลาด
• ต้องคุมอัตราการร้องเรียนว่าเป็นสแปมให้ต่ำกว่าเกณฑ์

ผลคือระบบที่เคยส่งได้ดีมาหลายปี อาจเริ่มถูกปฏิเสธโดยไม่มีอะไรในโค้ดเปลี่ยนเลย

ก่อนอื่น — TXT record คืออะไร

DNS คือสมุดที่อยู่ของอินเทอร์เน็ต ปกติใช้แปลงชื่อโดเมนเป็นหมายเลขเครื่อง แต่มันเก็บข้อความอิสระได้ด้วย ซึ่งเรียกว่า TXT record

SPF, DKIM และ DMARC ทั้งหมดเก็บอยู่ใน TXT record เพราะเป็นวิธีเดียวที่ทำให้ “เจ้าของโดเมน” ประกาศอะไรบางอย่างให้คนทั้งโลกตรวจสอบได้ — และมีแต่เจ้าของโดเมนเท่านั้นที่แก้ได้

ระเบียนที่เกี่ยวข้องกับอีเมลมี 4 ชนิด

ชนิด	ใช้ทำอะไร
TXT	เก็บ SPF · DKIM · DMARC · MTA-STS · BIMI
MX	บอกว่าอีเมลขาเข้าของโดเมนนี้ให้ส่งไปเครื่องไหน
CNAME	ชี้ต่อไปหาระเบียนของผู้ให้บริการ — DKIM มักตั้งแบบนี้เพื่อให้ผู้ให้บริการหมุนกุญแจเองได้
PTR	แปลงหมายเลขเครื่องกลับเป็นชื่อ (reverse DNS) — สำคัญเมื่อส่งจากเครื่องตัวเอง

ข้อควรรู้ที่ทำให้คนงงบ่อย — MX ไม่เกี่ยวกับการส่งออก โดเมนที่ไม่มี MX ก็ยังส่งอีเมลออกได้ แค่รับอีเมลเข้าไม่ได้

SPF — ใครมีสิทธิ์ส่งในนามโดเมนนี้

SPF คือรายชื่อเซิร์ฟเวอร์ที่ได้รับอนุญาตให้ส่งอีเมลในนามโดเมนของคุณ

ตัวอย่างจริงของโดเมนบริษัทเรา

v=spf1 include:_spf.google.com include:sendgrid.net -all

อ่านได้ว่า — อีเมลของโดเมนนี้ส่งผ่าน Google Workspace หรือ SendGrid เท่านั้น นอกนั้นให้ปฏิเสธ

ท้ายบรรทัดสำคัญที่สุด

ลงท้ายด้วย	ความหมาย	ผลจริง
-all	ปฏิเสธเด็ดขาด	ปลายทางทิ้งอีเมลที่ไม่อยู่ในรายการ
~all	น่าสงสัย	ปลายทางมักรับไว้แต่ให้คะแนนลบ
?all	ไม่มีความเห็น	แทบไม่มีประโยชน์
+all	อนุญาตทุกคน	ห้ามใช้เด็ดขาด เท่ากับเปิดให้ใครก็ปลอมเป็นคุณได้

คนส่วนใหญ่เริ่มที่ ~all เพราะกลัวอีเมลของตัวเองหาย ซึ่งถูกต้องในช่วงแรก แต่ถ้าอยู่ที่นั่นถาวรก็เท่ากับไม่ได้ปิดช่องอะไรเลย

กับดักที่เจอบ่อยที่สุดของ SPF

• เพดาน 10 การค้นหา — ทุก include: ต้องไปค้น DNS ต่อ และมาตรฐานกำหนดเพดานไว้ที่ 10 ครั้ง เกินแล้วถือว่าตรวจไม่ผ่านทันที ไม่ใช่แค่ช้าลง · ผู้ให้บริการรายเดียวอาจกินไป 3-4 ครั้ง ใส่หลายเจ้าแล้วทะลุได้ง่ายกว่าที่คิด
• หนึ่งโดเมนมีได้ SPF เดียว — ถ้ามีสอง TXT ที่ขึ้นต้น v=spf1 จะถือว่าผิดพลาดทั้งคู่ · เวลาเพิ่มผู้ส่งใหม่ต้องเติมเข้าไปในบรรทัดเดิม ไม่ใช่เพิ่มบรรทัดใหม่
• SPF พังเมื่อมีการส่งต่ออีเมล — เมื่อผู้รับตั้งส่งต่อไปกล่องอื่น เครื่องที่ส่งต่อไม่ได้อยู่ในรายการของคุณ SPF จึงไม่ผ่าน ซึ่งเป็นเหตุผลที่มี SPF อย่างเดียวไม่พอ

DKIM — ลายเซ็นดิจิทัลของอีเมลแต่ละฉบับ

DKIM แก้จุดอ่อนของ SPF ด้วยวิธีที่ต่างกันโดยสิ้นเชิง — แทนที่จะถามว่า “ส่งมาจากเครื่องที่ได้รับอนุญาตไหม” มันถามว่า “อีเมลฉบับนี้มีลายเซ็นที่ถูกต้องหรือไม่”

ทำงานอย่างไร

1. สร้างคู่กุญแจ — กุญแจลับเก็บไว้ที่ระบบส่งอีเมล กุญแจสาธารณะประกาศไว้ใน DNS
2. ตอนส่ง ระบบเซ็นหัวจดหมายและเนื้อหาด้วยกุญแจลับ แล้วแนบลายเซ็นไปกับอีเมล
3. ปลายทางไปดึงกุญแจสาธารณะจาก DNS มาตรวจลายเซ็น

ข้อดีที่เหนือกว่า SPF คือลายเซ็นติดไปกับตัวอีเมล ส่งต่อกี่ทอดก็ยังตรวจได้ ตราบใดที่เนื้อหาไม่ถูกแก้

Selector — ส่วนที่คนไม่ค่อยเข้าใจ

กุญแจสาธารณะไม่ได้อยู่ที่ชื่อโดเมนตรง ๆ แต่อยู่ใต้ชื่อย่อยที่เรียกว่า selector ในรูป {selector}._domainkey.{โดเมน}

เหตุผลที่ต้องมี selector คือเพื่อให้มีกุญแจได้หลายดอกพร้อมกัน ซึ่งจำเป็นในสองกรณี

• มีผู้ส่งหลายเจ้า — แต่ละเจ้ามีกุญแจของตัวเอง อยู่คนละ selector
• ตอนหมุนกุญแจ — ประกาศกุญแจใหม่ที่ selector ใหม่ก่อน แล้วค่อยสลับ โดยไม่มีช่วงที่อีเมลตรวจไม่ผ่าน

โดเมนบริษัทเราใช้ selector สามตัวพร้อมกัน — หนึ่งตัวสำหรับอีเมลพนักงานที่ส่งผ่าน Google Workspace และอีกสองตัวสำหรับอีเมลอัตโนมัติที่ส่งผ่าน SendGrid

ทำไมมักตั้งเป็น CNAME

ผู้ให้บริการอีเมลส่วนใหญ่ให้คุณตั้ง DKIM เป็น CNAME ชี้ไปที่ระเบียนของเขา แทนที่จะคัดลอกกุญแจมาวางเอง

เหตุผลคือเขาหมุนกุญแจให้เองได้โดยที่คุณไม่ต้องทำอะไร ซึ่งเป็นเรื่องดี เพราะกุญแจที่ไม่เคยหมุนเลยเป็นความเสี่ยงที่สะสมขึ้นทุกปี

ความยาวกุญแจ

ควรใช้ 2048 บิต ซึ่งเป็นค่ามาตรฐานปัจจุบัน ส่วน 1024 บิตยังใช้ได้แต่ถือว่าอ่อนแล้ว

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

DMARC — ชิ้นที่ทำให้สองอย่างข้างบนมีความหมาย

นี่คือส่วนที่สำคัญที่สุดของบทความ และเป็นจุดที่คนเข้าใจผิดมากที่สุด

ปัญหาที่ SPF กับ DKIM แก้ไม่ได้

อีเมลหนึ่งฉบับมี “ผู้ส่ง” มากกว่าหนึ่งที่

• ที่อยู่ในซองจดหมาย — ใช้ตอนส่งจริง ผู้ใช้ไม่เห็น และเป็นตัวที่ SPF ตรวจ
• ช่อง “จาก” ที่ผู้ใช้เห็น — ตัวที่แสดงบนหน้าจอ

สองอย่างนี้ไม่จำเป็นต้องเป็นโดเมนเดียวกัน

ผลคือผู้โจมตีส่งอีเมลจากโดเมนของตัวเอง ตั้ง SPF และ DKIM ของตัวเองให้ถูกต้องทุกอย่าง แล้วใส่ช่อง “จาก” เป็นชื่อธนาคารหรือบริษัทคุณ — อีเมลนั้นจะผ่าน SPF และผ่าน DKIM ทั้งคู่ ทั้งที่เป็นของปลอม

DMARC เพิ่มกฎข้อเดียวที่เปลี่ยนทุกอย่าง

โดเมนที่ผ่าน SPF หรือ DKIM ต้องเป็นโดเมนเดียวกับที่แสดงในช่อง “จาก”

กฎนี้เรียกว่า alignment และมันคือเหตุผลทั้งหมดที่ DMARC มีอยู่ ถ้าเข้าใจข้อนี้ข้อเดียวก็เข้าใจ DMARC แล้ว

DMARC ผ่านเมื่ออย่างน้อยหนึ่งอย่างผ่านแบบตรงโดเมน — ไม่จำเป็นต้องผ่านทั้งคู่ ซึ่งเป็นเหตุผลที่ควรตั้งทั้ง SPF และ DKIM เพราะเมื่ออีเมลถูกส่งต่อและ SPF พัง DKIM ยังพยุงไว้ได้

อ่านระเบียน DMARC

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

ส่วน	หมายถึง
p=	ให้ปลายทางทำอย่างไรกับอีเมลที่ไม่ผ่าน
rua=	ส่งรายงานสรุปรายวันมาที่ไหน
fo=1	ส่งรายงานเมื่อมีอย่างใดอย่างหนึ่งไม่ผ่าน
sp=	นโยบายสำหรับโดเมนย่อย — ถ้าไม่ระบุจะใช้ตาม p=
pct=	ให้บังคับใช้กับอีเมลกี่เปอร์เซ็นต์ — ใช้ตอนทยอยเพิ่มความเข้ม

สามระดับของนโยบาย

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

กับดักที่สำคัญที่สุดของ DMARC

คนจำนวนมากตั้ง p=none แล้วคิดว่า “มี DMARC แล้ว ปลอดภัยแล้ว”

ไม่ใช่ — p=none แปลว่า “เห็นแล้วแต่อย่าทำอะไร” มันมีประโยชน์มากในฐานะเครื่องมือเก็บข้อมูล แต่ไม่ได้กันการปลอมแม้แต่ฉบับเดียว

เราเองก็อยู่ที่ p=none ณ ตอนที่เขียนบทความนี้ และรู้ดีว่านั่นแปลว่ายังไม่จบ

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

ทางออกคืออ่านรายงานให้ครบก่อนขยับ ไม่ใช่ไม่ขยับ

รายงาน DMARC — ของฟรีที่มีค่าที่สุด

เมื่อใส่ rua= แล้ว ปลายทางทั่วโลกจะส่งรายงานสรุปรายวันกลับมาให้ บอกว่ามีใครส่งอีเมลในนามโดเมนคุณบ้าง จากที่ไหน และผ่านหรือไม่ผ่าน

สิ่งที่มักเจอในรายงานเดือนแรก

• ผู้ส่งที่ลืมไปแล้ว — เครื่องมือที่ฝ่ายการตลาดสมัครไว้เมื่อสามปีก่อนและยังส่งอยู่
• เครื่องเก่าในออฟฟิศ — เครื่องพิมพ์หรือระบบสำรองข้อมูลที่ส่งอีเมลแจ้งเตือน
• คนปลอมเป็นคุณจริง ๆ — ซึ่งเป็นเหตุผลที่ต้องขยับไประดับที่บังคับใช้

รายงานเป็นไฟล์ XML ที่อ่านด้วยตาลำบาก จึงควรใช้บริการที่แปลงเป็นรายงานอ่านง่าย ซึ่งมีทั้งแบบฟรีและเสียเงิน

ข้อควรระวัง — อย่าใส่อีเมลของคนคนเดียวใน rua เพราะจะได้ไฟล์ XML วันละหลายสิบฉบับ แล้วสุดท้ายจะไม่มีใครเปิดอ่าน

ส่วนที่เหลือที่ต้องตั้งให้ครบ

Reverse DNS

ถ้าส่งอีเมลจากเครื่องของตัวเอง หมายเลขเครื่องต้องแปลงกลับเป็นชื่อได้ และชื่อนั้นต้องแปลงกลับมาเป็นหมายเลขเดิมได้ด้วย

ปลายทางหลายเจ้าปฏิเสธอีเมลจากเครื่องที่ไม่มี reverse DNS ตั้งแต่ก่อนดูเนื้อหาเลย และตั้งได้เฉพาะผู้ให้บริการเครื่อง ไม่ใช่ที่ระบบจัดการ DNS ของโดเมน

ถ้าส่งผ่านผู้ให้บริการอีเมล เรื่องนี้เขาจัดการให้แล้ว

ปุ่มยกเลิกรับข่าวสารแบบคลิกเดียว

สำหรับอีเมลเชิงการตลาด ปัจจุบันเป็นเงื่อนไขบังคับของผู้ให้บริการรายใหญ่ ไม่ใช่ทางเลือก

ต้องเป็นการยกเลิกที่ทำงานจริงภายในสองวัน ไม่ใช่ลิงก์ที่พาไปหน้าให้ล็อกอินก่อน

เหตุผลเชิงปฏิบัติคือ ถ้ายกเลิกยาก คนจะกด “นี่คือสแปม” แทน ซึ่งทำลายชื่อเสียงของโดเมนคุณหนักกว่ามาก

MTA-STS และ TLS-RPT

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

ไม่ใช่เงื่อนไขบังคับ แต่เป็นสิ่งที่ควรมีเมื่อระบบโตขึ้น โดยเฉพาะเมื่อรับส่งข้อมูลที่มีข้อมูลส่วนบุคคล

BIMI

ทำให้โลโก้ของคุณแสดงข้างชื่อผู้ส่งในกล่องจดหมาย

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

ลำดับที่ควรทำ

1. รวบรวมว่ามีใครส่งอีเมลในนามโดเมนเราบ้าง — ทั้งระบบหลัก เครื่องมือการตลาด ระบบบัญชี และของที่ฝ่ายอื่นสมัครไว้เอง ขั้นนี้ใช้เวลานานที่สุดและข้ามไม่ได้
2. ตั้ง SPF ให้ครบทุกเจ้า เริ่มที่ ~all ก่อน
3. ตั้ง DKIM ให้ทุกเจ้าที่รองรับ — ทีละเจ้า ตรวจทีละเจ้า
4. ตั้ง DMARC ที่ p=none พร้อม rua แล้วรออ่านรายงานอย่างน้อย 2-4 สัปดาห์
5. ไล่แก้จนอีเมลที่ถูกต้องผ่านครบ ทุกเจ้า
6. ขยับเป็น p=quarantine — จะใช้ pct= ทยอยก็ได้
7. ขยับเป็น p=reject และเปลี่ยน SPF เป็น -all

ข้อ 4 คือข้อที่คนข้าม และเป็นข้อที่ทำให้ขั้นตอนหลังจากนั้นปลอดภัย

อย่าลืมโดเมนที่ไม่ได้ส่งอีเมล

โดเมนที่จอดไว้เฉย ๆ หรือใช้แค่ทำเว็บถูกปลอมได้ง่ายที่สุด เพราะไม่มีใครดูแล

โดเมนกลุ่มนี้ควรประกาศให้ชัดว่าไม่มีใครส่งอีเมลจากที่นี่ — SPF ที่ไม่อนุญาตใครเลย และ DMARC ที่ปฏิเสธทันที ซึ่งตั้งครั้งเดียวจบและไม่มีอะไรต้องดูแลต่อ

สิ่งที่เราเจอกับระบบของเราเอง

ระหว่างจัดระเบียบเรื่องอีเมลของเรา มีสองเรื่องที่คุ้มกับการเล่า

กุญแจของผู้ให้บริการกระจายอยู่ 3 ที่

ตอนที่ระบบโตขึ้น การตั้งค่าอีเมลถูกเพิ่มทีละจุดตามงานที่ต้องใช้ — จุดหนึ่งสำหรับรหัสยืนยัน อีกจุดสำหรับคำเชิญ อีกจุดสำหรับการแจ้งเตือน

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

เรารวมเป็นหนึ่งเครื่องหนึ่งกุญแจ ตั้งค่าจากหน้าจอเดียว แล้วส่งค่าให้ทุกบริการตอนเริ่มทำงาน พร้อมปุ่มทดสอบส่ง

อีเมลที่ส่งแบบไม่เข้ารหัสจากอีเมลส่วนตัว

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

เรื่องนี้แย่สองชั้น — ชั้นความปลอดภัยชัดเจนอยู่แล้ว แต่ชั้นที่เกี่ยวกับบทความนี้คืออีเมลที่ส่งจากนอกช่องทางที่ประกาศไว้จะไม่ผ่าน SPF และ DMARC เสมอ จึงมีโอกาสสูงที่จะไม่ถึงปลายทาง แล้วไม่มีใครรู้

เราลบทิ้งทั้งหมด เพราะการแจ้งเตือนเหล่านั้นซ้ำซ้อนกับระบบเฝ้าระวังที่มีอยู่แล้ว

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

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

ข้อผิดพลาด	ผลที่เกิด
มี SPF สองบรรทัด	ผิดพลาดทั้งคู่ ไม่ใช่ใช้อันใดอันหนึ่ง
เกินเพดาน 10 การค้นหา	ตรวจไม่ผ่านทันที ทั้งที่รายชื่อถูกต้อง
ตั้ง DMARC แต่ไม่ตั้ง DKIM	พังทันทีที่มีการส่งต่ออีเมล
ค้างอยู่ที่ p=none ตลอดไป	เห็นปัญหาแต่ไม่ได้กันอะไรเลย
คัดลอกกุญแจ DKIM แล้วแบ่งบรรทัดผิด	ตรวจไม่ผ่านแบบเงียบ ไม่มีข้อความบอก
ลืมโดเมนย่อย	ผู้โจมตีใช้โดเมนย่อยแทน — ปิดด้วย sp=
ส่ง rua เข้าอีเมลคนเดียว	ไม่มีใครอ่าน เท่ากับไม่ได้ตั้ง
เปลี่ยนผู้ให้บริการแล้วลืมแก้ DNS	อีเมลหายทันทีโดยไม่มีสัญญาณเตือน

สรุป

1. SPF บอกว่าใครส่งได้ · DKIM พิสูจน์ว่าไม่ถูกแก้ · DMARC บังคับว่าทั้งสองอย่างต้องตรงกับชื่อที่ผู้ใช้เห็น
2. ต้องมีทั้ง SPF และ DKIM เพราะ SPF พังเมื่ออีเมลถูกส่งต่อ
3. DMARC ที่ p=none ยังไม่กันอะไร — มันคือขั้นเก็บข้อมูล ไม่ใช่ปลายทาง
4. อ่านรายงานก่อนขยับความเข้ม เพราะสิ่งที่ทำให้พังคือผู้ส่งที่นึกไม่ถึง
5. โดเมนที่ไม่ได้ส่งอีเมลก็ต้องประกาศ ว่าไม่มีใครส่ง ไม่งั้นมันคือโดเมนที่ปลอมง่ายที่สุดของคุณ

เรื่องนี้ไม่มีอะไรซับซ้อนในทางเทคนิค แต่ต้องทำให้ครบและทำตามลำดับ — และผลของการทำไม่ครบคืออีเมลที่ระบบบอกว่า “ส่งแล้ว” แต่ไม่มีใครได้รับ ซึ่งเป็นความล้มเหลวชนิดที่เงียบที่สุดแบบหนึ่ง