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

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

เลือก SMTP relay ของ Google Workspace ก็ต่อเมื่อโมเดลด้านการบริหาร ตัวตน และโควตาของมันเหมาะกับงาน ยืนยันว่าใครเป็นเจ้าของโดเมน Workspace และการตั้งค่าใน Admin console แอปพลิเคชันใช้ IP สาธารณะที่คงที่และอยู่ใน allowlist หรือ SMTP authentication ที่ป้องกันด้วย TLS ได้หรือไม่ envelope sender ใดได้รับอนุญาต และบังคับใช้ TLS อย่างไร จำลองขีดจำกัดปัจจุบันของ Google ต่อผู้ใช้ ต่อลูกค้า และต่อธุรกรรมก่อนเปิดใช้ ทดสอบข้อผิดพลาดชั่วคราวและถาวร เก็บการตอบกลับ SMTP ยืนยันตัวตนของผู้ส่งที่มองเห็นด้วย SPF, DKIM และ DMARC และแยกการยอมรับ การส่งถึงเซิร์ฟเวอร์ปลายทาง และการเข้ากล่องจดหมายเป็นผลลัพธ์ที่ต่างกัน

เริ่มจากความเหมาะสมของงานและการบริหาร

บริการ SMTP relay ของ Google เป็นเส้นทางการบริหารของ Google Workspace สำหรับแอปพลิเคชัน อุปกรณ์ และเมลเซิร์ฟเวอร์ที่ส่งผ่าน smtp-relay.gmail.com ให้ประเมินเป็นส่วนหนึ่งของขอบเขต Workspace และความปลอดภัยของอีเมลขององค์กร ไม่ใช่ endpoint SMTP แบบนิรนามทั่วไป ระบุเจ้าของที่เป็นซูเปอร์แอดมินของ Workspace โดเมนในบัญชี ระบบต้นทาง IP egress สาธารณะ ที่อยู่ผู้ส่ง ประเภทข้อความ ปริมาณผู้รับสูงสุดและรายวัน ลักษณะไฟล์แนบ และผู้ติดต่อเมื่อเกิดเหตุ ตัดสินใจว่างานเป็น transactional, ปฏิบัติการภายใน, ผู้ใช้เขียนเอง, จำนวนมากที่ผู้รับสมัครไว้ หรือสร้างจากอุปกรณ์ แยกประเภทเหล่านี้ออกจากกัน เพราะความต้องการด้านการอนุญาต ความยินยอม การระงับการส่ง การตรวจสอบย้อนหลัง และชื่อเสียงต่างกัน ยืนยันว่าสภาพแวดล้อมระดับล่างใช้เส้นทางของ production หรือที่อยู่ของลูกค้าไม่ได้ relay ขนส่งข้อความที่ได้รับอนุญาตได้ แต่ไม่ได้ตัดสินว่าเหตุการณ์ทางธุรกิจนั้นถูกต้อง ผู้รับยินยอม หรือสถานะแอปพลิเคชันปลายทางควรเดินหน้าหรือไม่

เปรียบเทียบการอนุญาตด้วย IP กับ SMTP authentication

การตั้งค่าปัจจุบันของ Google อนุญาตให้ผู้ดูแลระบบจำกัดการรับ relay เฉพาะที่อยู่ IP สาธารณะที่ระบุ กำหนดให้ใช้ SMTP authentication ผ่าน TLS หรือรวมตัวเลือกนโยบายตามการตั้งค่าที่มีเอกสาร การอนุญาตด้วย IP ที่คงที่เหมาะกับศูนย์ข้อมูลที่ควบคุมได้หรือเกตเวย์ egress คงที่ แต่จะเปราะบางเมื่ออยู่หลัง cloud NAT ที่เปลี่ยนแปลง หลายภูมิภาค บริการ failover หรือเครือข่ายของบุคคลที่สาม SMTP authentication ระบุบัญชี Workspace และโดเมนผู้ส่ง แต่เพิ่มวงจรชีวิตของข้อมูลรับรอง สถานะผู้ใช้ ปฏิสัมพันธ์กับ multi-factor และนโยบาย และข้อกำหนดเด็ดขาดว่าต้องใช้ TLS ห้ามใช้ข้อมูลรับรองกว้างชุดเดียวข้าม tenant หรือแอปพลิเคชันที่ไม่เกี่ยวข้อง สำหรับแต่ละตัวเลือก ให้บันทึกว่าใครเพิ่ม IP หรือบัญชีได้ การเปลี่ยนแปลงถูกทบทวนอย่างไร ตรวจพบการถูกบุกรุกอย่างไร เพิกถอนการเข้าถึงอย่างไร และ failover ทำอะไร ให้ช่วง IP ที่อนุญาตเล็กที่สุดเท่าที่ปฏิบัติได้ และตรวจสอบที่อยู่ egress สาธารณะจากรันไทม์จริง แทนที่จะคัดลอกที่อยู่ภายใน

กำหนดผู้ส่งที่อนุญาตและตัวตนของโดเมน

การตั้งค่า relay ใน Admin console ควบคุมว่าผู้ส่งรายใดได้รับอนุญาต Google ระบุตัวเลือกที่ผูกกับผู้ใช้ Apps ที่ลงทะเบียนและที่อยู่ในโดเมนที่เป็นเจ้าของ รวมถึงตัวเลือกที่อนุญาตทุกที่อยู่ซึ่งเพิ่มความเสี่ยงต่อการละเมิด เลือกตัวเลือกที่แคบที่สุดที่งานทำได้ ตรวจสอบรายการ envelope sender ของ SMTP แยกจากฟิลด์ From และ Reply-To ที่มองเห็น Google ระบุว่าเมื่อผู้ส่งอยู่นอกโดเมนของบัญชี SMTP AUTH หรือโดเมนที่ระบุใน HELO หรือ EHLO อาจส่งผลต่อวิธีที่ envelope sender ถูกระบุหรือเขียนใหม่ อย่าพึ่งการเขียนใหม่แทนโมเดลผู้ส่งที่เป็นเจ้าของ ควรมีการแมปที่อนุมัติแล้วระหว่างแอปพลิเคชัน tenant ประเภทข้อความ envelope sender โดเมน From ที่มองเห็น และ return path บล็อกเฮดเดอร์ที่ผู้ใช้ระบุเอง การแทรกบรรทัดใหม่ และที่อยู่ From ข้าม tenant ก่อนเชื่อมต่อกับ Google ทดสอบการกำหนดเส้นทาง bounce และข้อความ out-of-office รวมถึง envelope sender ที่ว่าง โดยไม่ลดทอนการตั้งค่าทั้งหมด

กำหนดให้มีความปลอดภัยของการขนส่งอย่างตั้งใจ

คู่มือ relay ปัจจุบันของ Google ให้ระบบภายในองค์กรที่รองรับ TLS ไปที่ smtp-relay.gmail.com พอร์ต 587 และอธิบายว่า SMTP authentication ต้องใช้ TLS การตั้งค่าใน Admin ยังกำหนดให้ต้องใช้ TLS สำหรับการเชื่อมต่อจากเซิร์ฟเวอร์ผู้ส่งได้ด้วย เปิดใช้ TLS แบบบังคับสำหรับ production เว้นแต่ข้อจำกัดของระบบเก่าที่มีเอกสารจะได้รับข้อยกเว้นที่มีกำหนดเวลา ตรวจสอบชื่อเซิร์ฟเวอร์ chain ของใบรับรอง นโยบายโปรโตคอลและ cipher ที่รองรับ การเจรจา STARTTLS และพฤติกรรมเมื่อล้มเหลว ไคลเอนต์ต้อง fail closed หากสร้าง TLS ที่จำเป็นไม่ได้ การถอยกลับไปใช้ plaintext อย่างเงียบ ๆ ทำให้นโยบายไร้ผล ปกป้องข้อมูลรับรอง SMTP ในที่เก็บความลับที่มีการจัดการ และไม่ให้อยู่ในบรรทัดคำสั่ง URL ซอร์สโค้ด ล็อก ระบบวิเคราะห์ รายงานการล่ม และตั๋ว TLS ของการขนส่งปกป้องช่วงเชื่อมต่อถึง Google ไม่ใช่วงจรชีวิตของข้อความทั้งหมดหรือกล่องจดหมาย เนื้อหาที่อ่อนไหวอาจต้องมีการควบคุมระดับแอปพลิเคชัน การลดข้อมูล การเก็บรักษา และการตัดสินใจเรื่องการเข้ารหัสแบบ end-to-end แยกต่างหาก

จำลองโควตาปัจจุบันก่อนเลือก relay

เอกสารการตั้งค่า SMTP relay ปัจจุบันของ Google ระบุว่าผู้ใช้แต่ละคนส่งได้สูงสุด 10,000 ข้อความ และไปยังผู้รับที่ไม่ซ้ำกันไม่เกิน 10,000 รายใน 24 ชั่วโมง โดยบัญชีทดลองอาจมีขีดจำกัดต่ำกว่า และยังระบุขีดจำกัด 100 ผู้รับต่อธุรกรรม SMTP พร้อมการควบคุมเพิ่มเติมระดับลูกค้า ช่วงพีค และรายวัน ให้ถือว่าเป็นเพดานที่มีเอกสารในปัจจุบัน ไม่ใช่เป้าหมายความจุหรือสัญญาถาวร ตรวจสอบหน้าทางการซ้ำสำหรับบัญชีและงานของคุณก่อนเปิดใช้ คำนวณผู้รับ ไม่ใช่แค่ข้อความ ทั้ง To, Cc, Bcc การลองใหม่ และ fan-out วางการควบคุมระดับแอปพลิเคชันด้านอัตรา ความพร้อมกัน อายุคิว และความเป็นธรรมของ tenant ไว้ต่ำกว่าขีดจำกัดของ Google แจ้งเตือนเมื่อการใช้เร่งขึ้นและพื้นที่ที่เหลือ อย่าตอบสนองต่อขีดจำกัดด้วยการแบ่งทราฟฟิกไปยังบัญชีที่ไม่ได้รับอนุญาต หมุน envelope sender หรือเปิดการเชื่อมต่อที่ไม่ควบคุม งานที่เข้าใกล้ขอบเขต Workspace ที่ใช้ร่วมกันเป็นประจำอาจต้องประเมินการขนส่งที่สร้างมาเพื่อวัตถุประสงค์นี้โดยเฉพาะ

สร้างเวิร์กโฟลว์การส่งที่ทนทาน

วางไคลเอนต์ SMTP ไว้หลัง server worker หรือคิวที่ได้รับอนุญาต เก็บงานขาออกหนึ่งรายการพร้อม event key ทางธุรกิจที่คงที่ tenant ประเภทข้อความ revision ของเทมเพลต ผู้ส่งและผู้รับที่อนุมัติ ฐานความยินยอมหรือความจำเป็น การตัดสินใจเรื่องการระงับการส่ง และประวัติความพยายาม รับงานนั้นเพียงครั้งเดียว เรนเดอร์และตรวจสอบเนื้อหา แล้วเชื่อมต่อกับ endpoint ของ Google ที่ตั้งค่าไว้ จำกัดผู้รับต่อธุรกรรมและขนาดข้อความตามขีดจำกัดปัจจุบันและนโยบายผลิตภัณฑ์ บันทึกการตอบกลับ SMTP ทั้งหมด รหัสสถานะแบบขยาย โฮสต์ปลายทาง เวลา และตัวระบุความพยายาม โดยไม่บันทึกข้อมูลรับรองหรือเนื้อหาที่ไม่จำเป็น หาก relay ยอมรับธุรกรรม DATA ให้ทำเครื่องหมายเฉพาะขั้นที่ผู้ให้บริการหรือ relay ยอมรับ หากไคลเอนต์ timeout หลังส่งข้อมูลแต่ก่อนเห็นการตอบกลับสุดท้าย ให้คงความพยายามนั้นเป็นสถานะไม่ทราบ และกระทบยอดก่อนส่งซ้ำ SMTP ไม่มี idempotency key ของแอปพลิเคชัน การควบคุมการส่งซ้ำจึงเป็นหน้าที่ของคิวและโมเดลอีเวนต์ของผลิตภัณฑ์

จำแนกข้อผิดพลาดของ relay แทนการลองใหม่ทุกอย่าง

หน้าข้อผิดพลาดของ SMTP relay ของ Google ระบุเงื่อนไขที่แตกต่างกัน ได้แก่ mail relay denied ข้อมูลรับรอง relay หรือการระบุโดเมนไม่ถูกต้อง เกินขีดจำกัดรายวัน การเลื่อนส่งชั่วคราวจากขีดจำกัดช่วงพีค และผู้รับต่อธุรกรรมมากเกินไป บันทึกการตอบกลับที่แน่นอนและแมปกับประเภทภายในที่แคบ แก้ข้อผิดพลาดด้านการตั้งค่า โดเมนผู้ส่ง ข้อมูลรับรอง IP และจำนวนผู้รับต่อธุรกรรมก่อนเล่นซ้ำ หยุดหรือจัดตารางงานใหม่หลังใช้ขีดจำกัดรายวันหมด ลองใหม่ข้อผิดพลาดช่วงพีคหรือการขนส่งชั่วคราวที่เข้าเกณฑ์ด้วย exponential backoff, jitter, เพดานจำนวนครั้ง และขีดจำกัดอายุคิว ห้ามลองใหม่การตอบกลับถาวรไม่รู้จบ หากข้อผิดพลาดระบุ IP ที่ไม่ได้ลงทะเบียน ให้ยืนยัน egress สาธารณะจริงของรันไทม์และการตั้งค่า Workspace ที่ถูกต้อง แทนการขยาย allowlist เก็บจำนวนรวมที่ลดข้อมูลส่วนบุคคลตามระบบต้นทาง revision ของการตั้งค่า โดเมนผู้ส่ง ประเภทสถานะ และเวลา แจ้งเตือนเมื่อพบการตอบกลับใหม่และการยืนยันตัวตนพุ่งสูง เพราะอาจบ่งชี้การเปลี่ยนแปลงของนโยบาย การเพิกถอนข้อมูลรับรอง การเปลี่ยน NAT หรือการละเมิด

ยืนยันตัวตนผู้ส่งเกินกว่าการเข้าถึง relay

การได้รับอนุญาตให้ใช้ relay ของ Google ไม่เหมือนกับการยืนยันตัวตนผู้ส่งที่ผู้รับเห็น เผยแพร่นโยบาย SPF ที่อนุญาตเส้นทางการส่งจริงสำหรับตัวตน envelope ตั้งค่าการลงลายเซ็น DKIM ด้วยโดเมนที่องค์กรควบคุมและ align กับ DMARC และเผยแพร่นโยบาย DMARC ที่ผ่านการทบทวนสำหรับโดเมน From ที่มองเห็น ตรวจสอบข้อความดิบที่ได้รับจากกล่องจดหมายภายนอกที่ควบคุมได้ บันทึกผลและโดเมนของ SPF ผลของ DKIM โดเมน d= และ selector โดเมน From ที่มองเห็น alignment และผล DMARC ลายเซ็นของผู้ให้บริการหรือ Workspace ที่ถูกต้องทางเทคนิคอาจยังไม่ align กับโดเมน From แบบกำหนดเองได้ การส่งต่อก็เปลี่ยนหลักฐาน SPF ได้เช่นกัน อย่าเพิ่มเรคคอร์ด SPF ที่สองหรือลดทอน DMARC ทั้งองค์กรเพียงเพื่อให้การทดสอบหนึ่งผ่าน ประสานงานกับผู้ดูแล DNS และอีเมล เก็บเรคคอร์ดเดิม ทดสอบคำตอบ authoritative และ recursive และทยอยเปลี่ยนตัวตนทีละหนึ่งรายการ

เรียกร้องการสังเกตการณ์ระบบและเส้นทางการออกที่ทดสอบแล้ว

ใช้การค้นหาล็อกอีเมลของ Google Admin และล็อกฝั่ง relay เมื่อมี แต่ให้บัญชีขาออกที่ผลิตภัณฑ์เป็นเจ้าของเป็นระบบตัดสินใจ ติดตามอายุคิว การยอมรับ การตอบกลับชั่วคราวและถาวร การใช้ขีดจำกัด สัญญาณอีเมลตีกลับและการร้องเรียน การยืนยันตัวตน และความหน่วงตามประเภทข้อความและโดเมนผู้ส่ง จำกัดการเข้าถึง และหลีกเลี่ยงที่อยู่เต็มหรือเนื้อหาในเมตริกปกติ ทดสอบการเปลี่ยน IP ต้นทาง การหมุนเวียนข้อมูลรับรอง TLS ล้มเหลว การปิดการตั้งค่าใน Admin การระงับผู้ใช้ การใช้ขีดจำกัดหมด การกระจายผู้รับ การเปลี่ยน DNS และผู้ให้บริการล่ม กำหนดการย้อนกลับที่หยุดกลุ่มที่ได้รับผลกระทบได้โดยไม่ทิ้งงานที่คงทน สำหรับการย้ายระบบ ให้แยกฟิลด์ SMTP เฉพาะผู้ให้บริการไว้ใน adapter เดียว และเก็บ event key ทางธุรกิจ สถานะการระงับการส่ง การอนุญาตผู้ส่ง และประวัติความพยายาม relay ตัวที่สองต้องไม่กลายเป็นทางอ้อมอัตโนมัติสำหรับการปฏิเสธถาวรด้านนโยบายหรือผู้รับ ความเข้ากันได้ต้องมีการทดสอบระดับฟิลด์และระดับข้อผิดพลาด ไม่ใช่แค่เปลี่ยนชื่อโฮสต์

SendHQ เหมาะกับการใช้งานอย่างไร

SendHQ คือ Email API ระดับเวิร์กสเปซสำหรับการสื่อสารผลิตภัณฑ์ที่คาดหวัง พร้อมการส่งจากโดเมนที่ยืนยันแล้ว อีเมลขาเข้า เทมเพลตแบบโฮสต์ อีเวนต์การส่ง การระงับการส่ง และแดชบอร์ดเว็บ เปรียบเทียบกับ Google Workspace SMTP relay ผ่านเอกสารปัจจุบันและการทดสอบแบบควบคุมสำหรับขอบเขตบัญชีและ tenant ข้อมูลรับรองและการหมุนเวียน การบังคับใช้ผู้ส่งที่อนุญาต ตัวตน envelope และที่มองเห็น ความล้มเหลว TLS ขีดจำกัดผู้รับ การตอบกลับชั่วคราวและถาวร ผลลัพธ์กำกวม การระงับการส่ง การอ่านอีเวนต์กลับ และการย้ายระบบ

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

Google Workspace ใช้ชื่อโฮสต์ใดสำหรับ SMTP relay

คู่มือการตั้งค่าปัจจุบันของ Google ใช้ smtp-relay.gmail.com ให้เลือกพอร์ตและพฤติกรรม TLS จากคำแนะนำอย่างเป็นทางการและนโยบายความปลอดภัยที่องค์กรบังคับใช้

จำกัด Google SMTP relay ตาม IP ต้นทางได้หรือไม่

ได้ การตั้งค่าใน Admin สามารถรับเฉพาะที่อยู่ IP สาธารณะที่ระบุได้ ให้จำกัดช่วง IP ให้แคบ และตรวจสอบที่อยู่ egress จริงของรันไทม์และพฤติกรรม failover

SMTP authentication ทำงานโดยไม่มี TLS บน relay นี้ได้หรือไม่

คู่มือปัจจุบันของ Google ระบุว่าการยืนยันตัวตน SMTP ต้องใช้ TLS ไคลเอนต์ใน production ควร fail closed หากการเจรจา TLS ที่จำเป็นหรือการตรวจสอบใบรับรองไม่สำเร็จ

ธุรกรรม SMTP relay หนึ่งรายการมีผู้รับได้กี่ราย

ปัจจุบัน Google ระบุขีดจำกัด 100 ผู้รับต่อธุรกรรมของ smtp-relay.gmail.com ให้ตรวจสอบหน้าทางการซ้ำ เพราะขีดจำกัดของผู้ให้บริการและเงื่อนไขของบัญชีอาจเปลี่ยนแปลง

ควรลองใหม่เมื่อเกิดข้อผิดพลาดขีดจำกัดช่วงพีคของ relay หรือไม่

Google อธิบายว่าการใช้ขีดจำกัดช่วงพีคหมดเป็นภาวะชั่วคราว ให้คงงานที่ทนทานเดิมและใช้ backoff ที่มีขอบเขต jitter เพดานจำนวนครั้ง และขีดจำกัดอายุคิว แทนการกระจายออกทันที

การที่ relay ยอมรับหมายความว่าผู้รับได้รับอีเมลหรือไม่

ไม่ การที่ relay ยอมรับเป็นเพียงขั้นหนึ่งของการขนส่ง การยอมรับของเซิร์ฟเวอร์ปลายทาง อีเมลตีกลับภายหลัง การกรองของกล่องจดหมาย การเข้ากล่องจดหมาย และการมีส่วนร่วมของผู้คน ยังเป็นข้อสังเกตที่แยกจากกัน

การเข้าถึง Google relay แทน SPF, DKIM และ DMARC ได้หรือไม่

ไม่ การอนุญาต relay ควบคุมการใช้บริการของ Google ส่วนการยืนยันตัวตนที่ผู้รับเห็นและ DMARC alignment ต้องมีตัวตนผู้ส่ง เรคคอร์ด DNS ลายเซ็น และการตรวจสอบข้อความที่ได้รับที่ถูกต้อง

หน้านี้พิสูจน์ว่า SendHQ เข้ากันได้กับ Google SMTP relay หรือไม่

ไม่ เปรียบเทียบความสามารถที่ SendHQ จัดทำเอกสารไว้กับข้อกำหนด Google Workspace SMTP relay และใช้การทดสอบแบบควบคุมสำหรับการยืนยันตัวตน TLS โควตา ข้อผิดพลาด และการอ่านอีเวนต์การส่งกลับ

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

เรียนรู้ต่อ

วิธีประเมินบริการ SMTP Relayประเมินบริการ SMTP relay ตามความปลอดภัยของการส่งเข้า การยืนยันตัวตน คิว พฤติกรรมการลองใหม่ ขีดจำกัด อีเวนต์การส่ง การระงับการส่ง การแยกส่วน และความเหมาะสมในการย้ายระบบโปรโตคอลอีเมล SMTP: อีเมลของแอปพลิเคชันเคลื่อนที่อย่างไรเรียนรู้ว่า SMTP submission, relay, envelope, รหัสตอบกลับ, TLS, การลองใหม่ และเนื้อหาข้อความ กำหนดรูปแบบเวิร์กโฟลว์อีเมลของแอปพลิเคชันอย่างไรพอร์ต SMTP 25, 465 และ 587: คู่มือเชิงปฏิบัติเลือกพอร์ต SMTP ที่เหมาะสมตามบทบาทและโหมด TLS แล้ววินิจฉัยความล้มเหลวของการเชื่อมต่อ handshake การยืนยันตัวตน และการยอมรับข้อความวิธีประเมินบริการด้านความสามารถในการส่งถึงของอีเมลประเมินบริการด้านความสามารถในการส่งถึงของอีเมลตามขอบเขต หลักฐาน การยืนยันตัวตน feedback loop การระงับการส่ง ความเป็นส่วนตัว ความสามารถในการย้ายผู้ให้บริการ และความเหมาะสมในการปฏิบัติการคู่มือการนำ Gmail API ไปใช้สำหรับทีมผลิตภัณฑ์นำการเข้าถึง Gmail API ไปใช้ด้วย OAuth ที่ให้สิทธิ์น้อยที่สุด การซิงก์กล่องจดหมายที่ทนทาน การส่งอย่างปลอดภัย การลองใหม่ที่มีขอบเขต และโมเดล service account ที่ชัดเจน