คำศัพท์ · รายละเอียด SMTP ของ Office 365

รายละเอียด SMTP ของ Office 365 คืออะไร และส่งผลต่ออีเมลของแอปพลิเคชันอย่างไร

รายละเอียด Office 365 SMTP ไม่ได้มี host และรหัสผ่านสากลชุดเดียว Microsoft จัดทำเอกสารรูปแบบสำหรับแอปพลิเคชันและอุปกรณ์หลายแบบ รวมถึงการส่งจากไคลเอ็นต์ที่ยืนยันตัวตนผ่าน smtp.office365.com, SMTP relay ผ่าน connector ผ่าน endpoint MX ของ tenant และ Direct Send ถึงผู้รับ Microsoft 365 ภายใน รูปแบบเหล่านี้ต่างกันด้านการยืนยันตัวตน TLS port ตัวตนผู้ส่ง การรองรับผู้รับภายนอก licensing ขีดจำกัด และการตั้งค่าดูแลระบบ เลือกรูปแบบจากงานและขอบเขตความไว้วางใจ ใช้ OAuth เมื่อใช้การส่งจากไคลเอ็นต์ เปิด SMTP AUTH ให้แคบ ทดสอบตัวตน envelope และ From ที่แน่นอน และถือการยอมรับของ relay แยกจากการส่งถึงขั้นสุดท้ายหรือการเข้ากล่องจดหมาย

รายละเอียด Office 365 SMTP อธิบายเส้นทางหลายแบบ

เอกสารของ Microsoft 365 และ Office 365 แยก client SMTP submission, SMTP relay และ Direct Send Client submission ยืนยันตัวตนเป็นกล่องจดหมาย Exchange Online และส่งผ่าน smtp.office365.com SMTP relay ถือแอปพลิเคชันหรืออุปกรณ์เป็นเซิร์ฟเวอร์อีเมลขององค์กร และยืนยันตัวตนการเชื่อมต่อด้วย inbound connector Direct Send ส่งแบบไม่ระบุตัวตนไปยัง endpoint MX ของ Microsoft 365 ของ tenant สำหรับผู้รับในองค์กร ทั้งสามเป็นผลิตภัณฑ์ที่ต่างกันในการดำเนินงานเบื้องหลังคำสั่ง SMTP ที่คล้ายกัน อย่าคัดลอกชื่อโฮสต์และพอร์ตจากฟอรัมโดยไม่ตัดสินใจก่อนว่าต้องการเส้นทางใด ให้บันทึก tenant โดเมนที่ยอมรับ ผู้ดูแล ปริมาณงาน ตัวตนผู้ส่ง เครือข่ายต้นทาง ขอบเขตผู้รับ วิธียืนยันตัวตน นโยบาย TLS ปริมาณ และเจ้าของความล้มเหลวก่อน การขนส่ง SMTP ไม่ได้อนุญาตอีเวนต์ทางธุรกิจต้นทาง สร้างความยินยอมของผู้รับ หรือทำให้คิวของแอปพลิเคชันคงทน

การตั้งค่า client SMTP submission

คู่มือการตั้งค่าปัจจุบันของ Microsoft ระบุ smtp.office365.com เป็นชื่อ DNS สำหรับ client submission และระบุว่าไม่ให้แทนที่ด้วยที่อยู่ IP แนะนำพอร์ต TCP 587 อนุญาตพอร์ต 25 ในสถานการณ์ที่ระบุ และต้องใช้ TLS 1.2 หรือ TLS 1.3 พร้อมเปิด STARTTLS แอปพลิเคชันยืนยันตัวตนเป็นกล่องจดหมาย Microsoft 365 หรือ Office 365 ที่มีใบอนุญาต และส่งถึงผู้รับภายในและภายนอกได้ภายในขีดจำกัดที่ระบุ ใช้ที่อยู่กล่องจดหมายเป็นตัวตนที่ชัดเจน และทดสอบสิทธิ์ Send As เมื่อ From ที่มองเห็นต่างออกไป เก็บข้อมูลรับรองหรือโทเค็นไว้ใน secret manager ฝั่งเซิร์ฟเวอร์ การล็อกอินบัญชีสำเร็จไม่ได้พิสูจน์ว่า From ที่มองเห็นได้รับอนุญาต ผู้รับถูกต้อง หรือข้อความจะเข้ากล่องจดหมาย Client submission เป็นเส้นทางที่จำกัดขอบเขตตามกล่องจดหมาย ดังนั้นการระงับผู้ใช้ การเปลี่ยนใบอนุญาต การตัดสิน conditional access และการตั้งค่า SMTP AUTH อาจขัดจังหวะแอปพลิเคชันที่ไม่ได้เปลี่ยนแปลงอะไร

ใช้ OAuth และเปิด SMTP AUTH อย่างจำกัด

Microsoft แนะนำ Modern authentication ด้วย OAuth สำหรับ client SMTP submission เอกสาร OAuth ของ Microsoft กำหนดขอบเขต SMTP.Send และรูปแบบ SASL XOAUTH2 พร้อมโฟลว์แบบ delegated และแบบเน้นแอปพลิเคชันที่ขึ้นกับการลงทะเบียน Microsoft Entra และสิทธิ์ของ Exchange ถือโทเค็นการเข้าถึงและโทเค็นรีเฟรชเป็นความลับ ขอเฉพาะสิทธิ์ที่จำเป็น ตรวจสอบการผูก tenant และกล่องจดหมาย หมุนเวียนข้อมูลรับรองของแอปพลิเคชัน และลบสิทธิ์ที่ไม่ใช้ Microsoft ยังแนะนำให้ปิด SMTP AUTH สำหรับองค์กร Exchange Online และเปิดเฉพาะกล่องจดหมายที่ยังต้องใช้ มีทั้งการตั้งค่าระดับองค์กรและการแทนที่รายกล่องจดหมาย และการตั้งค่ารายกล่องจดหมายอาจมีลำดับความสำคัญสูงกว่า Security defaults ปิด SMTP AUTH อย่าปิดฐานความปลอดภัยทั้ง tenant เพียงเพื่อรักษาอุปกรณ์เก่าเครื่องเดียว ให้ใช้ connector ไคลเอนต์สมัยใหม่ที่รองรับ รีเลย์ในองค์กร หรือบริการอื่นที่ระบุไว้ เมื่อปริมาณงานไม่เป็นไปตามข้อกำหนด OAuth และ TLS

ขีดจำกัดของ client submission ส่งผลต่อการออกแบบแอปพลิเคชัน

การเปรียบเทียบปัจจุบันของ Microsoft ระบุการจำกัดอัตรา client SMTP submission ที่ 10,000 ผู้รับต่อวันและ 30 ข้อความต่อนาที ถือค่าเหล่านี้เป็นขีดจำกัดบริการปัจจุบันที่อาจเปลี่ยนแปลงและอาจเกี่ยวข้องกับขีดจำกัดอื่นของ Exchange Online นับผู้รับ ไม่ใช่แค่ข้อความ ข้าม To, Cc, Bcc การลองใหม่ และ fan-out วางการควบคุมอัตราของแอปพลิเคชัน ความเป็นธรรมระหว่าง tenant concurrency ความพยายาม และอายุคิวไว้ต่ำกว่าเพดานของบริการ เส้นทางกล่องจดหมายที่ใช้ร่วมกันอาจเกิดการแย่งใช้ระหว่างการใช้งานโดยมนุษย์และอัตโนมัติ ขณะที่ข้อมูลรับรองเดียวที่หลายแอปพลิเคชันใช้ซ่อนความเป็นเจ้าของ ติดตามอัตราและช่องว่างของผู้รับ แต่ห้ามหลบขีดจำกัดโดยการสลับกล่องจดหมายหรือโดเมนผู้ส่ง หากปริมาณงานเข้าใกล้ขีดจำกัดการส่งของกล่องจดหมายเป็นประจำ ให้ประเมิน connector relay, High Volume Email สำหรับทราฟฟิกภายในที่เข้าเกณฑ์, Azure Communication Services Email สำหรับการส่งของแอปพลิเคชัน หรือการขนส่งเฉพาะทางอื่น โดยใช้คำแนะนำปัจจุบันของ Microsoft

รายละเอียด SMTP relay แบบ connector

SMTP relay ของ Microsoft 365 ใช้ endpoint MX ของ tenant แทน smtp.office365.com และ inbound connector ที่ระบุระบบส่งขององค์กร Microsoft แนะนำให้ยืนยันตัวตน connector ด้วยใบรับรอง TLS โดยที่อยู่ IP แบบคงที่สาธารณะเป็นวิธีระบุตัวตนอีกแบบที่ระบุไว้ แอปพลิเคชันเชื่อมต่อที่พอร์ต TCP 25 และส่งจากที่อยู่ในโดเมนที่ยอมรับได้โดยไม่ต้องมีกล่องจดหมายที่มีใบอนุญาตสำหรับผู้ส่งแต่ละราย รูปแบบนี้เหมาะกับเซิร์ฟเวอร์อีเมล อุปกรณ์ หรือเกตเวย์ที่ควบคุมได้ซึ่งมีความเป็นเจ้าของใบรับรองและเครือข่ายที่คงที่ ต้องดูแลมากกว่า ได้แก่ ขอบเขตของ connector วงจรชีวิตใบรับรอง การเปลี่ยน IP สาธารณะ reverse DNS นโยบายโดเมนที่ยอมรับ การป้องกันการละเมิด และการติดตาม blocklist ห้ามสร้าง open relay จำกัดว่าเกตเวย์ยอมรับระบบภายใน tenant ผู้ส่ง ผู้รับ และประเภทข้อความใดบ้าง connector รู้จักการเชื่อมต่อว่าเป็นขององค์กร แต่ไม่ได้ตรวจสอบว่าอินพุตของแอปพลิเคชันโดยพลการนั้นถูกต้อง

Direct Send คือการส่งถึงผู้รับภายใน ไม่ใช่รีเลย์ทั่วไป

Direct Send ส่งไปยัง endpoint MX ของ tenant ในฐานะเซิร์ฟเวอร์ SMTP ภายนอกโดยไม่ยืนยันตัวตนเป็นกล่องจดหมายหรือ connector Microsoft ระบุไว้สำหรับการส่งถึงผู้รับในองค์กร Microsoft 365 หรือ Office 365 ไม่ใช่เส้นทางไปยังที่อยู่ภายนอกโดยพลการ อุปกรณ์หรือแอปพลิเคชันต้องเข้าถึงพอร์ต TCP 25 ได้และควรใช้ผู้ส่งในโดเมนที่ยอมรับ เนื่องจากเส้นทางไม่ระบุตัวตนจากมุมมองของบริการที่หันหน้าสู่อินเทอร์เน็ต ชื่อเสียงผู้ส่ง DNS IP ต้นทาง และการตัดสินใจด้านการป้องกันการปลอมแปลงจึงสำคัญ อย่าเปิดเผยเกตเวย์ Direct Send ให้เครือข่ายที่ไม่น่าเชื่อถือ หรือใช้หลบการยืนยันตัวตนกล่องจดหมาย ควรสร้างโมเดลรายงานส่งไม่ถึงและความเป็นเจ้าของการซัพพอร์ต เพราะเครื่องพิมพ์หรือแอปพลิเคชันอาจรับข้อความอีเมลตีกลับอย่างปลอดภัยไม่ได้ หากต้องการส่งถึงภายนอก ให้เลือก client submission, connector relay, Azure Communication Services Email หรือวิธีที่รองรับอื่น หลังประเมินตัวตนและปริมาณ

แยกตัวตน envelope, From ที่มองเห็น และการยืนยันตัวตนออกจากกัน

ทุกเส้นทางมี envelope sender ของ SMTP และคำสั่งผู้รับ รวมถึงเฮดเดอร์ที่มองเห็นตาม RFC 5322 envelope sender ควบคุมอีเมลตีกลับระดับการขนส่งและมักเป็นตัวตน SPF ส่วน From ที่มองเห็นควบคุมสิ่งที่ผู้อ่านเห็นและเป็นตัวตนหลักของ DMARC การยืนยันตัวตนกล่องจดหมายด้วย OAuth ตัวตนของ connector หรือการยอมรับ IP ต้นทางไม่สร้าง alignment ของ SPF, DKIM หรือ DMARC โดยอัตโนมัติสำหรับทุกโดเมน From ที่กำหนดเอง ให้สำรวจ MAIL FROM, From, Reply-To, โดเมน d= และ selector ของ DKIM และ IP ที่เชื่อมต่อที่แน่นอนจากตัวอย่างที่ได้รับซึ่งควบคุมได้ เผยแพร่นโยบาย SPF ที่ถูกต้องหนึ่งรายการสำหรับโดเมนที่เกี่ยวข้อง กำหนดค่าการลงลายเซ็น DKIM เมื่อรองรับ และประเมิน DMARC alignment อย่าเพิ่มเรคคอร์ด SPF ที่สองหรือผ่อนคลายนโยบาย DMARC ขององค์กรเพื่อซ่อมอุปกรณ์เครื่องเดียว แยกการยอมรับโดย Microsoft การยอมรับโดยเซิร์ฟเวอร์ปลายทาง อีเมลตีกลับภายหลัง การกรองกล่องจดหมาย การเข้ากล่องจดหมาย และการกระทำของมนุษย์ในโมเดลสถานะ

สร้างขอบเขตของแอปพลิเคชันที่คงทน

วาง SMTP ของ Microsoft 365 ไว้หลัง worker ฝั่งเซิร์ฟเวอร์ที่ได้รับอนุญาตหรือรีเลย์ที่ควบคุมได้ บันทึกอีเวนต์ทางธุรกิจก่อนเชื่อมต่อ รวมถึง idempotency key ที่คงที่ tenant ประเภทข้อความ การแก้ไขเทมเพลต ผู้ส่งและผู้รับที่ได้รับอนุมัติ ฐานความยินยอมหรือความจำเป็น สถานะการระงับการส่ง และประวัติความพยายาม บังคับใช้กฎผู้ส่งและผู้รับรายต่อ tenant ก่อนสร้างคำสั่ง SMTP จำกัดขนาดข้อความ fan-out ของผู้รับ ไฟล์แนบ และค่าเฮดเดอร์ เก็บโทเค็น รหัสผ่าน คีย์ส่วนตัวของใบรับรอง และการดูแล connector ไว้นอกซอร์ส ล็อก ระบบวิเคราะห์ ตั๋ว และพรอมต์ ตั้ง timeout ที่จำกัด และจัดประเภทการตอบกลับ 4xx เป็นตัวเลือกสำหรับการลองใหม่ที่มีขอบเขต และ 5xx เป็นถาวรสำหรับความพยายามนั้น โดยใช้การวินิจฉัยแบบขยายที่สมบูรณ์และคำแนะนำของ Microsoft การตัดการเชื่อมต่อหลัง DATA แต่ก่อนการตอบกลับสุดท้ายเป็นสถานะกำกวม ให้เก็บความพยายามไว้และกระทบยอดก่อนส่งซ้ำ SMTP ไม่มีการรับประกัน exactly-once ระดับผลิตภัณฑ์

ทดสอบการกำหนดค่าและโหมดความล้มเหลวก่อนเปิดใช้

ใช้ผู้รับที่ควบคุมได้โดยเฉพาะและเครือข่ายต้นทางที่เหมือนระบบจริง ตรวจสอบการแก้ DNS การเข้าถึงพอร์ต การเจรจา STARTTLS ชื่อโฮสต์และเชนของใบรับรอง การขอโทเค็น OAuth และขอบเขต การตั้งค่า SMTP AUTH ระดับองค์กรและกล่องจดหมาย การอนุญาต Send As การจับคู่ connector โดเมนที่ยอมรับ และการเลือก endpoint MX ส่งตัวอย่างข้อความธรรมดา HTML ไฟล์แนบ Unicode อีเมลตีกลับ และปริมาณที่คาดไว้ บันทึกเฮดเดอร์ดิบ Authentication-Results ที่เชื่อถือได้ การตอบกลับ SMTP ตัวระบุ trace และหลักฐาน message trace โดยไม่เก็บเนื้อหาของลูกค้า การทดสอบเชิงลบควรครอบคลุมโทเค็นที่ถูกเพิกถอน ใบรับรอง connector ที่หมดอายุ IP สาธารณะที่เปลี่ยน SMTP AUTH ของกล่องจดหมายที่ปิด Security defaults From ที่ไม่ถูกต้อง ผู้รับภายนอกผ่าน Direct Send ขีดจำกัดต่อนาทีและผู้รับ การเลื่อนชั่วคราว การปฏิเสธถาวร และการเชื่อมต่อขาดรอบ DATA ซ้อมการหยุดปริมาณงานและย้ายงานที่คงทนโดยไม่หลบความล้มเหลวด้านนโยบายถาวรหรือผู้รับ

ใช้คำแนะนำ Microsoft ปัจจุบันและทดสอบ tenant ของคุณ

การกำหนดค่า Microsoft 365 SMTP ขึ้นกับนโยบาย ตัวตน connector และสภาพแวดล้อมเครือข่ายของ tenant ใช้เอกสาร Microsoft Learn ปัจจุบันและทดสอบเส้นทางที่เลือกใน tenant ของคุณก่อนพึ่งพาสำหรับอีเมลระบบจริง

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

ชื่อโฮสต์ client SMTP ของ Microsoft 365 คืออะไร

ปัจจุบัน Microsoft ระบุ smtp.office365.com สำหรับ client submission ที่ยืนยันตัวตน และระบุให้ใช้ชื่อ DNS แทนที่อยู่ IP ของบริการที่ตายตัว

client SMTP submission ควรใช้พอร์ตใด

Microsoft แนะนำพอร์ต TCP 587 และระบุพอร์ต 25 สำหรับสถานการณ์ client submission ที่รองรับ โดยต้องใช้ STARTTLS และ TLS 1.2 หรือ TLS 1.3

client submission ของ Microsoft 365 รองรับ OAuth หรือไม่

รองรับ Microsoft แนะนำ OAuth และระบุขอบเขต SMTP.Send พร้อม SASL XOAUTH2 การลงทะเบียน tenant สิทธิ์ การดูแลโทเค็น และการผูกกล่องจดหมายยังต้องกำหนดค่าอย่างระมัดระวัง

SMTP relay และ Direct Send ต่างกันอย่างไร

Connector relay ยืนยันตัวตนระบบอีเมลขององค์กรและรองรับผู้รับภายนอกได้ Direct Send ใช้ endpoint MX ของ tenant โดยไม่มี connector นั้นและมีไว้สำหรับผู้รับภายใน

ควรเปิด SMTP AUTH สำหรับทุกกล่องจดหมายหรือไม่

ไม่ Microsoft แนะนำให้ปิดทั้งองค์กรและเปิดเฉพาะกล่องจดหมายที่ยังต้องใช้ พร้อมให้ความสำคัญกับการยืนยันตัวตนสมัยใหม่และทางเลือกที่รองรับ

การที่ SMTP ของ Office 365 ยอมรับหมายความว่าเข้ากล่องจดหมายหรือไม่

ไม่ การยอมรับเป็นผลลัพธ์ของการขนส่งที่มีขอบเขต การส่งถึงภายหลัง การส่งไม่ถึง การกรองของผู้รับ การเข้าโฟลเดอร์กล่องจดหมาย และการมีส่วนร่วมของมนุษย์ยังเป็นหลักฐานแยกกัน

แอปพลิเคชันใช้พอร์ต 465 สำหรับ client submission ของ Microsoft ได้หรือไม่

คู่มือปัจจุบันของ Microsoft ระบุว่าอุปกรณ์ที่ใช้พอร์ต 465 เป็นค่าเริ่มต้นไม่รองรับ TLS เวอร์ชันที่จำเป็นสำหรับ client submission บนเส้นทาง Microsoft 365 นี้

ฉันควรตรวจสอบการกำหนดค่า Microsoft 365 SMTP ที่ใด

ใช้เอกสาร Microsoft Learn ปัจจุบันและทดสอบเส้นทางที่เลือกใน tenant ของคุณก่อนพึ่งพาสำหรับอีเมลระบบจริง