ลูกค้ากรอกฟอร์มบนเว็บไซต์แล้วเห็นข้อความ “ส่งสำเร็จ” แต่ทีมขายกลับไม่ได้รับอีเมล ปัญหานี้อันตรายกว่าฟอร์มเสียแบบเห็นชัด เพราะหน้าเว็บดูเหมือนทำงานปกติ ขณะที่ Lead อาจตกหล่นโดยไม่มีใครรู้ บางครั้งอีเมลเข้า Spam บางครั้งถูกเซิร์ฟเวอร์ปลายทางปฏิเสธ และบางครั้ง WordPress ส่งคำสั่งออกไปไม่ได้ตั้งแต่ต้น
คำว่า “ส่งสำเร็จ” บนฟอร์มยังไม่ยืนยันว่าอีเมลถึง Inbox
ข้อความสำเร็จบนหน้าฟอร์มมักหมายถึงเบราว์เซอร์ส่งข้อมูลเข้า WordPress ได้และปลั๊กอินประมวลผลคำขอโดยไม่เกิดข้อผิดพลาดทันที แต่ไม่ได้ยืนยันทุกขั้นตอนหลังจากนั้น ระบบยังต้องสร้างอีเมล ส่งให้ Mail Transfer Agent หรือ SMTP Relay ผ่านการตรวจสอบของเซิร์ฟเวอร์ผู้รับ และถูกจัดวางใน Inbox หรือ Spam
WordPress ใช้ฟังก์ชัน wp_mail() เป็นตัวกลางในการจัดรูปแบบและส่งข้อความต่อให้ระบบเมล โดยค่าเริ่มต้นอาจพึ่ง PHP mail() และสภาพแวดล้อมบนเซิร์ฟเวอร์ หากโฮสติ้งไม่มี Mail Transfer Agent ที่ตั้งค่าถูกต้อง หรือปิดการส่งเมลไว้ ข้อความจะไม่ออกจากเซิร์ฟเวอร์ การเปลี่ยนไปใช้ SMTP Relay ที่ตรวจสอบตัวตนได้จึงมักควบคุมและตรวจสอบง่ายกว่า
เริ่มตรวจจากหลักฐานของฟอร์มก่อนแตะ SMTP
เป้าหมายแรกคือแยกว่า “Lead ไม่ถูกบันทึก” กับ “บันทึกแล้วแต่อีเมลแจ้งเตือนไม่ถึง” เพราะเป็นคนละปัญหา เปิด Entries, Submissions หรือฐานข้อมูลของปลั๊กอินฟอร์ม แล้วส่งฟอร์มทดสอบด้วยข้อมูลที่ระบุเวลาได้ชัด หากพบรายการ แสดงว่าฝั่งรับข้อมูลทำงานและควรตรวจเส้นทางอีเมลต่อ แต่ถ้าไม่มีรายการ ให้ตรวจ Validation, JavaScript error, REST/AJAX request, Cache, Firewall และการตั้งค่าปลั๊กอินก่อน
ตรวจ wp_mail และ Email Log ว่า WordPress ส่งคำสั่งออกหรือไม่
ติดตั้งหรือเปิดระบบ Email Log ที่บันทึกเวลา ผู้รับ Subject สถานะ และ Error โดยหลีกเลี่ยงการเก็บข้อมูลละเอียดเกินจำเป็น หาก Log ไม่เกิดรายการหลังส่งฟอร์ม ให้กลับไปตรวจ Notification ของฟอร์ม เงื่อนไขการส่ง Hook หรือความขัดแย้งของปลั๊กอิน แต่ถ้า Log มีรายการและระบุว่า Sent ต้องเข้าใจว่า Sent ในระดับแอปพลิเคชันอาจหมายถึงระบบรับคำสั่งแล้ว ไม่ใช่หลักฐานว่า Inbox ปลายทางได้รับข้อความ
หลักฐานที่แข็งแรงกว่าคือ Transaction Log จากผู้ให้บริการ SMTP ซึ่งควรมี Message ID เวลา ผู้รับ และสถานะ เช่น accepted, delivered, deferred, bounced หรือ rejected หากมี Bounce Code ให้เก็บข้อความตอบกลับจากเซิร์ฟเวอร์ผู้รับ เพราะรหัสนั้นช่วยชี้ว่าปัญหาเกิดจาก Authentication, Reputation, กล่องเต็ม ผู้รับไม่มีอยู่ หรือ Policy ขององค์กร
SMTP แก้ปัญหาอะไร และต้องตั้งค่าตรงไหน
SMTP ช่วยให้ WordPress ส่งอีเมลผ่านผู้ให้บริการที่มีการยืนยันตัวตน แทนการพึ่ง PHP mail() จากเว็บเซิร์ฟเวอร์โดยตรง จุดที่ต้องตรวจไม่ใช่เพียง Host, Port และ Password แต่รวมถึง Encryption, Authentication, From Email, From Name, Return-Path และสิทธิ์ของบัญชีที่ใช้ส่ง
ใช้ From Email บนโดเมนที่ควบคุมได้
ควรใช้ที่อยู่ผู้ส่งจริงบนโดเมนของเว็บไซต์หรือโดเมนที่ผู้ให้บริการอนุญาต เช่น notification@yourdomain.com ไม่ควรนำอีเมลที่ลูกค้ากรอกมาใส่ใน From เพราะจะทำให้ข้อความดูเหมือนเว็บไซต์ส่งแทนโดเมนของลูกค้าและอาจไม่ผ่าน DMARC ให้ใส่อีเมลลูกค้าใน Reply-To เพื่อให้ทีมขายกดตอบกลับได้
ตรวจพอร์ตและการเข้ารหัสให้ตรงผู้ให้บริการ
ค่าที่พบบ่อยคือ Port 587 กับ STARTTLS หรือ Port 465 กับ TLS/SSL แต่ต้องยึดคู่มือของผู้ให้บริการ ไม่เดาค่าเอง หาก Test Email ไม่ผ่าน ให้ดู Error แบบเต็ม ตรวจ DNS, Firewall และข้อจำกัดของโฮสติ้ง เพราะบางรายบล็อกพอร์ตขาออกหรือจำกัดการเชื่อมต่อไปยัง SMTP ภายนอก
SPF, DKIM และ DMARC ต้องเช็กหลัง SMTP ส่งออกได้แล้ว
หาก SMTP Test ผ่านแต่ข้อความเข้า Spam ถูกปฏิเสธ หรือผู้รับบางโดเมนไม่ได้รับ ให้ตรวจ Email Authentication ที่ DNS ของโดเมนผู้ส่ง Google กำหนดให้ผู้ส่งเข้า Gmail ต้องตั้ง SPF หรือ DKIM และแนะนำให้ตั้ง SPF, DKIM และ DMARC ให้ครบ ส่วนผู้ส่งปริมาณมากมีข้อกำหนดเข้มขึ้น การมี Record ไม่ได้แปลว่าถูกต้อง ต้องตรวจว่าโดเมนที่ใช้ยืนยันสอดคล้องกับ From ด้วย
ALT: แผนภาพตรวจสอบโดเมนผู้ส่งด้วย SPF, DKIM และ DMARC ก่อนส่งอีเมลจาก WordPress ไปยัง Inbox
SPF ตรวจว่าเซิร์ฟเวอร์ใดมีสิทธิ์ส่งแทนโดเมน
SPF เป็น TXT Record ที่ระบุแหล่งส่งที่ได้รับอนุญาต ตรวจว่า Record รวมผู้ให้บริการ SMTP ปัจจุบันและไม่มี SPF หลาย Record ซ้ำกัน หากเว็บไซต์ส่งผ่านหลายระบบ เช่น Google Workspace, CRM และ Transactional Email ต้องรวมทุกแหล่งตามรูปแบบที่ผู้ให้บริการกำหนด โดยระวังข้อจำกัดจำนวน DNS Lookup
DKIM ใช้ลายเซ็นยืนยันว่าข้อความมาจากโดเมน
ผู้ให้บริการ SMTP จะให้ Selector และค่า Public Key สำหรับเพิ่มใน DNS จากนั้นต้องเปิด Signing ในระบบส่ง ตรวจผลจาก Header ของอีเมลทดสอบว่า DKIM ผ่านและโดเมนที่ลงลายเซ็นเป็นโดเมนที่คาดไว้ การมี Record แต่ระบบไม่ได้เซ็นข้อความจริงยังไม่ถือว่าตั้งค่าสำเร็จ
DMARC ตรวจ Alignment และกำหนดนโยบายเมื่อไม่ผ่าน
DMARC ใช้ผลของ SPF และ DKIM ร่วมกับความสอดคล้องของโดเมนใน From เริ่มจากนโยบายที่เหมาะกับสถานะระบบและเปิดรับ Aggregate Report เพื่อเห็นว่าใครกำลังส่งในนามโดเมน ก่อนเพิ่มความเข้มของ Policy ต้องสำรวจระบบส่งทั้งหมด ไม่เช่นนั้นอีเมลที่ถูกต้องจากระบบเก่าอาจถูกปฏิเสธ
แยกอาการเพื่อเลือกจุดตรวจให้ถูก
- ไม่มี Submission และไม่มี Email Log: ตรวจฟอร์ม, Validation, JavaScript, Cache และ Security ก่อน
- มี Submission แต่ไม่มี Email Log: ตรวจ Notification, เงื่อนไขการส่ง, Hook และความขัดแย้งของปลั๊กอิน
- Email Log สำเร็จแต่ SMTP Log ไม่มี: ตรวจการเชื่อมต่อ Credential และปลั๊กอิน WordPress SMTP
- SMTP รับแล้วแต่ Deferred หรือ Bounced: อ่าน Bounce Code ตรวจผู้รับ Reputation และนโยบายปลายทาง
- Delivered แต่หาไม่พบ: ตรวจ Spam, Quarantine, Inbox Rule, Forwarding และระบบกรองขององค์กร
ทำระบบสำรองเพื่อไม่ให้ Lead หายเงียบ
อีเมลแจ้งเตือนควรเป็นช่องทางเตือน ไม่ใช่ฐานข้อมูลเดียวของ Lead ให้เก็บ Submission ใน WordPress หรือ CRM อย่างมีสิทธิ์และระยะเวลาชัดเจน พร้อมมีหน้ารายการที่ทีมขายตรวจได้ หากอีเมลขัดข้อง Lead ยังถูกติดตามจากระบบหลักได้
Checklist ก่อนส่งงานให้ทีมขาย
- ส่งฟอร์มจริงและพบ Submission พร้อม Timestamp
- พบ Email Log ใน WordPress และ Message ID ใน SMTP Transaction Log
- From Email เป็นโดเมนที่ควบคุมได้ ส่วนอีเมลลูกค้าอยู่ใน Reply-To
- SPF และ DKIM ผ่าน พร้อมตรวจ DMARC Alignment จาก Header จริง
สรุป
เมื่อฟอร์ม WordPress ส่งแล้วแต่อีเมลไม่เข้า อย่าเริ่มจากเดาว่าเป็น SMTP, SPF หรือ DKIM ให้ไล่จากหลักฐานตามลำดับ: Submission → WordPress Email Log → SMTP Transaction Log → Authentication Result → Inbox หรือ Quarantine หากข้อความยังไม่ออกจาก WordPress ให้แก้ Form Notification หรือ SMTP หากส่งออกแล้วแต่ถูกปฏิเสธจึงตรวจ SPF, DKIM, DMARC, Reputation และนโยบายผู้รับ
สำหรับแนวทางดูแลเว็บไซต์ การตั้งค่า และการแก้ปัญหา WordPress เพิ่มเติม สามารถดูได้ในหมวด WordPress ของ WanTalk
