SendGrid ยกเลิกแพ็กเกจฟรีแล้ว: คู่มือย้ายระบบใน 30 นาที

จุดจบของแพ็กเกจฟรีตลอดกาล

หากคุณพึ่งพาแพ็กเกจฟรีของ SendGrid สำหรับโปรเจกต์เสริมที่มีปริมาณน้อยหรือผลิตภัณฑ์ใหม่ คุณน่าจะสังเกตเห็นการเปลี่ยนแปลงแล้ว แพ็กเกจฟรีกลายเป็นช่วงทดลอง 60 วัน เมื่อช่วงทดลองหมดอายุ คุณต้องย้ายไปแพ็กเกจแบบชำระเงิน โดย Essentials เริ่มต้น 19.95 USD ต่อเดือน (ราคาของ SendGrid) การย้ายระบบต้องส่งออกรายการระงับการส่ง อัปเดตเรคคอร์ด DNS และเปลี่ยนการเชื่อมต่อ API กระบวนการนี้ใช้เวลาราว 30 นาที หากเทมเพลตของคุณไม่ซับซ้อน

การประเมินทางเลือก

เมื่อเลือกตัวแทน คุณต้องแยกให้ออกระหว่างการยอมรับของผู้ให้บริการ (API ยอมรับคำขอของคุณ) การส่งถึง (เซิร์ฟเวอร์ผู้รับยอมรับอีเมล) และการเข้ากล่องจดหมาย (อีเมลไม่ตกโฟลเดอร์สแปม) ไม่มีผู้ให้บริการรายใดรับประกันอย่างหลังได้ เพราะขึ้นอยู่กับชื่อเสียงผู้ส่งและเนื้อหาของคุณ

ภาพรวมต้นทุน (กันยายน 2026)

สำหรับอีเมล transactional ปริมาณน้อย ส่วนต่างของราคาสูงมาก การส่งอีเมล 50,000 ฉบับมีค่าใช้จ่ายราว 5 USD บน Amazon SES แบบ a la carte เทียบกับราว 66 USD บนแพ็กเกจของ Postmark

• Amazon SES: ราคา 0.10 USD ต่อ 1,000 อีเมลแบบ a la carte (ราคาของ AWS SES) แพ็กเกจแบบแบ่งระดับใหม่ที่เปิดตัวเมื่อวันที่ 21 กรกฎาคม 2026 ได้แก่ Essentials (0.16 USD ต่อ 1,000) Pro (0.22 USD ต่อ 1,000 บวก 105 USD ต่อเดือนต่อภูมิภาค) และ Enterprise (0.23 USD ต่อ 1,000 บวก 500 USD ต่อเดือน)
• Resend: มีแพ็กเกจฟรี 3,000 อีเมลต่อเดือน จำกัด 100 ต่อวัน แพ็กเกจ Pro คือ 20 USD ต่อเดือนสำหรับ 50,000 อีเมล โดยส่วนที่เกินคิด 0.90 USD ต่อ 1,000 (ราคาของ Resend)
• Mailgun: เริ่มที่ 15 USD ต่อเดือนสำหรับ 10,000 อีเมล โดยส่วนที่เกินคิดตั้งแต่ 1.80 ถึง 1.10 USD ต่อ 1,000 (ราคาของ Mailgun)
• Postmark: เริ่มที่ 15 USD ต่อเดือนสำหรับ 10,000 อีเมล โดยส่วนที่เกินคิดตั้งแต่ 1.80 ถึง 1.20 USD ต่อ 1,000 (ราคาของ Postmark)
• SendHQ: เป็นทางเลือกยุคใหม่สำหรับทีมผลิตภัณฑ์และเอเจนต์ AI เน้น telemetry ที่ลดข้อมูลส่วนบุคคลให้น้อยที่สุดและเก็บเฉพาะใน EU และ API key ระดับเวิร์กสเปซ

ขั้นตอนที่ 1: การส่งออกข้อมูลและรายการระงับการส่ง

อย่าย้ายรายชื่อโดยไม่ส่งออกรายการระงับการส่ง หากคุณส่งไปยังที่อยู่ที่เคยตีกลับหรือยกเลิกการรับ คุณเสี่ยงที่จะทำลายชื่อเสียงกับผู้ให้บริการรายใหม่

SendGrid ให้คุณส่งออกรายการระงับการส่งผ่าน UI หรือ API คุณจะได้ไฟล์ CSV ของอีเมลที่ไม่ควรติดต่อ เมื่อนำเข้าไปยังผู้ให้บริการรายใหม่ ให้จับคู่ "เหตุผล" (bounce เทียบกับยกเลิกการรับ) อย่างถูกต้องเพื่อรักษาการปฏิบัติตามกฎหมายอย่าง GDPR หรือ CAN-SPAM

ขั้นตอนที่ 2: DNS และการยืนยันตัวตน

นี่คือจุดที่การย้ายระบบส่วนใหญ่ล้มเหลว คุณเปลี่ยนแค่ API key ไม่ได้ คุณต้องพิสูจน์ความเป็นเจ้าของโดเมนกับผู้ให้บริการรายใหม่

DKIM, SPF และ DMARC

คุณจะต้องเพิ่มเรคคอร์ด CNAME หรือ TXT ใหม่ที่ผู้ให้บริการ DNS ของคุณ หากย้ายมาที่ SendHQ คุณสามารถใช้ Email DNS Checker ตรวจสอบการตั้งค่าปัจจุบันก่อนเปลี่ยนแปลง

1. SPF: อัปเดตเรคคอร์ด SPF ให้รวมผู้ให้บริการรายใหม่ หากใช้ผู้ให้บริการหลายราย โปรดจำไว้ว่าคุณมีเรคคอร์ด SPF TXT หลายเรคคอร์ดไม่ได้ ต้องรวมเป็นเรคคอร์ดเดียว (เช่น v=spf1 include:sendgrid.net include:_spf.sendhq.cc ~all) หากต้องการเจาะลึก ดูศัพท์ SPF ในอภิธานศัพท์
2. DKIM: สร้างคีย์ DKIM ใหม่ในแดชบอร์ดของผู้ให้บริการรายใหม่ แล้วเพิ่มเรคคอร์ด CNAME ที่ได้ไปยัง DNS ของคุณ เพื่อให้เซิร์ฟเวอร์ผู้รับตรวจสอบได้ว่าอีเมลไม่ถูกดัดแปลงระหว่างทาง
3. DMARC: นโยบาย DMARC ของคุณยังคงเหมือนเดิมไม่ว่าจะใช้ผู้ให้บริการรายใด เพราะเป็นนโยบายระดับโดเมน อย่างไรก็ตาม ตรวจสอบให้แน่ใจว่าผู้ให้บริการรายใหม่ผ่าน alignment กับนโยบาย DMARC ของคุณ เพื่อไม่ให้อีเมลถูกปฏิเสธ ดูรายละเอียดการนำไปใช้ในคู่มือ DKIM, SPF และ DMARC

ขั้นตอนที่ 3: การย้ายโค้ด

ผู้ให้บริการส่วนใหญ่ใช้ REST API หากคุณใช้เทมเพลตแบบไดนามิกของ SendGrid คุณจะต้องย้ายเลย์เอาต์ HTML/CSS เหล่านั้นไปยังเอนจินเทมเพลตของผู้ให้บริการรายใหม่

ตัวอย่าง: จาก SendGrid ไปยัง REST API ทั่วไป

SendGrid ใช้โครงสร้าง JSON เฉพาะสำหรับ personalizations API ยุคใหม่ส่วนใหญ่ รวมถึง SendHQ นิยมโครงสร้างที่แบนกว่าเพื่อให้อ่านง่ายขึ้น

Payload ของ SendGrid:

{ "personalizations": [ { "to": [{"email": "user@example.com"}], "dynamic_template_data": { "first_name": "Alice" } } ], "from": {"email": "noreply@yourdomain.com"}, "template_id": "d-12345" }

Payload ของ API ยุคใหม่ (เช่น SendHQ):

{ "to": "user@example.com", "from": "noreply@yourdomain.com", "template_id": "welcome-email", "variables": { "first_name": "Alice" } }

การจัดการการย้ายระบบในโค้ด

เพื่อหลีกเลี่ยงระบบหยุดชะงัก ให้ทำ wrapper หรือ strategy pattern ซึ่งช่วยให้สลับระหว่างผู้ให้บริการได้ด้วยตัวแปรสภาพแวดล้อม

interface EmailProvider { send(payload: EmailPayload): Promise<void>; } class SendGridProvider implements EmailProvider { async send(payload: EmailPayload) { // SendGrid specific implementation } } class SendHQProvider implements EmailProvider { async send(payload: EmailPayload) { // SendHQ specific implementation } } const provider = process.env.EMAIL_PROVIDER === 'sendhq' ? new SendHQProvider() : new SendGridProvider();

ขั้นตอนที่ 4: เอเจนต์ AI และ Idempotency

หากคุณใช้เอเจนต์ AI สั่งส่งอีเมล คุณเผชิญความเสี่ยงเฉพาะ คือเอเจนต์อาจวนลูปหรือลองส่งคำขอซ้ำหลายครั้งเพราะหมดเวลา ทำให้ผู้ใช้ได้รับอีเมลเหมือนกันสิบฉบับ

การส่งอีเมลเป็นผลข้างเคียงภายนอก คุณต้องทำ idempotency idempotency key คือตัวระบุที่ไม่ซ้ำกันซึ่งส่งใน header เพื่อบอก API ว่า "หากเคยเห็นคีย์นี้แล้ว อย่าส่งอีเมลอีก ให้คืนการตอบกลับสำเร็จเดิม"

การนำไปใช้ที่พร้อมสำหรับเอเจนต์:

{ "headers": { "Idempotency-Key": "order_123_welcome_email" }, "body": { "to": "customer@example.com", "template_id": "order-confirmation" } }

นอกจากนี้ สำหรับการกระทำของเอเจนต์ที่มีความเสี่ยงสูง (เช่น การส่งอีเมลรีเซ็ตรหัสผ่านหรือการแจ้งเตือนการเรียกเก็บเงิน) ให้ใช้ขั้นตอนอนุมัติโดยมนุษย์หรือ rate limit ที่เข้มงวดต่อ user ID เพื่อป้องกันไม่ให้ภาพหลอนของเอเจนต์ส่งสแปมถึงลูกค้าของคุณ

ขั้นตอนที่ 5: การทดสอบและการตรวจสอบ

ก่อนสลับตัวแปรสภาพแวดล้อมไปยังผู้ให้บริการรายใหม่ ให้ทำตามเช็กลิสต์นี้:

• การเผยแพร่ DNS: ใช้เครื่องมืออย่าง dig หรือเครื่องมือตรวจสอบบนเว็บเพื่อให้แน่ใจว่าเรคคอร์ด DKIM และ SPF ใหม่ของคุณใช้งานได้แล้ว
• การตรวจสอบ Webhook: หากคุณพึ่งพาอีเวนต์การส่งถึง (delivered, opened, clicked) ให้อัปเดต endpoint ของ webhook รูปแบบอีเวนต์ของ SendGrid ต่างจากรายอื่น ตรวจสอบให้แน่ใจว่า endpoint ของคุณรองรับ JSON schema ใหม่ได้โดยไม่ล่ม
• การจัดการข้อผิดพลาด: ทดสอบว่าแอปพลิเคชันของคุณจัดการข้อผิดพลาดเฉพาะของผู้ให้บริการอย่างไร ตัวอย่างเช่น 429 (Too Many Requests) ควรกระตุ้นกลยุทธ์ backoff ขณะที่ 400 (Bad Request) มักบ่งชี้ว่าที่อยู่อีเมลผิดรูปแบบ ซึ่งควรทำเครื่องหมายเป็น bounce ในฐานข้อมูลของคุณ

กรณีข้อผิดพลาดทั่วไปที่ควรทดสอบ

1. รูปแบบอีเมลไม่ถูกต้อง: ตรวจสอบให้แน่ใจว่า API คืนข้อผิดพลาดที่ชัดเจนและโค้ดของคุณไม่ลองใหม่ไม่รู้จบ
2. Rate Limiting: จำลองอีเมลที่พุ่งเป็นชุดเพื่อดูว่าคิวของคุณรองรับขีดจำกัดของผู้ให้บริการได้หรือไม่
3. ไฟล์แนบขนาดใหญ่: ตรวจสอบขนาด payload สูงสุดของผู้ให้บริการรายใหม่ บางรายจำกัด 10MB บางรายจำกัด 25MB

เช็กลิสต์สรุปสำหรับการย้ายระบบ

• ส่งออกรายการระงับการส่ง: ส่งออก CSV จาก SendGrid
• ตั้งค่าเรคคอร์ด DNS: SPF, DKIM และ DMARC alignment
• ย้ายเทมเพลต: แปลง HTML/CSS เป็นรูปแบบใหม่
• อัปเดต logic ของ API: สร้าง provider wrapper
• เพิ่ม Idempotency: จำเป็นสำหรับ trigger ของเอเจนต์ AI
• ทดสอบ webhook: ตรวจสอบการส่งอีเวนต์และการแยกวิเคราะห์
• สลับทราฟฟิก: อัปเดตตัวแปร ENV และติดตาม log

ข้อคิดสุดท้ายเรื่องความสามารถในการส่งถึง

การย้ายผู้ให้บริการเป็นโอกาสที่ดีในการตรวจสอบพฤติกรรมการส่งของคุณ โปรดจำไว้ว่าการยอมรับจากผู้ให้บริการเป็นเพียงด่านแรก การส่งถึงขึ้นอยู่กับ ISP ผู้รับ (Gmail, Outlook ฯลฯ) ที่ยอมรับการเชื่อมต่อ การเข้ากล่องจดหมายคือด่านสุดท้าย ซึ่งกำหนดโดยชื่อเสียงระยะยาวของโดเมนและอัตราการมีส่วนร่วมของผู้รับ

อย่าถูกล่อลวงให้ใช้ API เหล่านี้ส่งอีเมลจำนวนมากที่ไม่ได้รับการร้องขอ นอกจากจะผิดกฎหมายบ่อยครั้งแล้ว ยังทำให้บัญชีของคุณถูกระงับไม่ว่าจะเลือกผู้ให้บริการรายใด ให้ยึดอีเมล transactional และการสื่อสารที่ผู้รับยินยอม เพื่อรักษาคะแนนผู้ส่งให้ดี

สำหรับทีมที่สร้างแอปพลิเคชันแบบ AI-native ให้มองหาผู้ให้บริการที่มีฟีเจอร์ความพร้อมสำหรับเอเจนต์ เช่น MCP server และไฟล์ llms.txt เพื่อให้การเชื่อมต่อราบรื่น SendHQ ออกแบบมาเพื่อเวิร์กโฟลว์นี้โดยเฉพาะ โดยให้โครงสร้างพื้นฐานที่ทีมผลิตภัณฑ์ยุคใหม่ต้องการ

เรียนรู้เพิ่มเติมเกี่ยวกับการสร้างระบบอีเมลที่เชื่อถือได้ที่ https://sendhq.cc