การชะลอการรับ (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 มี SNDS สำหรับดูชื่อเสียง และมีฟอร์มติดต่อฝ่ายช่วยเหลือผู้ส่งของตัวเอง

Microsoft 365 (Exchange Online) ให้บริการกล่องจดหมายขององค์กร อีเมลถึง acme.com จะไปที่ acme-com.mail.protection.outlook.com ข้อผิดพลาดต่าง ๆ มีเอกสารอยู่ใน Microsoft Learn เรื่องการถูกบล็อกต้องดำเนินการผ่าน sender.office.com และผู้ดูแลระบบฝั่งผู้รับเป็นผู้กำหนดว่า tenant ของตนจะจัดการอีเมลของคุณอย่างไร

ชื่อโดเมนบอกไม่ได้ว่าคุณกำลังส่งไปที่ระบบไหน แต่รหัสตอบกลับบอกได้ ในบรรทัดบันทึกนี้ที่โพสต์ลงใน mailop เมื่อวันที่ 4 กันยายน โฮสต์ relay= คือ tenant ของ Microsoft 365:

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 ได้แก่ เอกสารอ้างอิง NDR ของ Exchange Online, บทความเรื่อง ASxxx, ตารางรหัสบนเว็บไซต์ Postmaster และบทความเรื่อง 550 5.7.515 รวมถึงบทความของ Al Iverson เรื่อง S775 และ S3115 และคำแนะนำของ Twilio SendGrid เรื่องการบล็อก S3140/S3150

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

Sender Best Common Practices ของ M3AAWG ระบุว่าหลังเกิดความล้มเหลวชั่วคราว “ผู้ส่งควรปิดการเชื่อมต่อ แล้วเปิดการเชื่อมต่อใหม่ในภายหลัง” และผู้ส่งต้องไม่ถือว่าความล้มเหลวชั่วคราว (tempfail) เป็นความล้มเหลวถาวรเด็ดขาด ส่วนนโยบายสำหรับผู้ส่งของ Microsoft ระบุเรื่อง 5xx ไว้ว่า “ผู้ส่งต้องไม่พยายามส่งข้อความนั้นซ้ำไปยังผู้รับรายนั้น”

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

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

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

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

Qboxmail แจ้งใน mailop ว่าปัญหา “เริ่มเมื่อเวลา 9:47 CEST ในทุก IP ของเราพร้อมกัน” โดยมีรหัสย่อย S77714, S77717 และ S77719 ส่วนหน้าสถานะของ Poppulo อ้างถึงรหัสเหตุขัดข้องของ Microsoft คือ EX1467029 ซึ่งเริ่มเมื่อเวลา 11:19 BST

ตามบทสรุปเมื่อวันที่ 10 กันยายนของ emailexpert ผู้ดูแลระบบอีเมลรายหนึ่งโทษว่าสายไฟเบอร์ขาด จนกระทั่ง One.com, Qboxmail, Mailjet และ Poppulo รายงานรหัสเดียวกันในทุก IP ที่ใช้ส่งและทุกภูมิภาค ด้าน Microsoft ระบุว่าสาเหตุมาจากโมเดลป้องกันสแปม จากนั้นจึงเป็นกฎจำกัดปริมาณที่ยังทำงานอยู่ระหว่างการกู้คืนระบบ ทั้งนี้ emailexpert ไม่พบรายงานหลังเหตุขัดข้องที่เผยแพร่ต่อสาธารณะ ส่วนความผิดพลาดด้านการยืนยันตัวตนอีกเหตุการณ์หนึ่ง คือ MO1465074 กินเวลาราว 67 ชั่วโมง ตั้งแต่ 31 สิงหาคมถึง 3 กันยายน รายงานฉบับเดือนกันยายนของเราครอบคลุมช่วงสิบวันนั้นไว้แล้ว

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

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

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

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

Smart Network Data Services (SNDS) คือพอร์ทัลฟรีของ Microsoft สำหรับดูชื่อเสียงราย IP บน Outlook.com ส่วนหน้าคำถามที่พบบ่อยของ SNDS ระบุข้อมูลที่ 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 มิถุนายนว่า return-path ของ JMRP ระบุแคมเปญและผู้รับได้ไม่แม่นยำอีกต่อไป จึงควรใส่ข้อมูลเหล่านั้นไว้ที่อื่น ตามหน้าแรกของ SNDS (อัปเดตเมื่อ 22 กันยายน) สิทธิ์เข้าถึงจะหมดอายุ 10 เดือนหลังได้รับอนุมัติหรือย้ายระบบ โดยจะมีการแจ้งเตือน 3 ครั้ง ให้จดไว้ในปฏิทิน

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

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

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

Microsoft 365: สำหรับ 5.7.606-649 ให้ใช้พอร์ทัลขอให้นำออกจากรายชื่อที่ 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 ระบุว่า “ช่วงห่างระหว่างการลองใหม่ควร (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 ไปสู่การบังคับใช้ ดูได้ในคู่มืออัตราการส่งถึงของเรา ส่วนการทำให้อีเมลรีเซ็ตรหัสผ่านและใบเสร็จยังส่งออกไปได้ต่อเนื่อง คู่มืออีเมลธุรกรรมของเราอธิบายการแยกอีเมลเหล่านี้ไปไว้บนโดเมนของตัวเอง

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

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

• เหตุการณ์ส่งล่าช้า: การชะลอการรับจะบันทึกเป็นเหตุการณ์ “ส่งล่าช้า” (delivery_delayed) และสถานะของผู้รับจะเปลี่ยนจาก “ส่งออกแล้ว” เป็น “ส่งล่าช้า” จากนั้นเป็น “ส่งถึง” หรือ “ตีกลับ” ในหน้า เหตุการณ์ ให้ค้นหา “ส่งล่าช้า” แล้วพิมพ์ @hotmail.com หรือ @outlook.com เพื่อกรองเฉพาะ Outlook.com (ตัวกรองโดเมนหลายตัวจะรวมกันแบบ OR ส่วนผู้รับใน Microsoft 365 ใช้โดเมนของบริษัทตัวเอง) เหตุการณ์นี้บอกว่าอีเมลกำลังรออยู่ แต่ไม่ได้บอกเหตุผล
• รายละเอียดการตีกลับ: ส่วน “เมตาดาตา” ของเหตุการณ์ “ตีกลับ” จะเก็บประเภทการตีกลับและข้อความจากผู้ให้บริการอีเมลไว้
• ตัวเลขผ่าน API: ภาพรวมการวิเคราะห์ส่งค่า deliveryDelayed และ pending กลับมาพร้อมกับค่าส่งถึงและตีกลับ และ get_email_analytics ก็ทำแบบเดียวกันผ่าน MCP
• การระงับการส่งที่ปฏิบัติต่อ 4xx อย่างถูกต้อง: การตีกลับถาวรและการร้องเรียนจะทำให้ระงับการส่งทันที ส่วนการตีกลับชั่วคราว (soft bounce) จะทำให้ระงับการส่งก็ต่อเมื่อเกิดขึ้น 3 ครั้งภายใน 30 วัน
• การค่อย ๆ เพิ่มปริมาณ: ทยอยส่งแบ่งการส่งขนาดใหญ่ออกเป็นชุดตามเปอร์เซ็นต์รายชั่วโมงหรือรายวัน ซึ่งคุณหยุดชั่วคราวได้หาก 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 การชะลอการรับจะแสดงเป็นเหตุการณ์ “ส่งล่าช้า” และผู้ติดต่อจะถูกระงับการส่งก็ต่อเมื่อเกิดการตีกลับชั่วคราวซ้ำหลายครั้งเท่านั้น