THAI DATA CLOUD
Cloud Email Hosting (WorkMail) Manual

ทำความเข้าใจอีเมลตีกลับ (Bounce) และ SMTP Error Code

อ่านข้อความอีเมลตีกลับให้เป็น แยก Soft Bounce กับ Hard Bounce และรู้ความหมายของ SMTP Error Code ที่พบบ่อย พร้อมวิธีแก้ไขในแต่ละกรณี

โดย ทีมงาน THAI DATA CLOUD อัปเดต อ่าน 11 นาที เข้าชม 4 ครั้ง

แชร์FacebookXLINELinkedIn
SMTP Error Code — ทำความเข้าใจอีเมลตีกลับ (Bounce) และ SMTP Error Code
ทำความเข้าใจอีเมลตีกลับ (Bounce) และ SMTP Error Code

คำตอบสั้น ๆ: อ่านข้อความอีเมลตีกลับให้เป็น แยก Soft Bounce กับ Hard Bounce และรู้ความหมายของ SMTP Error Code ที่พบบ่อย พร้อมวิธีแก้ไขในแต่ละกรณี

คู่มือนี้อธิบาย SMTP Error Code ทีละขั้นตอน พร้อมคำสั่งที่ใช้ได้จริงและปัญหาที่พบบ่อย

เมื่อส่งอีเมลออกไปแล้วได้รับข้อความตอบกลับจากระบบ เช่น "Mail Delivery Failed", "Undeliverable" หรือ "Delivery Status Notification (Failure)" แปลว่าอีเมลฉบับนั้นถูกตีกลับ (Bounce) ข้อความตีกลับนี้เรียกอีกชื่อว่า NDR (Non-Delivery Report) และทุกฉบับมีรหัส SMTP Error Code ที่บอกสาเหตุไว้ชัดเจน หากอ่านรหัสเป็น จะรู้ทันทีว่าปัญหาอยู่ที่ฝั่งผู้ส่ง ฝั่งผู้รับ หรือเป็นแค่ปัญหาชั่วคราวที่ระบบจะลองส่งซ้ำเอง

คู่มือนี้อธิบายโครงสร้างของอีเมลตีกลับ ความหมายของรหัสที่พบบ่อย และวิธีแก้ไขในแต่ละกรณี ใช้ได้กับอีเมลบน Web Hosting (Plesk, DirectAdmin), Cloud Server ที่ติดตั้ง Mail Server เอง รวมถึง Microsoft 365 และ Google Workspace เพราะรหัสเหล่านี้เป็นมาตรฐานเดียวกันตาม RFC 5321 และ RFC 3463

สิ่งที่ต้องเตรียม (SMTP Error Code)

  • ข้อความตีกลับฉบับเต็ม อย่าเพิ่งลบทิ้ง และควรเปิดดูแบบเต็ม ไม่ใช่เฉพาะบรรทัดแรก
  • หากดูแล Mail Server เอง: สิทธิ์ root หรือ sudo เพื่ออ่าน Log ของ Postfix หรือ Exim
  • สิทธิ์แก้ไข DNS ของโดเมน หากสาเหตุเกี่ยวกับ SPF, DKIM, DMARC หรือ PTR

ขั้นตอนที่ 1: หาบรรทัดสำคัญในอีเมลตีกลับ (SMTP Error Code)

ข้อความตีกลับมักขึ้นต้นด้วยคำอธิบายทั่วไปที่ไม่ค่อยมีประโยชน์ ให้เลื่อนลงไปหาส่วนที่เป็นรายละเอียดทางเทคนิค ซึ่งหน้าตาจะคล้ายตัวอย่างนี้

Reporting-MTA: dns; mail.example.com
Final-Recipient: rfc822; [email protected]
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx1.example.net
Diagnostic-Code: smtp; 550 5.1.1 <[email protected]>: Recipient address rejected: User unknown in virtual mailbox table

บรรทัดที่ต้องอ่านมีดังนี้

  • Final-Recipient ที่อยู่ปลายทางที่ส่งไม่ถึง ตรวจดูก่อนเลยว่าพิมพ์ถูกหรือไม่
  • Action ถ้าเป็น failed คือส่งไม่สำเร็จถาวร ถ้าเป็น delayed คือยังรอส่งซ้ำอยู่
  • Remote-MTA เซิร์ฟเวอร์ที่ปฏิเสธอีเมล บอกได้ว่าเป็นฝั่งผู้รับหรือเซิร์ฟเวอร์ของเราเอง
  • Diagnostic-Code ข้อความจริงจากเซิร์ฟเวอร์ปลายทาง ประกอบด้วยรหัสสามหลัก รหัสแบบขยาย และคำอธิบาย ส่วนนี้สำคัญที่สุด

ขั้นตอนที่ 2: แยกให้ออกว่าเป็นปัญหาชั่วคราวหรือถาวร (SMTP Error Code)

ตัวเลขหลักแรกของรหัสบอกประเภทของปัญหา

หลักแรกความหมายสิ่งที่ระบบทำต่อ
2xxสำเร็จ เช่น 250 OKส่งถึงเซิร์ฟเวอร์ปลายทางแล้ว
4xxล้มเหลวชั่วคราว (Soft Bounce)เซิร์ฟเวอร์ผู้ส่งเก็บไว้ในคิวและลองส่งซ้ำ Postfix มีค่าเริ่มต้นให้ลองซ้ำได้นานถึง 5 วัน ระหว่างนั้นผู้ส่งอาจได้ข้อความแจ้งว่า "delayed"
5xxล้มเหลวถาวร (Hard Bounce)ไม่ลองซ้ำ ต้องแก้สาเหตุก่อนแล้วส่งใหม่เอง

รหัสแบบขยาย (Enhanced Status Code) เช่น 5.1.1 อ่านเป็นสามส่วน ส่วนแรกคือชั่วคราวหรือถาวรเหมือนเดิม ส่วนที่สองคือหมวด: 1 เกี่ยวกับที่อยู่ผู้รับ, 2 เกี่ยวกับกล่องจดหมาย, 3 เกี่ยวกับระบบเมลปลายทาง, 4 เกี่ยวกับเครือข่ายและการส่งต่อ, 5 เกี่ยวกับโปรโตคอล และ 7 เกี่ยวกับความปลอดภัยหรือนโยบาย ส่วนที่สามคือรายละเอียดภายในหมวดนั้น

ขั้นตอนที่ 3: เทียบรหัสที่พบบ่อยและวิธีแก้ (SMTP Error Code)

รหัสความหมายวิธีแก้
550 5.1.1ไม่มีผู้ใช้นี้ที่ปลายทาง (User unknown)ตรวจการสะกดที่อยู่ ถามผู้รับว่าอีเมลยังใช้งานอยู่หรือไม่
5.1.2 หรือ "Host not found"หาโดเมนปลายทางไม่เจอ หรือโดเมนไม่มี MX Recordตรวจการสะกดโดเมน เช่น gmial.com หรือโดเมนผู้รับหมดอายุ
452 4.2.2 หรือ 552 5.2.2กล่องจดหมายผู้รับเต็มแจ้งผู้รับผ่านช่องทางอื่นให้ล้างกล่องจดหมาย แล้วส่งใหม่
552 5.3.4อีเมลใหญ่เกินกว่าที่ปลายทางยอมรับลดขนาดไฟล์แนบ หรือส่งเป็นลิงก์ดาวน์โหลดแทน
421 4.7.0 หรือ 451 4.7.1ปลายทางขอให้ชะลอการส่ง (Rate limit หรือ Greylisting)โดยมากไม่ต้องทำอะไร ระบบจะลองส่งซ้ำเอง หากเกิดต่อเนื่องหลายชั่วโมงให้ดูชื่อเสียงของ IP
530 5.7.0 หรือ 535 5.7.8ต้องยืนยันตัวตนก่อนส่ง หรือชื่อผู้ใช้และรหัสผ่านผิดตรวจการตั้งค่า SMTP Authentication ในโปรแกรมอีเมล ใช้ชื่อผู้ใช้เป็นอีเมลเต็ม
550 5.7.1 "Relaying denied"เซิร์ฟเวอร์ไม่ยอมส่งต่อให้ เพราะไม่ได้ยืนยันตัวตนเปิด "Outgoing server requires authentication" ในโปรแกรมอีเมล
550 5.7.1 พร้อมชื่อ Blacklist เช่น SpamhausIP ของเซิร์ฟเวอร์ผู้ส่งติด Blacklistดูคู่มือ ตรวจสอบและขอถอด IP ออกจาก Blacklist อีเมล
550 5.7.25 (Gmail)IP ผู้ส่งไม่มี PTR Record (Reverse DNS)ตั้งค่า PTR ของ IP ให้ชี้กลับมาที่ชื่อ Hostname ของ Mail Server
550 5.7.26 (Gmail) หรือข้อความที่มีคำว่า DMARCอีเมลไม่ผ่าน SPF/DKIM/DMARCตรวจ Record ตามคู่มือ ตั้งค่า SPF, DKIM และ DMARC
554 5.7.1 พร้อมคำว่า spam หรือ policyเนื้อหาหรือผู้ส่งถูกระบบกรองสแปมปฏิเสธตรวจเนื้อหา ลิงก์ และไฟล์แนบ รวมถึงการยืนยันตัวตนของโดเมน
550 5.7.520 (Microsoft 365)องค์กรไม่อนุญาตให้ Forward อีเมลออกนอกองค์กรอัตโนมัติดูคู่มือ ตั้งค่า Forward อีเมลจาก Microsoft 365 Admin Center

หมายเหตุ: ผู้ให้บริการแต่ละรายเขียนคำอธิบายต่อท้ายรหัสต่างกัน และบางรายใช้รหัสเดียวกันกับหลายสาเหตุ เช่น 550 5.7.1 ให้อ่านข้อความภาษาอังกฤษที่ตามหลังรหัสประกอบทุกครั้ง มักมีลิงก์ไปยังหน้าอธิบายของผู้ให้บริการนั้นแนบมาด้วย

ขั้นตอนที่ 4: ดู Log บนเซิร์ฟเวอร์ (กรณีดูแล Mail Server เอง)

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

Postfix (รวมถึง Plesk) บน Ubuntu

sudo grep "[email protected]" /var/log/mail.log | tail -n 20

Postfix บน AlmaLinux/Rocky Linux

sudo grep "[email protected]" /var/log/maillog | tail -n 20

Exim (DirectAdmin)

sudo grep "[email protected]" /var/log/exim/mainlog | tail -n 20

ใน Log ของ Postfix ให้ดูค่า status= ซึ่งเป็นได้ทั้ง sent, deferred (4xx ยังรอส่งซ้ำ) และ bounced (5xx) ตามด้วยข้อความจากปลายทางในวงเล็บ บนระบบที่ใช้ systemd journal เป็นหลักและไม่มีไฟล์ข้างต้น ใช้ sudo journalctl -u postfix --since "1 hour ago" แทน

ดูอีเมลที่ค้างอยู่ในคิว

# Postfix
sudo postqueue -p

# Exim
sudo exim -bp

หลังแก้สาเหตุแล้ว สั่งให้ลองส่งคิวที่ค้างทันทีด้วย sudo postqueue -f (Postfix) หรือ sudo exim -qff (Exim)

ตรวจสอบผลลัพธ์

  • ส่งอีเมลทดสอบไปยังที่อยู่เดิมอีกครั้ง หากไม่มีข้อความตีกลับภายใน 10-15 นาที และผู้รับยืนยันว่าได้รับ ถือว่าแก้ไขสำเร็จ
  • สำหรับผู้ดูแลเซิร์ฟเวอร์ ใน Log ต้องเห็น status=sent (250 ...) สำหรับผู้รับรายนั้น
  • หากสาเหตุเป็นเรื่อง SPF/DKIM/DMARC ให้ส่งไปที่ Gmail แล้วเปิด "Show original" ดูว่าผ่านทั้งสามรายการ วิธีอ่านอยู่ในคู่มือ อ่าน Email Header

ปัญหาที่พบบ่อยเกี่ยวกับ SMTP Error Code

ได้รับอีเมลตีกลับจากอีเมลที่ไม่ได้ส่ง

เรียกว่า Backscatter เกิดจากผู้ไม่หวังดีปลอมที่อยู่ของคุณเป็นผู้ส่ง แล้วปลายทางตีกลับมาหาคุณ ให้เปิด Header ของข้อความตีกลับ ดูส่วนต้นฉบับที่แนบมา หาก IP ผู้ส่งไม่ใช่เซิร์ฟเวอร์ของคุณ แปลว่าไม่ได้ส่งจากระบบคุณ การตั้ง SPF และ DMARC ให้ถูกต้องช่วยให้ปลายทางปฏิเสธอีเมลปลอมตั้งแต่แรก แต่หากพบว่าส่งจากบัญชีของคุณจริง ให้เปลี่ยนรหัสผ่านทันที

ได้แต่ข้อความ "delayed" ซ้ำหลายวัน

เป็นรหัส 4xx ที่ไม่หาย มักเกิดจากเซิร์ฟเวอร์ปลายทางล่ม หรือปลายทางจำกัดอัตราการรับจาก IP ของคุณ ลองส่งไปยังโดเมนอื่นเพื่อเปรียบเทียบ ถ้าส่งที่อื่นได้ปกติ ปัญหาอยู่ที่ปลายทาง ให้แจ้งผู้รับ

ส่งถึงบางโดเมนไม่ได้ แต่โดเมนอื่นได้

มักเป็นนโยบายเฉพาะของปลายทาง เช่น Gmail และ Microsoft เข้มงวดเรื่องการยืนยันตัวตนของโดเมนมากกว่าเซิร์ฟเวอร์ทั่วไป ดูรหัสกลุ่ม 5.7.x แล้วแก้ตามตารางด้านบน

อ่าน Log แล้วไม่พบอีเมลฉบับนั้นเลย

แปลว่าอีเมลไม่ได้ออกจากเซิร์ฟเวอร์นี้ อาจตั้งค่า SMTP ในโปรแกรมผิดเซิร์ฟเวอร์ หรือถูกปฏิเสธตั้งแต่ขั้นยืนยันตัวตน ดูแนวทางไล่ตรวจทีละจุดในคู่มือ อีเมลส่งไม่ออกหรือไม่ได้รับ: วิธีตรวจสอบเบื้องต้น

หากอ่านรหัสแล้วยังไม่แน่ใจสาเหตุ หรือแก้ไขแล้วอีเมลยังตีกลับ สามารถส่งข้อความตีกลับฉบับเต็มมาให้ทีมงาน THAI DATA CLOUD ช่วยตรวจสอบได้ที่ https://thaidata.cloud/contact/

สรุปขั้นตอน SMTP Error Code

ทบทวน SMTP Error Code ทั้งหมดตามลำดับ ก่อนนำไปใช้กับระบบจริง

  1. หาบรรทัดสำคัญในอีเมลตีกลับ (SMTP Error Code)
  2. แยกให้ออกว่าเป็นปัญหาชั่วคราวหรือถาวร (SMTP Error Code)
  3. เทียบรหัสที่พบบ่อยและวิธีแก้ (SMTP Error Code)
  4. ดู Log บนเซิร์ฟเวอร์ (กรณีดูแล Mail Server เอง)

เมื่อทำครบทุกข้อแล้ว SMTP Error Code จะพร้อมใช้งาน หากผลลัพธ์ไม่เป็นไปตามที่คาด ให้ย้อนกลับไปดูหัวข้อปัญหาที่พบบ่อยด้านบน ซึ่งรวบรวมกรณีที่พบจริงจากการใช้งาน SMTP Error Code ไว้แล้ว

อ่านเพิ่มเติมเกี่ยวกับ SMTP Error Code

แชร์FacebookXLINELinkedIn

มีคำถามเรื่องบริการ? ติดต่อทีมงาน