# อัตราการส่งถึงของอีเมล: วินิจฉัยเส้นทางสู่อินบ็อกซ์

URL หลัก: https://brew.new/th/blog/email-deliverability
ผู้เขียน: Brew Team
เผยแพร่: 2026-08-23
อัปเดต: 2026-09-29

การนำส่งกับการเข้าอินบ็อกซ์ไม่ใช่เรื่องเดียวกัน เซิร์ฟเวอร์ผู้รับอาจรับอีเมลไว้แล้วนำไปไว้ในสแปมก็ได้ แดชบอร์ดแคมเปญที่แสดงว่า “ส่งถึง” จึงไม่ได้พิสูจน์ว่าผู้อ่านได้เห็นอีเมลนั้น

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

## เริ่มจากการตอบกลับของเซิร์ฟเวอร์ผู้รับ

สำหรับอีเมลที่ถูกปฏิเสธหรือถูกชะลอการรับ ให้ตรวจการตอบกลับ SMTP จริงและรหัสสถานะแบบขยาย (enhanced status code) ความล้มเหลวชั่วคราวกับการปฏิเสธถาวรต้องจัดการต่างกัน [หน้าคำถามที่พบบ่อยสำหรับผู้ส่ง](https://support.google.com/mail/answer/14229414)ของ Google อธิบายไว้ทั้งสองกรณี แต่ไม่ได้บอกว่าตอนนี้การไม่ปฏิบัติตามข้อกำหนดทุกกรณีจะทำให้เกิดข้อผิดพลาดถาวร

หากอีเมลถูกรับแต่ไปอยู่ในสแปม ให้ตรวจผลการยืนยันตัวตนในเฮดเดอร์ของอีเมลที่ได้รับ ข้อมูลชื่อเสียงจากผู้ให้บริการอีเมลหากมี และการเปลี่ยนแปลงล่าสุดของกลุ่มเป้าหมายหรือปริมาณการส่ง อินบ็อกซ์ทดสอบไม่กี่กล่องช่วยวินิจฉัยปัญหาได้ แต่ไม่ได้วัดการเข้าอินบ็อกซ์ของรายชื่อทั้งหมด

### อ่านรหัสสถานะแบบขยาย

รหัสสถานะแบบขยายประกอบด้วยตัวเลข 3 ตัวคั่นด้วยจุด ตามที่กำหนดไว้ใน [RFC 3463](https://www.rfc-editor.org/rfc/rfc3463.html) ตัวเลขแรกคือคลาส รหัสที่ขึ้นต้นด้วย 4 คือความล้มเหลวชั่วคราว ซึ่งเซิร์ฟเวอร์ผู้ส่งควรลองส่งใหม่ภายหลัง ส่วนรหัสที่ขึ้นต้นด้วย 5 คือความล้มเหลวถาวร การส่งอีเมลเดิมซ้ำโดยไม่แก้ไขอะไรจึงไม่ช่วย

ตัวเลขที่สองช่วยระบุหมวดของปัญหาให้แคบลง รหัสในกลุ่ม X.1.X เกี่ยวกับที่อยู่ผู้รับ และ 5.1.1 มักหมายความว่าไม่มีกล่องจดหมายนั้นอยู่ ให้ระงับการส่งไปยังที่อยู่นั้น ส่วนรหัสในกลุ่ม X.7.X เกี่ยวกับความปลอดภัยหรือนโยบาย ซึ่งเป็นกลุ่มที่ปัญหาการยืนยันตัวตนและชื่อเสียงมักปรากฏ

Google รวบรวมการตอบกลับที่ Gmail ส่งกลับมาไว้ใน[เอกสารอ้างอิงข้อผิดพลาด SMTP](https://support.google.com/a/answer/3726730) ให้อ่านข้อความตอบกลับฉบับเต็มควบคู่กับรหัสด้วย เพราะรหัสเดียวอาจครอบคลุมหลายสาเหตุ

### หาข้อมูลชื่อเสียงจากผู้ให้บริการอีเมลได้ที่ไหน

[Google Postmaster Tools](https://postmaster.google.com/) แสดงว่า Gmail มองโดเมนผู้ส่งของคุณอย่างไร รวมถึงอัตราสแปมที่ผู้ใช้รายงานซึ่งข้อกำหนดของ Google อ้างถึง คุณยืนยันโดเมนด้วยระเบียน DNS ทั้งนี้ Gmail จะแสดงข้อมูลก็ต่อเมื่อโดเมนส่งอีเมลถึงผู้ใช้ Gmail ในแต่ละวันมากพอ ผู้ส่งรายเล็กจึงอาจเห็นแดชบอร์ดที่ว่างเปล่า

Smart Network Data Services ของ Microsoft หรือที่เรียกว่า [SNDS](https://substrate.office.com/ip-domain-management-snds/snds) รายงานข้อมูลอีเมลจาก IP ที่ระบุไปยังกล่องจดหมายของผู้ใช้ทั่วไปบน Outlook.com รวมถึงอัตราการร้องเรียนและจำนวนครั้งที่ติดกับดักสแปม คุณต้องลงทะเบียน IP ที่คุณควบคุมเอง เครื่องมือนี้จึงมีประโยชน์ที่สุดเมื่อใช้ IP เฉพาะสำหรับส่งอีเมล หากใช้ IP ร่วม ให้ถามผู้ให้บริการส่งอีเมลของคุณว่าตรวจติดตามอะไรบ้าง

ทั้งสองเครื่องมือไม่ได้บอกว่าแคมเปญใดแคมเปญหนึ่งไปตกที่ไหน แต่แสดงแนวโน้มรายวัน ซึ่งเป็นสิ่งที่คุณต้องการเมื่อปัญหาสะสมมาจากการส่งหลายครั้ง

## ตรวจตัวตนผู้ส่งจากอีเมลที่ส่งออกไปจริง

SPF ให้สิทธิ์โครงสร้างพื้นฐานที่ใช้ส่งอีเมลสำหรับโดเมนของ envelope ส่วน DKIM ลงนามอีเมลด้วยตัวตนของโดเมน และ DMARC ตรวจ alignment กับโดเมนใน From ที่ผู้รับมองเห็น พร้อมเผยแพร่นโยบายและกลไกการรายงาน แต่ไม่มีอย่างใดรับประกันว่าอีเมลจะเข้าอินบ็อกซ์

ใช้ระเบียนที่ผู้ให้บริการส่งอีเมลของคุณให้มา แล้วตรวจผลในอีเมลที่ได้รับจริง อย่าเพิ่มระเบียน SPF ที่ขัดแย้งกัน และอย่าคิดเอาเองว่าการมีระเบียน DNS พิสูจน์ได้ว่าทุกเส้นทางการส่งใช้ระเบียนนั้นอย่างถูกต้อง โครงสร้างพื้นฐานของคุณยังต้องมี reverse DNS ที่เหมาะสมและการรับส่งที่ปลอดภัยด้วย

ใน Brew ให้ทำตามขั้นตอนการยืนยันโดเมน และเพิ่มระเบียนตามที่ระบบขอ ตรวจที่อยู่ From ที่แคมเปญหรือระบบอัตโนมัติใช้จริง โดยเฉพาะเมื่อเอเจนต์ดูแลหลายแบรนด์

### ขยับ DMARC จากการเฝ้าดูไปสู่การบังคับใช้

นโยบาย DMARC คือระเบียน TXT ที่โฮสต์ `_dmarc` ของโดเมนในที่อยู่ From ให้เริ่มจาก `p=none` ซึ่งขอให้เซิร์ฟเวอร์ผู้รับไม่ต้องดำเนินการใดเป็นพิเศษกับอีเมลที่ไม่ผ่าน แต่เซิร์ฟเวอร์ผู้รับยังส่งรายงานแบบรวมไปยังที่อยู่ `rua` อยู่

```text
_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
```

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

เมื่ออีเมลที่ถูกต้องทั้งหมดผ่านแล้ว ให้ขยับไปใช้ `p=quarantine` ซึ่งขอให้เซิร์ฟเวอร์ผู้รับมองว่าอีเมลที่ไม่ผ่านนั้นน่าสงสัย โดยมักหมายถึงการนำไปไว้ในสแปม

```text
_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](https://support.google.com/mail/answer/81126) แยกข้อกำหนดสำหรับผู้ส่งทุกรายออกจากกฎที่เข้มงวดกว่าสำหรับผู้ส่งที่ส่งอีเมลถึงบัญชี Gmail ส่วนตัวราว 5,000 ฉบับต่อวัน Google กำหนดให้อัตราสแปมต่ำกว่า 0.1% และเตือนไม่ให้แตะ 0.3% ข้อกำหนดสำหรับผู้ส่งอีเมลปริมาณมากครอบคลุม SPF และ DKIM, DMARC, alignment และการยกเลิกการรับข่าวสารในคลิกเดียวสำหรับทราฟฟิกแบบสมัครรับข่าวสารที่เกี่ยวข้อง

### ข้อกำหนดของ Google สำหรับผู้ส่งทุกราย

รายการข้อกำหนดของ Google สำหรับผู้ส่งทุกราย ไม่ว่าจะส่งปริมาณเท่าใด มีดังนี้:

- ตั้งค่า SPF หรือ DKIM ให้โดเมนผู้ส่งของคุณ
- ให้โดเมนหรือ IP ที่ใช้ส่งมีระเบียน DNS แบบ forward และ reverse ที่ถูกต้อง
- ส่งผ่านการเชื่อมต่อแบบ TLS
- รักษาอัตราสแปมที่รายงานใน Postmaster Tools ให้ต่ำกว่าเกณฑ์ข้างต้น
- จัดรูปแบบอีเมลตาม RFC 5322

### ข้อกำหนดเพิ่มเติมสำหรับผู้ส่งอีเมลปริมาณมาก

ผู้ส่งอีเมลปริมาณมากต้องทำสิ่งต่อไปนี้ด้วย:

- ตั้งค่าทั้ง SPF และ DKIM
- เผยแพร่ระเบียน DMARC สำหรับโดเมนผู้ส่ง โดย Google ยอมรับนโยบาย `p=none`
- ทำให้โดเมนใน From ตรงกับ (align) โดเมนของ SPF หรือโดเมนของ DKIM อย่างใดอย่างหนึ่ง
- รองรับการยกเลิกการรับข่าวสารในคลิกเดียวสำหรับอีเมลการตลาดและอีเมลที่ผู้รับสมัครรับไว้ และใส่ลิงก์ยกเลิกการรับข่าวสารที่มองเห็นได้ชัดเจนในเนื้อหาอีเมล

Google นับอีเมลจากโดเมนหลักเดียวกันรวมกันเมื่อพิจารณาเกณฑ์ และโดเมนที่เคยข้ามเกณฑ์แล้วครั้งหนึ่งจะคงสถานะผู้ส่งอีเมลปริมาณมากไว้ [หน้าคำถามที่พบบ่อยสำหรับผู้ส่ง](https://support.google.com/mail/answer/14229414)ของ Google อธิบายวิธีนับไว้

[แนวทางของ Yahoo](https://senders.yahooinc.com/best-practices/) ครอบคลุมการยืนยันตัวตน การร้องเรียน และการยกเลิกการรับข่าวสารเช่นกัน แต่ Yahoo ไม่ได้เผยแพร่เกณฑ์ตัวเลขสำหรับผู้ส่งอีเมลปริมาณมากแบบเดียวกัน ให้ดู[หน้าคำถามที่พบบ่อย](https://senders.yahooinc.com/faqs/)ของ Yahoo แทนการนำตัวเลขของ Gmail ไปใช้กับผู้ให้บริการทุกราย

### Microsoft Outlook.com

Microsoft [ประกาศเมื่อปี 2025](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730) ว่าโดเมนที่ส่งอีเมลมากกว่า 5,000 ฉบับต่อวันไปยังกล่องจดหมายของผู้ใช้ทั่วไป ได้แก่ที่อยู่ outlook.com, hotmail.com และ live.com ต้องผ่าน SPF และ DKIM และต้องเผยแพร่ DMARC ทั้งนี้นโยบาย DMARC เป็น `p=none` ได้ และโดเมนใน From ต้อง align กับ SPF หรือ DKIM

ตรวจสอบแนวทางของผู้ให้บริการอีเมลเมื่อ 28 กันยายน 2026 หากกำลังวินิจฉัยเหตุขัดข้องครั้งใหม่ ให้ตรวจหน้าที่ลิงก์ไว้อีกครั้ง

## ทดสอบการยกเลิกการรับข่าวสารจากการทำงานจริง

การยกเลิกการรับข่าวสารในคลิกเดียวตาม [RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.html) เป็นกลไกที่ใช้เฮดเดอร์และ HTTPS POST ส่วนลิงก์ที่มองเห็นได้ในส่วนท้ายอีเมลก็มีประโยชน์และเป็นสิ่งที่กฎที่เกี่ยวข้องกำหนด แต่หน้าตั้งค่าการรับอีเมลเพียงอย่างเดียวไม่ได้ทำให้เป็นไปตามโปรโตคอลนี้

อีเมลที่รองรับการยกเลิกการรับข่าวสารในคลิกเดียวจะมีเฮดเดอร์ 2 รายการ:

```text
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 แบบคลิกเดียว

ยืนยันว่าการยกเลิกการรับอีเมลการตลาดจะหยุดการส่งอีเมลการตลาดครั้งต่อ ๆ ไปได้ในทุกช่องทางที่คุณใช้ เก็บบันทึกการระงับการส่งไว้ให้ครบเมื่อนำเข้าผู้ติดต่อหรือเปลี่ยนแพลตฟอร์ม และแยก[อีเมลธุรกรรม](/th/blog/transactional-emails)ที่จำเป็นออกไปทั้งในแง่วัตถุประสงค์และการตั้งค่าการส่ง

## ตรวจกลุ่มเป้าหมายก่อนเพิ่มปริมาณการส่ง

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

ไม่มีอายุของรายชื่อ สัดส่วนรูปภาพต่อข้อความ หรือคำต้องห้ามใดที่ใช้ได้กับทุกกรณีและรับประกันการส่งถึง การเพิ่มปริมาณการส่งอย่างกะทันหันไปยังรายชื่อที่คุณยังไม่เข้าใจดีพอเป็นปัญหาที่ร้ายแรงกว่าการใช้คำว่า “ฟรี”

หาก[เอเจนต์เป็นผู้ส่งแคมเปญ](/th/blog/agent-email-deliverability) การตรวจเหล่านี้ก็ยังใช้เหมือนเดิม ใช้ข้อเท็จจริงที่ตรวจสอบแล้ว กลุ่มเป้าหมายที่เกี่ยวข้อง และที่อยู่ตอบกลับที่มีคนคอยดูแล แก้ไขสาเหตุที่พบ ส่งทดสอบแบบควบคุม และตรวจการตอบกลับจากผู้ให้บริการอีเมลก่อนขยายการส่งอีกครั้ง