پلن رایگان SendGrid حذف شد: راهنمای مهاجرت 30 دقیقه‌ای

پایان پلن همیشه رایگان

اگر برای یک پروژه جانبی کم‌حجم یا یک محصول تازه به پلن رایگان SendGrid متکی بودید، احتمالاً متوجه تغییر شده‌اید: پلن رایگان اکنون یک دوره آزمایشی 60 روزه است. پس از پایان این دوره، باید به یک پلن پولی بروید که پلن Essentials آن از 19.95 USD در ماه شروع می‌شود (قیمت‌گذاری SendGrid). برای مهاجرت، باید فهرست توقف ارسال خود را خروجی بگیرید، رکوردهای DNS را به‌روز کنید و یکپارچه‌سازی API را جایگزین کنید. اگر قالب‌هایتان ساده باشند، این فرایند حدود 30 دقیقه طول می‌کشد.

ارزیابی جایگزین‌ها

هنگام انتخاب جایگزین، باید میان پذیرش توسط ارائه‌دهنده (پذیرفته شدن درخواست شما توسط API)، تحویل (پذیرفته شدن ایمیل توسط سرور گیرنده) و رسیدن به صندوق ورودی (دور ماندن ایمیل از پوشه اسپم) تمایز بگذارید. هیچ ارائه‌دهنده‌ای نمی‌تواند مورد آخر را تضمین کند، چون به اعتبار فرستنده و محتوای شما بستگی دارد.

چشم‌انداز هزینه‌ها (سپتامبر 2026)

برای ایمیل تراکنشی کم‌حجم، اختلاف قیمت چشمگیر است. ارسال 50,000 ایمیل روی Amazon SES با پرداخت به‌ازای مصرف حدود 5 USD هزینه دارد، در حالی که روی پلن‌های Postmark تقریباً 66 USD است.

• Amazon SES: با پرداخت به‌ازای مصرف 0.10 USD برای هر 1,000 ایمیل (قیمت‌گذاری AWS SES). پلن‌های سطح‌بندی‌شده جدید که در 21 ژوئیه 2026 معرفی شدند شامل Essentials (0.16 USD برای هر 1,000 ایمیل)، Pro (0.22 USD برای هر 1,000 ایمیل به‌علاوه 105 USD در ماه برای هر region) و 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: جایگزینی مدرن برای تیم‌های محصول و ایجنت‌های هوش مصنوعی که بر تله‌متری حداقلی و حریم‌خصوصی‌محور صرفاً در EU و کلیدهای API در سطح فضای کاری تمرکز دارد.

گام 1: خروجی گرفتن از داده‌ها و فهرست‌های توقف ارسال

فهرست خود را بدون خروجی گرفتن از موارد توقف ارسال منتقل نکنید. اگر به نشانی‌ای ایمیل بفرستید که قبلاً برگشت خورده یا لغو اشتراک کرده است، اعتبار خود نزد ارائه‌دهنده جدید را به خطر می‌اندازید.

SendGrid امکان خروجی گرفتن از فهرست توقف ارسال را از طریق رابط کاربری یا API فراهم می‌کند. یک فایل CSV از ایمیل‌هایی دریافت می‌کنید که نباید با آن‌ها تماس گرفت. هنگام وارد کردن آن‌ها در ارائه‌دهنده جدید، مطمئن شوید «دلیل» (برگشت ایمیل در برابر لغو اشتراک) را درست نگاشت می‌کنید تا با قوانینی مانند GDPR یا CAN-SPAM سازگار بمانید.

گام 2: DNS و احراز هویت

بیشتر مهاجرت‌ها همین‌جا شکست می‌خورند. نمی‌توانید فقط کلید API را عوض کنید؛ باید مالکیت دامنه را به ارائه‌دهنده جدید ثابت کنید.

DKIM، SPF و DMARC

باید رکوردهای CNAME یا TXT جدیدی به ارائه‌دهنده DNS خود اضافه کنید. اگر به SendHQ مهاجرت می‌کنید، می‌توانید پیش از اعمال تغییرات، با بررسی DNS ایمیل پیکربندی فعلی خود را بررسی کنید.

1. SPF: رکورد SPF خود را به‌روز کنید تا ارائه‌دهنده جدید را شامل شود. اگر از چند ارائه‌دهنده استفاده می‌کنید، به یاد داشته باشید که نمی‌توانید چند رکورد TXT از نوع SPF داشته باشید. باید آن‌ها را در یک رکورد ترکیب کنید (مثلاً v=spf1 include:sendgrid.net include:_spf.sendhq.cc ~all). برای بررسی عمیق‌تر، مدخل SPF در واژه‌نامه را ببینید.
2. DKIM: در داشبورد ارائه‌دهنده جدید کلیدهای DKIM تازه بسازید و رکوردهای CNAME حاصل را به DNS خود اضافه کنید. این کار تضمین می‌کند سرور گیرنده بتواند تأیید کند ایمیل در مسیر دست‌کاری نشده است.
3. DMARC: سیاست DMARC شما صرف‌نظر از ارائه‌دهنده ثابت می‌ماند، چون یک سیاست در سطح دامنه است. با این حال، مطمئن شوید ارائه‌دهنده جدید با سیاست DMARC شما هم‌راستاست تا ایمیل‌ها رد نشوند. برای جزئیات پیاده‌سازی به راهنمای DKIM، SPF و DMARC مراجعه کنید.

گام 3: مهاجرت کد

بیشتر ارائه‌دهندگان از REST API استفاده می‌کنند. اگر از قالب‌های پویای SendGrid استفاده می‌کردید، باید آن طرح‌بندی‌های HTML/CSS را به موتور قالب ارائه‌دهنده جدید منتقل کنید.

مثال: از SendGrid به یک REST API عمومی

SendGrid برای personalizations از ساختار JSON خاصی استفاده می‌کند. بیشتر 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 پیاده‌سازی کنید. این کار امکان جابه‌جایی بین ارائه‌دهندگان را با یک متغیر محیطی فراهم می‌کند.

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: ایجنت‌های هوش مصنوعی و idempotency

اگر از ایجنت‌های هوش مصنوعی برای راه‌اندازی ایمیل‌ها استفاده می‌کنید، با یک ریسک مشخص روبه‌رو هستید: ایجنت ممکن است به‌دلیل timeout در حلقه بیفتد یا یک درخواست را چند بار تکرار کند و کاربر ده ایمیل یکسان دریافت کند.

ارسال ایمیل یک اثر جانبی خارجی است. باید idempotency را پیاده‌سازی کنید. کلید idempotency یک شناسه یکتاست که در هدر ارسال می‌شود و به API می‌گوید: «اگر این کلید را قبلاً دیده‌ای، ایمیل را دوباره نفرست؛ فقط پاسخ موفق اصلی را برگردان.»

پیاده‌سازی آماده برای ایجنت:

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

علاوه بر این، برای اقدامات پرریسک ایجنت (مانند ارسال بازنشانی رمز عبور یا هشدار صورتحساب)، یک مرحله تأیید با حضور انسان یا یک محدودیت نرخ سخت‌گیرانه به‌ازای هر شناسه کاربر پیاده‌سازی کنید تا توهمات ایجنت باعث اسپم شدن مشتریانتان نشود.

گام 5: آزمایش و اعتبارسنجی

پیش از تغییر متغیر محیطی به ارائه‌دهنده جدید، این چک‌لیست را مرور کنید:

• انتشار DNS: با ابزاری مانند dig یا یک بررسی‌کننده وب مطمئن شوید رکوردهای جدید DKIM و SPF فعال شده‌اند.
• بررسی وب‌هوک‌ها: اگر به رویدادهای تحویل (delivered، opened، clicked) متکی هستید، endpointهای وب‌هوک خود را به‌روز کنید. قالب رویدادهای SendGrid با دیگران فرق دارد. مطمئن شوید endpoint شما می‌تواند schema جدید JSON را بدون از کار افتادن پردازش کند.
• مدیریت خطا: آزمایش کنید برنامه‌تان خطاهای خاص ارائه‌دهنده را چگونه مدیریت می‌کند. برای مثال، خطای 429 (Too Many Requests) باید یک راهبرد backoff را فعال کند، در حالی که 400 (Bad Request) معمولاً نشان‌دهنده نشانی ایمیل نادرستی است که باید در پایگاه داده شما به‌عنوان برگشت‌خورده علامت‌گذاری شود.

موارد خطای رایج برای آزمایش

1. قالب نامعتبر ایمیل: مطمئن شوید API خطای روشنی برمی‌گرداند و کد شما بی‌نهایت تلاش مجدد نمی‌کند.
2. محدودیت نرخ: یک جهش ناگهانی در ارسال ایمیل را شبیه‌سازی کنید تا ببینید صف شما محدودیت‌های ارائه‌دهنده را مدیریت می‌کند یا نه.
3. پیوست‌های بزرگ: حداکثر اندازه payload ارائه‌دهنده جدید را بررسی کنید. برخی آن را به 10MB و برخی به 25MB محدود می‌کنند.

چک‌لیست خلاصه مهاجرت

• خروجی گرفتن از موارد توقف ارسال: خروجی CSV از SendGrid.
• تنظیم رکوردهای DNS: هم‌راستایی SPF، DKIM و DMARC.
• مهاجرت قالب‌ها: HTML/CSS را به قالب جدید تبدیل کنید.
• به‌روزرسانی منطق API: wrapper ارائه‌دهنده را پیاده‌سازی کنید.
• افزودن Idempotency: برای triggerهای ایجنت AI ضروری است.
• آزمایش وب‌هوک‌ها: تحویل و parse رویداد را تأیید کنید.
• تغییر ترافیک: متغیر ENV را به‌روزرسانی کنید و logها را پایش کنید.

نکات پایانی درباره تحویل‌پذیری

تغییر ارائه‌دهنده فرصت خوبی برای ممیزی عادت‌های ارسال شماست. به یاد داشته باشید که پذیرش توسط ارائه‌دهنده فقط اولین مانع است. تحویل به این بستگی دارد که ISP گیرنده (Gmail، Outlook و غیره) اتصال را بپذیرد. رسیدن به صندوق ورودی آخرین مانع است و اعتبار بلندمدت دامنه شما و نرخ تعامل گیرندگانتان آن را تعیین می‌کند.

از وسوسه استفاده از این API‌ها برای ایمیل انبوه ناخواسته دوری کنید. این کار نه‌تنها اغلب غیرقانونی است، بلکه صرف‌نظر از ارائه‌دهنده‌ای که انتخاب می‌کنید به تعلیق حساب شما منجر می‌شود. به ارتباطات تراکنشی و مبتنی بر رضایت پایبند بمانید تا امتیاز فرستنده سالمی داشته باشید.

تیم‌هایی که برنامه‌های مبتنی بر هوش مصنوعی می‌سازند باید به دنبال ارائه‌دهندگانی باشند که قابلیت‌های آمادگی برای ایجنت، مانند سرورهای MCP و فایل‌های llms.txt، را برای یکپارچه‌سازی بی‌دردسر ارائه می‌دهند. SendHQ دقیقاً برای همین گردش‌کار طراحی شده و زیرساخت لازم برای تیم‌های محصول مدرن را فراهم می‌کند.

درباره ساخت سیستم‌های ایمیل قابل‌اعتماد در https://sendhq.cc بیشتر بدانید.