Defaults.Exposed

Defaults.Exposedการแก้ไขGuides

Outlook ปฏิเสธอีเมลของคุณ: 550 5.7.515, 550 5.7.509 และ compauth=fail อธิบายและแก้ไข (2026)

เผยแพร่ 2026-07-08

ตัวเลข ณ 2026-06-29 · methodology v7. ข้อมูล census รวมจากโดเมนที่ผ่านการให้คะแนน 261 ล้านโดเมน ดู วิธีที่เราให้คะแนน

Microsoft มีสองระบบรับอีเมลที่แยกกัน Consumer Outlook.com บล็อกผู้ส่งปริมาณสูงที่ไม่ผ่านการยืนยันตัวตน (550 5.7.515, บังคับใช้ตั้งแต่พฤษภาคม 2025); Exchange Online บล็อกอีเมลที่ไม่ผ่านนโยบาย DMARC reject ของคุณเอง (550 5.7.509) จากโดเมน 10,205,070 ที่อนุญาต spf.protection.outlook.com, 85.0% มี SPF แบบเข้มงวด แต่มีเพียง 21.7% ที่บังคับใช้ DMARC ตาม census ของ Defaults.Exposed จาก 261,086,232 โดเมน

ปัญหา “Outlook ปฏิเสธอีเมลของฉัน” ส่วนใหญ่ไม่ได้เป็นการปฏิเสธจริงๆ — แต่เป็นอีเมลที่ตกไปอยู่ใน Junk อย่างเงียบๆ พร้อม compauth=fail ใน headers คู่มือนี้จะถอดรหัส Microsoft codes แสดงวิธีอ่าน Authentication-Results header และแนะนำขั้นตอนการแก้ไข: ยืนยัน SPF เปิดใช้งาน DKIM สำหรับ custom domain เผยแพร่และบังคับใช้ DMARC แล้วทดสอบใหม่

Microsoft error อะไรที่คุณมีอยู่จริงๆ?

Microsoft มีสองพื้นที่รับอีเมลที่แยกกัน และปฏิเสธด้วยเหตุผลที่ต่างกัน จับคู่อาการของคุณก่อน — การวินิจฉัยผิดเสียเวลาทั้งวัน

Code / สัญญาณมาจากไหนหมายความว่าอะไรข้อมูล ณ 2026-06-29
550 5.7.515Consumer Outlook.com / Hotmail / Liveคุณส่งมากกว่า 5,000 ข้อความ/วัน ไปยัง consumer Outlook และไม่ผ่านข้อกำหนดการยืนยันตัวตน (SPF + DKIM + DMARC) บังคับใช้ตั้งแต่ พฤษภาคม 2025
550 5.7.509Exchange Online / EOP (business tenants)เซิร์ฟเวอร์ผู้รับปฏิบัติตาม DMARC p=reject ของโดเมนของคุณเอง — อีเมลของคุณไม่ผ่าน DMARCมีเพียง 10.59% ของโดเมน 261,086,232 ที่บังคับใช้ DMARC
550 5.7.511Exchange Online / EOPที่อยู่ผู้ส่งหรือโดเมนของคุณอยู่ใน banned-sender list ขององค์กรผู้รับหรือ Microsoft
S3140 / S3150Consumer Outlook.comIP ของผู้ส่งมี reputation ไม่ดี — เป็น block ไม่ใช่ authentication failure
compauth=fail (headers)ทั้งสองพื้นที่ — กรณีที่พบบ่อยที่สุดอีเมลถูกรับแต่ถูกส่งไป Junk: composite authentication ของ Microsoft ล้มเหลว ไม่มี bounce ไม่มี NDR — แค่โฟลเดอร์ spamจากโดเมนที่ส่ง M365 10,205,070 โดเมน มีเพียง 21.7% ที่บังคับใช้ DMARC

ข้อความ NDR แน่นอนอาจเปลี่ยนแปลง; ตรวจสอบ string ที่คุณอ้างอิงกับ bounce จริงก่อนพึ่งพา

550 5.7.515 หมายความว่าอะไร?

นี่คือข้อกำหนดของ consumer Outlook.com/Hotmail ไม่ใช่ Microsoft 365 tenant error ตั้งแต่พฤษภาคม 2025 ผู้ส่งมากกว่า 5,000 ข้อความต่อวันไปยัง consumer Outlook ต้องผ่าน SPF ผ่าน DKIM และเผยแพร่ DMARC record (อย่างน้อย p=none) ที่ align กับ From domain ล้มเหลวเงื่อนไขนั้น consumer Outlook จะปฏิเสธด้วยข้อความเช่น:

550 5.7.515 Access denied, sending domain [yourdomain.com] does not meet the required authentication level.

สองสิ่งที่นี่ ไม่ใช่: ไม่ใช่คำสั่งปี 2026 (ถ้าอีเมลของคุณเพิ่งเริ่มบาวซ์ ปริมาณหรือ DNS ของคุณเปลี่ยน ไม่ใช่กฎที่เปลี่ยน) และไม่ใช่เรื่องของการตั้งค่า M365 tenant ของผู้รับ การแก้ไขคือ authentication ladder ด้านล่าง — และวันส่งแคมเปญที่ข้ามผ่าน 5,000/วันก็นับรวมด้วย

550 5.7.509 หมายความว่าอะไร?

อันนี้มาจาก Exchange Online Protection บน business tenants และหมายความว่านโยบาย DMARC ของคุณเองกำลังถูกปฏิบัติตาม:

550 5.7.509: Access denied, sending domain [yourdomain.com] does not pass DMARC verification and has a DMARC policy of reject.

อ่านอย่างระมัดระวัง — ไม่ใช่ Microsoft ที่ยุ่งยาก โดเมนของคุณเผยแพร่ p=reject ข้อความนี้ไม่ผ่าน DMARC และผู้รับทำตามที่คุณขอ ถ้าอีเมลที่บาวซ์เป็นของจริง แหล่งส่งบางแหล่ง (newsletter tool, CRM, อุปกรณ์ scan-to-email) ไม่ได้รับการ authenticate แบบ aligned อย่าลดนโยบาย แต่ให้แหล่งนั้นมี SPF หรือ DKIM แบบ aligned — ดู แก้ไข DMARC และ จาก p=none ไปสู่ p=reject

ทำไม Outlook ถึงส่งอีเมลไป junk พร้อม compauth=fail แทนที่จะบาวซ์?

ความเจ็บปวดด้านการส่งอีเมลของ Microsoft ส่วนใหญ่ไม่เคยก่อให้เกิด bounce ข้อความถูกรับ ให้คะแนน และถูกเก็บใน Junk — หลักฐานเดียวคือ Authentication-Results header ใน mailbox ของผู้รับ (หรือ outlook.com test mailbox ของคุณเอง) เปิดข้อความ เลือก View message source และค้นหาบรรทัด:

Authentication-Results: spf=pass ... dkim=fail ... dmarc=fail action=none ... compauth=fail reason=001

compauth คือคำตัดสิน composite authentication ของ Microsoft: แม้เมื่อโดเมนไม่มี DMARC record Microsoft จะใช้การตรวจสอบแบบ implicit คล้าย DMARC ค่าที่พบบ่อย:

บทเรียน: บน Microsoft อ่าน header ไม่ใช่แค่ NDR คำตัดสิน spf=, dkim= และ dmarc= บนบรรทัดเดียวกันบอกคุณว่าต้องแก้ขาไหน

จะแก้ไขการปฏิเสธและการ junk ของ Outlook ได้อย่างไร?

  1. รัน free scan ก่อน มันให้คะแนน SPF, DKIM และ DMARC ของคุณในรอบเดียวและแสดงว่าขาไหนกำลังล้มเหลวก่อนที่คุณจะแตะ DNS
  2. ยืนยัน SPF — มักจะโอเคอยู่แล้วบน Microsoft 365 Record มาตรฐานคือ v=spf1 include:spf.protection.outlook.com -all และ M365 setup วางมันไว้แล้ว: 85.0% ของโดเมน 10,205,070 ที่อนุญาต spf.protection.outlook.com สิ้นสุดด้วย strict -all (ข้อมูล ณ 2026-06-29) สิ่งที่ต้องระวัง: ผู้รับประเมิน SPF กับ Return-Path (RFC5321.MailFrom) domain ไม่ใช่ From header — ดังนั้น newsletter tool อาจผ่าน SPF บน bounce domain ของตัวเอง ในขณะที่ไม่ทำอะไรกับ domain ของคุณ นั่นคือเหตุผลที่ขั้นตอน 3 และ 4 สำคัญกว่า
  3. เปิดใช้งาน DKIM สำหรับ custom domain ของคุณ — CNAME สอง selectors M365 ลงนามด้วย onmicrosoft.com default ที่ไม่ aligned จนกว่าคุณจะเปิดใช้งาน custom-domain signing: เผยแพร่ CNAME selector1._domainkey และ selector2._domainkey ที่ชี้ไปยัง keys ของ tenant คุณ แล้วเปิดใช้งาน signing ใน Defender portal คลิกครบถ้วน: ตั้งค่า DKIM บน Microsoft 365 ถ้า DKIM แสดง “pass” แต่ DMARC ยังล้มเหลว คุณอยู่ใน กับดัก default-signature
  4. เผยแพร่ DMARC แล้วบังคับใช้ เริ่มด้วย v=DMARC1; p=none; rua=mailto:... เพื่อรับ reports แก้ไขทุก legitimate source ที่เปิดเผย จากนั้นค่อยๆ เพิ่มเป็น p=quarantine และ p=reject — เส้นทางแบบแบ่งระยะอยู่ใน แก้ไข DMARC นี่คือขั้นตอนที่ Microsoft shops ส่วนใหญ่ข้ามไป: มีเพียง 21.7% ของโดเมนที่ส่ง M365 ที่บังคับใช้ DMARC
  5. ทดสอบอีกครั้งโดยอ่าน header ส่งไปยัง consumer outlook.com mailbox เปิด message source และยืนยัน spf=pass, dkim=pass, dmarc=pass และ compauth=pass
  6. ผู้ส่งปริมาณสูง: ตรงตามมาตรฐาน consumer-Outlook มากกว่า 5,000/วัน คุณยังต้องการ From/reply-to ที่ถูกต้องและมีการ monitor ลิงก์ยกเลิกสมาชิกที่ใช้งานได้ และ list ที่สะอาด — การยืนยันตัวตนแก้ไข 5.7.515; อัตราร้องเรียนรักษาให้คุณออกจาก S3140/S3150 IP blocks ถ้าคุณถูก IP block อยู่แล้ว การแก้ไข SPF/DKIM/DMARC ไม่ได้ ยกเลิก block: ขอ delist ผ่าน Microsoft’s sender support และถือว่าการยืนยันตัวตนคือเหตุผลที่คุณจะไม่กลับมาอีก

ทำไมโดเมน Microsoft 365 จำนวนมากยังล้มเหลว?

เพราะค่า default ทำขั้นตอนแรกให้คุณและไม่ทำส่วนที่เหลือ ในบรรดาโดเมน 10,205,070 ที่อนุญาต spf.protection.outlook.com, 85.0% มี SPF แบบเข้มงวด — record ที่ M365 ให้คุณตอน setup — แต่มีเพียง 21.7% ที่บังคับใช้ DMARC ตาม census ของ Defaults.Exposed จาก 261,086,232 โดเมน M365 ให้ SPF แบบเข้มงวดเป็น default จากนั้น tenant ส่วนใหญ่หยุดอยู่แค่นั้น — population ที่ compauth ถูกสร้างมาเพื่อจับ (แม้ว่าจะยังดีกว่า 10.59% DMARC enforcement ทั่วทุกโดเมนที่ผ่านการให้คะแนน) ตาราง provider เปรียบเทียบครบ: SPF league table ของ email-provider

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

550 5.7.515 เป็น Microsoft 365 error หรือไม่? ไม่ มาจาก consumer Outlook.com/Hotmail และกำหนดเป้าหมายผู้ส่งมากกว่า 5,000 ข้อความ/วัน บังคับใช้ตั้งแต่พฤษภาคม 2025 Business Exchange Online rejections ใช้ codes ที่ต่างกัน — บ่อยที่สุดคือ 550 5.7.509 (DMARC reject policy ของคุณ) หรือ 5.7.511 (banned sender)

เราได้รับ 550 5.7.509 แต่อีเมลเป็นของจริง — เราควรปล่อย p=reject หรือไม่? ไม่ — นโยบายของคุณจับ unauthenticated source ซึ่งนั่นคือการทำงานของมัน ค้นหา source ใน header หรือ DMARC reports ของคุณและให้มี DKIM แบบ aligned (หรือ SPF แบบ aligned) การอ่อนแอลงเป็น p=none เปิดการ spoof domain ที่แน่นอนสำหรับทุกคนอีกครั้ง

compauth=fail หมายความว่ามีคนกำลัง spoof เราหรือไม่? ไม่จำเป็น reason=001 มักหมายความว่าอีเมลของคุณเองไม่สามารถพิสูจน์ว่าเป็นของคุณ — ไม่มี DKIM แบบ aligned ไม่มี DMARC มีเพียง 21.7% ของโดเมนที่ส่ง M365 10,205,070 โดเมนที่บังคับใช้ DMARC (ข้อมูล ณ 2026-06-29) ดังนั้น Microsoft ใช้การตรวจสอบแบบ implicit กับทุกคนอื่น และอีเมลที่ถูกต้องแต่ไม่มีการยืนยันตัวตนก็ล้มเหลว

ฉันส่งอีเมลน้อยกว่า 5,000 ฉบับต่อวัน — ฉันสามารถเพิกเฉยสิ่งนี้ได้หรือไม่? คุณจะหลีกเลี่ยง 550 5.7.515 ได้ แต่ไม่ใช่โฟลเดอร์ Junk: compauth ใช้ที่ทุกปริมาณ Gmail ทำสิ่งเดียวกัน — ดู คู่มือ Gmail 550 5.7.26 การแก้ไขฟรี; อุปสรรคคือการรับรู้ ไม่ใช่ต้นทุน

ส่ง report ให้เจ้าของ

ถ้าคุณแก้ไขอีเมลให้คนอื่น — ลูกค้า หัวหน้า บริษัทที่ invoice กำลังบาวซ์ — จบงานด้วยหลักฐาน รันใหม่ free scan หลังจาก DNS ตั้งใจและส่ง graded report ไปยังเจ้าของธุรกิจ มันแสดง SPF, DKIM และ DMARC เป็นสีเขียวในภาษาธรรมดาที่เจ้าของธุรกิจสามารถอ่านได้ และเป็น artifact ที่พวกเขาต้องการครั้งต่อไปเมื่อการต่ออายุ cyber-insurance หรือแบบสอบถามความปลอดภัยของลูกค้าถามว่าอีเมลของพวกเขาได้รับการ authenticate หรือไม่ แก้ไขดี; แก้ไขแบบ พิสูจน์ได้ คือสิ่งที่ทำให้คุณได้รับเงินและพวกเขาได้รับการคุ้มครอง

ตรวจสอบโดเมนของคุณฟรี

ดูว่า Microsoft ล้มเหลวในขาไหน SPF, DKIM, DMARC — แบบส่วนตัวและเจ้าของเท่านั้น

ตรวจสอบโดเมนของคุณ → · แก้ไข DMARC → · DKIM ผ่านแต่ DMARC ล้มเหลว → · วิธีที่เราให้คะแนน → · ข้อมูลรวมเท่านั้น ข้อมูลจัดเก็บและประมวลผลใน EU