كيف ترسل رسائل البريد الإلكتروني من تطبيقك (وتصل إلى صندوق الوارد)

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

البريد المعاملاتي مقابل البريد التسويقي

يشبه هذان النوعان بعضهما في الكود، لكن مزودي صناديق الوارد والقانون يتعاملان معهما بشكل مختلف تماماً.

أبقِهما منفصلين. إذا تلقّت حملة تسويقية شكاوى بريد مزعج، فلا تريد أن تتضرر رسائل إعادة تعيين كلمة المرور من المسار نفسه بسببها. ومن الأساليب الشائعة استخدام نطاقات فرعية منفصلة، مثل mail.example.com لبريد الحساب وnews.example.com للنشرات الإخبارية، وبعض المزوّدين يفصلان بينهما داخلياً. فعلى سبيل المثال، تصف Postmark مساري "تدفق الرسائل" المعاملاتي والبث بأنهما يعملان على بنية إرسال منفصلة، وذلك اعتباراً من سبتمبر 2026.

اختيار المزوّد

لا ينبغي لتطبيقك أن يرسل البريد بنفسه من خادمه. فمزودو الإرسال يتولون البنية التحتية وسمعة عناوين IP وإعادة المحاولة ومعالجة الرسائل المرتدة. ومن الخيارات المعروفة Postmark وResend وSendGrid وAmazon SES وMailgun؛ ولكل منها واجهة HTTP ووصول عبر SMTP، والأسعار والخطط تتغير، لذا قارنها على مواقعها الرسمية.

ما الذي تقارنه:

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

بالنسبة للنشرات الإخبارية المرسلة إلى قائمة، غالباً ما تكون أداة نشرات أو تسويق بالبريد المخصصة أنسب من بناء ميزات الحملات داخل تطبيقك.

إعداد نطاق الإرسال

أرسل من نطاقك الخاص، مثل hello@example.com، وليس من عنوان Gmail أو Outlook. فالبريد المرسل من صندوق مجاني عبر خدمة طرف ثالث يفشل في فحوص المصادقة ويُرجح أن يُصفّى.

فكّر في نطاق فرعي مخصص للإرسال فقط. فعلى سبيل المثال، توصي Resend بالإرسال من نطاقات فرعية مثل updates.example.com لعزل سمعة الإرسال، وذلك اعتباراً من سبتمبر 2026. كما يُبقي ذلك سجلات DNS الخاصة بالبريد منفصلة عن سجلات موقعك الرئيسي.

ثم يعطيك المزوّد سجلات DNS لإضافتها حيث تُدار إعدادات DNS لنطاقك. وإذا كان DNS جديداً عليك، فإن كيف تعمل النطاقات وDNS يشرح السجلات أولاً.

SPF

SPF (إطار سياسة المرسل) هو سجل TXT يسرد الخوادم المسموح لها بإرسال البريد عن نطاقك. ويتحقق المستلم مما إذا كان الخادم المرسِل ضمن هذه القائمة.

• يجب أن يكون لنطاقك سجل SPF واحد فقط. وإذا أضفت مزوّداً، فادمجه في السجل الحالي بدلاً من إضافة سجل ثانٍ.
• يسمح SPF بما يصل إلى 10 عمليات بحث DNS عند تقييمه؛ وقد تتجاوز السلاسل الطويلة من مدخلات include: هذا الحد فتسبب إخفاقات.
• كثير من المزودين يضبطون SPF على نطاق فرعي لمسار الرجوع الذي يطلبون منك إنشاءه، لذا قد لا تحتاج إلى تعديل سجل SPF الرئيسي أصلاً.

DKIM

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

خطوة "التحقق من النطاق" لدى المزوّد تتعلق في معظمها بـ DKIM، فلا تتجاوزها.

DMARC

DMARC يربط السجلين الآخرين ببعضهما. وهو سجل TXT على _dmarc.yourdomain.com يخبر المستلمين بما يلي:

• المحاذاة: يجب أن يتطابق النطاق الظاهر في عنوان "من" مع النطاق الذي نجح في SPF أو DKIM.
• السياسة: ما يجب فعله مع البريد الفاشل، وهي p=none (الإبلاغ فقط)، أو p=quarantine (اعتباره مشبوهاً، وغالباً ما يُوضع في الرسائل المزعجة)، أو p=reject (رفضه).
• التقارير: العنوان الذي تُرسل إليه التقارير المجمّعة (rua=)، حتى تعرف من يرسل باسم نطاقك.

مسار مناسب هو البدء بـ p=none مع عنوان للتقارير، والتأكد من أن بريدك المشروع ينجح، ثم الانتقال إلى quarantine وفي النهاية إلى reject. كما أن السياسة الصارمة تصعّب على الآخرين انتحال نطاقك.

ما الذي تشترطه Gmail

اعتباراً من سبتمبر 2026، تنص إرشادات Google للمرسلين على ما يلي:

• جميع المرسلين إلى حسابات Gmail الشخصية يحتاجون إلى SPF أو DKIM، وإلى سجل عكسي وأمامي صحيح لخوادم الإرسال، وTLS، ومعدل رسائل مزعجة في Postmaster Tools أقل من 0.3%.
• المرسلون بالجملة (أكثر من 5,000 رسالة يومياً إلى Gmail) يحتاجون إلى SPF وDKIM، وسجل DMARC (تُسمح سياسة p=none)، ومحاذاة نطاق "من"، وإلغاء اشتراك بنقرة واحدة، ورابط إلغاء اشتراك ظاهر في الرسائل التسويقية والرسائل المشترَك فيها.

المزوّد يتولى الجوانب الخاصة بالخادم. أما سجلات DNS ومعالجة إلغاء الاشتراك فهي مسؤوليتك. وحتى لو كنت بعيداً جداً عن 5,000 رسالة يومياً، فإن الالتزام بقواعد الإرسال بالجملة هو أبسط طريقة لتكون في أمان.

ادمج الإرسال في تطبيقك

بعد التحقق من النطاق:

1. خزّن مفتاح الواجهة البرمجية كمتغير سري على الخادم، ولا تضعه أبداً في كود الواجهة الأمامية. انظر ما هي متغيرات البيئة والأسرار.
2. أرسل من الخادم، بعد أن ينجح الفعل الذي يُطلق البريد.
3. لا تجعل المستخدم ينتظر البريد. لأي شيء يتجاوز التطبيق البسيط جداً، ضع الإرسال في قائمة انتظار وأعد المحاولة عند الأعطال المؤقتة، حتى لا يؤدي بطء استجابة المزوّد إلى إبطاء التسجيل.
4. سجّل النتيجة، أي معرّف الرسالة وحالتها لدى المزوّد، دون تسجيل المفتاح أو نصوص الرسائل الكاملة التي تحتوي على بيانات شخصية.
5. تعامل مع Webhooks الخاصة بالرسائل المرتدة والشكاوى: أوقف الإرسال إلى العناوين التي ترتد نهائياً أو يعلّم أصحابها الرسائل كبريد مزعج.

وهذا نص يغطي الأساسيات:

أرسل بريداً معاملاتياً باستخدام [PROVIDER] بالمتغير السري على الخادم [ENV_NAME]، من "Acme hello@mail.acme.com". أرسل بريد ترحيب بعد التسجيل، وتأكيد حجز بعد حفظ الحجز. احتفظ بالقوالب في الكود، مع نسخة نصية عادية إلى جانب HTML. ضع الإرسال في قائمة انتظار وأعد محاولة الأعطال المؤقتة حتى ثلاث مرات. سجّل الأخطاء مع خطأ المزوّد، لكن لا تسجّل مفتاح الواجهة البرمجية أبداً. أضف نقطة نهاية Webhook تعلّم العناوين بأنها غير قابلة للتسليم عند الارتداد النهائي والشكاوى، وتتجاوزها في المستقبل.

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

عادات قابلية التسليم

المصادقة تجعل رسالتك مُعتبرة، والسلوك هو ما يُبقيها في صندوق الوارد.

• أرسل ما يتوقعه الناس. تسجيلات مؤكدة، وموافقة صريحة للبريد التسويقي، ولا قوائم مشتراة.
• اجعل إلغاء الاشتراك سهلاً في أي بريد ليس معاملاتياً بحتاً، واحترمه فوراً.
• سخّن النطاقات الجديدة تدريجياً. فالنطاق الجديد الذي يرسل آلاف الرسائل في أول يوم يبدو مشبوهاً. ابدأ ببريدك المعاملاتي، وزد الحجم تدريجياً.
• أبقِ القوائم نظيفة. أزل الرسائل المرتدة نهائياً فوراً، وفكّر في إزالة من لم يفتحوا أي رسالة منذ فترة طويلة.
• اكتب كإنسان. موضوع واضح، واسم مرسل يسهل التعرف عليه، ونص عادي، وصور وروابط قليلة تشير إلى نطاقك. وتجنب مختصرات الروابط.
• راقب. سجّل نطاقك في Google Postmaster Tools، واقرأ تقارير DMARC من حين لآخر.
• استخدم عنوان رد حقيقياً يقرأه شخص فعلاً. فالردود إشارة جيدة، وتغذية راجعة مفيدة.

الاختبار دون إزعاج أحد

• استخدم وضع الاختبار أو البيئة التجريبية لدى المزوّد إن وُجد، أو أرسل إلى عناوين تملكها.
• في بيئة التطوير، أرسل إلى صندوق اختبار يستقبل كل الرسائل بدلاً من المستخدمين الحقيقيين؛ فقاعدة بيانات مليئة ببيانات تبدو حقيقية قد تجعلك ترسل بالخطأ إلى أشخاص غرباء.
• اختبر كل قالب في عدة عملاء بريد، مثل Gmail على الويب، وتطبيق البريد على الهاتف، وOutlook، وفي الوضع الداكن.
• انظر إلى ترويسات رسالة الاختبار؛ فهي تُظهر ما إذا كانت SPF وDKIM وDMARC قد نجحت.

الأساسيات القانونية

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

قائمة تحقق البريد الإلكتروني

• تم اختيار مزوّد الإرسال، وخُزّن مفتاح الواجهة البرمجية كمتغير سري على الخادم
• الإرسال من نطاقك أو نطاق فرعي تملكه، وليس من صندوق بريد مجاني
• أُضيفت سجلات SPF وDKIM وDMARC وتنجح جميعها
• البريد المعاملاتي والتسويقي منفصلان
• الرسائل توضع في قائمة انتظار وتُعاد محاولتها، وتُسجَّل النتائج
• تمت معالجة Webhooks الخاصة بالرسائل المرتدة والشكاوى
• إلغاء الاشتراك في البريد غير المعاملاتي، ويُحترم فوراً
• اختُبرت القوالب في عدة عملاء، ولا تصل رسائل الاختبار إلى المستخدمين الحقيقيين أبداً

إرسال البريد الإلكتروني من تطبيق Mythex

لا يتضمن Mythex خدمة إرسال بريد مدمجة للتطبيقات التي تبنيها، لذا ستحتاج إلى مزوّد مثل Resend أو SendGrid أو Postmark. خزّن مفتاح واجهته البرمجية كمتغير سري للمشروع، ويمكن للوكيل أن يطلبه عبر بطاقة أسرار في المحادثة، واطلب رسائل البريد التي تحتاجها بكلمات بسيطة. تضم الوثائق نص طلب جاهز في إرسال البريد الإلكتروني من تطبيقك. وإذا اشتريت نطاقك عبر Mythex في خطة Pro، يمكنك إضافة سجلات TXT وCNAME الخاصة بالمزوّد في إعدادات DNS للنطاق؛ راجع النطاقات المخصصة.

الأسئلة