ตรวจการยืนยันตัวตน การตอบกลับจากผู้ให้บริการอีเมล คุณภาพกลุ่มเป้าหมาย และการทำงานของการยกเลิกการรับข่าวสาร เพื่อเข้าใจว่าทำไมอีเมลจึงถูกปฏิเสธหรือเข้าสแปม
การนำส่งกับการเข้าอินบ็อกซ์ไม่ใช่เรื่องเดียวกัน เซิร์ฟเวอร์ผู้รับอาจรับอีเมลไว้แล้วนำไปไว้ในสแปมก็ได้ แดชบอร์ดแคมเปญที่แสดงว่า “ส่งถึง” จึงไม่ได้พิสูจน์ว่าผู้อ่านได้เห็นอีเมลนั้น
เมื่อเกิดปัญหา ให้รวบรวมหลักฐานก่อนจะแก้ข้อความหรือเปลี่ยนผู้ให้บริการ ส่วนที่มีปัญหาอาจเป็นการยืนยันตัวตน ชื่อเสียงผู้ส่ง กลุ่มเป้าหมาย หรือตัวอีเมลเอง
สำหรับอีเมลที่ถูกปฏิเสธหรือถูกชะลอการรับ ให้ตรวจการตอบกลับ SMTP จริงและรหัสสถานะแบบขยาย (enhanced status code) ความล้มเหลวชั่วคราวกับการปฏิเสธถาวรต้องจัดการต่างกัน หน้าคำถามที่พบบ่อยสำหรับผู้ส่งของ Google อธิบายไว้ทั้งสองกรณี แต่ไม่ได้บอกว่าตอนนี้การไม่ปฏิบัติตามข้อกำหนดทุกกรณีจะทำให้เกิดข้อผิดพลาดถาวร
หากอีเมลถูกรับแต่ไปอยู่ในสแปม ให้ตรวจผลการยืนยันตัวตนในเฮดเดอร์ของอีเมลที่ได้รับ ข้อมูลชื่อเสียงจากผู้ให้บริการอีเมลหากมี และการเปลี่ยนแปลงล่าสุดของกลุ่มเป้าหมายหรือปริมาณการส่ง อินบ็อกซ์ทดสอบไม่กี่กล่องช่วยวินิจฉัยปัญหาได้ แต่ไม่ได้วัดการเข้าอินบ็อกซ์ของรายชื่อทั้งหมด
รหัสสถานะแบบขยายประกอบด้วยตัวเลข 3 ตัวคั่นด้วยจุด ตามที่กำหนดไว้ใน RFC 3463 ตัวเลขแรกคือคลาส รหัสที่ขึ้นต้นด้วย 4 คือความล้มเหลวชั่วคราว ซึ่งเซิร์ฟเวอร์ผู้ส่งควรลองส่งใหม่ภายหลัง ส่วนรหัสที่ขึ้นต้นด้วย 5 คือความล้มเหลวถาวร การส่งอีเมลเดิมซ้ำโดยไม่แก้ไขอะไรจึงไม่ช่วย
ตัวเลขที่สองช่วยระบุหมวดของปัญหาให้แคบลง รหัสในกลุ่ม X.1.X เกี่ยวกับที่อยู่ผู้รับ และ 5.1.1 มักหมายความว่าไม่มีกล่องจดหมายนั้นอยู่ ให้ระงับการส่งไปยังที่อยู่นั้น ส่วนรหัสในกลุ่ม X.7.X เกี่ยวกับความปลอดภัยหรือนโยบาย ซึ่งเป็นกลุ่มที่ปัญหาการยืนยันตัวตนและชื่อเสียงมักปรากฏ
Google รวบรวมการตอบกลับที่ Gmail ส่งกลับมาไว้ในเอกสารอ้างอิงข้อผิดพลาด SMTP ให้อ่านข้อความตอบกลับฉบับเต็มควบคู่กับรหัสด้วย เพราะรหัสเดียวอาจครอบคลุมหลายสาเหตุ
Google Postmaster Tools แสดงว่า Gmail มองโดเมนผู้ส่งของคุณอย่างไร รวมถึงอัตราสแปมที่ผู้ใช้รายงานซึ่งข้อกำหนดของ Google อ้างถึง คุณยืนยันโดเมนด้วยระเบียน DNS ทั้งนี้ Gmail จะแสดงข้อมูลก็ต่อเมื่อโดเมนส่งอีเมลถึงผู้ใช้ Gmail ในแต่ละวันมากพอ ผู้ส่งรายเล็กจึงอาจเห็นแดชบอร์ดที่ว่างเปล่า
Smart Network Data Services ของ Microsoft หรือที่เรียกว่า SNDS รายงานข้อมูลอีเมลจาก IP ที่ระบุไปยังกล่องจดหมายของผู้ใช้ทั่วไปบน Outlook.com รวมถึงอัตราการร้องเรียนและจำนวนครั้งที่ติดกับดักสแปม คุณต้องลงทะเบียน IP ที่คุณควบคุมเอง เครื่องมือนี้จึงมีประโยชน์ที่สุดเมื่อใช้ IP เฉพาะสำหรับส่งอีเมล หากใช้ IP ร่วม ให้ถามผู้ให้บริการส่งอีเมลของคุณว่าตรวจติดตามอะไรบ้าง
ทั้งสองเครื่องมือไม่ได้บอกว่าแคมเปญใดแคมเปญหนึ่งไปตกที่ไหน แต่แสดงแนวโน้มรายวัน ซึ่งเป็นสิ่งที่คุณต้องการเมื่อปัญหาสะสมมาจากการส่งหลายครั้ง
SPF ให้สิทธิ์โครงสร้างพื้นฐานที่ใช้ส่งอีเมลสำหรับโดเมนของ envelope ส่วน DKIM ลงนามอีเมลด้วยตัวตนของโดเมน และ DMARC ตรวจ alignment กับโดเมนใน From ที่ผู้รับมองเห็น พร้อมเผยแพร่นโยบายและกลไกการรายงาน แต่ไม่มีอย่างใดรับประกันว่าอีเมลจะเข้าอินบ็อกซ์
ใช้ระเบียนที่ผู้ให้บริการส่งอีเมลของคุณให้มา แล้วตรวจผลในอีเมลที่ได้รับจริง อย่าเพิ่มระเบียน SPF ที่ขัดแย้งกัน และอย่าคิดเอาเองว่าการมีระเบียน DNS พิสูจน์ได้ว่าทุกเส้นทางการส่งใช้ระเบียนนั้นอย่างถูกต้อง โครงสร้างพื้นฐานของคุณยังต้องมี reverse DNS ที่เหมาะสมและการรับส่งที่ปลอดภัยด้วย
ใน Brew ให้ทำตามขั้นตอนการยืนยันโดเมน และเพิ่มระเบียนตามที่ระบบขอ ตรวจที่อยู่ From ที่แคมเปญหรือระบบอัตโนมัติใช้จริง โดยเฉพาะเมื่อเอเจนต์ดูแลหลายแบรนด์
นโยบาย DMARC คือระเบียน TXT ที่โฮสต์ _dmarc ของโดเมนในที่อยู่ From ให้เริ่มจาก p=none ซึ่งขอให้เซิร์ฟเวอร์ผู้รับไม่ต้องดำเนินการใดเป็นพิเศษกับอีเมลที่ไม่ผ่าน แต่เซิร์ฟเวอร์ผู้รับยังส่งรายงานแบบรวมไปยังที่อยู่ rua อยู่
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"รายงานจะแสดงทุกแหล่งที่ส่งอีเมลในนามโดเมนของคุณ และบอกว่าแต่ละแหล่งผ่าน SPF หรือ DKIM แบบ aligned หรือไม่ คุณน่าจะเจอเครื่องมือที่ลืมไปแล้ว เช่น ระบบเรียกเก็บเงินหรือระบบเฮลป์เดสก์ ให้แก้ไขหรือนำแหล่งส่งที่ไม่ผ่านออกทีละแหล่ง
เมื่ออีเมลที่ถูกต้องทั้งหมดผ่านแล้ว ให้ขยับไปใช้ p=quarantine ซึ่งขอให้เซิร์ฟเวอร์ผู้รับมองว่าอีเมลที่ไม่ผ่านนั้นน่าสงสัย โดยมักหมายถึงการนำไปไว้ในสแปม
_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"นโยบายที่เข้มงวดที่สุดคือ p=reject ซึ่งขอให้เซิร์ฟเวอร์ผู้รับปฏิเสธอีเมลที่ไม่ผ่าน ให้ขยับไปใช้หลังจากใช้ quarantine มาสักระยะโดยไม่มีอีเมลที่ถูกต้องรายการใดไม่ผ่านเท่านั้น อ่านรายงานต่อไปในทุกขั้น เพราะเครื่องมือใหม่ที่เริ่มส่งอีเมลในนามโดเมนของคุณจะปรากฏในรายงานก่อน
ข้อยกเว้นคือซับโดเมนสำหรับส่งอีเมลโดยเฉพาะ เช่น mail.example.com เมื่อไม่มีบริการอื่นส่งจากซับโดเมนนั้น และผู้ให้บริการของคุณยืนยัน SPF และ DKIM แล้ว ซับโดเมนนั้นเริ่มที่ p=reject ได้เลย Brew แนะนำ p=reject สำหรับซับโดเมนเฉพาะที่ Brew ตั้งค่าให้ และ p=none สำหรับโดเมนหลักที่บริการอื่นอาจส่งอีเมลด้วย
แนวทางของ Google แยกข้อกำหนดสำหรับผู้ส่งทุกรายออกจากกฎที่เข้มงวดกว่าสำหรับผู้ส่งที่ส่งอีเมลถึงบัญชี Gmail ส่วนตัวราว 5,000 ฉบับต่อวัน Google กำหนดให้อัตราสแปมต่ำกว่า 0.1% และเตือนไม่ให้แตะ 0.3% ข้อกำหนดสำหรับผู้ส่งอีเมลปริมาณมากครอบคลุม SPF และ DKIM, DMARC, alignment และการยกเลิกการรับข่าวสารในคลิกเดียวสำหรับทราฟฟิกแบบสมัครรับข่าวสารที่เกี่ยวข้อง
รายการข้อกำหนดของ Google สำหรับผู้ส่งทุกราย ไม่ว่าจะส่งปริมาณเท่าใด มีดังนี้:
ผู้ส่งอีเมลปริมาณมากต้องทำสิ่งต่อไปนี้ด้วย:
p=noneGoogle นับอีเมลจากโดเมนหลักเดียวกันรวมกันเมื่อพิจารณาเกณฑ์ และโดเมนที่เคยข้ามเกณฑ์แล้วครั้งหนึ่งจะคงสถานะผู้ส่งอีเมลปริมาณมากไว้ หน้าคำถามที่พบบ่อยสำหรับผู้ส่งของ Google อธิบายวิธีนับไว้
แนวทางของ Yahoo ครอบคลุมการยืนยันตัวตน การร้องเรียน และการยกเลิกการรับข่าวสารเช่นกัน แต่ Yahoo ไม่ได้เผยแพร่เกณฑ์ตัวเลขสำหรับผู้ส่งอีเมลปริมาณมากแบบเดียวกัน ให้ดูหน้าคำถามที่พบบ่อยของ Yahoo แทนการนำตัวเลขของ Gmail ไปใช้กับผู้ให้บริการทุกราย
Microsoft ประกาศเมื่อปี 2025 ว่าโดเมนที่ส่งอีเมลมากกว่า 5,000 ฉบับต่อวันไปยังกล่องจดหมายของผู้ใช้ทั่วไป ได้แก่ที่อยู่ outlook.com, hotmail.com และ live.com ต้องผ่าน SPF และ DKIM และต้องเผยแพร่ DMARC ทั้งนี้นโยบาย DMARC เป็น p=none ได้ และโดเมนใน From ต้อง align กับ SPF หรือ DKIM
ตรวจสอบแนวทางของผู้ให้บริการอีเมลเมื่อ 28 กันยายน 2026 หากกำลังวินิจฉัยเหตุขัดข้องครั้งใหม่ ให้ตรวจหน้าที่ลิงก์ไว้อีกครั้ง
การยกเลิกการรับข่าวสารในคลิกเดียวตาม RFC 8058 เป็นกลไกที่ใช้เฮดเดอร์และ HTTPS POST ส่วนลิงก์ที่มองเห็นได้ในส่วนท้ายอีเมลก็มีประโยชน์และเป็นสิ่งที่กฎที่เกี่ยวข้องกำหนด แต่หน้าตั้งค่าการรับอีเมลเพียงอย่างเดียวไม่ได้ทำให้เป็นไปตามโปรโตคอลนี้
อีเมลที่รองรับการยกเลิกการรับข่าวสารในคลิกเดียวจะมีเฮดเดอร์ 2 รายการ:
List-Unsubscribe: <https://example.com/unsubscribe/opaque-token>, <mailto:unsubscribe@example.com?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-Clickเมื่อผู้อ่านคลิกยกเลิกการรับข่าวสารในอินบ็อกซ์ ผู้ให้บริการอีเมลจะส่ง POST ไปยัง URL แบบ HTTPS พร้อมเนื้อหา List-Unsubscribe=One-Click ส่วนที่อยู่ mailto: เป็นทางเลือกสำหรับโปรแกรมอีเมลที่ไม่รองรับแบบคลิกเดียว RFC 8058 ยังกำหนดให้ต้องมีลายเซ็น DKIM ที่ถูกต้องและครอบคลุมเฮดเดอร์ทั้งสองรายการ ให้ทำ URL ให้เฉพาะเจาะจงกับผู้รับแต่ละรายและเดาได้ยาก ระบบสแกนความปลอดภัยมักดึงลิงก์ในอีเมลขาเข้า คำขอ GET ธรรมดาไปยัง URL นั้นจึงไม่ควรทำให้ใครถูกยกเลิกการรับข่าวสาร
Brew เพิ่มเฮดเดอร์ List-Unsubscribe และ List-Unsubscribe-Post ให้กับการส่งอีเมลการตลาด โดยชี้ไปยัง URL แบบ HTTPS ที่ลงนามแล้วและเฉพาะสำหรับผู้รับแต่ละราย ซึ่งรับ POST แบบคลิกเดียว
ยืนยันว่าการยกเลิกการรับอีเมลการตลาดจะหยุดการส่งอีเมลการตลาดครั้งต่อ ๆ ไปได้ในทุกช่องทางที่คุณใช้ เก็บบันทึกการระงับการส่งไว้ให้ครบเมื่อนำเข้าผู้ติดต่อหรือเปลี่ยนแพลตฟอร์ม และแยกอีเมลธุรกรรมที่จำเป็นออกไปทั้งในแง่วัตถุประสงค์และการตั้งค่าการส่ง
ตรวจว่าที่อยู่อีเมลมาจากไหน และผู้คนคาดหวังอะไรตอนสมัคร นำที่อยู่ที่ไม่ถูกต้องออกผ่านกระบวนการระงับการส่งของผู้ให้บริการ ตรวจสอบเมื่อการร้องเรียนพุ่งสูงขึ้น และหลีกเลี่ยงการส่งซ้ำถึงผู้รับเพียงเพราะระบบติดตามบอกว่าพวกเขาไม่ได้เปิดอ่าน
ไม่มีอายุของรายชื่อ สัดส่วนรูปภาพต่อข้อความ หรือคำต้องห้ามใดที่ใช้ได้กับทุกกรณีและรับประกันการส่งถึง การเพิ่มปริมาณการส่งอย่างกะทันหันไปยังรายชื่อที่คุณยังไม่เข้าใจดีพอเป็นปัญหาที่ร้ายแรงกว่าการใช้คำว่า “ฟรี”
หากเอเจนต์เป็นผู้ส่งแคมเปญ การตรวจเหล่านี้ก็ยังใช้เหมือนเดิม ใช้ข้อเท็จจริงที่ตรวจสอบแล้ว กลุ่มเป้าหมายที่เกี่ยวข้อง และที่อยู่ตอบกลับที่มีคนคอยดูแล แก้ไขสาเหตุที่พบ ส่งทดสอบแบบควบคุม และตรวจการตอบกลับจากผู้ให้บริการอีเมลก่อนขยายการส่งอีกครั้ง
