ทีมผลิตภัณฑ์ควรใช้ Resend Email API อย่างปลอดภัยอย่างไร

กำหนดการดำเนินการของผลิตภัณฑ์ก่อนคำขอไปยังผู้ให้บริการ

เริ่มจากการดำเนินการของแอปพลิเคชันที่แคบ เช่น การยืนยันบัญชี ใบเสร็จ การแจ้งเตือนความปลอดภัย หรือการแจ้งเตือนที่ผู้รับร้องขอ endpoint สาธารณะของผลิตภัณฑ์ควรอนุญาตผู้เรียก tenant ประเภทข้อความ ตัวตนผู้ส่ง ผู้รับ และเทมเพลตก่อนที่จะมี payload ของ Resend ห้ามให้เบราว์เซอร์ส่ง `from`, `to`, HTML หรือตัวเลือกของผู้ให้บริการโดยพลการขณะถือข้อมูลรับรองที่ใช้ซ้ำได้ สร้างบันทึกขาออกภายในที่คงทน ซึ่งมีคีย์อีเวนต์ของแอปพลิเคชัน tenant การแก้ไขเทมเพลต ผู้ส่งที่ได้รับอนุมัติ ชุดผู้รับ และสถานะปัจจุบัน worker แปลงบันทึกนั้นเป็นคำขอไปยังผู้ให้บริการได้ ขอบเขตนี้เก็บ API key และเนื้อหาข้อความที่ไม่น่าเชื่อถือให้พ้นจากไคลเอนต์ ทำให้ทดสอบการป้องกันการซ้ำได้ และให้ผลิตภัณฑ์เปลี่ยนผู้ให้บริการได้โดยไม่ต้องเขียนเวิร์กโฟลว์ทางธุรกิจทุกอันใหม่ แยกข้อความ transactional และข้อความที่ขึ้นกับความยินยอมในโมเดลภายใน เพื่อให้การตั้งค่าความชอบ การระงับการส่ง และการตัดสินใจเมื่อเกิดเหตุการณ์ชัดเจน

ยืนยันโดเมนที่แน่นอนที่ใช้ในที่อยู่ From

เพิ่มโดเมนที่คุณควบคุมใน Resend และเผยแพร่เรคคอร์ด DNS ที่แสดงสำหรับโดเมนนั้น ยืนยันโดเมนองค์กรหรือซับโดเมนจริงที่ใช้ในที่อยู่ From ที่มองเห็น แทนการสมมติว่าตัวตนแม่ที่ไม่เกี่ยวข้องครอบคลุมโดเมนนั้น ตรวจสอบนโยบาย SPF และ DMARC ที่มีอยู่ก่อนเปลี่ยน DNS และห้ามสร้างเรคคอร์ด SPF ที่สองสำหรับชื่อโฮสต์เดียวกัน ใช้ซับโดเมนสำหรับการส่งเฉพาะวัตถุประสงค์เมื่อข้อกำหนดด้านการแยก ความเป็นเจ้าของ หรือการย้ายระบบสมเหตุสมผล หลังแดชบอร์ดรายงานว่ายืนยันแล้ว ให้ตรวจข้อความทดสอบที่ได้รับเพื่อยืนยันที่อยู่ From ที่มองเห็น ตัวตนลงลายเซ็น DKIM return path ผลการยืนยันตัวตน และพฤติกรรมการตอบกลับ การยืนยันโดยผู้ให้บริการพิสูจน์ว่าตัวตนที่กำหนดค่าไว้ผ่านการตรวจสอบการตั้งค่าของผู้ให้บริการ ไม่ได้พิสูจน์ความยินยอมของผู้รับ การยอมรับโดยเซิร์ฟเวอร์ผู้รับ การเข้ากล่องจดหมาย หรือชื่อเสียงที่ดี เก็บความเป็นเจ้าของ DNS และประวัติการเปลี่ยนแปลงไว้นอกแดชบอร์ดของผู้ให้บริการ เพื่อให้หมุนเวียนและย้อนกลับได้

สร้าง API key สิทธิ์ขั้นต่ำสำหรับแต่ละปริมาณงาน

Resend ระบุ API key พร้อมระดับการเข้าถึงและการจำกัดโดเมนที่เป็นทางเลือก worker ที่ส่งควรใช้คีย์ที่จำกัดเฉพาะสิทธิ์การส่ง และเมื่อสถาปัตยกรรมอนุญาต ก็จำกัดเฉพาะโดเมนเดียวที่ปริมาณงานนั้นเป็นเจ้าของ แยกการจัดการ โดเมน webhook และการดูแลบัญชีไว้ภายใต้อำนาจที่แยกกัน สร้างคีย์แยกสำหรับการพัฒนา staging และระบบจริง เพื่อไม่ให้สภาพแวดล้อมระดับล่างส่งด้วยตัวตนของระบบจริงหรือใช้ขีดจำกัดของมัน เก็บความลับแต่ละรายการโดยตรงใน secret store ที่จัดการ เปิดเผยเฉพาะโปรเซสเซิร์ฟเวอร์ที่ต้องใช้ และส่งเป็น Bearer authorization ผ่าน HTTPS ห้ามคัดลอกคีย์ลงในระบบควบคุมซอร์ส artifact ของการ build ล็อก เทมเพลต ระบบวิเคราะห์ ตั๋ว หรือพรอมต์ ควรซ้อมการหมุนเวียน สร้างคีย์ทดแทนที่มีขอบเขตเท่ากัน อัปเดต worker ตรวจสอบทราฟฟิกที่ควบคุมได้และการเชื่อมโยงอีเวนต์ แล้วเพิกถอนคีย์เก่า แจ้งเตือนเมื่อการยืนยันตัวตนและการอนุญาตล้มเหลวโดยไม่คาดคิด เพราะอาจบ่งชี้ว่าหมดอายุ ถูกเพิกถอน ขอบเขตคลาดเคลื่อน หรือความลับรั่วไหล

สร้างงานที่คงทนหนึ่งงานและความพยายามส่งแบบ idempotent หนึ่งครั้ง

จองงานขาออกภายในก่อนเรียก Resend สร้างค่า idempotency จากข้อเท็จจริงของผลิตภัณฑ์ที่คงที่ เช่น tenant ประเภทการดำเนินการ และ ID อีเวนต์ของแอปพลิเคชันที่ไม่เปลี่ยนแปลง ไม่ใช่จากความพยายามลองใหม่แบบสุ่ม ส่งค่านั้นในเฮดเดอร์ `Idempotency-Key` ปัจจุบัน Resend ระบุว่าคีย์เหล่านี้ป้องกันคำขออีเมลซ้ำ หมดอายุหลัง 24 ชั่วโมง และยาวได้ไม่เกิน 256 อักขระ ช่วงเวลาของผู้ให้บริการนั้นมีประโยชน์ แต่ไม่ใช่การรับประกันการไม่ซ้ำระดับผลิตภัณฑ์ที่สมบูรณ์ ให้มีข้อจำกัดความไม่ซ้ำบนคีย์อีเวนต์ภายในสำหรับเวิร์กโฟลว์ทางธุรกิจที่ยาวกว่า จัดลำดับ worker ที่อาจอ้างสิทธิ์งานเดียวกัน และเก็บ ID อีเมลของผู้ให้บริการที่ส่งกลับจากคำขอที่สำเร็จ หาก network timeout ทำให้การยอมรับกำกวม ให้พักงานไว้ในสถานะไม่ทราบและกระทบยอดกับล็อกหรืออีเวนต์ของผู้ให้บริการก่อนส่งซ้ำ การใช้คีย์คงที่เดียวซ้ำสำหรับการดำเนินการตรรกะเดียวกันปลอดภัยกว่าการสร้างคีย์ใหม่สำหรับทุกการลองใหม่ของการขนส่ง

สร้างและตรวจสอบคำขออีเมลอย่างตั้งใจ

endpoint ส่งอีเมลของ Resend รับที่อยู่ From ผู้รับ หัวเรื่อง และเนื้อหาข้อความ พร้อมตัวเลือกที่ระบุไว้ เช่น ข้อความ HTML เนื้อหาที่เรนเดอร์ด้วย React เทมเพลต Cc, Bcc, reply-to เฮดเดอร์ ไฟล์แนบ แท็ก และการส่งตามกำหนดเวลา เปิดเผยเฉพาะส่วนย่อยที่ผลิตภัณฑ์ต้องการ ตรวจสอบไวยากรณ์ที่อยู่และความเป็นเจ้าของ tenant จำกัดจำนวนผู้รับและไฟล์แนบให้ต่ำกว่าขีดจำกัดของผู้ให้บริการ ปฏิเสธการแทรกบรรทัดใหม่ในเฮดเดอร์ และสร้างเนื้อหาที่เกี่ยวกับ MIME ผ่านไลบรารีที่ยังมีการดูแลหรือฟิลด์ของผู้ให้บริการที่เชื่อถือได้ ห้ามใส่ข้อมูลรับรอง ข้อมูลส่วนบุคคลที่ละเอียดอ่อน หรืออินพุตของลูกค้าที่ไม่จำกัดในแท็กหรือเฮดเดอร์ เก็บการแก้ไขเทมเพลตและตัวแปรที่ทำความสะอาดแล้ว แทนการบันทึกเนื้อหาทั้งหมด adapter ภายในควรคืนผลที่แคบ เช่น ID ผู้ให้บริการที่ยอมรับ หรือความล้มเหลวที่จัดประเภทแล้ว ไม่รั่วรายละเอียดการตอบกลับของผู้ให้บริการเข้าไปในโค้ดทางธุรกิจ วิธีนี้ทำให้อัปเดตชื่อฟิลด์เฉพาะผู้ให้บริการ เวอร์ชัน SDK หรือขีดจำกัดของคำขอได้โดยไม่ต้องเปลี่ยนสัญญาอีเวนต์ของผลิตภัณฑ์

จัดประเภทการตอบกลับ API และขีดจำกัดการใช้งานก่อนลองใหม่

ถือการตอบกลับ HTTP เป็นข้อสังเกตหนึ่งในเวิร์กโฟลว์ การตอบกลับการส่งที่สำเร็จคืนตัวระบุอีเมลที่ควรเก็บไว้กับงานภายใน แต่ไม่ได้ยืนยันการยอมรับโดยปลายทางหรือการเข้ากล่องจดหมาย แก้ข้อผิดพลาดด้านการตรวจสอบ การยืนยันตัวตน โดเมน สิทธิ์ และ payload แทนการลองใหม่แบบไม่ไตร่ตรอง Resend ระบุขีดจำกัดคำขอ API และส่งเฮดเดอร์ rate-limit และโควตา รวมถึงฟิลด์ที่อธิบายความจุที่เหลือ เวลารีเซ็ต และความหน่วงในการลองใหม่ การตอบกลับ 429 ควรรอตามช่วงที่ระบุพร้อมเพิ่ม jitter ลองใหม่ความล้มเหลวของการขนส่งและข้อผิดพลาดฝั่งเซิร์ฟเวอร์ที่เข้าเกณฑ์ด้วย exponential backoff จำนวนครั้งที่จำกัด และ idempotency key เชิงตรรกะเดิมตราบที่ช่วงเวลาที่ระบุยังใช้อยู่ ความล้มเหลวที่กำกวมต้องกระทบยอด เพราะผู้ให้บริการอาจยอมรับอีเมลแล้วแม้ไคลเอนต์ไม่ได้รับการตอบกลับ แจ้งเตือนเมื่อความล้มเหลวซ้ำกระจุกตามโดเมน เทมเพลต คีย์ หรือ tenant แต่เก็บข้อมูลรับรอง เนื้อหาทั้งหมด และข้อมูลผู้รับที่ไม่จำเป็นออกจากล็อกการดำเนินงาน

ยืนยันตัวตนคำขอ webhook ก่อนประมวลผลอีเวนต์

กำหนดค่า endpoint webhook HTTPS เฉพาะและเก็บ body คำขอดิบที่แน่นอน Resend ระบุการลงลายเซ็น webhook ผ่านเฮดเดอร์และความลับลงลายเซ็นที่เข้ากันได้กับ Svix ตรวจสอบ ID ของ webhook timestamp และลายเซ็นเหนือ payload ที่ไม่ได้ดัดแปลงก่อนแยกวิเคราะห์ JSON หรือ serialize ใหม่ และใช้ขั้นตอนตรวจสอบอย่างเป็นทางการหรือไลบรารีที่เข้ากันได้ซึ่งยังมีการดูแล ปฏิเสธคำขอที่ไม่ถูกต้องหรือเก่าเกินไป จำกัดขนาดคำขอ และแยกความลับลงลายเซ็นออกจากคีย์ที่ใช้ส่ง หลังยืนยันตัวตนแล้ว ให้บันทึกหรือเข้าคิวอีเวนต์อย่างคงทนก่อนตอบรับ เพื่อไม่ให้การล่มของโปรเซสทิ้งหลักฐานการส่งถึงโดยไม่แจ้ง ระบบส่งอาจลองซ้ำและทำให้ webhook ซ้ำ จึงใช้ตัวระบุอีเวนต์เป็นคีย์กำจัดข้อมูลซ้ำและทำให้การเปลี่ยนสถานะเป็นแบบทิศทางเดียว อีเวนต์ที่มาช้าหรือซ้ำต้องไม่เขียนทับผลสิ้นสุดที่ให้ข้อมูลมากกว่าเพียงเพราะมาถึงทีหลังสุด บันทึกความล้มเหลวของการตรวจสอบและความล่าช้าของอีเวนต์เป็นสัญญาณการดำเนินงาน โดยไม่เก็บเนื้อหาข้อความดิบเกินระยะเวลาเก็บรักษาที่จำเป็น

สร้างโมเดลอีเวนต์ของผู้ให้บริการโดยไม่กล่าวเกินจริงเรื่องการส่งถึง

Resend เผยแพร่ประเภทอีเวนต์อีเมลที่มีชื่อ ได้แก่ sent, delivered, delivery delayed, bounced, complained, failed, opened และ clicked แมปชื่อของผู้ให้บริการเหล่านั้นเข้ากับโมเดลสถานะภายใน พร้อมประเภทอีเวนต์เดิม ID อีเมลของผู้ให้บริการ ID อีเวนต์ timestamp ขอบเขตผู้รับ และข้อมูลวินิจฉัยที่มี อีเวนต์ sent อธิบายความคืบหน้าของผู้ให้บริการ อีเวนต์ delivered รายงานการส่งถึงตามความหมายของอีเวนต์ที่ Resend ระบุ แต่ SMTP สำเร็จที่ระบบผู้รับก็ยังไม่เปิดเผยโฟลเดอร์สุดท้ายของผู้รับ การเปิดและการคลิกเป็นข้อสังเกตด้านการมีส่วนร่วม ไม่ใช่หลักฐานการส่งถึง และเทคโนโลยีด้านความเป็นส่วนตัวอาจมีผลต่อสิ่งเหล่านี้ อีเมลตีกลับ การร้องเรียน และความล้มเหลวถาวรควรอัปเดตสถานะความปลอดภัยของผู้รับก่อนการตัดสินใจส่งครั้งถัดไป เก็บประวัติอีเวนต์ของผู้ให้บริการแบบ append-only และอนุมานสถานะที่แสดงต่อผู้ใช้จากกฎที่ชัดเจน วิธีนี้เก็บหลักฐานไว้สำหรับซัพพอร์ตและหลีกเลี่ยงการลองใหม่ที่ไม่ปลอดภัยหลังจากโอนความรับผิดชอบแล้วหรือผู้รับส่งสัญญาณเชิงลบ

ทดสอบเส้นทางความล้มเหลวและการกู้คืนด้วยผู้รับที่ควบคุมได้

ใช้คีย์ที่ไม่ใช่ระบบจริง ซับโดเมนที่ยืนยันแล้วซึ่งควบคุมได้ และกล่องจดหมายที่ทีมเป็นเจ้าของ ทดสอบเนื้อหาข้อความและ HTML พฤติกรรม reply-to ขีดจำกัดไฟล์แนบ idempotency key ที่คงที่ และตัวระบุของผู้ให้บริการที่เก็บไว้ ส่งงานตรรกะเดียวกันสองครั้งและยืนยันว่าการควบคุมของแอปพลิเคชันและผู้ให้บริการไม่สร้างสำเนาที่ไม่ตั้งใจ ทดสอบ payload ที่ไม่ถูกต้อง โดเมนผิด คีย์ที่ถูกเพิกถอน สิทธิ์ไม่เพียงพอ rate limit transport timeout อีเมลตีกลับ การร้องเรียน การส่งถึงล่าช้า webhook ซ้ำ body ลายเซ็นที่ถูกแก้ไข timestamp ของ webhook ที่เก่า และการหมุนเวียนความลับลงลายเซ็น ยืนยันว่าการรับอีเวนต์คงทนก่อนตอบรับ และความปลอดภัยของผู้รับบล็อกงานถัดไป ทดสอบการหมุนเวียน DNS และการลบผู้ให้บริการโดยไม่ลบเรคคอร์ดที่ไม่เกี่ยวข้อง แดชบอร์ดควรครอบคลุมความล้มเหลวในการส่ง ความหน่วง ความล้มเหลวของการตรวจสอบ webhook ความล่าช้าของอีเวนต์ อีเมลตีกลับ การร้องเรียน และคิวการกระทบยอด ตรวจสอบเอกสาร Resend และการตั้งค่าบัญชีปัจจุบันเมื่อเปิดตัว เพราะโควตา ขีดจำกัด ฟิลด์อีเวนต์ และสิทธิ์ที่ใช้ได้อาจเปลี่ยนแปลงอย่างเป็นอิสระจากโค้ดแอปพลิเคชันที่ดีพลอยแล้ว

เปรียบเทียบความสามารถ API ที่เผยแพร่ก่อนย้ายระบบ

SendHQ เผยแพร่ contract OpenAPI 3.1 สำหรับ Email API ระดับเวิร์กสเปซ ซึ่งรวมการส่งจากโดเมนที่ยืนยันแล้ว อีเมลขาเข้า เทมเพลตแบบโฮสต์ อีเวนต์การส่ง และการระงับการส่ง ก่อนย้ายการเชื่อมต่อ ให้เปรียบเทียบ request body การยืนยันตัวตน idempotency ตัวระบุที่ส่งคืน รูปแบบข้อผิดพลาด webhook กฎโดเมน และพฤติกรรมการระงับการส่ง แล้วตรวจสอบด้วยการทดสอบระดับฟิลด์ อย่าคิดว่าเข้ากันได้จากชื่อ endpoint ที่คล้ายกัน

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

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

• Resend Send Email API — Resend
• Resend API Keys — Resend
• Resend Domains — Resend
• Resend Idempotency Keys — Resend
• ขีดจำกัดการใช้งานของ Resend — Resend
• Resend Webhooks — Resend
• การตรวจสอบคำขอ Webhook ของ Resend — Resend
• ประเภทอีเวนต์ Webhook ของ Resend — Resend
• ข้อกำหนด RFC 5321: Simple Mail Transfer Protocol — RFC Editor
• สัญญา OpenAPI ของ SendHQ — SendHQ