وضع Sandbox في Amazon SES: لماذا لا تصل رسائلك للعملاء وكيف تطلب رفع الحد إلى الإنتاج

أعددت كل شيء — قالب البريد الإلكتروني، منطق الإرسال، بيانات الاعتماد — وعندما اختبرت الإرسال لنفسك نجح كل شيء. لكن حين حاولت إرسال رسالة لأحد عملائك الفعليين، اختفت الرسالة تماماً. هذا هو وضع Sandbox في Amazon SES، وهو قيد افتراضي يطبّقه AWS على كل حساب جديد يستخدم خدمة البريد الإلكتروني SES.

ملخص سريع (TL;DR) — وضع Sandbox في SES

الجانب	وضع Sandbox	وضع الإنتاج
المستلمون المسموح بهم	عناوين بريد إلكتروني موثّقة (Verified) فقط	أي عنوان بريد إلكتروني
حد الإرسال اليومي	محدود — راجع التوثيق الرسمي	أعلى بكثير — يتدرّج حسب السمعة
معدل الإرسال	محدود — راجع التوثيق الرسمي	أعلى — يتدرّج حسب الاستخدام
طريقة الخروج	طلب رفع الحد عبر AWS Support	—
وقت المعالجة المعتاد	—	24 ساعة في الغالب (غير مضمون)

كيف يعمل وضع Sandbox في SES

عند إنشاء حساب AWS جديد وتفعيل SES لأول مرة، يضعك AWS تلقائياً في وضع Sandbox. هذا ليس خطأً في الإعداد — إنه سياسة مقصودة لحماية سمعة خوادم البريد الخاصة بـ AWS من الإساءة المبكرة. الفكرة بسيطة: قبل أن تثق بأي مُرسِل جديد بإرسال رسائل لعناوين عشوائية، تتحقق أولاً من نيّته.

في وضع Sandbox، يمكنك الإرسال فقط من وإلى عناوين البريد الإلكتروني أو النطاقات التي وثّقتها مسبقاً في SES. هذا يفسّر لماذا نجح إرسال الرسالة لنفسك — عنوانك موثّق — لكنه فشل مع عميلك الذي لم يُضَف لقائمة التوثيق.

graph TD A["حساب AWS جديد"] --> B["SES مُفعَّل تلقائياً في Sandbox"] B --> C{"هل المستلم موثَّق؟"} C -- نعم --> D["الإرسال ينجح"] C -- لا --> E["الرسالة تُرفض"] B --> F["طلب رفع الحد عبر AWS Support"] F --> G["مراجعة AWS"] G -- موافقة --> H["وضع الإنتاج مُفعَّل"] G -- رفض أو طلب معلومات --> F H --> I["الإرسال لأي عنوان بريد إلكتروني"]

1. الحساب الجديد: كل حساب AWS يبدأ في Sandbox تلقائياً عند استخدام SES.
2. التحقق من المستلم: SES يتحقق إذا كان عنوان المستلم موثّقاً في حسابك.
3. الرفض الصامت: الإرسال لعنوان غير موثّق يُرفض — في بعض الحالات دون رسالة خطأ واضحة.
4. طلب الرفع: الخروج من Sandbox يتطلب طلباً صريحاً عبر AWS Support.
5. وضع الإنتاج: بعد الموافقة، يمكنك الإرسال لأي عنوان بريد إلكتروني.

التحقق من وضعك الحالي في SES

قبل أي شيء، تأكد من المنطقة التي تستخدمها — SES خدمة إقليمية، ووضع Sandbox مستقل لكل منطقة. حساب في us-east-1 قد يكون في الإنتاج بينما نفس الحساب في eu-west-1 لا يزال في Sandbox.

# التحقق من حالة الإرسال في المنطقة الحالية
aws ses get-send-quota --region us-east-1

الناتج يُظهر Max24HourSend وMaxSendRate وSentLast24Hours. لكن هذا وحده لا يخبرك صراحةً إذا كنت في Sandbox. الطريقة الأوضح هي عبر واجهة AWS Console أو عبر فحص Account-level sending status:

# فحص حالة الحساب في SES v2
aws sesv2 get-account --region us-east-1

في الناتج، ابحث عن ProductionAccessEnabled. إذا كانت القيمة false، أنت لا تزال في Sandbox.

خطوات طلب رفع الحد إلى الإنتاج

الخروج من Sandbox لا يتم تلقائياً — يجب أن تطلب ذلك صراحةً عبر AWS Support. إليك العملية الكاملة.

الخطوة 1: توثيق نطاقك أو عنوان بريدك أولاً

قبل تقديم الطلب، تأكد أن النطاق الذي ستُرسل منه موثّق في SES. AWS لن يوافق على طلبك إذا لم يكن لديك هوية مُرسِل موثّقة — هذا أول ما يتحقق منه فريق المراجعة.

# التحقق من الهويات الموثّقة
aws sesv2 list-email-identities --region us-east-1

إذا لم يظهر نطاقك، وثّقه أولاً:

# توثيق نطاق جديد
aws sesv2 create-email-identity \
  --email-identity example.com \
  --region us-east-1

بعد التوثيق، تأكد من إعداد سجلات DKIM و SPF في DNS الخاص بنطاقك. طلبات الإنتاج التي تأتي بدون DKIM مُفعَّل غالباً تُرفض أو تتأخر.

الخطوة 2: تقديم طلب رفع الحد عبر AWS Support

الطريقة الرسمية هي عبر AWS Console في قسم SES مباشرةً. انتقل إلى SES Console → Account dashboard → Request production access. هذا يفتح نموذجاً مدمجاً يُنشئ تذكرة AWS Support تلقائياً من النوع Service Limit Increase.

يمكن أيضاً تقديم الطلب مباشرةً عبر AWS Support Center بتحديد:

• Regarding: Service Limit Increase
• Limit Type: SES Sending Limits
• Region: المنطقة التي تريد رفع الحد فيها

الخطوة 3: كتابة طلب مقنع — هذا ما يحدد الموافقة

هنا يخطئ معظم المطورين. يكتبون طلباً مختصراً من سطرين ويتفاجؤون بالرفض أو بطلب معلومات إضافية. فريق مراجعة SES يبحث عن إجابات محددة:

• نوع البريد الإلكتروني: هل هو تسويقي (Marketing)، أم معاملاتي (Transactional)، أم كلاهما؟
• كيف جمعت قائمة المستلمين: هل هم مشتركون اختاروا الاشتراك (Opt-in)؟ متى وكيف؟
• كيف تتعامل مع طلبات إلغاء الاشتراك: هل لديك آلية Unsubscribe واضحة؟
• كيف تتعامل مع الارتداد (Bounce) والشكاوى (Complaint): هل تراقب هذه المعدلات وتتخذ إجراءً؟
• الحجم المتوقع: كم رسالة يومياً أو شهرياً تتوقع إرسالها؟

فكّر في الأمر كأنك تتقدم لاستئجار خادم بريد مشترك — المالك يريد أن يعرف أنك لن تُدمّر سمعة الخادم بإرسال spam. كلما كانت إجاباتك أكثر تفصيلاً وتدل على وعي بمعايير إرسال البريد، زادت فرصة الموافقة السريعة.

الخطوة 4: التحقق من الموافقة بعد تحديث الطلب

بعد موافقة AWS، تحقق مجدداً من حالة الحساب للتأكد من تفعيل وضع الإنتاج:

aws sesv2 get-account --region us-east-1

ابحث عن ProductionAccessEnabled: true في الناتج. إذا لم تتغير القيمة بعد 24 ساعة من إشعار الموافقة، تواصل مع AWS Support مجدداً.

إعداد مراقبة Bounce وComplaint — شرط غير معلن للبقاء في الإنتاج

الحصول على موافقة الإنتاج ليس نهاية القصة. AWS يراقب معدلات الارتداد والشكاوى باستمرار، وإذا تجاوزت حدوداً معينة، قد يُعلّق حسابك تلقائياً — هذه المرة دون إشعار مسبق كافٍ.

الطريقة الصحيحة هي ربط SES بـ SNS لاستقبال إشعارات Bounce وComplaint فور حدوثها:

# ربط هوية البريد بـ SNS لإشعارات Bounce
aws sesv2 put-email-identity-feedback-attributes \
  --email-identity example.com \
  --email-forwarding-enabled false \
  --region us-east-1

ثم اضبط Configuration Set لإرسال أحداث الإرسال لـ SNS أو CloudWatch:

# إنشاء Configuration Set
aws sesv2 create-configuration-set \
  --configuration-set-name my-config-set \
  --region us-east-1

راجع التوثيق الرسمي لـ SES لإعداد Event Destinations داخل Configuration Set — الخطوات تختلف حسب نوع الوجهة (SNS، CloudWatch، Kinesis).

سيناريو حقيقي: التشخيص الخاطئ الشائع

المشكلة ظهرت في بيئة staging: الرسائل تُرسَل بنجاح لعناوين الفريق الداخلي، لكن لا شيء يصل لعملاء beta. السجلات تُظهر MessageId صحيحاً — أي أن SES قَبِل الرسالة من الناحية التقنية.

التشخيص الأول كان خاطئاً: ظننا أن المشكلة في إعداد SPF أو DKIM لأن بعض رسائل الاختبار وصلت. الواقع أن الرسائل التي وصلت كانت كلها لعناوين موثّقة مسبقاً في حساب SES، والرسائل التي لم تصل كانت لعناوين خارج قائمة التوثيق.

المفتاح كان في فحص SES Event Logs في CloudWatch — ظهر فيها Rendering Failure لبعض الرسائل وSend ناجح لأخرى. لكن الرسائل التي رُفضت بسبب Sandbox لم تظهر في السجلات أصلاً لأنها رُفضت قبل الإرسال الفعلي.

الدرس: MessageId في استجابة SES يعني أن الرسالة قُبلت للمعالجة، لا أنها وصلت. في وضع Sandbox، الرسالة المرسلة لعنوان غير موثّق قد تُرفض بعد القبول الأولي.

sequenceDiagram participant App as التطبيق participant SES as Amazon SES participant CW as CloudWatch participant Inbox as صندوق المستلم App->>SES: SendEmail API SES-->>App: 200 OK + MessageId SES->>SES: فحص وضع Sandbox alt المستلم موثَّق SES->>Inbox: تسليم الرسالة SES->>CW: حدث Send ناجح else المستلم غير موثَّق SES->>SES: إسقاط الرسالة داخلياً Note over SES,CW: قد لا يظهر سجل واضح في CloudWatch end

1. طلب الإرسال: تطبيقك يستدعي SES API.
2. القبول الأولي: SES يُعيد MessageId — هذا لا يعني الوصول.
3. فحص Sandbox: SES يتحقق إذا كان المستلم موثّقاً.
4. الرفض الداخلي: إذا لم يكن موثّقاً، الرسالة تُسقط داخلياً.
5. غياب السجل: هذا الرفض لا يظهر دائماً في CloudWatch بشكل واضح.

صلاحيات IAM المطلوبة للعمل مع SES

إذا كنت تُشغّل هذه الأوامر من دور IAM أو مستخدم محدود الصلاحيات، تأكد من وجود الصلاحيات التالية:

🔽 انقر لعرض سياسة IAM المطلوبة

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SESReadAndSend",
      "Effect": "Allow",
      "Action": [
        "ses:GetSendQuota",
        "ses:ListIdentities",
        "sesv2:GetAccount",
        "sesv2:ListEmailIdentities",
        "sesv2:CreateEmailIdentity",
        "sesv2:PutEmailIdentityFeedbackAttributes",
        "sesv2:CreateConfigurationSet",
        "sesv2:SendEmail"
      ],
      "Resource": "*"
    }
  ]
}

لاحظ أن عدة عمليات Read/List في SES تتطلب "Resource": "*" لأن Service Authorization Reference لا يدعم تقييد الموارد على مستوى ARN لهذه الإجراءات تحديداً. تحقق دائماً من مرجع تفويض خدمة SES قبل تضييق الصلاحيات.

الخلاصة والخطوات التالية — الخروج من Sandbox في SES

وضع Sandbox في Amazon SES ليس عقبة تقنية — هو بوابة ثقة. AWS يريد أن يرى أنك تفهم معايير إرسال البريد الإلكتروني قبل أن يمنحك وصولاً غير مقيّد لخوادمه.

الخطوات الحاسمة:

1. تحقق من وضعك الحالي باستخدام aws sesv2 get-account في كل منطقة تستخدمها.
2. وثّق نطاقك وفعّل DKIM قبل تقديم الطلب.
3. اكتب طلب رفع الحد بتفصيل كافٍ — اشرح نوع البريد، مصدر القائمة، وآلية التعامل مع Bounce وComplaint.
4. بعد الموافقة، أعدّ مراقبة Bounce وComplaint فوراً — لا تنتظر حتى تظهر مشكلة.

للمزيد من التفاصيل، راجع التوثيق الرسمي لطلب وصول الإنتاج في SES.

مسرد المصطلحات

المصطلح	التعريف
Sandbox Mode	وضع افتراضي في SES يقيّد الإرسال لعناوين موثّقة فقط، يُطبَّق على كل حساب جديد.
Verified Identity	عنوان بريد إلكتروني أو نطاق تم التحقق من ملكيته في SES عبر رابط تأكيد أو سجل DNS.
Bounce Rate	نسبة الرسائل التي لم تصل لصناديق البريد المستهدفة — ارتفاعها يُعرّض الحساب للتعليق.
Complaint Rate	نسبة المستلمين الذين أبلغوا عن الرسالة كـ spam — تُراقَب بدقة من AWS.
Configuration Set	مجموعة قواعد في SES تتحكم في تتبع أحداث الإرسال وتوجيهها لخدمات مثل SNS أو CloudWatch.

Related Posts

• 📄 إرسال تنبيهات البريد الإلكتروني عبر SNS: لماذا لا تصل الرسائل؟