# Microsoft 451 4.7.500: คู่มือรับมือการชะลอการรับสำหรับผู้ส่ง

URL หลัก: https://brew.new/th/blog/microsoft-451-4-7-500-deferrals-playbook
ผู้เขียน: Thomas Park
เผยแพร่: 2026-10-05
อัปเดต: 2026-10-05

การชะลอการรับ (deferral) ของ Microsoft คือการปฏิเสธชั่วคราวในระดับ SMTP ซึ่งเป็นรหัสตอบกลับที่ขึ้นต้นด้วย 4 ที่เซิร์ฟเวอร์ของ Outlook.com หรือ Microsoft 365 ส่งกลับมาเมื่อยังไม่รับอีเมลของคุณในตอนนี้ เซิร์ฟเวอร์ของคุณควรเก็บอีเมลไว้แล้วลองส่งใหม่ รหัสที่รู้จักกันดีที่สุดคือ `451 4.7.500 Server busy. Please try again later` และรหัสเดียวกันนี้อาจหมายถึง “การส่งของคุณดูน่าสงสัย” หรือ “ฝั่ง Microsoft เองกำลังมีปัญหา” ก็ได้

เมื่อวันที่ 4 กันยายน 2026 รหัสนี้หมายถึงอย่างหลัง แต่มีผู้ดูแลระบบอีเมลที่มีประสบการณ์อย่างน้อยหนึ่งรายเสียเวลาทั้งเช้าไล่หาสาเหตุแบบแรก บทความนี้อธิบายวิธีแยกทั้งสองกรณีออกจากกัน

## ประเด็นสำคัญ

- ดูโฮสต์ก่อน: `*.olc.protection.outlook.com` คืออีเมลของผู้ใช้ทั่วไปบน Outlook.com ส่วน `*.mail.protection.outlook.com` คือ tenant ของ Microsoft 365 ซึ่งมีเอกสารต่างกัน และช่องทางยกระดับปัญหาก็ต่างกัน
- รหัส 4xx หมายถึงให้เข้าคิวแล้วลองใหม่ โดย RFC 5321 ระบุให้เว้นระยะอย่างน้อย 30 นาที และลองต่อเนื่องอย่างน้อย 4 ถึง 5 วัน ส่วนรหัส 5xx หมายถึงให้หยุด และนโยบายของ Microsoft ห้ามลองส่งซ้ำ
- หากทุก IP ได้รับรหัสเดียวกันจาก Microsoft ในนาทีเดียวกัน ขณะที่ Gmail และ Yahoo ยังปกติ ให้สงสัยฝั่ง Microsoft ก่อน และตรวจเมลลิงลิสต์ mailop ก่อนเปลี่ยนแปลงอะไร
- Outlook.com บังคับใช้ SPF, DKIM และ DMARC กับโดเมนที่ส่งอีเมลมากกว่า 5,000 ฉบับต่อวัน มาตั้งแต่วันที่ 5 พฤษภาคม 2025 ทั้งนี้ `550 5.7.515` เป็นปัญหาที่คุณต้องแก้เองเสมอ
- ลงทะเบียน IP ที่ใช้ส่งใน SNDS และ JMRP ไว้ตั้งแต่ตอนนี้ สิทธิ์เข้าถึง SNDS จะหมดอายุหลัง 10 เดือน หากคุณไม่ยืนยันสิทธิ์ซ้ำ
- อย่าเร่งลองส่งซ้ำให้ถี่ขึ้น อย่าเปลี่ยนไปใช้ IP ใหม่ และอย่าระงับการส่งถึงผู้ติดต่อที่ถูกชะลอการรับ

## ขั้นแรก หาให้เจอว่าคุณกำลังส่งถึง Microsoft ระบบไหน

Microsoft มีระบบรับอีเมล 2 ระบบ

**Outlook.com** คืออีเมลของผู้ใช้ทั่วไป ได้แก่ `outlook.com`, `hotmail.com`, `live.com` และ `msn.com` ซึ่งมีโฮสต์ MX อย่าง `hotmail-com.olc.protection.outlook.com` ระบบนี้มี[เว็บไซต์ Postmaster ของ Outlook.com](https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting) มี SNDS สำหรับดูชื่อเสียง และมีฟอร์มติดต่อฝ่ายช่วยเหลือผู้ส่งของตัวเอง

**Microsoft 365** (Exchange Online) ให้บริการกล่องจดหมายขององค์กร อีเมลถึง `acme.com` จะไปที่ `acme-com.mail.protection.outlook.com` ข้อผิดพลาดต่าง ๆ มีเอกสารอยู่ใน [Microsoft Learn](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online) เรื่องการถูกบล็อกต้องดำเนินการผ่าน `sender.office.com` และผู้ดูแลระบบฝั่งผู้รับเป็นผู้กำหนดว่า tenant ของตนจะจัดการอีเมลของคุณอย่างไร

ชื่อโดเมนบอกไม่ได้ว่าคุณกำลังส่งไปที่ระบบไหน แต่รหัสตอบกลับบอกได้ ในบรรทัดบันทึกนี้ที่[โพสต์ลงใน mailop](https://www.mail-archive.com/mailop@mailop.org/msg27209.html) เมื่อวันที่ 4 กันยายน โฮสต์ `relay=` คือ tenant ของ Microsoft 365:

```text
relay=xxxx-com.mail.protection.outlook.com[52.101.10.16]:25, dsn=4.7.500,
status=deferred (host xxx-com.mail.protection.outlook.com[52.101.10.16] said:
451 4.7.500 Server busy. Please try again later from [199.89.3.6]. (S77714)
[BN2PEPF000055E1.namprd21.prod.outlook.com 2026-09-04T10:28:53.346Z ...]
(in reply to end of DATA command))
```

## ถอดความหมายรหัสตอบกลับ

อ่านรหัสพื้นฐาน (`451`) รหัสสถานะแบบขยาย (`4.7.500`) และรหัสย่อยในวงเล็บอย่าง `(S77714)` ทั้งนี้ Microsoft ไม่ได้เผยแพร่ความหมายของรหัสย่อยแบบ S แต่การที่ผู้ส่งจำนวนมากรายงานรหัสเดียวกันในเวลาเดียวกันก็เป็นสัญญาณอย่างหนึ่ง

| รหัสตอบกลับ | ระบบ | สิ่งที่เอกสารของ Microsoft ระบุ | สิ่งแรกที่ควรทำ |
|---|---|---|---|
| `451 4.7.500 Server busy. Please try again later from [IP]. (S77714)` | Microsoft 365 | Learn ระบุ 4.7.500-699 ว่า “Access denied, please try again later”: พบกิจกรรมที่น่าสงสัย การส่งจึงถูกจำกัดชั่วคราว | ปล่อยให้คิวลองส่งใหม่เอง และตรวจขอบเขตของปัญหาก่อน |
| `451 4.7.500-699 (ASxxx)` | Microsoft 365 | การจำกัดปริมาณ (throttling) ระดับ IP เมื่อ IP ที่เชื่อมต่อ “เปลี่ยนรูปแบบการส่งอีเมลจากเดิมด้วยการส่งในปริมาณที่สูงขึ้นมาก” | ชะลอการเพิ่มปริมาณ แล้วปัญหาจะหายไป “ภายในช่วงเวลาไม่กี่วัน” |
| `451 4.7.650 ... temporarily rate limited due to IP reputation (S775)` | Outlook.com | ไม่มีอยู่ในตารางที่ Microsoft เผยแพร่ | ลดปริมาณและจำนวนการเชื่อมต่อพร้อมกัน แล้วตรวจ SNDS |
| `451 4.7.652 ... exceeded the maximum number of connections (S3115)` | Outlook.com | ไม่มีอยู่ในตาราง แต่ข้อความระบุสาเหตุไว้แล้ว | เปิดการเชื่อมต่อให้น้อยลง |
| `421 RP-001`, `RP-002`, `RP-003` | Outlook.com | เกินขีดจำกัดอัตรา อัตราต่อการเชื่อมต่อ และจำนวนการเชื่อมต่อ “ซึ่งเกี่ยวข้องกับชื่อเสียงของ IP/โดเมน” | จำกัดปริมาณการส่ง แล้วตรวจ SNDS |
| `550 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level.` | Outlook.com | โดเมนส่งอีเมลมากกว่า 5,000 ฉบับต่อวัน และไม่ผ่านข้อกำหนดด้าน SPF, DKIM และ DMARC | แก้การยืนยันตัวตนและ alignment |
| `550 5.7.1 ... part of their network is on our block list (S3150)` | Outlook.com | IP หรือช่วง IP ของคุณถูกบล็อก | หยุดส่งจาก IP นั้น แล้วเปิดคำร้องถึงฝ่ายสนับสนุน |
| `550 SC-001`, `SC-004`, `OU-002` และรหัสที่คล้ายกัน | Outlook.com | การปฏิเสธตามนโยบายเนื่องจากเนื้อหา ชื่อเสียง หรือการร้องเรียน โดย SC-004 ชี้ไปที่ JMRP | หาสาเหตุให้เจอก่อนกลับมาส่งต่อ |
| `550 5.7.606-649 Access denied, banned sending IP [IP]` | Microsoft 365 | IP อยู่ในรายชื่อผู้ส่งที่ถูกบล็อก | ขอให้นำออกจากรายชื่อที่ `sender.office.com` |
| `550 5.7.511 Access denied, banned sender` | Microsoft 365 | ต้องให้เจ้าหน้าที่ตรวจสอบเอง | ส่งต่อ NDR (รายงานการส่งไม่สำเร็จ) ไปที่ `delist@microsoft.com` |

แหล่งที่มา: เอกสารของ Microsoft ได้แก่ [เอกสารอ้างอิง NDR ของ Exchange Online](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online), [บทความเรื่อง ASxxx](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/fix-error-code-451-4-7-500-699-asxxx-in-exchange-online), ตารางรหัสบนเว็บไซต์ Postmaster และ[บทความเรื่อง 550 5.7.515](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com) รวมถึงบทความของ Al Iverson เรื่อง [S775](https://www.spamresource.com/2026/02/microsoft-rate-limiting-issues.html) และ [S3115](https://www.spamresource.com/2025/07/microsoft-says-too-many-connections.html) และคำแนะนำของ Twilio SendGrid เรื่อง[การบล็อก S3140/S3150](https://support.sendgrid.com/hc/en-us/articles/38465017420955-Troubleshooting-Microsoft-Delivery-Issues-With-Error-550-5-7-1-S3140-S3150-Blocks)

### เลข 4 หรือเลข 5 คือคำสั่งว่าต้องทำอะไร

[Sender Best Common Practices ของ M3AAWG](https://www.m3aawg.org/sites/default/files/document/M3AAWG_Senders_BCP_Ver3-2015-02.pdf) ระบุว่าหลังเกิดความล้มเหลวชั่วคราว “ผู้ส่งควรปิดการเชื่อมต่อ แล้วเปิดการเชื่อมต่อใหม่ในภายหลัง” และผู้ส่งต้องไม่ถือว่าความล้มเหลวชั่วคราว (tempfail) เป็นความล้มเหลวถาวรเด็ดขาด ส่วน[นโยบายสำหรับผู้ส่ง](https://substrate.office.com/ip-domain-management-snds/Postmaster/Policies)ของ Microsoft ระบุเรื่อง 5xx ไว้ว่า “ผู้ส่งต้องไม่พยายามส่งข้อความนั้นซ้ำไปยังผู้รับรายนั้น”

รหัส 451 ไม่ใช่การตีกลับ หากแพลตฟอร์มหรือสคริปต์ของคุณนับเป็นการตีกลับ ให้แก้จุดนั้นก่อน

## เหตุขัดข้องของ Microsoft หรือปัญหาชื่อเสียงของคุณ

แนวทางของ Microsoft สำหรับ 4.7.500 ชี้ให้คุณตรวจการส่งของตัวเอง ซึ่งส่วนใหญ่ก็ถูก แต่ไม่ใช่ทุกครั้ง

### วันที่ 4 กันยายน 2026 เกิดอะไรขึ้น

Qboxmail [แจ้งใน mailop](https://www.mail-archive.com/mailop@mailop.org/msg27208.html) ว่าปัญหา “เริ่มเมื่อเวลา 9:47 CEST ในทุก IP ของเราพร้อมกัน” โดยมีรหัสย่อย S77714, S77717 และ S77719 ส่วน[หน้าสถานะ](https://poppulo1.statuspage.io/incidents/w0671ycn23fw)ของ Poppulo อ้างถึงรหัสเหตุขัดข้องของ Microsoft คือ EX1467029 ซึ่งเริ่มเมื่อเวลา 11:19 BST

ตาม[บทสรุปเมื่อวันที่ 10 กันยายน](https://emailexpert.com/microsofts-ten-days-three-exchange-online-incidents-three-causes/)ของ emailexpert ผู้ดูแลระบบอีเมลรายหนึ่งโทษว่าสายไฟเบอร์ขาด จนกระทั่ง One.com, Qboxmail, Mailjet และ Poppulo รายงานรหัสเดียวกันในทุก IP ที่ใช้ส่งและทุกภูมิภาค ด้าน Microsoft ระบุว่าสาเหตุมาจากโมเดลป้องกันสแปม จากนั้นจึงเป็นกฎจำกัดปริมาณที่ยังทำงานอยู่ระหว่างการกู้คืนระบบ ทั้งนี้ emailexpert ไม่พบรายงานหลังเหตุขัดข้องที่เผยแพร่ต่อสาธารณะ ส่วนความผิดพลาดด้านการยืนยันตัวตนอีกเหตุการณ์หนึ่ง คือ MO1465074 กินเวลาราว 67 ชั่วโมง ตั้งแต่ 31 สิงหาคมถึง 3 กันยายน [รายงานฉบับเดือนกันยายน](/th/blog/state-of-email-september-2026)ของเราครอบคลุมช่วงสิบวันนั้นไว้แล้ว

### ตรวจ 5 ข้อก่อนลงมือ

1. **ขอบเขตของปัญหาฝั่งคุณ:** ปัญหาที่เกิดจากแพลตฟอร์มกระทบทุก IP ทุกโดเมน และทุกสตรีมอีเมลภายในไม่กี่นาที ส่วนปัญหาชื่อเสียงมักเริ่มจากจุดเดียว
2. **ผู้ให้บริการรายอื่น:** หาก Gmail, Yahoo และ Apple ยังรับอีเมลตามปกติ และผู้ส่งรายอื่นรายงานรหัสเดียวกันจาก Microsoft สาเหตุน่าจะอยู่ที่ Microsoft
3. **ช่วง 72 ชั่วโมงที่ผ่านมาของคุณ:** ปริมาณการส่งที่พุ่งขึ้น, IP ใหม่, รายชื่อที่นำเข้า, การแก้ไข DNS หรือการส่งถึงรายชื่อเก่าเพื่อปลุกให้กลับมา ล้วนต้องแก้ไม่ว่าสาเหตุจะเป็นอะไร
4. **ถามคนอื่น:** ตรวจคลังข้อความเก่าของ mailop และหน้าสถานะต่าง ๆ ผู้ดูแลระบบ Microsoft 365 เปิด **Health > Service health** (สถานะบริการ) ได้ ซึ่งหน้า [Issue history](https://learn.microsoft.com/en-us/microsoft-365/enterprise/view-service-health) (ประวัติปัญหา) แสดงเหตุขัดข้องที่ประกาศถึง tenant ของคุณในช่วง 7 หรือ 30 วันที่ผ่านมา และ Poppulo ก็พบ EX1467029 จากหน้านี้
5. **SNDS:** หากเป็นสีเขียวและไม่มีการบล็อก ขณะที่การชะลอการรับเพิ่มขึ้นเรื่อย ๆ แสดงว่าสาเหตุไม่น่าจะอยู่ที่คุณ

| สัญญาณ | ชี้ไปที่ Microsoft | ชี้ไปที่คุณ |
|---|---|---|
| ช่วงเวลา | ทุก IP เริ่มมีปัญหาในนาทีเดียวกัน | IP หรือโดเมนเดียว หรือค่อย ๆ เพิ่มขึ้น |
| ผู้ให้บริการรายอื่น | ปกติ | แย่ลงด้วย หรือการร้องเรียนเพิ่มขึ้น |
| ผู้ส่งรายอื่น | รหัสเดียวกันใน mailop และหน้าสถานะ | ไม่มีใครพูดถึง |
| การเปลี่ยนแปลงล่าสุดของคุณ | ไม่มี | ปริมาณการส่งพุ่งขึ้น, IP ใหม่ หรือรายชื่อใหม่ |
| SNDS | สีเขียว และไม่มีการบล็อก | สีเหลืองหรือแดง, มีการร้องเรียน, สถานะ “Blocked” |
| รหัส | 4.7.500 พร้อมรหัสย่อยที่คนอื่นรายงานเหมือนกัน | RP-00x, 4.7.650, 5.7.515, S3150 |

![แผนผังการตัดสินใจสำหรับรหัสตอบกลับของ Microsoft: รหัส 5xx นำไปสู่การแก้การยืนยันตัวตน พอร์ทัลขอให้นำออกจากรายชื่อ หรือคำร้องถึงฝ่ายสนับสนุน ส่วนรหัส 4xx นำไปสู่ขั้นตอนตรวจสอบเมื่อเกิดเหตุขัดข้อง แล้วจึงรอให้ผ่านไปเอง หรือจำกัดปริมาณการส่งและตรวจ SNDS](/images/blog/microsoft-451-4-7-500-deferrals-playbook-flowchart.png)

*วิธีจัดการรหัสตอบกลับของ Microsoft ตามเอกสารของ Microsoft และรายงานเหตุขัดข้องเดือนกันยายน 2026*

## SNDS และ JMRP: ตั้งค่าไว้ก่อนจะต้องใช้

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

- **ผลการกรอง (Filter result):** สีเขียวคือข้อความที่ถูกตัดสินว่าเป็นสแปมน้อยกว่า 10% สีเหลืองคือ 10% ถึง 90% และสีแดงคือมากกว่า 90%
- **อัตราการร้องเรียน (Complaint rate):** จำนวนการร้องเรียนหารด้วยจำนวนผู้รับ โดย IP มากกว่า 30% มีอัตราต่ำกว่า 0.3% ซึ่งเป็น “เกณฑ์ที่ดีที่ควรตั้งเป้าไว้”
- **คำสั่ง RCPT เทียบกับจำนวนผู้รับข้อความ:** หากตัวเลขต่างกันมาก แสดงว่ารายชื่อล้าสมัย
- **สถานะ IP**: Blocked, Bot หรือ Junked

ข้อมูล “อาจไม่แสดงสำหรับ IP ที่ส่งข้อความน้อยกว่า 100 ฉบับในวันนั้น” หากต้องการสิทธิ์เข้าถึง ให้ขอสิทธิ์สำหรับ IP, ช่วง IP หรือ ASN แล้ว SNDS จะส่งลิงก์ไปยังที่อยู่อีเมลที่พบผ่าน reverse DNS (`postmaster@`, `abuse@`) หรือ RDAP โดยไม่รับคำขอที่ส่งเข้ามาเอง

SNDS เปิดตัวใหม่เมื่อเดือนมิถุนายน 2026 ทั้งนี้ Al Iverson [ตั้งข้อสังเกตเมื่อวันที่ 19 มิถุนายน](https://www.spamresource.com/2026/06/snds-and-jmrp-in-transition.html)ว่า return-path ของ JMRP ระบุแคมเปญและผู้รับได้ไม่แม่นยำอีกต่อไป จึงควรใส่ข้อมูลเหล่านั้นไว้ที่อื่น ตามหน้าแรกของ SNDS (อัปเดตเมื่อ 22 กันยายน) สิทธิ์เข้าถึงจะหมดอายุ 10 เดือนหลังได้รับอนุมัติหรือย้ายระบบ โดยจะมีการแจ้งเตือน 3 ครั้ง ให้จดไว้ในปฏิทิน

[Junk Mail Reporting Program](https://substrate.office.com/ip-domain-management-snds/Postmaster/Services) (JMRP) ซึ่งลงทะเบียนได้ภายใน SNDS จะส่งข้อความทุกฉบับที่ผู้ใช้ Outlook.com ทำเครื่องหมายว่าเป็นอีเมลขยะกลับมาให้คุณ โดยมักเริ่มได้ “ภายในเวลาเพียง 72 ชั่วโมง” หลังลงทะเบียน นำผู้ที่ร้องเรียนออกจากทุกรายชื่อ และลงทะเบียน IP ใหม่ทุกครั้งที่เพิ่มเข้ามา ส่วน IP ร่วมซึ่งคุณลงทะเบียนเองไม่ได้ ให้ถามผู้ให้บริการของคุณว่าเฝ้าดูอะไรอยู่บ้าง

## การติดต่อฝ่ายช่วยเหลือผู้ส่งและการขอให้นำออกจากรายชื่อ

**Outlook.com:** ฟอร์มติดต่อฝ่ายช่วยเหลือบน[หน้าการแก้ปัญหาของ Postmaster](https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting) ต้องใช้บัญชี Microsoft ครอบคลุมเฉพาะโดเมนของผู้ใช้ทั่วไป 4 โดเมน และ “ไม่ได้รับประกัน” ว่าอีเมลจะส่งถึง ส่วน Twilio SendGrid (คำแนะนำจากผู้ให้บริการรายนี้) แนะนำให้ใส่โดเมน, IP, คำอธิบายสตรีมอีเมล, ข้อความตีกลับ และภาพหน้าจอจาก SNDS ตอบกลับอีเมลตอบรับอัตโนมัติฉบับแรกเพื่อขอยกระดับปัญหา และขอทราบโควตาปริมาณการส่งของคุณ พร้อมขอให้ทบทวน Volume-Based Limit

**Microsoft 365:** สำหรับ `5.7.606-649` ให้ใช้[พอร์ทัลขอให้นำออกจากรายชื่อ](https://learn.microsoft.com/en-us/defender-office-365/external-senders-use-the-delist-portal-to-unblock-yourself)ที่ `sender.office.com` ซึ่งรับได้ครั้งละ 1 ที่อยู่และ 1 IP และยืนยันทางอีเมล การนำออก “อาจใช้เวลาถึง 24 ชั่วโมงหรือนานกว่านั้น” ส่วน `5.7.511` ให้ส่ง NDR ทางอีเมลไปที่ `delist@microsoft.com` และรอการตอบกลับภายใน 48 ชั่วโมง

การจำกัดปริมาณแบบ ASxxx ไม่มีขั้นตอนขอให้นำออกจากรายชื่อ หากบริษัทผู้รับกรองอีเมลขาเข้าผ่านบริการภายนอกก่อนเข้าสู่ Microsoft 365 บทความใน Learn ระบุว่าตัวเชื่อมต่อ (connector) ที่ผู้ดูแลระบบของบริษัทนั้นตั้งค่าไว้จะยกเลิกการจำกัดปริมาณนี้ได้ หากไม่ใช่กรณีนั้น การจำกัดจะหายไปเองเมื่อคุณสร้างประวัติการส่งได้มากพอ

## ลองส่งใหม่ จำกัดปริมาณ และค่อย ๆ เพิ่มปริมาณ

**ลองส่งใหม่ตามกำหนดเวลา:** [RFC 5321 หัวข้อ 4.5.4.1](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.5.4.1) ระบุว่า “ช่วงห่างระหว่างการลองใหม่ควร (SHOULD) อยู่ที่อย่างน้อย 30 นาที” และระยะเวลาก่อนยกเลิกการส่ง “โดยทั่วไปต้องนานอย่างน้อย 4 ถึง 5 วัน” โดยลอง 2 ครั้งในชั่วโมงแรก จากนั้นลองครั้งละหนึ่งทุก 2 หรือ 3 ชั่วโมง อย่าย่นระยะเวลานี้เพื่อการส่งที่เร่งด่วน

**จำกัดปริมาณแยกตามปลายทาง:** M3AAWG ระบุว่าเซิร์ฟเวอร์ผู้รับคาดหวังให้ผู้ส่งปรับ “ในลักษณะเหมารวมกับอีเมลทั้งหมดที่ส่งมาจาก IP เดียวกัน” เมื่อ Microsoft ชะลอการรับ ให้ชะลอทุกอย่างที่ส่งไปยังกลุ่ม MX นั้น (Outlook.com หรือ Microsoft 365)

**ระวังจำนวนการเชื่อมต่อ:** นโยบายของ Outlook.com ระบุว่าผู้ส่ง “ต้องไม่เปิดการเชื่อมต่อพร้อมกันเกิน 500 รายการ” หากไม่ได้ตกลงกันไว้ล่วงหน้า ตัวเลขนี้คือเพดาน และหากได้รับ `4.7.652 (S3115)` แปลว่าคุณเกินเพดานของคุณแล้ว

**ค่อย ๆ เพิ่มปริมาณบน IP และโดเมนใหม่:** Microsoft ระบุว่า IP ใหม่ “น่าจะเพิ่มปริมาณได้เต็มที่ภายในสองสามสัปดาห์หรือเร็วกว่านั้น” ขึ้นอยู่กับปริมาณการส่ง ความถูกต้องของรายชื่อ และการร้องเรียน ทั้งนี้ IP ใหม่ที่อยู่ในระเบียน SPF เดิมจะได้รับชื่อเสียงของโดเมนบางส่วนไปด้วย ให้เริ่มจากผู้ที่มีส่วนร่วมล่าสุด

## สิ่งที่ไม่ควรทำ

- **เร่งลองส่งซ้ำให้ถี่ขึ้น:** การล้างคิว (flush) ทุกไม่กี่นาทีจะเพิ่มการเชื่อมต่อเข้าไปที่ IP ซึ่ง Microsoft ต้องการให้ชะลอ และทำให้คุณได้รับ 4.7.652
- **เปลี่ยน IP เพื่อหลบ:** IP ใหม่ยังไม่มีชื่อเสียงและมีแนวโน้มจะเจอปัญหามากกว่า อีกทั้งการกระจายอีเมลไปยัง IP ใหม่หลาย ๆ ตัวคือสิ่งที่สแปมเมอร์แบบ snowshoe ทำกัน
- **ลองส่ง 5xx ซ้ำ:** Microsoft ห้ามไว้ และหลังได้รับ “การตอบกลับว่าส่งไม่สำเร็จหลายครั้ง” คุณต้องหยุดส่งถึงผู้รับรายนั้น
- **ระงับการส่งถึงผู้ติดต่อที่ถูกชะลอการรับ:** ที่อยู่อีเมลนั้นยังใช้ได้อยู่
- **ส่งซ้ำถึงผู้รับที่ถูกชะลอการรับ:** อีเมลของพวกเขายังอยู่ในคิว คุณจะส่งซ้ำซ้อน
- **แก้ DNS ด้วยความตื่นตระหนก:** การเปลี่ยน SPF หรือ DKIM ระหว่างเกิดเหตุขัดข้องจะเพิ่มปัญหาที่สองเข้ามา เว้นแต่คุณได้รับ `5.7.515`

เรื่อง DMARC alignment และการขยับจาก `p=none` ไปสู่การบังคับใช้ ดูได้ใน[คู่มืออัตราการส่งถึง](/th/blog/email-deliverability)ของเรา ส่วนการทำให้อีเมลรีเซ็ตรหัสผ่านและใบเสร็จยังส่งออกไปได้ต่อเนื่อง [คู่มืออีเมลธุรกรรม](/th/blog/transactional-emails)ของเราอธิบายการแยกอีเมลเหล่านี้ไปไว้บนโดเมนของตัวเอง

## ใน Brew จะเห็นอะไรบ้าง

Brew ดูแลโครงสร้างพื้นฐานการส่งและลองส่งใหม่เมื่อเกิดความล้มเหลวชั่วคราวให้เอง คุณจึงไม่ต้องปรับคิวหรือขีดจำกัดการเชื่อมต่อเลย สิ่งที่คุณจะเห็นมีดังนี้:

- **เหตุการณ์ส่งล่าช้า:** การชะลอการรับจะบันทึกเป็นเหตุการณ์ “ส่งล่าช้า” (`delivery_delayed`) และสถานะของผู้รับจะเปลี่ยนจาก “ส่งออกแล้ว” เป็น “ส่งล่าช้า” จากนั้นเป็น “ส่งถึง” หรือ “ตีกลับ” ในหน้า **เหตุการณ์** ให้ค้นหา “ส่งล่าช้า” แล้วพิมพ์ `@hotmail.com` หรือ `@outlook.com` เพื่อกรองเฉพาะ Outlook.com (ตัวกรองโดเมนหลายตัวจะรวมกันแบบ OR ส่วนผู้รับใน Microsoft 365 ใช้โดเมนของบริษัทตัวเอง) เหตุการณ์นี้บอกว่าอีเมลกำลังรออยู่ แต่ไม่ได้บอกเหตุผล
- **รายละเอียดการตีกลับ:** ส่วน “เมตาดาตา” ของเหตุการณ์ “ตีกลับ” จะเก็บประเภทการตีกลับและข้อความจากผู้ให้บริการอีเมลไว้
- **ตัวเลขผ่าน API:** [ภาพรวมการวิเคราะห์](https://docs.brew.new/api-reference/public-v1/analytics/brand-overview-totals-rates-timeseries)ส่งค่า `deliveryDelayed` และ `pending` กลับมาพร้อมกับค่าส่งถึงและตีกลับ และ `get_email_analytics` ก็ทำแบบเดียวกันผ่าน MCP
- **การระงับการส่งที่ปฏิบัติต่อ 4xx อย่างถูกต้อง:** การตีกลับถาวรและการร้องเรียนจะทำให้ระงับการส่งทันที ส่วนการตีกลับชั่วคราว (soft bounce) จะทำให้ระงับการส่งก็ต่อเมื่อเกิดขึ้น 3 ครั้งภายใน 30 วัน
- **การค่อย ๆ เพิ่มปริมาณ:** [ทยอยส่ง](https://docs.brew.new/create-emails/send-options#gradual-send)แบ่งการส่งขนาดใหญ่ออกเป็นชุดตามเปอร์เซ็นต์รายชั่วโมงหรือรายวัน ซึ่งคุณหยุดชั่วคราวได้หาก Outlook.com เริ่มชะลอการรับ
- **สุขภาพโดเมน:** การ์ด “อัตราการส่งถึง” ของแต่ละโดเมนให้คะแนน 0 ถึง 100 จากด้านการเข้าอินบ็อกซ์ ชื่อเสียง การยืนยันตัวตน เนื้อหา และการตั้งค่าการส่ง ซึ่งดูได้ผ่านเครื่องมือ MCP `get_domain_health` ด้วย ส่วนการทดสอบการเข้าอินบ็อกซ์ (10 เครดิต) จะส่งไปยังอินบ็อกซ์ทดสอบที่ Gmail, Outlook, Yahoo, Apple และผู้ให้บริการอื่น ๆ

Brew ยังไม่มีเว็บฮุกการนำส่ง หรือข้อมูลจาก SNDS หรือ JMRP (ส่วนจำนวนแยกตามผู้ให้บริการอีเมลดึงได้จาก API เหตุการณ์ด้วย `groupBy=recipientDomain`) จึงควรใช้พอร์ทัลของ Microsoft เพื่อดูชื่อเสียง ระหว่างที่สงสัยว่า Microsoft เกิดเหตุขัดข้อง เราจะปล่อยการส่งไว้ตามเดิม แล้วรอดูสถานะเปลี่ยนจาก “ส่งล่าช้า” เป็น “ส่งถึง”

## คำถามที่พบบ่อย

### 451 4.7.500 Server busy จาก Outlook หรือ Microsoft 365 หมายความว่าอะไร?

นี่คือการปฏิเสธชั่วคราวจาก Microsoft 365 (Exchange Online) ซึ่งเอกสารระบุไว้ว่า “Access denied, please try again later” หลังพบกิจกรรมที่น่าสงสัย ส่วนใหญ่เกิดจากรูปแบบการส่งของคุณเปลี่ยนไป แต่เมื่อวันที่ 4 กันยายน 2026 สาเหตุคือเหตุขัดข้องของ Microsoft (EX1467029) ให้เซิร์ฟเวอร์ของคุณลองส่งใหม่ และตรวจว่าผู้ส่งรายอื่นเจอรหัสนี้ด้วยหรือไม่

### Microsoft จะชะลอการรับอีเมลไปนานแค่ไหน?

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

### 550 5.7.515 คืออะไร และแก้อย่างไร?

Outlook.com ปฏิเสธอีเมลจากโดเมนที่ส่งมากกว่า 5,000 ฉบับต่อวันซึ่งไม่ผ่านกฎด้านการยืนยันตัวตน โดยบังคับใช้มาตั้งแต่วันที่ 5 พฤษภาคม 2025 ข้อกำหนดคือ SPF และ DKIM ต้องผ่าน โดเมนต้องเผยแพร่ DMARC (`p=none` ก็เพียงพอ) และ SPF หรือ DKIM ต้อง align กับโดเมนใน From

### ควรเปลี่ยนไปใช้ IP ใหม่ไหม หาก Microsoft บล็อก IP เดิม?

ไม่ควร เพราะ Microsoft ระบุว่า IP ใหม่ยังไม่มีชื่อเสียง และมีแนวโน้มจะเจอปัญหามากกว่า ให้แก้ที่สาเหตุ ขอให้นำออกจากรายชื่อ แล้วค่อย ๆ เพิ่มปริมาณกลับขึ้นมาบน IP ที่มีอยู่

### การชะลอการรับของ Microsoft นับเป็นการตีกลับไหม?

ไม่นับ เพราะ M3AAWG ระบุว่าผู้ส่งต้องไม่ถือว่า 4xx เป็นความล้มเหลวถาวร รหัสนี้จะกลายเป็นการตีกลับก็ต่อเมื่อลองส่งใหม่จนหมดเวลาแล้ว หรือเซิร์ฟเวอร์ตอบกลับด้วย 5xx ส่วนใน Brew การชะลอการรับจะแสดงเป็นเหตุการณ์ “ส่งล่าช้า” และผู้ติดต่อจะถูกระงับการส่งก็ต่อเมื่อเกิดการตีกลับชั่วคราวซ้ำหลายครั้งเท่านั้น