Documentation menu

الإرسال المباشر

ملاحظة: الإرسال المباشر متاح في كل باقة، بما فيها الباقة المجانية — فهو محسوب بحسب الحجم الشهري، لا محجوب خلف ترقية. راجع الأسعار لمعرفة الحصة المتاحة في كل مستوى.

إلى جانب خادم ترحيل SMTP الخاص بك، يستطيع MailInApp الإرسال مباشرة من نطاق توثّقه لدينا — دون مزوّد خدمة بريد، ودون بيانات اعتماد SMTP تحتاج إلى إنشائها وتدويرها. يجري التسليم على بنيتنا التحتية (Amazon SES) باستخدام نطاق الإرسال الخاص بك، فيرى المستلمون بريدًا من [email protected]، لا من عنوان MailInApp مشترك.

توثيق نطاق

ضمن الإعدادات ← النطاقات، ترشدك الصفحة خطوة بخطوة:

  1. أدخل نطاقك واضغط توثيق النطاق. افتراضيًا، ينشئ MailInApp هوية إرسال لـ mail.<yourdomain> ونطاقًا فرعيًا لمعالجة الارتدادات (bounce.mail.<yourdomain>) — وهو نطاق فرعي مخصّص يتعايش بأمان مع أي بريد آخر تشغّله أصلًا على النطاق الجذري. وإن فضّلت الإرسال من النطاق الجذري مباشرة ([email protected]، لا [email protected])، فحدّد استخدام النطاق الجذري بدلًا من نطاق فرعي — ولا تفعل ذلك إلا إن كان النطاق غير مستخدم لأي بريد آخر؛ راجع استقبال البريد على نطاقك لمعرفة سبب ازدياد أهمية ذلك عند تفعيل الاستقبال الوارد.
  2. أضف سجلات DNS المعروضة — بضعة سجلات CNAME خاصة بـ DKIM، وسجل MX وسجل TXT للنطاق الفرعي للارتدادات، وسجل TXT أوّليًا لـ DMARC — لدى مزوّد DNS الخاص بك. تثبت هذه السجلات أنك تتحكم في النطاق، وتتيح للبريد المرسل عبره اجتياز فحوص DKIM/SPF.
  3. اضغط التحقق الآن بعد إضافتها، أو انتظر فحسب — فـ MailInApp يتحقق تلقائيًا كل 15–30 دقيقة.
  4. بمجرد أن يظهر كلٌّ من النطاق والنطاق الفرعي MAIL FROM بحالة موثّق، يظهر مفتاح تبديل لتحويل طريقة الإرسال في حسابك إلى الإرسال المباشر.

العودة إلى SMTP متاحة دائمًا وفورية — ولا تفصل النطاق، فيمكنك التبديل بين الطريقتين دون إعادة التوثيق.

DMARC

يخبر DMARC صناديق البريد الوارد بما يجب فعله مع البريد الذي يدّعي أنه من نطاقك لكنه يفشل في SPF/DKIM — رفضه، أو إرساله إلى البريد العشوائي، أو (وهو الإعداد الافتراضي الذي نولّده) مراقبته فقط. وهو السجل الوحيد هنا الذي لا يستطيع MailInApp التحقق منه تلقائيًا بالطريقة التي يتحقق بها من حالة DKIM وMAIL FROM — إذ لا توجد واجهة API لذلك، فيُعرض لتضيفه لكنه لا يُظهر أبدًا شارة «موثّق/قيد الانتظار».

يأتي السجل الذي نولّده بقيمة p=none (مراقبة فقط) عن قصد — فلن يؤثر في التسليم بمفرده. وبمجرد تأكدك من أن لا شيء مشروعًا يفشل، شدّد السياسة إلى p=quarantine ثم إلى p=reject في نهاية المطاف لدى مزوّد DNS الخاص بك. ومعظم مزوّدي DNS، بما فيهم Cloudflare، يعرضون لك تقارير DMARC التجميعية إن أضفت عنوان rua=mailto: الخاص بك إلى السجل.

ما لا يتغيّر

الإرسال اليدوي، والإرسال المجدول، ورسائل دورة الحياة (إشعارات الطلبات/التذاكر)، وواجهة Send API للبريد المعاملاتي — كلها تمر عبر طريقة الإرسال المضبوطة في حسابك أيًّا كانت — فلا توجد إعدادات منفصلة لكل ميزة. ويعمل حظر الإرسال، وسجل الإرسال، وتتبّع التفاعلات، والردود بشكل مطابق بغض النظر عن الطريقة التي سلّمت البريد.

وضع الاختبار المعزول (Sandbox)

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