หน้าแนะนำ · บริการ smtp relay

ทีมผลิตภัณฑ์ควรประเมินอะไรเมื่อเลือกบริการ SMTP relay

ประเมินบริการ SMTP relay ในฐานะระบบส่งข้อความและการปฏิบัติงานที่ควบคุมได้ ไม่ใช่เพียงชื่อโฮสต์และพอร์ต ตรวจสอบ TLS แบบบังคับ พอร์ต submission ที่รองรับ การควบคุม SMTP AUTH การแยกข้อมูลรับรอง การยืนยันโดเมนผู้ส่ง ความคงทนของคิว พฤติกรรม 4xx และ 5xx ที่มีเอกสาร โควตา ขีดจำกัดขนาดข้อความ อีเวนต์สถานะการส่ง การจัดการอีเมลตีกลับและการร้องเรียน ขอบเขตการระงับการส่ง การแยกผู้เช่า การสังเกตการณ์ และความสามารถในการส่งออก ทดสอบไคลเอนต์และเครือข่ายที่จะเชื่อมต่อจริง การตอบกลับ 250 ของรีเลย์เป็นการโอนความรับผิดชอบในการจัดการต่อ ไม่ได้พิสูจน์การส่งถึงเซิร์ฟเวอร์ผู้รับหรือการเข้ากล่องจดหมาย

แยก submission ออกจากรีเลย์ระหว่างเซิร์ฟเวอร์

ทีมผลิตภัณฑ์มักใช้คำว่า “SMTP relay” เพื่อหมายถึงบริการที่ผ่านการยืนยันตัวตนซึ่งรับข้อความขาออกจากแอปพลิเคชันและถ่ายโอนไปยังเมลเซิร์ฟเวอร์ของผู้รับ มาตรฐานแยกบทบาท submission นั้นออกจากรีเลย์ระหว่างเมลเซิร์ฟเวอร์ RFC 6409 สงวนพอร์ต 587 สำหรับการส่งข้อความ และอนุญาตให้เซิร์ฟเวอร์ submission ใช้กฎการยืนยันตัวตน นโยบาย และการแก้ไขข้อความที่ต่างจากรีเลย์ที่พอร์ต 25 ให้ถามผู้ให้บริการแต่ละรายว่าคุณกำลังซื้ออินเทอร์เฟซแบบใด ได้แก่ submission ที่ยืนยันตัวตนสำหรับแอปพลิเคชัน รีเลย์ขาเข้าระหว่างเซิร์ฟเวอร์ หรือทั้งสองแบบ บันทึกชื่อโฮสต์ พอร์ต โหมดการเข้ารหัส กลไกการยืนยันตัวตน กฎของผู้ส่ง และส่วนขยาย SMTP ที่รองรับ บริการที่ใช้ได้กับไคลเอนต์เดสก์ท็อปอาจไม่เหมาะกับคิวปริมาณสูง ขณะที่รีเลย์เซิร์ฟเวอร์อาจปฏิเสธการยืนยันตัวตนของแอปพลิเคชัน ให้ทดสอบบทบาทที่แน่นอน แทนการสมมติว่า SMTP endpoint ทุกตัวทำงานเหมือนกัน

กำหนดให้ submission ต้องได้รับการปกป้องและยืนยันตัวตนอย่างปลอดภัย

อย่าส่งข้อมูลรับรองหรือเนื้อหาข้อความผ่านการเชื่อมต่อที่ไม่ได้รับการปกป้อง RFC 8314 ถือว่า submission แบบ cleartext ล้าสมัย แนะนำ TLS 1.2 ขึ้นไปสำหรับทราฟฟิก submission และให้ความสำคัญกับ implicit TLS เมื่อรองรับ RFC 4954 นิยาม SMTP AUTH และกำหนดให้เซิร์ฟเวอร์เสนอการตั้งค่าที่ไม่อนุญาตกลไกรหัสผ่านแบบข้อความล้วนโดยไม่มี TLS หรือการป้องกันเทียบเท่า ระหว่างการประเมิน ให้ยืนยันการตรวจสอบใบรับรอง เวอร์ชัน TLS ที่รองรับ พอร์ต implicit-TLS และ STARTTLS พฤติกรรม downgrade และว่าการยืนยันตัวตนถูกปฏิเสธก่อนเข้ารหัสหรือไม่ เก็บข้อมูลรับรองของรีเลย์ไว้ในที่เก็บความลับฝั่งเซิร์ฟเวอร์ สร้าง principal แยกสำหรับแต่ละสภาพแวดล้อมและแอปพลิเคชัน และหมุนเวียนโดยไม่มี downtime พิจารณาว่าสิทธิ์จำกัดโดเมนผู้ส่งหรือประเภทข้อความได้หรือไม่ ข้อมูลรับรองร่วมตัวเดียวข้ามผู้เช่าในระบบจริงทำให้การเพิกถอน การระบุที่มา และการจำกัดเหตุการณ์ผิดปกติกว้างเกินความจำเป็น

ตรวจสอบความเข้ากันได้ของไคลเอนต์และเครือข่าย

ตรวจสอบผู้ส่งทุกรายก่อนเลือกรีเลย์ ได้แก่ ไลบรารีของแอปพลิเคชัน queue worker อุปกรณ์เฝ้าติดตาม ซอฟต์แวร์ธุรกิจ อุปกรณ์มัลติฟังก์ชัน และระบบเดิม บางตัวรองรับพอร์ต 587 กับ STARTTLS บางตัวต้องใช้ implicit TLS และบางตัวตรวจสอบใบรับรองสมัยใหม่หรือยืนยันตัวตนอย่างปลอดภัยไม่ได้ ข้อจำกัดนั้นเป็นเหตุผลให้แยกหรือเปลี่ยนไคลเอนต์ ไม่ใช่ให้ลดความเข้มงวดของบัญชีรีเลย์ทั้งระบบ ทดสอบการ resolve DNS IPv4 และ IPv6 กฎไฟร์วอลล์ขาออก timeout ของการเชื่อมต่อ พฤติกรรมพร็อกซี การเจรจา TLS AUTH ส่วนขยาย EHLO ขีดจำกัดขนาดข้อความ และที่อยู่แบบสากลหากจำเป็น สภาพแวดล้อมคลาวด์อาจจำกัดพอร์ต 25 พอร์ต submission สำรองของผู้ให้บริการจึงมีความสำคัญในการปฏิบัติงาน ให้ทดสอบความเข้ากันได้จากเครือข่ายระบบจริงแต่ละแห่ง ไม่ใช่จากแล็ปท็อปของนักพัฒนา จัดทำเอกสารการตั้งค่าที่รองรับ และบล็อกการถอยกลับไปใช้ cleartext หรือชื่อโฮสต์ที่ไม่ได้รับอนุมัติ

เข้าใจการยอมรับ คิว และการลองใหม่

รหัสตอบกลับ SMTP เป็นส่วนหนึ่งของสัญญาของแอปพลิเคชัน 2xx บ่งบอกความสำเร็จของคำสั่งนั้น หลังจากยอมรับข้อความขั้นสุดท้าย รีเลย์รับผิดชอบการส่งหรือการแจ้งความล้มเหลวภายหลังตามกฎ SMTP การตอบกลับ 4xx เป็นชั่วคราวและสมเหตุสมผลที่จะลองใหม่ ส่วน 5xx เป็นถาวรสำหรับคำสั่งที่พยายาม และโดยปกติต้องแก้ไขแทนการทำซ้ำ ให้ถามว่าบริการเก็บข้อความในคิวนานเท่าใด ลองใหม่กับความล้มเหลวประเภทใด ตาราง backoff เป็นอย่างไร สร้างการแจ้งสถานะการส่งเมื่อใด และเมลที่อยู่ในคิวรอดจากความล้มเหลวระดับ region หรือไม่ แอปพลิเคชันของคุณยังต้องมีตัวระบุงานที่คงที่ การลองเชื่อมต่อใหม่แบบมีขอบเขต และการป้องกันผลลัพธ์ที่กำกวม หากการเชื่อมต่อขาดหลัง DATA การสร้างงานใหม่แบบไม่ดูสถานการณ์อาจทำให้เมลซ้ำ ให้บันทึกตัวระบุข้อความของรีเลย์เมื่อมี และกระทบยอดก่อนส่งซ้ำ

วัดความจุด้วยหน่วยที่ถูกต้อง

ขีดจำกัดของรีเลย์อาจใช้กับผู้รับต่อวันแบบเลื่อน ข้อความต่อวินาที การเชื่อมต่อพร้อมกัน ผู้รับต่อธุรกรรม ไบต์ต่อข้อความ ขนาดไฟล์แนบหลังเข้ารหัส และความลึกของคิวที่จัดเก็บ แพ็กเกจที่โฆษณายอดรวมรายเดือนสูงก็ยังอาจ throttle ช่วงพุ่งตอนเปิดตัวหรือการ failover ขอขีดจำกัดปัจจุบันของแต่ละบัญชีและ Region แล้วจำลองทราฟฟิกปกติ สูงสุด การลองใหม่ และ failover เต็มรูปแบบตามผู้รับ ไม่ใช่เพียงเซสชัน SMTP พิจารณาว่ารีเลย์ตอบกลับชั่วคราวเมื่อถูก throttle หรือไม่ และไคลเอนต์ของคุณปฏิบัติตามโดยไม่เปิดการเชื่อมต่อมากเกินไปหรือไม่ ทดสอบ backpressure ให้ต่ำกว่าเพดานที่ได้รับอนุมัติ และแจ้งเตือนเมื่อโควตาคงเหลือ การเชื่อมต่อเต็ม อายุคิว และการตอบกลับ throttle อย่าเพิ่มการทำงานพร้อมกันจนกว่าผู้ให้บริการและระบบนิเวศของผู้รับจะรองรับทราฟฟิกได้ ความจุยังเป็นขอบเขตการป้องกันการละเมิดด้วย จึงควรประเมินการควบคุมรายข้อมูลรับรองและรายผู้เช่า ไม่ใช่เพียงค่าสูงสุดระดับบัญชีเดียว

ตรวจสอบการยืนยันตัวตนผู้ส่งและการ onboard โดเมน

รีเลย์ควรมีขั้นตอน onboard โดเมนที่ชัดเจนและตรวจสอบได้ ยืนยันว่ามีวิธีตรวจสอบความเป็นเจ้าของ สร้าง DKIM selector ตั้งค่าโดเมน MAIL FROM ของ envelope และรายงานสถานะการยืนยันตัวตนอย่างไร SPF อนุญาตตัวตน SMTP และต้องรวมเข้ากับเรคคอร์ดที่ถูกต้องเดิม ไม่ใช่เผยแพร่เป็นเรคคอร์ด SPF ที่เลือกได้ตัวที่สอง DKIM เชื่อมโยงโดเมนที่ลงลายเซ็นกับลายเซ็นเข้ารหัส DMARC ประเมินว่าตัวระบุ SPF หรือ DKIM ที่สำเร็จ align กับโดเมน From ที่มองเห็นหรือไม่ และให้เจ้าของโดเมนเผยแพร่นโยบายและรับรายงาน ถามว่าใครควบคุมคีย์ลงลายเซ็น การหมุนเวียน selector การ align ของ return-path และการเปลี่ยน DNS ระหว่างการย้ายระบบ ส่งข้อความทดสอบแบบควบคุมและตรวจสอบเฮดเดอร์ที่ได้รับก่อนใช้งานจริง แดชบอร์ดที่แสดง “verified” ไม่ได้พิสูจน์ว่าทุกสตรีมที่ถูกต้อง align แล้ว และการยืนยันตัวตนไม่ได้กำหนดการเข้ากล่องจดหมาย

เรียกร้องอีเวนต์ผลลัพธ์ที่ใช้งานได้และการเชื่อมโยง

SMTP submission อย่างเดียวให้เพียงการตอบกลับของคำสั่ง ขณะที่การปฏิบัติงานของผลิตภัณฑ์ต้องการผลลัพธ์ภายหลัง ให้ประเมินว่าบริการเปิดอีเวนต์การส่งถึงเซิร์ฟเวอร์ผู้รับ อีเมลตีกลับ การร้องเรียน การปฏิเสธ ความล่าช้า และการระงับการส่งผ่าน webhook ที่ยืนยันตัวตน คิว หรือ API หรือไม่ พิจารณาตัวระบุอีเวนต์ พฤติกรรมการลองใหม่ การรับประกันลำดับ การเก็บรักษา การยืนยันลายเซ็น และว่าปกปิดรายละเอียดผู้รับได้หรือไม่ RFC 3461 นิยามส่วนขยาย SMTP สำหรับขอการแจ้งสถานะการส่งภายใต้เงื่อนไขที่เลือก แต่ระบบอีเวนต์ของผู้ให้บริการอาจให้ข้อมูลการปฏิบัติงานแบบมีโครงสร้างมากกว่า แมปรหัสงานของแอปพลิเคชันกับรหัสข้อความของรีเลย์ ณ เวลาที่ยอมรับ แล้วรับอีเวนต์แบบ idempotent แยกแนวคิดการยอมรับ การส่งถึงเมลเซิร์ฟเวอร์ผู้รับ การร้องเรียน อีเมลตีกลับ และการเข้ากล่องจดหมายออกจากกัน การสังเกตการเปิดและการคลิกต้องมีการทบทวนด้านความเป็นส่วนตัวแยกต่างหาก และไม่ควรเขียนทับความจริงของ transport

ประเมินขอบเขตการระงับการส่งและชื่อเสียง

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

ทดสอบการแยกผู้เช่า การสังเกตการณ์ และการกู้คืนจากความล้มเหลว

สร้างผู้เช่าทดสอบสองราย และพิสูจน์ว่าข้อมูลรับรองแต่ละชุดส่งได้เฉพาะจากโดเมนที่ได้รับอนุมัติ ดูได้เฉพาะข้อความของตน และใช้เฉพาะขีดจำกัดของตน ลองที่อยู่ From ที่ไม่ได้รับอนุญาต ข้อมูลรับรองที่ถูกเพิกถอน ข้อความขนาดเกิน ผู้รับไม่ถูกต้อง การละเมิด rate limit ความล้มเหลวของ TLS การหมดเวลาของเครือข่าย การส่งซ้ำ ผู้รับที่ตีกลับ การร้องเรียน การส่งที่ล่าช้า และ webhook ซ้ำ ตรวจสอบว่าบันทึกมีรหัสข้อความที่คงที่ ผู้เช่า ประเภทการตอบกลับที่ทำความสะอาดแล้ว จำนวนความพยายาม และเวลา โดยไม่คัดลอกข้อมูลรับรองหรือเนื้อหาข้อความ ขอประวัติสถานะ การสื่อสารเหตุการณ์ พฤติกรรม failover ระดับ region ที่ตั้งของข้อมูล การเก็บรักษา รูปแบบการส่งออก และการยกระดับซัพพอร์ตจากผู้ให้บริการ การอ้างระดับบริการมีประโยชน์เมื่อแอปพลิเคชันตรวจพบการละเมิดและกู้คืนได้เท่านั้น ทำแบบฝึก failover พร้อมข้อความในคิว และพิสูจน์ว่าการตั้งค่าสำรองมีโดเมนที่ยืนยันแล้ว ข้อมูลรับรอง โควตา อีเวนต์ และสถานะการระงับการส่ง

เปรียบเทียบ SMTP relay กับ email API

การส่ง SMTP มีคุณค่าเมื่อซอฟต์แวร์เดิมสื่อสาร SMTP อยู่แล้ว หรือเมื่ออินเทอร์เฟซขนส่งอีเมลที่เป็นกลางต่อผู้ให้บริการมีความสำคัญ HTTPS Email API สามารถให้การตรวจสอบที่มีโครงสร้าง ตัวระบุ resource semantics แบบ batch และ resource อีเวนต์โดยตรงที่แอปพลิเคชันใหม่ควบคุมได้ง่ายกว่า ทีมที่ต้องการความเข้ากันได้กับ SMTP เดิมควรเลือก relay ที่มีเอกสารกำกับ หรือสร้าง adapter ที่ควบคุมอย่างเข้มงวด ทีมที่สร้างเวิร์กโฟลว์ผลิตภัณฑ์ใหม่สามารถเปรียบเทียบชั้น API ด้านการอนุญาต คิว อีเวนต์ ขอบเขต tenant ต้นทุนการย้ายระบบ และความเป็นเจ้าของด้านปฏิบัติการ แทนการคิดว่า SMTP พกพาได้มากกว่าโดยอัตโนมัติ

ทำการประเมินรีเลย์แบบมีคะแนน

สร้างเมทริกซ์ข้อกำหนดก่อนขอข้อเสนอ ให้น้ำหนักความปลอดภัยของ submission ความเข้ากันได้ของไคลเอนต์ การ onboard โดเมน การ align ของการยืนยันตัวตน ความคงทนของคิว ความหมายของการลองใหม่ โควตา ความครบถ้วนของอีเวนต์ การยืนยัน webhook ขอบเขตการระงับการส่ง การแยกผู้เช่า การสังเกตการณ์ การจัดการข้อมูล การออกแบบระดับ region ซัพพอร์ต ความสามารถในการส่งออก และต้นทุนการดำเนินงานรวม แยกความล้มเหลวเด็ดขาดออกจากความชอบ ได้แก่ การถอยไปใช้ cleartext ไม่มีเส้นทางอีเมลตีกลับหรือการร้องเรียน อีเวนต์ที่ตรวจสอบไม่ได้ ข้อมูลรับรองร่วม ไม่มีการตรวจสอบความเป็นเจ้าของโดเมน หรือขีดจำกัดต่ำกว่าความต้องการสูงสุด ไม่ควรถูกเฉลี่ยทิ้งด้วยราคาต่ำ รันชุดทดสอบแบบควบคุมเดียวกันกับทุกตัวเลือกสุดท้าย และเก็บบันทึกการสนทนาที่ลบความลับแล้ว ให้คะแนนพฤติกรรมที่มีเอกสารในปัจจุบัน ไม่ใช่คำสัญญาใน roadmap ก่อนย้ายระบบ ให้ซ้อมการส่งคู่ที่ปริมาณต่ำ การเปลี่ยน DNS การกระทบยอดอีเวนต์ การโอนการระงับการส่ง การหมุนเวียนข้อมูลรับรอง การย้อนกลับ และการเพิกถอนรีเลย์เดิมขั้นสุดท้าย

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

SMTP submission ต่างจากรีเลย์อย่างไร

Submission รับเมลขาออกจากไคลเอนต์ที่ยืนยันตัวตนแล้ว โดยปกติใช้พอร์ต 587 และนโยบายเฉพาะ submission ส่วนรีเลย์อธิบายการถ่ายโอนระหว่างเมลเซิร์ฟเวอร์ ซึ่งมักใช้พอร์ต 25 พร้อมกฎความน่าเชื่อถือและการกำหนดเส้นทางที่ต่างออกไป

SMTP relay ควรบังคับ TLS หรือไม่

ควรสำหรับ submission ของแอปพลิเคชัน ให้บังคับ TLS ที่ตรวจสอบใบรับรอง และปฏิเสธการใช้ข้อมูลรับรองหรือการส่งข้อความเมื่อไม่มีระดับความลับตามที่ตั้งค่า ทดสอบทั้งพอร์ตที่รองรับและพฤติกรรม downgrade

SMTP 250 หมายความว่าผู้รับได้รับข้อความแล้วหรือไม่

ไม่ หมายความว่าเซิร์ฟเวอร์ยอมรับความรับผิดชอบต่อคำสั่ง SMTP หรือข้อความที่เสร็จสมบูรณ์ การแจ้งสถานะการส่งหรืออีเวนต์ของผู้ให้บริการในภายหลังจะอธิบายการส่งถึงเซิร์ฟเวอร์ผู้รับ อีเมลตีกลับ การร้องเรียน ความล่าช้า หรือการปฏิเสธ

แอปพลิเคชันควรลองใหม่เมื่อ SMTP ล้มเหลวอย่างไร

ลองใหม่กับ 4xx ชั่วคราวและความล้มเหลวของเครือข่ายด้วย backoff แบบมีขอบเขตและตัวตนของงานที่คงที่ แก้ความล้มเหลว 5xx ก่อนลองอีกครั้ง และกระทบยอดความล้มเหลวหลัง DATA ที่กำกวมเพื่อหลีกเลี่ยงข้อความซ้ำ

SMTP relay จัดการ DKIM, SPF และ DMARC หรือไม่

ความสามารถต่างกัน ให้ยืนยันว่าใครลงลายเซ็น DKIM ใช้โดเมน MAIL FROM ใด ต้องใช้ SPF mechanism ใด และ SPF หรือ DKIM align กับโดเมน From ที่มองเห็นสำหรับ DMARC หรือไม่

เมื่อใดที่ email API เหมาะกว่า SMTP relay

API เหมาะกว่าสำหรับแอปพลิเคชันใหม่ที่ต้องการการตรวจสอบแบบมีโครงสร้าง ตัวระบุรีซอร์ส การอนุญาตผู้เช่าที่ชัดเจน ผลลัพธ์แบบชุด และรีซอร์สอีเวนต์ SMTP ยังมีประโยชน์สำหรับซอฟต์แวร์เดิมที่รองรับ SMTP

แหล่งอ้างอิง

เรียนรู้ต่อ

โปรโตคอลเมล SMTP: อีเมลของแอปพลิเคชันเดินทางอย่างไรเรียนรู้ว่าการส่งผ่าน SMTP การรีเลย์ envelope รหัสตอบกลับ TLS การลองใหม่ และเนื้อหาข้อความกำหนดเวิร์กโฟลว์อีเมลของแอปพลิเคชันอย่างไรคู่มือการใช้งาน Email API สำหรับทีมผลิตภัณฑ์ออกแบบการเชื่อมต่อ email API ที่ปลอดภัยด้วยโดเมนที่ยืนยันแล้ว การส่งแบบเข้าคิว ตัวระบุที่คงที่ การลองใหม่ที่ควบคุมได้ อีเวนต์การส่ง การระงับการส่ง และการแยกผู้เช่า