ตั้งค่า SPF, DKIM และ DMARC สำหรับร้านค้าออนไลน์ตามกฎผู้ส่งของ Gmail และ Yahoo

เพื่อให้เป็นไปตามกฎผู้ส่งของ Gmail และ Yahoo ร้านค้าออนไลน์ทุกแห่งต้องมี SPF หรือ DKIM บนโดเมนที่ใช้ส่งอีเมล ส่วนผู้ส่งอีเมลจำนวนมาก (bulk sender) ต้องมีทั้งสองอย่าง พร้อมระเบียน DMARC ที่มีนโยบายอย่างน้อย p=none และโดเมน From ที่ผู้รับมองเห็นต้องสอดคล้อง (align) กับ SPF หรือ DKIM ผู้ส่งจำนวนมากยังต้องมีปุ่มยกเลิกการรับข่าวสารแบบคลิกเดียวในอีเมลการตลาด และรักษาอัตราสแปมที่ถูกรายงานให้ต่ำกว่า 0.3% บน Shopify หมายถึงการยืนยันตัวตนโดเมนผู้ส่งในหน้าผู้ดูแลระบบ (admin) แล้วเพิ่มระเบียน DMARC ส่วนบน WooCommerce หมายถึงการส่งอีเมลผ่านผู้ให้บริการอีเมลที่ยืนยันตัวตนแล้ว เมื่อรายงาน DMARC แสดงว่าอีเมลที่ถูกต้องทั้งหมดของคุณผ่านการตรวจสอบ คุณจึงปรับนโยบายไปสู่ p=reject ได้

ประเด็นสำคัญ

• ตั้งแต่วันที่ 1 กุมภาพันธ์ 2024 Gmail กำหนดให้ผู้ส่งทุกรายตั้งค่า SPF หรือ DKIM และให้ผู้ส่งจำนวนมากตั้งค่า SPF, DKIM และ DMARC (Google (เปิดในแท็บใหม่))
• Gmail จะถือว่าคุณเป็นผู้ส่งจำนวนมากเมื่อคุณส่งอีเมลเกือบ 5,000 ฉบับถึงบัญชี Gmail ส่วนบุคคลภายใน 24 ชั่วโมง และสถานะนี้ไม่มีวันหมดอายุ (คำถามที่พบบ่อยของ Gmail (เปิดในแท็บใหม่))
• ตั้งแต่เดือนพฤศจิกายน 2025 Gmail เพิ่มความเข้มงวดในการบังคับใช้กับทราฟฟิกที่ไม่เป็นไปตามข้อกำหนด รวมถึงการปฏิเสธอีเมลทั้งแบบชั่วคราวและแบบถาวร (คำถามที่พบบ่อยของ Gmail (เปิดในแท็บใหม่))
• Outlook.com กำหนดให้โดเมนที่ส่งอีเมลมากกว่า 5,000 ฉบับต่อวันต้องมี SPF, DKIM และ DMARC ตั้งแต่วันที่ 5 พฤษภาคม 2025 (Microsoft (เปิดในแท็บใหม่))
• SPF อนุญาตให้มีเทอมที่ต้องค้นหา DNS ได้ไม่เกิน 10 รายการต่อการตรวจสอบหนึ่งครั้ง หากเกินจะได้ผลลัพธ์เป็น permerror (RFC 7208 (เปิดในแท็บใหม่))
• DMARC ได้รับการปรับปรุงในเดือนพฤษภาคม 2026: RFC 9989 (เปิดในแท็บใหม่) มาแทนที่ RFC 7489 และเปลี่ยนแท็ก pct เป็น t

SPF, DKIM และ DMARC ทำหน้าที่อะไรกันแน่

SPF ระบุว่าใครส่งอีเมลในนามโดเมนของคุณได้บ้าง DKIM ลงลายเซ็นดิจิทัลให้แต่ละข้อความ และ DMARC ผูกทั้งสองอย่างเข้ากับที่อยู่ From ที่ลูกค้าของคุณมองเห็น

ความสอดคล้อง (alignment) เป็นจุดที่มองข้ามได้ง่าย แพลตฟอร์มอีเมลของคุณอาจผ่าน SPF สำหรับโดเมน bounce ของตัวเอง ขณะที่ที่อยู่ From แสดงโดเมนของร้านคุณ ข้อความนั้นจะผ่าน SPF แต่ไม่ผ่าน DMARC เว้นแต่ DKIM จะลงลายเซ็นด้วยโดเมนของคุณ

Gmail และ Yahoo กำหนดอะไรกับผู้ส่งอีเมล

ทั้งสองรายกำหนดให้ผู้ส่งทุกรายต้องยืนยันตัวตน และเพิ่มกฎที่เข้มงวดขึ้นสำหรับผู้ส่งจำนวนมาก

สำหรับผู้ส่งทุกราย Gmail กำหนดให้มี SPF หรือ DKIM, DNS แบบ forward และ reverse ที่ถูกต้อง, TLS, การจัดรูปแบบข้อความตาม RFC 5322 และอัตราสแปมต่ำกว่า 0.3% ใน Postmaster Tools (Google (เปิดในแท็บใหม่)) ส่วน Yahoo กำหนดให้มีอย่างน้อย SPF หรือ DKIM และอัตราสแปมต่ำกว่า 0.3% (Yahoo Sender Hub (เปิดในแท็บใหม่)) สำหรับผู้ส่งจำนวนมาก:

รายละเอียดบางประการที่สำคัญสำหรับร้านค้า:

• Gmail นับตามโดเมน ข้อความจากโดเมนหลักเดียวกันจะถูกนับรวมในเกณฑ์ 5,000 ฉบับ ดังนั้นอีเมลคำสั่งซื้อ อีเมลการตลาด และอีเมลตอบกลับจากฝ่ายบริการลูกค้าจะถูกนับรวมกันทั้งหมด
• นับเฉพาะบัญชี Gmail ส่วนบุคคล แนวทางนี้ไม่ใช้กับข้อความที่ส่งไปยังบัญชี Google Workspace
• อีเมลธุรกรรม (transactional) ได้รับการยกเว้นเรื่องการยกเลิกรับแบบคลิกเดียว แต่อีเมลยืนยันคำสั่งซื้อยังต้องผ่านการยืนยันตัวตน

การยกเลิกรับข่าวสารแบบคลิกเดียวใช้ส่วนหัว (header) สองรายการที่กำหนดไว้ใน RFC 8058 (เปิดในแท็บใหม่) ซึ่งกำหนดด้วยว่าต้องมีลายเซ็น DKIM ที่ถูกต้องครอบคลุมส่วนหัวทั้งสองนี้:

List-Unsubscribe: <https://example.com/unsubscribe/opaquepart>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

หากต้องการยืนยันว่าแพลตฟอร์มการตลาดของคุณใส่ส่วนหัวเหล่านี้แล้ว ให้เปิดดูซอร์สต้นฉบับ (raw source) ของแคมเปญหนึ่งที่คุณส่งเอง

มีอะไรเปลี่ยนไปหลังเดือนกุมภาพันธ์ 2024

การบังคับใช้เข้มงวดขึ้นเป็นลำดับ และผู้ให้บริการกล่องจดหมายรายอื่นก็นำกฎที่คล้ายกันมาใช้ด้วย

กฎของ Outlook.com ใช้กับที่อยู่อีเมลสำหรับผู้ใช้ทั่วไป (outlook.com, hotmail.com และ live.com) โดยกำหนดให้ต้องผ่าน SPF และ DKIM และมี DMARC อย่างน้อย p=none ที่สอดคล้องกับ SPF หรือ DKIM

ตั้งค่า SPF, DKIM และ DMARC บน Shopify อย่างไร

ยืนยันตัวตนโดเมนผู้ส่งในหน้าผู้ดูแลระบบ Shopify จากนั้นเพิ่มระเบียน DMARC หนึ่งรายการที่ผู้ให้บริการ DNS ของคุณ

คู่มือการตั้งค่าอีเมล (เปิดในแท็บใหม่) ของ Shopify ระบุว่าตั้งแต่วันที่ 1 กุมภาพันธ์ 2024 Gmail และ Yahoo กำหนดให้ต้องมีโดเมนที่ยืนยันตัวตนแล้วและระเบียน DMARC จึงจะส่งอีเมลจากที่อยู่ที่ใช้แบรนด์ของคุณได้ หากยังไม่ได้ตั้งค่าระเบียนยืนยันตัวตน Shopify จะเขียนที่อยู่ผู้ส่งของคุณใหม่ในรูปแบบ store+123@shopifyemail.com ขั้นตอนมีดังนี้:

1. ในหน้าผู้ดูแลระบบ Shopify ไปที่ Settings > Notifications
2. ในส่วน Sender email ให้คลิก authenticate your domain
3. เพิ่มระเบียน CNAME ทุกรายการที่แสดงไว้ที่ผู้ให้บริการ DNS ของคุณ จำนวนระเบียนอาจแตกต่างกันไป Shopify ระบุว่าระเบียนเหล่านี้จัดการ SPF และ DKIM สำหรับที่อยู่ผู้ส่งของคุณ และคุณไม่จำเป็นต้องเพิ่มที่อยู่ IP
4. รอให้การเปลี่ยนแปลง DNS มีผล ซึ่งอาจใช้เวลาสูงสุด 48 ชั่วโมง
5. เพิ่มระเบียน TXT ชื่อ _dmarc ที่มีค่า v=DMARC1; p=none; ซึ่ง Shopify ใช้เป็นค่าเริ่มต้น

หากคุณซื้อโดเมนจาก Shopify หรือโอนโดเมนมาไว้ที่ Shopify ทาง Shopify จะจัดการระเบียนเหล่านี้ให้ Shopify ยังเตือนด้วยว่าโดเมนหนึ่งมีระเบียน DMARC ได้เพียงรายการเดียว และควรลบการตั้งค่า alignment แบบเข้มงวด (adkim=s หรือ aspf=s) หรือเปลี่ยนเป็น r

การยืนยันตัวตนของ Shopify ครอบคลุมเฉพาะอีเมลที่ Shopify เป็นผู้ส่ง หากคุณใช้แพลตฟอร์มอื่นสำหรับแคมเปญ ระบบ help desk หรือ Google Workspace สำหรับอีเมลของพนักงาน แต่ละระบบต้องตั้งค่า DKIM ของตัวเอง และหากระบบนั้นใช้โดเมนของคุณสำหรับ bounce ก็ต้องมีรายการ SPF ของตัวเองด้วย

ตั้งค่าการยืนยันตัวตนอีเมลสำหรับ WooCommerce อย่างไร

ส่งอีเมลของ WooCommerce ผ่านผู้ให้บริการเฉพาะทางที่ลงลายเซ็นด้วยโดเมนของคุณ ตามที่เอกสารของ WooCommerce เองแนะนำ

WooCommerce ส่งอีเมลโดยใช้ฟังก์ชัน wp_mail() ของ WordPress และคำถามที่พบบ่อยเกี่ยวกับอีเมล (เปิดในแท็บใหม่) ของ WooCommerce แนะนำให้ใช้ผู้ให้บริการ SMTP เฉพาะทาง เพราะเชื่อถือได้มากกว่าฟังก์ชันส่งอีเมลของเซิร์ฟเวอร์คุณเอง การตั้งค่าโดยทั่วไปมีดังนี้:

1. เลือกผู้ให้บริการอีเมลธุรกรรม (transactional email) และยืนยันโดเมนของคุณกับผู้ให้บริการนั้น ผู้ให้บริการจะให้ระเบียน DKIM และค่า SPF include ที่ต้องเผยแพร่
2. เชื่อมต่อ WordPress กับผู้ให้บริการนั้นด้วยปลั๊กอิน SMTP หรือ API
3. ตั้งค่า From address ใน WooCommerce > Settings > Emails เป็นที่อยู่บนโดเมนของคุณเอง WooCommerce เตือนว่าที่อยู่สาธารณะ เช่น ที่อยู่บน Gmail หรือ Yahoo มีแนวโน้มจะตกไปอยู่ในสแปมหรือถูกบล็อก
4. เผยแพร่ระเบียน DMARC ที่ _dmarc.yourdomain
5. ตรวจสอบ WooCommerce > Status > Logs และกรองตามแหล่งที่มา transactional-emails เพื่อดูว่าข้อความใดส่งสำเร็จหรือล้มเหลว

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

ขีดจำกัด 10 lookup ของ SPF คืออะไร และทำอย่างไรไม่ให้เกิน

การตรวจสอบ SPF หนึ่งครั้งใช้เทอมที่ต้องค้นหา DNS ได้ไม่เกิน 10 รายการ หากเกินแม้เพียงรายการเดียว ผลลัพธ์จะเป็น permerror และ SPF จะไม่ผ่าน

RFC 7208 หัวข้อ 4.6.4 (เปิดในแท็บใหม่) ระบุเทอมที่นับรวม ได้แก่ กลไก (mechanism) include, a, mx, ptr และ exists รวมถึงตัวปรับแต่ง (modifier) redirect ส่วนกลไก ip4, ip6 และ all ไม่นับรวม include ที่ซ้อนอยู่ภายใน include ของคุณก็นับด้วย เพราะขีดจำกัดนี้ใช้กับการประเมินทั้งหมด RFC ยังแนะนำให้จำกัด “void lookup” (การค้นหาที่ไม่ได้คำตอบกลับมา) ไว้ที่ 2 ครั้ง และระบุว่าไม่ควรเผยแพร่กลไก ptr

วิธีรักษาจำนวนให้ไม่เกิน 10:

• ลบ include ของบริการที่คุณไม่ได้ใช้แล้ว
• ใช้ ip4 หรือ ip6 สำหรับเซิร์ฟเวอร์ที่คุณดูแลเองและมีที่อยู่คงที่
• ย้ายอีเมลการตลาดไปยังซับโดเมน เช่น news.example.com ซึ่งมีระเบียน SPF และการนับจำนวนแยกเป็นของตัวเอง
• อย่าเผยแพร่ระเบียน SPF สองรายการเด็ดขาด RFC 7208 ห้ามมีหลายระเบียน และการประเมินจะได้ผลลัพธ์เป็น permerror

example.com.        TXT  "v=spf1 include:_spf.google.com include:spf.example-esp.com ~all"
news.example.com.   TXT  "v=spf1 include:spf.example-marketing.com ~all"

spf.example-esp.com และ spf.example-marketing.com เป็นเพียงตัวอย่างแทนค่าที่ผู้ให้บริการของคุณกำหนดให้ใช้

ปรับ DMARC จาก p=none ไปเป็น p=reject อย่างไร

เริ่มที่ p=none พร้อมเปิดรับรายงาน แก้ไขแหล่งส่งอีเมลที่ถูกต้องทุกแหล่งที่รายงานเผยให้เห็น แล้วจึงเพิ่มความเข้มงวดของนโยบาย

ขยับไปขั้นถัดไปเฉพาะเมื่อรายงานแสดงว่าแพลตฟอร์มร้านค้า เครื่องมือการตลาด ระบบ help desk และอีเมลของพนักงานผ่านทั้งหมดแล้ว รายงานรวมถูกกำหนดไว้ใน RFC 9990 (เปิดในแท็บใหม่) หากที่อยู่ rua อยู่บนโดเมนอื่น เช่น บริการรับรายงาน โดเมนนั้นต้องเผยแพร่ระเบียนที่อนุญาตให้รับรายงานดังกล่าว

คู่มือรุ่นเก่าแนะนำให้ทยอยเปิดใช้ด้วย pct=25 หรือ pct=50 แต่ RFC 9989 ได้ยกเลิก pct แล้ว (รายการในทะเบียนปัจจุบันมีสถานะ “historic”) เพราะค่าที่ไม่ใช่ 0 และ 100 ถูกนำไปใช้อย่างไม่สอดคล้องกัน สิ่งที่มาแทนคือ t=y ซึ่งขอให้ผู้รับใช้นโยบายที่ต่ำลงหนึ่งระดับ เช่น quarantine แทน reject หากต้องการขั้นทดลอง ให้ใช้ t=y แทนการกำหนดเปอร์เซ็นต์บางส่วน

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com"
_dmarc.example.com.  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com"

นโยบายที่บังคับใช้แล้วยังเปิดทางให้ใช้ BIMI ซึ่งแสดงโลโก้ของคุณในกล่องจดหมายที่รองรับ สำหรับ BIMI นั้น Gmail กำหนดให้มี DMARC ที่ p=quarantine หรือ p=reject และมี Verified Mark Certificate หรือ Common Mark Certificate (Google (เปิดในแท็บใหม่)) สำหรับอีเมลขาเข้าที่ส่งมายังโดเมนของคุณ MTA-STS (RFC 8461 (เปิดในแท็บใหม่)) ช่วยให้คุณแจ้งเซิร์ฟเวอร์ผู้ส่งให้ไม่ส่งอีเมลไปยังเมลเซิร์ฟเวอร์ของคุณ หากเมลเซิร์ฟเวอร์เหล่านั้นไม่รองรับ TLS ที่มีใบรับรองที่เชื่อถือได้

ตรวจสอบระเบียนของร้านคุณได้อย่างไร

ค้นหาระเบียนทั้งสามประเภทด้วย dig หรือใช้เครื่องมือตรวจสอบที่อ่านระเบียนเหล่านี้ให้คุณ

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT selector._domainkey.example.com

DKIM selector มาจากผู้ให้บริการของคุณ และคุณหาได้จากค่า s= ในส่วนหัว DKIM-Signature ของข้อความที่คุณส่งออกไป รายงานการส่งอีเมลถึงผู้รับ จะอ่าน DNS สาธารณะของคุณ นับจำนวน SPF lookup ลองใช้ DKIM selector ที่พบบ่อย และตรวจสอบนโยบาย DMARC, rua, pct, BIMI และ MTA-STS ระเบียนที่ถูกต้องช่วยได้ แต่ไม่มีชุดระเบียนใดรับประกันได้ว่าอีเมลจะเข้ากล่องจดหมาย เพราะผู้ให้บริการกล่องจดหมายยังพิจารณาการร้องเรียนว่าเป็นสแปมและพฤติกรรมการส่งด้วย

คำถามที่พบบ่อย

ร้านที่ส่งอีเมลน้อยกว่า 5,000 ฉบับต่อวันจำเป็นต้องมี DMARC หรือไม่

Gmail กำหนดให้มี DMARC เฉพาะผู้ส่งจำนวนมาก แต่ Shopify ระบุว่า Gmail และ Yahoo กำหนดให้ต้องมีโดเมนที่ยืนยันตัวตนแล้วและระเบียน DMARC จึงจะส่งอีเมลจากที่อยู่ที่ใช้แบรนด์ของร้านได้ ระเบียน p=none มีความเสี่ยงต่ำและให้รายงานแก่คุณ ร้านค้าส่วนใหญ่จึงควรเผยแพร่ระเบียนนี้

โดเมนหนึ่งมีระเบียน SPF สองรายการได้หรือไม่

ไม่ได้ RFC 7208 ระบุว่าโดเมนต้องไม่มีระเบียน SPF หลายรายการ และหากมี การประเมิน SPF จะได้ผลลัพธ์เป็น permerror ให้รวมผู้ส่งทั้งหมดไว้ในระเบียนเดียว

p=reject จะบล็อกอีเมลคำสั่งซื้อจาก Shopify หรือไม่

ไม่บล็อก หากตั้งค่าระเบียน CNAME ของ Shopify ไว้ครบแล้ว และรายงาน DMARC ของคุณแสดงว่าอีเมลจาก Shopify ผ่าน DKIM ที่สอดคล้องกัน ให้ตรวจสอบรายงานก่อนปรับนโยบายให้เข้มงวดกว่า p=none และคงการตั้งค่า alignment แบบ relaxed ตามที่ Shopify แนะนำ

แท็ก pct ของ DMARC ยังใช้ได้อยู่หรือไม่

RFC 9989 ซึ่งเผยแพร่ในเดือนพฤษภาคม 2026 ได้ยกเลิก pct และเพิ่ม t=y สำหรับโหมดทดสอบ แนวทาง BIMI ของ Google ยังคงกำหนดให้ใช้ pct=100 ซึ่งเป็นค่าเริ่มต้นเมื่อไม่มีแท็กนี้ ดังนั้นการไม่ใส่ pct จึงเป็นทางเลือกที่ง่ายที่สุดสำหรับระเบียนใหม่

การผ่าน SPF, DKIM และ DMARC รับประกันว่าอีเมลจะเข้ากล่องจดหมายหรือไม่

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

แหล่งข้อมูลอ้างอิง

• Email sender guidelines (เปิดในแท็บใหม่), Google, เข้าถึงเมื่อ 22 ตุลาคม 2026
• Email sender guidelines FAQ (เปิดในแท็บใหม่), Google, เข้าถึงเมื่อ 22 ตุลาคม 2026
• Sender best practices (เปิดในแท็บใหม่), Yahoo Sender Hub, เข้าถึงเมื่อ 22 ตุลาคม 2026
• Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders (เปิดในแท็บใหม่), Microsoft Tech Community, 2 เมษายน 2025 อัปเดตเมื่อ 29 เมษายน 2025
• Setting up your email (เปิดในแท็บใหม่), Shopify Help Center, เข้าถึงเมื่อ 22 ตุลาคม 2026
• Email FAQ (เปิดในแท็บใหม่), เอกสารของ WooCommerce, เข้าถึงเมื่อ 22 ตุลาคม 2026
• RFC 7208: Sender Policy Framework (SPF) (เปิดในแท็บใหม่), IETF, เมษายน 2014
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures (เปิดในแท็บใหม่), IETF, กันยายน 2011
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) (เปิดในแท็บใหม่), IETF, มีนาคม 2015 (ถูกแทนที่ด้วย RFC 9989)
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (เปิดในแท็บใหม่), IETF, พฤษภาคม 2026
• RFC 9990: DMARC Aggregate Reporting (เปิดในแท็บใหม่), IETF, พฤษภาคม 2026
• RFC 8058: Signaling One-Click Functionality for List Email Headers (เปิดในแท็บใหม่), IETF, มกราคม 2017
• RFC 8461: SMTP MTA Strict Transport Security (MTA-STS) (เปิดในแท็บใหม่), IETF, กันยายน 2018
• Set up BIMI (เปิดในแท็บใหม่), Google Workspace Admin Help, เข้าถึงเมื่อ 22 ตุลาคม 2026