SPF, DKIM และ DMARC: หยุดคนปลอม Email ด้วย Domain ของคุณ

โทรศัพท์ที่ไม่มีใครอยากรับ

ลูกค้าโทรมาถามว่า "เราโอนเงินเข้าบัญชีใหม่ตาม Email ของคุณแล้ว ทำไมยังทวงอีก" Email ฉบับนั้นแสดงว่ามาจาก [email protected] มีโลโก้ มีลายเซ็น แต่คุณไม่เคยส่ง การปลอม Email แบบนี้ (Business Email Compromise) เกิดได้ง่าย เพราะโปรโตคอล Email (SMTP) ถูกออกแบบมาโดยไม่ตรวจผู้ส่ง ใครก็ส่ง Email ที่แสดง Domain ของคุณในช่อง From ได้ ถ้า Domain ไม่ได้บอกโลกเป็นอย่างอื่น SPF, DKIM และ DMARC คือวิธีบอก

เหตุผลที่สองคือการส่ง Email ให้ถึง Inbox ตั้งแต่ปี 2024 Gmail และ Yahoo กำหนดให้ผู้ส่งปริมาณมาก (เกิน 5,000 ฉบับต่อวัน) ต้องมีครบทั้งสาม และผู้ส่งทุกรายต้องมีอย่างน้อย SPF หรือ DKIM Microsoft ใช้ข้อกำหนดคล้ายกันกับ Outlook.com ตั้งแต่เดือนพฤษภาคม 2025 และตั้งแต่ปลายปี 2025 Gmail ปฏิเสธ Email ที่ไม่ผ่านข้อกำหนดจริงจัง แทนที่จะแค่เตือน แม้บริษัทของคุณจะส่งน้อยกว่านั้นมาก Domain ที่ไม่มี Record เหล่านี้ก็มีแนวโน้มเข้า Spam มากขึ้น

สาม Record ในหนึ่งประโยค

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

ก่อนเริ่ม: ใครถือ DNS ของคุณ

ในลาว ปัญหาแรกที่เราเจอมักไม่ใช่เรื่องเทคนิค แต่คือไม่มีใครรู้ว่า DNS ของ Domain .la หรือ .com อยู่ที่ไหน และรหัสเข้าใช้อยู่กับใคร หลายครั้งอยู่กับบริษัททำเว็บที่จ้างไว้เมื่อหลายปีก่อน หาให้เจอว่า DNS อยู่กับผู้ให้บริการรายไหน โอนบัญชีมาเป็นชื่อบริษัท และเปิด MFA คนที่แก้ DNS ได้คือคนที่ควบคุม Email ทั้งหมดของคุณ

SPF

TXT Record ที่ Domain หลัก (yourcompany.la) สำหรับ Microsoft 365

v=spf1 include:spf.protection.outlook.com -all

สำหรับ Google Workspace ใช้ include:_spf.google.com แทน ถ้ามีระบบอื่นที่ส่ง Email ในนาม Domain (ERP ระบบ Newsletter เว็บไซต์ เครื่องสแกนที่ส่งผ่าน SMTP ของ ISP) ต้องเพิ่มให้ครบทุกตัว

สองกฎที่ทำให้ SPF พังบ่อยที่สุด

• มีได้ SPF Record เดียว ต่อ Domain ถ้ามีสองรายการ SPF จะล้มเหลวทั้งหมด (PermError) เราเจอบ่อยเมื่อผู้ให้บริการเว็บเพิ่ม Record ของตัวเองโดยไม่รวมกับของเดิม
• ไม่เกิน 10 DNS Lookup ทุก include, a, mx นับหมด รวมถึง include ที่ซ้อนอยู่ข้างใน include เดียวอาจกินหลาย Lookup ให้ตรวจด้วยเครื่องมือตรวจ SPF ทุกครั้งที่แก้

-all (Hard Fail) หรือ ~all (Soft Fail)? เมื่อ DMARC อยู่ในระดับ Enforcement แล้ว ผลสุดท้ายมาจาก DMARC หลายคนจึงใช้ ~all เพื่อไม่ให้ Server บางแห่งปฏิเสธ Email ที่ถูก Forward ก่อนจะตรวจ DKIM ทั้งสองแบบรับได้ สิ่งสำคัญคือรายการ Server ต้องครบ

DKIM

Server ผู้ส่งลงลายเซ็น Email ด้วย Private Key ส่วน Public Key อยู่ใน DNS ที่ <selector>._domainkey.yourcompany.la DKIM รอดจากการ Forward ได้ดีกว่า SPF เพราะลายเซ็นติดไปกับข้อความ

• Microsoft 365: เปิดใน Defender Portal (Email authentication settings) แล้วเพิ่ม CNAME สองรายการ selector1._domainkey และ selector2._domainkey ตามค่าที่ Portal แสดง คัดลอกค่าจาก Portal เสมอ อย่าพิมพ์เอง
• Google Workspace: สร้าง Key 2048-bit ใน Admin Console เพิ่ม TXT Record ที่ google._domainkey แล้วกด Start Authentication
• ระบบอื่น (Newsletter, CRM) ส่วนใหญ่มี DKIM ของตัวเอง เปิดให้ครบ และให้เซ็นด้วย Domain ของคุณ ไม่ใช่ Domain ของผู้ให้บริการ

หมายเหตุ: ผู้ให้บริการ DNS บางรายจำกัดความยาว TXT Record ไว้ 255 ตัวอักษรต่อ String Key 2048-bit ยาวกว่านั้นและต้องแบ่งเป็นหลาย String ถ้า DKIM ไม่ผ่านหลังเพิ่ม Record ให้เช็กจุดนี้ก่อน

DMARC

TXT Record ที่ _dmarc.yourcompany.la เริ่มด้วย

v=DMARC1; p=none; rua=mailto:[email protected]

เมื่อพร้อมจะเป็น

v=DMARC1; p=reject; rua=mailto:[email protected]

Email ผ่าน DMARC เมื่อ SPF หรือ DKIM ผ่าน และ Domain ที่ผ่านนั้น ตรงกัน (Align) กับ Domain ในช่อง From ที่ผู้ใช้เห็น นี่คือเหตุผลที่ระบบ Newsletter ที่ส่งผ่าน Domain ของผู้ให้บริการเองจะไม่ผ่าน DMARC จนกว่าคุณจะตั้ง DKIM ด้วย Domain ของคุณ

Report rua มาเป็นไฟล์ XML ที่อ่านยาก ใช้เครื่องมือวิเคราะห์ DMARC (มีทั้งฟรีและเสียเงิน) เพื่อดูว่า IP ไหนส่งในนามคุณ และผ่านหรือไม่ผ่าน ถ้าส่ง Report ไปอีก Domain หนึ่ง (เช่น ของผู้ให้บริการวิเคราะห์) Domain นั้นต้องมี Record อนุญาตให้รับ Report แทนคุณ บริการที่ดีจะตั้งให้เอง

การเปลี่ยนแปลงในมาตรฐานปี 2026

เดือนพฤษภาคม 2026 IETF เผยแพร่มาตรฐาน DMARC ฉบับปรับปรุง (DMARCbis, RFC 9989) สิ่งที่กระทบงานประจำวันคือ

• Tag pct ถูกยกเลิก เพราะผู้รับแต่ละรายทำไม่เหมือนกัน แทนด้วย t=y (โหมดทดสอบ: อย่าบังคับใช้ Policy) การค่อย ๆ เพิ่ม pct=25, pct=50 จึงไม่ใช่วิธีที่แนะนำอีกต่อไป
• มี Tag np สำหรับ Subdomain ที่ไม่มีอยู่จริง ซึ่งคนปลอมชอบใช้ เช่น billing.yourcompany.la
• Record เดิมยังใช้ได้ Tag ที่ยกเลิกจะถูกข้ามไป ไม่ทำให้ Record พัง

ตัวอย่าง: บริษัท 60 คนที่มี 4 ระบบส่ง Email

SPF สุดท้ายมี include แค่ตัวเดียว Newsletter ผ่าน DMARC ด้วย DKIM และชื่อเสียงของ Domain หลักไม่ขึ้นกับแคมเปญการตลาด การแยก Newsletter ไปไว้ที่ Subdomain เป็นสิ่งที่เราแนะนำแทบทุกครั้ง ถ้าแคมเปญหนึ่งโดนกด Spam เยอะ Email ใบแจ้งหนี้ก็ยังส่งถึง

แผน 6–8 สัปดาห์

สัปดาห์ที่ 1 ทำรายการทุกระบบที่ส่ง Email ในนาม Domain ถามฝ่ายบัญชี การตลาด และ HR ด้วย ไม่ใช่แค่ IT เปิด DKIM และแก้ SPF ให้ครบ

สัปดาห์ที่ 1–4 เผยแพร่ DMARC p=none พร้อม rua อ่าน Report ทุกสัปดาห์ คุณจะเห็นระบบที่ลืมไป และอาจเห็นคนที่กำลังปลอม Domain ของคุณอยู่แล้ว

สัปดาห์ที่ 4–6 เมื่อระบบจริงทั้งหมดผ่าน ให้เปลี่ยนเป็น p=quarantine ถ้ามีหลาย Subdomain ให้บังคับใช้ทีละ Subdomain แทนการใช้ pct

สัปดาห์ที่ 6–8 เปลี่ยนเป็น p=reject แล้วติดตาม Report ต่อ เพราะระบบใหม่ที่ฝ่ายอื่นซื้อมาจะโผล่ใน Report ก่อนที่จะมีใครบอกไอที

Domain ที่ไม่ส่ง Email เลย (Domain สำรอง ชื่อเก่าของบริษัท) ตั้ง v=spf1 -all และ v=DMARC1; p=reject; ได้ทันที

ตรวจผล: ส่ง Email ไปบัญชี Gmail เปิด "Show original" แล้วดูว่า SPF, DKIM และ DMARC เป็น PASS ทั้งสาม

สิ่งที่เราเจอบ่อย

• SPF สอง Record หลังย้าย Hosting เว็บ
• p=none ที่ตั้งไว้สองปีและไม่มีใครอ่าน Report ซึ่งไม่ได้ป้องกันอะไร
• กระโดดไป p=reject ในวันเดียว แล้ว Email ใบแจ้งหนี้จาก ERP หาย ลูกค้าไม่ได้รับ
• Mailbox ส่วนหนึ่งอยู่ Hosting เก่า อีกส่วนอยู่ Microsoft 365 แต่ SPF มีแค่ฝั่งเดียว
• คิดว่า DMARC ป้องกัน Domain ที่คล้ายกัน เช่น yourc0mpany.la หรือ yourcompany-la.com ได้ ซึ่งไม่ได้ ส่วนนี้ต้องใช้ Email Filtering และ การอบรมพนักงานให้รู้ทัน Phishing

นอกเหนือจาก DNS

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

สำหรับการโอนเงิน กฎที่ดีที่สุดไม่ใช่เรื่องเทคนิค ทุกการเปลี่ยนเลขบัญชีธนาคารต้องโทรยืนยันกับเบอร์ที่มีอยู่ในแฟ้มแล้ว ไม่ใช่เบอร์ใน Email

เมื่อ DMARC อยู่ระดับ quarantine หรือ reject แล้ว คุณพิจารณา BIMI เพื่อแสดงโลโก้ใน Inbox ที่รองรับได้ โดย Gmail ต้องใช้ใบรับรองโลโก้ (VMC หรือ CMC) ด้วย

ถ้าองค์กรยังใช้ Email ฟรี (Gmail หรือ Yahoo ส่วนตัว) ในการทำงาน ขั้นแรกคือย้ายมาใช้ Email ธุรกิจบน Domain ของตัวเอง คุณตั้ง DMARC ให้ gmail.com ไม่ได้

ส่งชื่อ Domain มาให้เรา

แค่ชื่อ Domain ก็พอ เพราะ Record เหล่านี้เป็นข้อมูลสาธารณะ เราจะตรวจ SPF, DKIM และ DMARC ที่มีอยู่ แล้วส่ง Record ที่แก้แล้วกลับไปให้คุณคัดลอกใส่ DNS ได้ทันที