SPF Record Builder: สร้างและตรวจ SPF Record สำหรับป้องกัน Email Spoofing

ถ้าคุณเคยส่งอีเมลหาลูกค้าแล้วเมลไปตกในกล่อง spam หรือเคยเห็นอีเมลแปลก ๆ ที่แอบอ้างชื่อโดเมนบริษัทส่งหาพนักงานในองค์กร ปัญหาทั้งสองเรื่องนี้มักมีรากเดียวกัน คือโดเมนของคุณยังไม่มีระบบยืนยันตัวตนผู้ส่งที่แข็งแรงพอ มาตรฐานสำคัญที่สุดที่แก้ปัญหานี้ได้คือ SPF หรือชื่อเต็มว่า Sender Policy Framework ซึ่งเป็นหนึ่งในสามเสาหลักของ email authentication (SPF, DKIM, DMARC) ที่ mail server ทั่วโลกใช้ตรวจสอบว่าอีเมลฉบับหนึ่งได้รับอนุญาตจากเจ้าของโดเมนจริงหรือไม่

หลักการทำงานของ SPF ตรงไปตรงมา: คุณประกาศ DNS TXT record ไว้ว่า "mail server ไหนบ้างที่มีสิทธิ์ส่งเมลในนามโดเมนนี้" เมื่อ receiving server ได้รับอีเมลจากโดเมนคุณ มันจะ query DNS เพื่ออ่าน SPF record แล้วเช็คว่า IP ของผู้ส่งอยู่ในรายการที่อนุญาตหรือเปล่า ถ้าไม่อยู่ เมลฉบับนั้นจะถูกมองว่าน่าสงสัยและอาจเป็น email spoofing ทันที แต่ปัญหาคลาสสิกที่ engineer เจอกันประจำคือ syntax ของ SPF record นั้นจำยาก มีทั้ง mechanism หลายแบบ qualifier หลายระดับ แถมยังมีกฎเหล็กอย่าง limit 10 DNS lookups ตาม RFC 7208 ที่ถ้าทำผิดเมื่อไหร่ record ของคุณจะใช้การไม่ได้ทั้งแถว

SPF Record Builder คือเครื่องมือออนไลน์ฟรีที่เราทำขึ้นมาเพื่อแก้ pain point นี้โดยตรง มันทำหน้าที่เป็นทั้ง SPF generator และ SPF validator ในตัว — คุณแค่เพิ่ม mechanism ที่ต้องการ เลือก qualifier แล้วเครื่องมือจะนับ DNS lookup ให้ ตรวจ format ให้ และ generate TXT string ที่พร้อม publish ได้ทันที คู่มือนี้จะพาคุณเข้าใจ SPF ตั้งแต่พื้นฐานไปจนถึงระดับที่อ่าน record ของคนอื่นออกทุกตัวอักษร

ทำไมต้องใช้ SPF Record Builder?

• ป้องกัน email spoofing อย่างได้ผลจริง — เมื่อ SPF record ถูกต้อง receiving server จะปฏิเสธหรือลดความน่าเชื่อถือของเมลที่แอบอ้างโดเมนคุณ ทำให้ attacker ปลอมตัวเป็นผู้ส่งจากโดเมนคุณได้ยากขึ้นมาก
• ลดโอกาสเมลเข้า spam หรือถูกตีกลับ — SPF check เป็นด่านแรกที่ mailbox provider อย่าง Gmail และ Outlook ใช้ตัดสินชะตาเมลของคุณ ถ้า record พัง เมลธุรกิจก็อาจไปไม่ถึงลูกค้า
• ไม่ต้องจำ syntax และไม่ต้องกลัวพิมพ์ผิด — เครื่องมือ generate TXT record ที่ขึ้นต้นด้วย v=spf1 และเรียง mechanism ให้ถูกต้องตามรูปแบบที่ RFC 7208 กำหนด พร้อมตรวจ format ของ IPv4/IPv6 CIDR และ domain ให้อัตโนมัติ
• ไม่ต้องเสี่ยงกับ DNS lookup limit — ตัวนับ DNS lookup ในเครื่องมือจะเตือนทันทีเมื่อ record ของคุณเริ่มเข้าใกล้หรือเกิน limit 10 ครั้ง ซึ่งเป็นสาเหตุอันดับต้น ๆ ที่ทำให้ SPF check ล้มเหลวเป็น PermError
• แก่ไขและเรียงลำดับ mechanism ได้ง่าย — เพิ่ม ลบ หรือสลับลำดับ mechanism กี่รอบก็ได้ก่อน publish โดยไม่ต้องนั่งแก้ string ด้วยมือ
• publish ได้ทันที — ได้ TXT string สมบูรณ์ที่คัดลอกไปวางในหน้าจัดการ DNS ของ provider ได้เลย หรือจะดาวน์โหลดเป็นไฟล์ .txt เก็บไว้ก็ได้

ฟิเจอร์เด่น

• ตัวนับ DNS lookup คือพระเอกของเครื่องมือนี้ — ความผิดพลาดที่พบบ่อยที่สุดในการเขียน SPF เองคือไม่นับ lookup ซ้อนที่ซ่อนอยู่ใน include ของเจ้าอื่น เช่น include:_spf.google.com หนึ่งบรรทัดอาจแตกเป็นหลาย lookup ข้างใน เครื่องมือจะนับรวมให้และโชว์ warning ก่อนที่คุณจะ publish record ที่พัง
• qualifier เลือกได้ราย mechanism — คุณสามารถทำ whitelist แบบ strict กับ mail server ของตัวเอง (-all ปิดท้าย) แต่ยังคง ~ กับ service ภายนอกที่ยังไม่มั่นใจได้ ซึ่งสำคัญมากช่วง migrate ระบบเมล
• validate ก่อน generate ทุกครั้ง — ถ้าพิมพ์ IP ผิดรูปแบบ เช่น ip4:203.0.113.300 หรือ CIDR ผิด เครื่องมือจะดักให้ก่อน ทำให้ TXT record ที่ได้ไม่มีทาง syntax พัง

วิธีใช้งาน

1. เปิดเครื่องมือ — เข้าไปที่ SPF Record Builder ไม่ต้องสมัครสมาชิก ไม่ต้องติดตั้งอะไร ทั้งเครื่องมือรันบน browser
2. เพิ่ม mechanism ที่ต้องการ — ระบุแหล่งส่งเมลทั้งหมดของโดเมนคุณ เช่น include:_spf.google.com สำหรับ Google Workspace, ip4: สำหรับ mail server ของตัวเอง หรือ include: ของ SaaS ที่ใช้ส่งเมลการตลาด
3. เลือก qualifier ให้แต่ละ mechanism — ค่าเริ่มต้นคือ + (Pass) สำหรับแหล่งที่ไว้ใจได้ และเลือก closing mechanism เป็น ~all (SoftFail) หรือ -all (Fail) ตามความเข้มงวดที่ต้องการ
4. เช็คตัวนับ DNS lookup — ดูให้แน่ใจว่าตัวเลขไม่เกิน 10 ถ้ามี warning ให้ตัด mechanism ที่ไม่จำเป็นออก หรือเปลี่ยน a/mx เป็น ip4/ip6 ที่ไม่ต้องใช้ lookup
5. Copy หรือดาวน์โหลด TXT record — นำ string ที่ generate ได้ (ขึ้นต้นด้วย v=spf1) ไปเพิ่มเป็น TXT record ใน DNS ของโดเมนคุณ รอ propagation แล้วทดสอบด้วยเครื่องมือ DNS Lookup ว่า record ขึ้นถูกต้อง

เข้าใจ SPF Record ให้ลึกกว่าเดิม

Syntax พื้นฐาน: ทุก record ต่องขึ้นต้นด้วย v=spf1

SPF record คือ TXT record ที่ต้องขึ้นต้นด้วย version identifier v=spf1 เสมอ ตามด้วยรายการ mechanism เรียงกันคั่นด้วยช่องว่าง และควรปิดท้ายด้วย all ตัวอย่างโครงสร้าง:

v=spf1 <mechanism1> <mechanism2> ... all

ถ้า record ไม่ขึ้นต้นด้วย v=spf1 receiving server จะไม่ถือว่าเป็น SPF record และถ้าในโดเมนมี record แบบนี้มากกว่าหนึ่งฉบับ ผลคือ PermError ทันที

Mechanism แต่ละแบบทำหน้าที่อะไร

• ip4: / ip6: — ระบุ IP address หรือ CIDR range ของผู้ส่งโดยตรง เช่น ip4:203.0.113.0/24 หรือ ip6:2001:db8::/32 ข้อดีคือ ไม่นับเป็น DNS lookup เพราะไม่ต้อง query อะไรเลย เหมาะกับ mail server ที่มี IP คงที่
• include: — ดึง SPF record ของอีกโดเมนมาใช้นิยมมากกับบริการภายนอก เช่น include:_spf.google.com กลไกนี้ นับเป็น DNS lookup และ lookup ทั้งหมดที่เกิดขึ้นภายใน record ที่ include มาก็ถูกนับรวมด้วย
• a — match ถ้า IP ผู้ส่งตรงกับ A/AAAA record ของโดเมนที่ระบุ นับเป็น lookup
• mx — match ถ้า IP ผู้ส่งตรงกับ mail server ใน MX record ของโดเมน นับเป็น lookup
• exists: — match ถ้าโดเมนที่ระบุมี A record อยู่จริง ใช้ทำ whitelist แบบ dynamic นับเป็น lookup
• ptr — match จาก reverse DNS (PTR record) นับเป็น lookup และไม่แนะนำให้ใช้ เพราะช้าและพึ่งพาไม่ได้ในทางปฏิบัติ
• redirect= — (modifier ไม่ใช่ mechanism) ชี้ให้ไปใช้ SPF record ของอีกโดเมนทั้งก้อน นับเป็น lookup ใช้ตอนหลายโดเมนแชร์นโยบายเดียวกัน

Qualifier: +, -, ~, ? แต่ละตัวหมายถึงอะไร

ทุก mechanism นำหน้าด้วย qualifier ได้หนึ่งตัว (ถ้าไม่เขียน ถือว่าเป็น + โดยปริยาย):

• + (Pass) — อนุญาตอย่างชัดเจน IP นี้ส่งเมลในนามโดเมนได้
• - (Fail) — ปฏิเสธเด็ดขาด IP นี้ห้ามส่ง เมลที่มาจาก IP นี้ควรถูก reject
• ~ (SoftFail) — ปฏิเสธแบบนุ่มนวล เมลอาจยังถูกส่งเข้าแต่มีแนวโน้มโดนทำเครื่องหมายหรือโยนเข้า spam
• ? (Neutral) — เป็นกลาง ไม่ยืนยันและไม่ปฏิเสธ ใช้ช่วงทดสอบหรือกับแหล่งที่ยังตัดสินใจไม่ได้

all: กลไกเล็ก ๆ ที่สำคัญที่สุด

all คือ mechanism สุดท้ายที่ match กับทุก IP ที่ mechanism ก่อนหน้าไม่ match จึงเป็นตัวกำหนด "นโยบายสำหรับคนแปลกหน้า" ทั้งหมด โดเมนที่ไม่ปิดท้ายด้วย all ถือว่าปล่อยช่องโหว่ เพราะ IP ใด ๆ ที่ไม่อยู่ในรายการจะไม่มีนโยบายกำกับ แนวปฏิบัติคือปิดท้ายด้วย ~all ในช่วงแรก และขยับเป็น -all เมื่อมั่นใจว่าไม่มีแหล่งส่งเมลหลุดจากรายการแล้ว

Limit 10 DNS lookups ตาม RFC 7208 และ PermError

RFC 7208 section 4.6.4 กำหนดว่า receiving server จะประเมิน mechanism ที่ต้อง query DNS ได้ไม่เกิน 10 ครั้ง ต่อการเช็คหนึ่งรอบ กลไกที่ถูกนับคือ include, a, mx, exists, ptr และ redirect ส่วน ip4, ip6 และ all ไม่นับ ถ้า record ของคุณทำให้ lookup เกิน 10 ครั้ง ผลการเช็คจะกลายเป็น PermError ทันที ซึ่งแย่กว่าการไม่มี SPF record เสียอีก เพราะ receiving server บางแห่งมองว่าโดเมนคุณตั้งค่าผิดพลาดและลดคะแนนความน่าเชื่อถือลง นี่คือเหตุผลที่ตัวนับ lookup ใน SPF Record Builder สำคัญมาก — โดยเฉพาะ include ที่ซ้อนกันหลายชั้น ซึ่งมองด้วยตาเปล่าไม่มีทางนับถูก

กฎเหล็ก: หนึ่ง domain ต่องมี SPF record เดียว

มาตรฐานกำหนดให้แต่ละโดเมนมี SPF TXT record ได้เพียง record เดียว ถ้ามีสอง record ขึ้นไป ผลคือ PermError เช่นกัน ดังนั้นถ้าคุณมีหลายบริการที่ต่างก็บอกให้ "เพิ่ม SPF record ของเรา" อย่าเพิ่มเป็นบรรทัดใหม่ — ให้ merge ทุก mechanism รวมกันใน record เดียว แล้วใช้ตัวนับ lookup ตรวจก่อน publish

Use Case ในทางปฏิบัตติ

ส่งเมลผ่าน Google Workspace

องค์กรที่ใช้ Gmail ผ่าน Google Workspace ต้องอนุญาตให้ server ของ Google ส่งเมลในนามโดเมน:

v=spf1 include:_spf.google.com ~all

include:_spf.google.com จะแตกเป็น include ย่อยภายในอีกหลายชั้น แต่โดยรวมยังอยู่ใน limit 10 lookup ช่วงแรกใช้ ~all ก่อน เมื่อตรวจสอบ log แล้วพบว่าไม่มีแหล่งส่งอื่นหลุดค่อยเปลี่ยนเป็น -all

ส่งเมลผ่าน Microsoft 365

สำหรับ tenant ของ Microsoft 365 record มาตรฐานคือ:

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

ถ้าองค์กรส่งเมลจาก on-premise server ด้วย ให้เพิ่ม ip4: ของ server นั้นเข้าไปก่อน ~all

Mail server ของต้วเองด้วย ip4/ip6

ถ้าคุณรัน mail server เอง เช่น Postfix หรือ Exim การระบุ IP ตรง ๆ คือทางเลือกที่ดีที่สุดเพราะไม่กิน DNS lookup เลยแม้แต่ครั้งเดียว:

v=spf1 ip4:203.0.113.10 ip6:2001:db8::/32 -all

ใช้ -all ได้เลยเพราะคุณควบคุมแหล่งส่งเองทั้งหมด รู้แน่ชัดว่าไม่มี server อื่นส่งเมลในนามโดเมนนี้

รวม SaaS การตลาดหลายเจ้า แล้วเปลี่ยน ~all เป็น -all

เคสที่เจอบ่อย: บริษัทใช้ Google Workspace ส่งเมลปกติ ใช้ Mailchimp ส่ง newsletter และใช้ SendGrid ส่ง transactional email record จะเป็น:

v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net ~all

แต่ละ include กินอย่างน้อย 1 lookup และบางเจ้าอย่าง Mailchimp แตกย่อยภายในอีก ต้องเช็คตัวนับ lookup ในเครื่องมือทุกครั้ง เมื่อระบบนิ่งแล้วและยืนยันจาก mail log ว่าไม่มีแหล่งส่งอื่น ให้เปลี่ยน ~all เป็น -all เพื่อบังคับนโยบายแบบ hard fail ปิดช่อง email spoofing ให้สนิท

Best Practices

• เริ่มด้วย ~all ก่อนเสมอ — ใช้ SoftFail ในช่วงแรกเพื่อสังเกตว่ามีแหล่งส่งไหนหลุดจากรายการบ้าง (ดูจาก mail log) เมื่อมั่นใจแล้วค่อยขยับเป็น -all เพื่อป้องกันเต็มรูปแบบ
• เฝ้าระวัง DNS lookup limit อย่าให้เกิด 10 — นับรวม lookup ที่ซ่อนใน include ทุกชั้น ถ้าใกล้เต็มให้ตัด service ที่เลิกใช้แล้วออก หรือเปลี่ยน a/mx เป็น ip4/ip6
• ใช้ ip4/ip6 แทน a/mx เมื่อรู้ IP แน่นอน — นอกจากไม่กิน lookup แล้ว ยังหลีกเลี่ยงปัญหา IP เปลี่ยนโดยไม่รู้ตัวได้อีกด้วย
• audit include เป็นประจำ — ทุก include คือการมอบความไว้วางใจให้โดเมนภายนอก ถ้า vendor เจ้าไหนไม่ได้ใช้แล้วให้ลบออกทันที เพราะ record ของเขาเปลี่ยนได้โดยคุณไม่รู้ตัว
• จำไว้ว่าหนึ่ง domain มี SPF record ได้เดียว — รวมทุก mechanism ไว้ใน TXT record เดียวเสมอ ถ้าเผลอมีหลาย record ให้รีบ merge ก่อนที่ receiving server จะคืน PermError
• อย่าหยุดแค่ SPF — SPF บอกแค่ว่า "server ไหนส่งได้" แต่ไม่ได้เซ็นกำกับเนื้อหาเมล ทำ SPF ให้ถูกแล้วต้องตั้ง DKIM และ DMARC ควบคู่กัน email authentication ถึงจะครบวงจรจริง ๆ

เริ่มสร้าง SPF Record ของคุณวันนี้

SPF record ที่ถูกต้องคือรากฐานของ email authentication ทั้งหมด — มันทั้งปกป้องโดเมนคุณจากการถูกแอบอ้าง และช่วยให้เมลธุรกิจส่งถึง inbox แทนที่จะไปนอนในกล่อง spam สิ่งที่ต้องจำมีแค่สามอย่าง: ขึ้นต้นด้วย v=spf1 ปิดท้ายด้วย all และอย่าให้ DNS lookup เกิน 10 ครั้ง

ถ้าคุณไม่อยากนั่งจำ syntax หรือนับ lookup เอง SPF Record Builder พร้อมช่วยคุณสร้าง record ที่ถูกต้องตาม RFC 7208 ในไม่กี่นาที เพิ่ม mechanism เลือก qualifier ให้เครื่องมือตรวจ format กับนับ lookup ให้ แล้วคัดลอก TXT record ไป publish ได้เลย — ฟรี ไม่ต้องล็อกอิน และใช้ได้ไม่จำกัดจำนวนครั้ง

เครื่องมือที่เกี่ยวข้อง

• DKIM Record Generator — สร้าง DKIM record เพื่อเซ็นกำกับอีเมล เพิ่มความน่าเชื่อถือให้โดเมน
• DMARC Record Builder — ตั้งนโยบาย DMARC เพื่อบอก receiving server ว่าควรทำอย่างไรกับเมลที่ SPF/DKIM ไม่ผ่าน
• DNS Lookup — ตรวจสอบว่า SPF TXT record ของคุณถูก publish ขึ้น DNS เรียบร้อยแล้วหรือยัง

ขอให้ส่งเมลอย่างมั่นใจ!