ทำความเข้าใจอีเมลตีกลับ (Bounce) และ 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
สิ่งที่ต้องเตรียม
- ข้อความตีกลับฉบับเต็ม อย่าเพิ่งลบทิ้ง และควรเปิดดูแบบเต็ม ไม่ใช่เฉพาะบรรทัดแรก
- หากดูแล Mail Server เอง: สิทธิ์ root หรือ
sudoเพื่ออ่าน Log ของ Postfix หรือ Exim - สิทธิ์แก้ไข DNS ของโดเมน หากสาเหตุเกี่ยวกับ SPF, DKIM, DMARC หรือ PTR
ขั้นตอนที่ 1: หาบรรทัดสำคัญในอีเมลตีกลับ
ข้อความตีกลับมักขึ้นต้นด้วยคำอธิบายทั่วไปที่ไม่ค่อยมีประโยชน์ ให้เลื่อนลงไปหาส่วนที่เป็นรายละเอียดทางเทคนิค ซึ่งหน้าตาจะคล้ายตัวอย่างนี้
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: แยกให้ออกว่าเป็นปัญหาชั่วคราวหรือถาวร
ตัวเลขหลักแรกของรหัสบอกประเภทของปัญหา
| หลักแรก | ความหมาย | สิ่งที่ระบบทำต่อ |
|---|---|---|
| 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: เทียบรหัสที่พบบ่อยและวิธีแก้
| รหัส | ความหมาย | วิธีแก้ |
|---|---|---|
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 เช่น Spamhaus | IP ของเซิร์ฟเวอร์ผู้ส่งติด 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 20Postfix บน AlmaLinux/Rocky Linux
sudo grep "[email protected]" /var/log/maillog | tail -n 20Exim (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
ปัญหาที่พบบ่อย
ได้รับอีเมลตีกลับจากอีเมลที่ไม่ได้ส่ง
เรียกว่า Backscatter เกิดจากผู้ไม่หวังดีปลอมที่อยู่ของคุณเป็นผู้ส่ง แล้วปลายทางตีกลับมาหาคุณ ให้เปิด Header ของข้อความตีกลับ ดูส่วนต้นฉบับที่แนบมา หาก IP ผู้ส่งไม่ใช่เซิร์ฟเวอร์ของคุณ แปลว่าไม่ได้ส่งจากระบบคุณ การตั้ง SPF และ DMARC ให้ถูกต้องช่วยให้ปลายทางปฏิเสธอีเมลปลอมตั้งแต่แรก แต่หากพบว่าส่งจากบัญชีของคุณจริง ให้เปลี่ยนรหัสผ่านทันที
ได้แต่ข้อความ "delayed" ซ้ำหลายวัน
เป็นรหัส 4xx ที่ไม่หาย มักเกิดจากเซิร์ฟเวอร์ปลายทางล่ม หรือปลายทางจำกัดอัตราการรับจาก IP ของคุณ ลองส่งไปยังโดเมนอื่นเพื่อเปรียบเทียบ ถ้าส่งที่อื่นได้ปกติ ปัญหาอยู่ที่ปลายทาง ให้แจ้งผู้รับ
ส่งถึงบางโดเมนไม่ได้ แต่โดเมนอื่นได้
มักเป็นนโยบายเฉพาะของปลายทาง เช่น Gmail และ Microsoft เข้มงวดเรื่องการยืนยันตัวตนของโดเมนมากกว่าเซิร์ฟเวอร์ทั่วไป ดูรหัสกลุ่ม 5.7.x แล้วแก้ตามตารางด้านบน
อ่าน Log แล้วไม่พบอีเมลฉบับนั้นเลย
แปลว่าอีเมลไม่ได้ออกจากเซิร์ฟเวอร์นี้ อาจตั้งค่า SMTP ในโปรแกรมผิดเซิร์ฟเวอร์ หรือถูกปฏิเสธตั้งแต่ขั้นยืนยันตัวตน ดูแนวทางไล่ตรวจทีละจุดในคู่มือ อีเมลส่งไม่ออกหรือไม่ได้รับ: วิธีตรวจสอบเบื้องต้น
หากอ่านรหัสแล้วยังไม่แน่ใจสาเหตุ หรือแก้ไขแล้วอีเมลยังตีกลับ สามารถส่งข้อความตีกลับฉบับเต็มมาให้ทีมงาน THAI DATA CLOUD ช่วยตรวจสอบได้ที่ https://thaidata.cloud/contact/
- Categories:
- Cloud
