SPF DKIM DMARC คืออะไร: ตั้งค่าอย่างไรให้อีเมลจากระบบองค์กรไม่ตกไปอยู่ใน spam

เช้าวันจันทร์ ฝ่ายบริการลูกค้าส่งข้อความมาในกลุ่มว่าผู้ใช้หลายคนโทรมาบอกว่า OTP ไม่เข้าอีเมล ทีม IT เปิด log ของระบบแล้วพบว่าอีเมลทุกฉบับถูกส่งออกไปครบ ไม่มี error สักบรรทัด ปัญหาจริงอยู่ที่ปลายทาง อีเมลถึงผู้รับแล้ว แต่ถูกคัดไปไว้ในโฟลเดอร์ spam ที่ไม่มีใครเปิดดู

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

บทความนี้เขียนให้คนที่ดูแลระบบซึ่งส่งอีเมลในนามองค์กร ทั้ง OTP ใบแจ้งหนี้ และการแจ้งเตือน เราจะเล่าว่าทำไมเรื่องนี้เปลี่ยนจากแนวปฏิบัติที่ดีมาเป็นเงื่อนไขของผู้ให้บริการอีเมลรายใหญ่ จุดที่องค์กรมักพลาดเพราะมีผู้ส่งมากกว่าที่คิด และวิธีขยับนโยบาย DMARC โดยไม่ทำให้อีเมลจริงหายไปกลางทาง บทความไม่ได้สอนตั้งค่า DNS ทีละขั้น เพราะขั้นตอนต่างกันตามผู้ให้บริการ แต่จะช่วยให้คุณรู้ว่าต้องตัดสินใจอะไรก่อนลงมือ

SPF DKIM DMARC คืออะไร และทำงานต่อกันอย่างไร

SPF ถูกนิยามไว้ใน RFC 7208 เจ้าของโดเมนประกาศรายชื่อ server หรือบริการที่มีสิทธิ์ส่งอีเมลไว้ใน DNS ผู้รับจะเทียบว่าอีเมลที่เข้ามาถูกส่งจากที่อยู่ในรายการหรือไม่ ข้อจำกัดสำคัญที่มักถูกลืมคือ RFC 7208 กำหนดให้การตรวจ SPF ใช้ term ที่ต้องค้น DNS ได้ไม่เกิน 10 ตัว ถ้าเกิน ผลจะออกมาเป็น permerror ทันที แม้ server ที่ส่งจะอยู่ในรายการก็ตาม

DKIM ถูกนิยามไว้ใน RFC 6376 ระบบที่ส่งอีเมลจะลงลายเซ็นด้วย private key และประกาศ public key ไว้ใน DNS ผู้รับใช้ public key ตรวจว่าลายเซ็นถูกต้อง ข้อดีของ DKIM คือลายเซ็นติดไปกับตัวข้อความ จึงยังตรวจได้แม้อีเมลถูกส่งต่อผ่าน server อื่น ซึ่ง SPF ทำแบบนั้นไม่ได้

DMARC ต่อยอดจากสองอย่างแรก มันตรวจว่าโดเมนที่ผ่าน SPF หรือ DKIM ตรงกับโดเมนที่ผู้ใช้เห็นในช่อง From หรือไม่ เรียกว่า alignment แล้วใช้นโยบายที่เจ้าของโดเมนประกาศไว้ ซึ่งมีสามระดับคือ none ไม่ขอให้ทำอะไร quarantine ขอให้คัดเป็น spam และ reject ขอให้ปฏิเสธ DMARC ยังให้ผู้รับส่งรายงานสรุปกลับมาว่ามีอีเมลที่อ้างชื่อโดเมนคุณผ่านหรือไม่ผ่านจากที่ไหนบ้าง

เรื่องที่ควรรู้คือ DMARC เพิ่งได้มาตรฐานฉบับใหม่ RFC 9989 ออกเมื่อเดือนพฤษภาคม 2026 ในสถานะ Standards Track และแทนที่ RFC 7489 ที่ใช้กันมาตั้งแต่ปี 2015 (อ้างอิง: RFC 9989) record ที่ตั้งไว้เดิมยังใช้ได้ แต่บางแท็กเปลี่ยนสถานะ ซึ่งเราจะพูดถึงในหัวข้อการไล่นโยบาย

ทำไมเรื่องนี้กลายเป็นเงื่อนไขของผู้ให้บริการอีเมล

หลายปีที่ผ่านมา SPF DKIM และ DMARC ถูกมองเป็นงานที่ดีถ้ามีเวลาทำ สถานะนั้นเปลี่ยนไปเมื่อผู้ให้บริการอีเมลรายใหญ่เริ่มเขียนเป็นเงื่อนไขการรับอีเมล

เอกสาร Google Workspace ระบุว่าผู้ส่งทุกรายที่ส่งถึงบัญชี Gmail ส่วนตัวต้องตั้ง SPF หรือ DKIM อย่างน้อยหนึ่งอย่าง และผู้ส่งที่ส่งเกิน 5,000 ฉบับต่อวันต้องตั้งทั้ง SPF DKIM และ DMARC (อ้างอิง: Google Workspace, Set up DKIM อัปเดต 20 ต.ค. 2026) เอกสาร Email sender guidelines ของ Google ระบุว่าเกณฑ์นี้เริ่มใช้ 1 กุมภาพันธ์ 2024 ให้รักษา spam rate ที่วัดใน Postmaster Tools ไว้ต่ำกว่า 0.3% และหน้า FAQ ของเอกสารเดียวกันระบุว่าตั้งแต่พฤศจิกายน 2025 Gmail เพิ่มความเข้มในการบังคับใช้กับอีเมลที่ไม่ผ่านเกณฑ์ ซึ่งอาจถูกปฏิเสธหรือถูกส่งเข้า spam

Yahoo ใช้เกณฑ์ในทิศทางเดียวกันตั้งแต่กุมภาพันธ์ 2024 ผู้ส่งทุกรายต้องมี SPF หรือ DKIM และรักษา spam rate ไว้ต่ำกว่า 0.3% ส่วนผู้ส่งปริมาณมากต้องมีทั้ง SPF และ DKIM มี DMARC อย่างน้อย p=none ที่ผ่านการตรวจ และรองรับการยกเลิกรับอีเมลด้วยคลิกเดียวสำหรับอีเมลการตลาด (อ้างอิง: Yahoo Sender Best Practices)

Microsoft ประกาศใน blog ของทีม Defender for Office 365 เมื่อ 2 เมษายน 2025 ว่าโดเมนที่ส่งถึง Outlook.com Hotmail และ Live เกิน 5,000 ฉบับต่อวัน ต้องผ่าน SPF และ DKIM และมี DMARC อย่างน้อย p=none ที่ align กับ SPF หรือ DKIM ข้อความที่อัปเดตเมื่อ 29 เมษายน 2025 ระบุว่าอีเมลที่ไม่ผ่านจะถูกปฏิเสธด้วยรหัส 550 5.7.515 ตั้งแต่ 5 พฤษภาคม 2025

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

ระบบขององค์กรอาจไม่ถึงเกณฑ์ 5,000 ฉบับต่อวัน แต่ผู้ใช้ส่วนใหญ่ใช้ Gmail หรือ Outlook อยู่แล้ว เกณฑ์ขั้นพื้นฐานสำหรับผู้ส่งทุกรายจึงมีผลกับ OTP ของคุณเช่นกัน

อีเมลของระบบไม่ได้ส่งจากที่เดียว

จุดที่ทำให้การตั้งค่าพังบ่อยที่สุด ไม่ได้อยู่ที่ความยากของ record แต่อยู่ที่องค์กรไม่รู้ว่ามีอะไรส่งอีเมลในนามโดเมนตัวเองบ้าง RFC 9989 เขียนไว้ตรง ๆ ว่าในการติดตั้งแทบทุกแบบ เจ้าของโดเมนอาจมองข้าม server สักตัว หรือไม่รู้ว่ามีข้อตกลงให้บุคคลภายนอกส่งอีเมลแทนอยู่

ในองค์กรขนาดกลางขึ้นไป รายการผู้ส่งมักยาวกว่าที่ทีม IT คาด อีเมลพนักงานอยู่บน Microsoft 365 หรือ Google Workspace ระบบหลักส่ง OTP ผ่าน SMTP relay หรือบริการส่งอีเมลบน cloud ระบบ CRM ส่งใบเสนอราคา ระบบ HR ส่งสลิปเงินเดือน ระบบ ticket ส่งการแจ้งเตือน และทีมการตลาดใช้เครื่องมือส่งจดหมายข่าวอีกตัว แต่ละตัวต้องอยู่ใน SPF หรือลงลายเซ็น DKIM ด้วยโดเมนที่ align กับโดเมนผู้ส่ง ไม่อย่างนั้น DMARC จะไม่ผ่าน

รูปแบบที่เจอบ่อยมีสามแบบ แบบแรกคือระบบใหม่ที่ vendor ติดตั้งให้ ส่งอีเมลในนามโดเมนองค์กรได้ตั้งแต่วันแรก แต่ไม่มีใครเพิ่มมันลงใน SPF แบบที่สองคือ SPF ที่ include บริการหลายเจ้าจนเกินขีดจำกัด 10 lookup ทำให้ผลตรวจล้มทั้ง record แบบที่สามคือบริการภายนอกลงลายเซ็น DKIM ด้วยโดเมนของบริการเอง ซึ่ง DKIM ผ่าน แต่ DMARC ไม่ผ่านเพราะโดเมนไม่ตรงกับช่อง From

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

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

ควรแยกโดเมนหรือ subdomain สำหรับอีเมลระบบไหม

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

ความเห็นของเราคือ ถ้าองค์กรส่งอีเมลการตลาดในปริมาณมาก การแยก subdomain สำหรับอีเมลแต่ละประเภทคุ้มค่า เช่น ใช้ subdomain หนึ่งสำหรับอีเมลธุรกรรมอย่าง OTP และใบแจ้งหนี้ อีก subdomain สำหรับจดหมายข่าว และเก็บโดเมนหลักไว้ให้พนักงาน การแยกแบบนี้ทำให้ปัญหาของช่องทางหนึ่งไม่กระทบอีกช่องทาง และทำให้อ่านรายงาน DMARC แยกตามประเภทได้ง่ายขึ้น

ถ้าองค์กรส่งแค่อีเมลพนักงานกับ OTP ปริมาณไม่มาก และไม่ได้ส่งอีเมลการตลาดเลย การแยกโดเมนอาจไม่จำเป็น สิ่งที่สำคัญกว่าในกรณีนั้นคือทำให้ทุกช่องทางผ่าน SPF DKIM และ DMARC ให้ครบก่อน

ไล่ DMARC จาก none ไป quarantine ไป reject ทีละขั้น

RFC 9989 แนะนำให้เจ้าของโดเมนเริ่มที่ p=none พร้อมตั้งที่รับรายงาน และเรียกสถานะนี้ว่า Monitoring Mode เหตุผลคือเพื่อให้แน่ใจว่าไม่มีช่องทางไหนตกหล่นจากการตั้ง SPF และ DKIM รอบแรก รายงานจะบอกว่ามีอีเมลที่อ้างชื่อโดเมนคุณถูกส่งจากที่ไหนบ้าง ทั้งช่องทางจริงที่ยังตั้งค่าไม่ครบ และผู้ที่ปลอมชื่อโดเมน

รายงานเหล่านี้มาในรูปแบบที่ออกแบบให้เครื่องอ่าน RFC 9989 เองแนะนำให้ใช้เครื่องมือแปลผล ไม่ว่าจะเป็นบริการภายนอกหรือเครื่องมือที่องค์กรทำเอง การตั้งที่รับรายงานโดยไม่มีใครอ่าน เท่ากับตั้ง DMARC ไว้เฉย ๆ ต้องมีคนที่มีชื่อรับผิดชอบการอ่านรายงานและไล่แก้ช่องทางที่ไม่ผ่าน

เรื่องระยะเวลา แหล่งหลักสองแหล่งแนะนำไม่เหมือนกัน เอกสาร Google Workspace ฉบับภาษาไทยแนะนำให้ตั้ง SPF และ DKIM อย่างน้อย 48 ชั่วโมงก่อนตั้ง DMARC อยู่ที่ p=none 1 สัปดาห์ แล้วค่อยเปลี่ยนเป็น quarantine โดยใช้แท็ก pct เริ่มจากสัดส่วนเล็ก ๆ แล้วค่อยเพิ่ม (อ้างอิง: Google Workspace, การเปิดตัว DMARC ที่แนะนำ อัปเดต 15 ต.ค. 2026) ส่วน RFC 9989 ระบุว่าขึ้นกับรอบการส่งอีเมลขององค์กร อาจต้องอ่านรายงานหลายเดือนกว่าจะมั่นใจว่าทุกช่องทางผ่านแล้ว และย้ายแท็ก pct ไปเป็นสถานะ historic โดยมีแท็ก t สำหรับโหมดทดสอบมาแทน

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

ข้อควรระวังเมื่อถึงขั้น reject คืออีเมลจริงบางประเภทอาจไม่ผ่าน DMARC แม้ตั้งค่าถูก เช่น อีเมลที่ผ่าน mailing list ซึ่งแก้ข้อความระหว่างทาง RFC 9989 จึงขอให้ฝั่งผู้รับไม่ปฏิเสธอีเมลเพียงเพราะนโยบายเป็น reject แต่เจ้าของโดเมนไม่ควรพึ่งข้อนี้ การขยับไป reject ควรเกิดหลังจากรายงานแสดงว่าช่องทางจริงทั้งหมดผ่านแล้วเท่านั้น

ใครถือ DNS และโดเมนขององค์กร

ทุกขั้นที่พูดมาต้องแก้ DNS ถ้าบัญชีที่จัดการ DNS อยู่ในมือ vendor หรือผู้ให้บริการ hosting เดิม ทุกครั้งที่จะเพิ่มบริการส่งอีเมลหรือขยับนโยบาย DMARC องค์กรต้องรอให้คนนอกทำให้ ปัญหานี้มักโผล่ตอนที่ OTP ไม่เข้าและต้องแก้ให้เสร็จภายในวันนั้น

เราเล่าไว้ในบทความ เขียน TOR ระบบอย่างไรให้ได้ระบบที่ดูแลต่อได้ ว่าชื่อโดเมนต้องอยู่ในนามองค์กรตั้งแต่วันแรก หลักเดียวกันใช้กับบัญชี DNS ด้วย องค์กรควรเป็นเจ้าของบัญชี และให้ผู้ดูแลภายนอกเข้าไปทำงานในฐานะผู้ใช้ที่องค์กรเพิ่มสิทธิ์ให้ เรื่องการจัดการสิทธิ์เมื่อทีมเปลี่ยนมือ อยู่ในบทความ ใครถือกุญแจบัญชี Cloud ขององค์กรอยู่จริง

อีกเรื่องที่ควรกำหนดคือขั้นตอนอนุมัติการแก้ DNS โดยเฉพาะ SPF กับ DMARC เพราะ record เดียวที่เขียนผิดอาจทำให้อีเมลของทั้งองค์กรไม่ผ่าน ใครขอแก้ได้ ใครอนุมัติ และใครตรวจผลหลังแก้ ควรมีคำตอบที่เขียนไว้ ไม่ใช่ปล่อยให้ใครก็ได้ที่มีรหัสผ่านเข้าไปแก้

วัดว่าอีเมลถึง inbox จริง

หลังตั้งค่าเสร็จ ต้องมีวิธีรู้ว่ามันยังใช้ได้อยู่ แหล่งข้อมูลหลักมีสองแหล่ง แหล่งแรกคือรายงาน DMARC ซึ่งบอกสัดส่วนอีเมลที่ผ่านและไม่ผ่านแยกตามที่มา แหล่งที่สองคือ Google Postmaster Tools ซึ่งแสดง spam rate ชื่อเสียงของโดเมน ผลการพิสูจน์ตัวตน และ error ในการส่ง สำหรับอีเมลที่ส่งถึงผู้ใช้ Gmail ข้อจำกัดคือถ้าองค์กรส่งอีเมลต่อวันน้อย Postmaster Tools อาจไม่แสดงข้อมูล

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

อีกวิธีที่ใช้ได้ทันทีคือเปิดหัวอีเมลของ OTP ที่ส่งถึงบัญชี Gmail หรือ Outlook ทดสอบ แล้วดูผล SPF DKIM และ DMARC ที่ผู้รับบันทึกไว้ ทำซ้ำทุกครั้งที่เพิ่มบริการส่งอีเมลใหม่

ข้อจำกัดที่ต้องพูดตรง ๆ

ตั้ง SPF DKIM และ DMARC ครบแล้ว ไม่ได้แปลว่าอีเมลจะเข้า inbox ทุกฉบับ ผู้ให้บริการยังดูเนื้อหา ชื่อเสียงของโดเมน และจำนวนคนที่กดรายงาน spam ด้วย RFC 9989 เองระบุว่าการผ่าน DMARC บอกแค่ว่าการใช้โดเมนนั้นได้รับอนุญาต ไม่ได้รับรองคุณภาพของข้อความ

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

ถ้าองค์กรของคุณส่งแค่อีเมลพนักงานผ่าน Workspace หรือ Microsoft 365 และไม่มีระบบอื่นส่งอีเมลในนามโดเมนเลย งานส่วนใหญ่ในบทความนี้แทบไม่มีอะไรต้องทำ นอกจากเปิด DKIM ในระบบอีเมลที่ใช้อยู่และตั้ง DMARC แบบ p=none ไว้อ่านรายงาน การไล่ไปจนถึง reject ในกรณีนั้นทำได้เร็ว เพราะมีช่องทางให้ตรวจไม่กี่ช่อง

จะเริ่มตรงไหน

เริ่มจากทำรายการระบบที่ส่งอีเมลในนามโดเมนองค์กร พร้อมชื่อเจ้าของแต่ละระบบ จากนั้นตรวจว่าแต่ละช่องทางผ่าน SPF หรือ DKIM ด้วยโดเมนที่ align แล้วตั้ง DMARC แบบ p=none พร้อมที่รับรายงาน และกำหนดคนอ่านรายงาน เมื่อรายงานแสดงว่าช่องทางจริงผ่านครบแล้ว ค่อยขยับนโยบายทีละขั้น

ถ้าวันนี้ OTP ของคุณยังเข้า spam อยู่ ให้เริ่มจากเปิดหัวอีเมลฉบับนั้น ผลการตรวจในนั้นมักบอกได้เลยว่าขาดอะไร

สรุป

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

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

หากต้องการคุยรายละเอียดของโครงการ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ สำหรับองค์กรที่กำลังทบทวนการส่งอีเมลจากระบบ เรายินดีนัดคุยเพื่อทำความเข้าใจโจทย์ก่อน และหากคุยแล้วพบว่าสิ่งที่มีอยู่เพียงพอแล้ว เราจะบอกตรง ๆ