انتهت باقة SendGrid المجانية: دليل ترحيل في 30 دقيقة

نهاية الباقة المجانية الدائمة

إذا كنت تعتمد على الباقة المجانية في SendGrid لمشروع جانبي منخفض الحجم أو منتج جديد، فمن المرجح أنك لاحظت التغيير: أصبحت الباقة المجانية فترة تجريبية مدتها 60 يومًا. وبعد انتهاء الفترة التجريبية يجب الانتقال إلى باقة مدفوعة، مع بدء Essentials من 19.95 USD شهريًا (أسعار SendGrid). وللترحيل تحتاج إلى تصدير قوائم المنع وتحديث سجلات DNS وتبديل تكامل API. تستغرق هذه العملية نحو 30 دقيقة إذا كانت قوالبك بسيطة.

تقييم البدائل

عند اختيار بديل، يجب أن تميّز بين قبول المزوّد (قبول API لطلبك) والتسليم (قبول الخادم المستقبِل للرسالة) والوصول إلى صندوق الوارد (تجنّب الرسالة مجلد البريد المزعج). ولا يستطيع أي مزوّد ضمان الأخير، لأنه يعتمد على سمعة مُرسِلك ومحتواك.

مشهد التكاليف (سبتمبر 2026)

بالنسبة إلى البريد المعاملاتي منخفض الحجم، فإن فارق السعر كبير. فإرسال 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: توفّر بديلًا حديثًا لفرق المنتجات ووكلاء الذكاء الاصطناعي، مع التركيز على القياس عن بُعد (telemetry) الذي يحدّ من جمع البيانات الخاصة ويقتصر على الاتحاد الأوروبي، ومفاتيح API محدودة النطاق بمساحة العمل.

الخطوة 1: تصدير البيانات وقوائم المنع

لا ترحّل قائمتك دون تصدير قوائم المنع. فإذا أرسلت إلى عنوان ارتدت رسائله سابقًا أو ألغى اشتراكه، فإنك تخاطر بالإضرار بسمعتك لدى المزوّد الجديد.

تتيح لك SendGrid تصدير قائمة المنع عبر الواجهة أو API. وستحصل على ملف CSV بعناوين البريد التي لا ينبغي الاتصال بها. وعند استيرادها إلى مزوّد جديد، احرص على ربط «السبب» (ارتداد أو إلغاء اشتراك) بشكل صحيح للحفاظ على الامتثال لقوانين مثل GDPR أو CAN-SPAM.

الخطوة 2: DNS والمصادقة

هنا تفشل معظم عمليات الترحيل. لا يمكنك ببساطة تغيير مفتاح API؛ بل يجب أن تثبت ملكية النطاق للمزوّد الجديد.

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 كما هي أيًّا كان المزوّد، لأنها سياسة على مستوى النطاق. لكن تأكد من أن مزوّدك الجديد محاذٍ لسياسة DMARC لديك لتجنب رفض الرسائل. راجع دليل DKIM وSPF وDMARC لمعرفة تفاصيل التنفيذ.

الخطوة 3: ترحيل الشيفرة

تستخدم معظم المزوّدات REST API. وإذا كنت تستخدم القوالب الديناميكية في SendGrid، فستحتاج إلى ترحيل تخطيطات HTML/CSS تلك إلى محرك القوالب لدى المزوّد الجديد.

مثال: من SendGrid إلى REST API عام

تستخدم SendGrid بنية JSON محددة لـ personalizations. وتفضّل معظم واجهات API الحديثة، ومنها SendHQ، بنية أكثر تسطّحًا لسهولة القراءة.

حمولة SendGrid:

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

حمولة 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: وكلاء الذكاء الاصطناعي وعدم التكرار

إذا كنت تستخدم وكلاء ذكاء اصطناعي لإطلاق الرسائل، فأنت تواجه خطرًا محددًا: قد يدخل الوكيل في حلقة أو يعيد الطلب مرات عدة بسبب انتهاء المهلة، فيتلقى المستخدم عشر رسائل متطابقة.

إرسال البريد أثر جانبي خارجي. يجب أن تطبّق عدم التكرار. مفتاح عدم التكرار (idempotency key) معرّف فريد يُرسَل في الترويسة ويخبر API: «إذا سبق أن رأيت هذا المفتاح، فلا ترسل الرسالة مرة أخرى؛ بل أعد استجابة النجاح الأصلية فقط».

تنفيذ جاهز للوكلاء:

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

وبالإضافة إلى ذلك، في إجراءات الوكلاء عالية المخاطر (مثل إرسال إعادة تعيين كلمة المرور أو تنبيه فوترة)، طبّق خطوة موافقة يشارك فيها إنسان أو حد معدّل صارمًا لكل معرّف مستخدم، لمنع هلوسات الوكلاء من إغراق عملائك برسائل مزعجة.

الخطوة 5: الاختبار والتحقق

قبل تبديل متغير البيئة إلى المزوّد الجديد، مرّ بقائمة التحقق هذه:

• انتشار DNS: استخدم أداة مثل dig أو أداة فحص على الويب للتأكد من أن سجلات DKIM وSPF الجديدة مفعّلة.
• التحقق من webhook: إذا كنت تعتمد على أحداث التسليم (delivered وopened وclicked)، فحدّث نقاط نهاية webhook لديك. يختلف تنسيق أحداث SendGrid عن غيره. وتأكد من أن نقطة النهاية لديك تستطيع التعامل مع مخطط JSON الجديد دون أن تتعطل.
• معالجة الأخطاء: اختبر كيف يتعامل تطبيقك مع الأخطاء الخاصة بالمزوّد. فمثلًا، ينبغي أن يؤدي 429 (Too Many Requests) إلى تفعيل استراتيجية التراجع، بينما يشير 400 (Bad Request) عادةً إلى عنوان بريد مشوَّه ينبغي تعليمه على أنه ارتداد في قاعدة بياناتك.

حالات الخطأ الشائعة التي يجب اختبارها

1. تنسيق بريد غير صالح: تأكد من أن API يُعيد خطأ واضحًا وأن شيفرتك لا تعيد المحاولة إلى ما لا نهاية.
2. تحديد المعدّل: حاكِ دفقة كبيرة من الرسائل لترى ما إذا كان طابورك يتعامل مع حدود المزوّد.
3. المرفقات الكبيرة: تحقق من الحد الأقصى لحجم الحمولة لدى المزوّد الجديد. يحدّك بعضهم بـ 10MB وآخرون بـ 25MB.

قائمة تحقق ملخصة للترحيل

• تصدير قوائم المنع: تصدير CSV من SendGrid.
• إعداد سجلات DNS: محاذاة SPF وDKIM وDMARC.
• ترحيل القوالب: حوّل HTML/CSS إلى التنسيق الجديد.
• تحديث منطق API: نفّذ غلاف المزوّد.
• إضافة عدم التكرار: ضروري لمشغلات وكلاء الذكاء الاصطناعي.
• اختبار webhooks: تحقق من تسليم الأحداث وتحليلها.
• تحويل حركة المرور: حدّث متغير ENV وراقب السجلات.

خلاصة حول قابلية التسليم

تغيير المزوّد فرصة جيدة لتدقيق عادات الإرسال لديك. تذكّر أن قبول المزوّد ليس سوى العقبة الأولى. فالتسليم يعتمد على قبول مزوّد خدمة الإنترنت المستقبِل (Gmail وOutlook وغيرهما) للاتصال. أما الوصول إلى صندوق الوارد فهو العقبة الأخيرة، ويتحدد بسمعة نطاقك على المدى الطويل ومعدلات تفاعل مستلِميك.

تجنّب إغراء استخدام واجهات API هذه لإرسال بريد جماعي غير مرغوب فيه. فهو ليس غير قانوني في أغلب الأحيان فحسب، بل سيؤدي إلى تعليق حسابك أيًّا كان المزوّد الذي تختاره. والتزم بالتواصل المعاملاتي القائم على الموافقة للحفاظ على درجة مُرسِل سليمة.

للفرق التي تبني تطبيقات أصلية للذكاء الاصطناعي، ابحث عن مزوّدين يقدّمون ميزات جاهزية للوكلاء مثل خوادم MCP وملفات llms.txt لجعل التكامل سلسًا. وقد صُمّمت SendHQ لسير العمل هذا تحديدًا، إذ توفّر البنية التحتية التي تحتاجها فرق المنتجات الحديثة.

اعرف المزيد عن بناء أنظمة بريد موثوقة على https://sendhq.cc.