دليل التعامل مع حوادث تسليم البريد الإلكتروني: كيف تستجيب لانخفاض مفاجئ

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

ما الذي يُعدّ حادث تسليم

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

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

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

أول 30 دقيقة: الفرز والاحتواء

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

1. من الدقيقة 0 إلى 5: أعلن الحادث. افتح قناة مشتركة، وعيّن قائد الحادث، ودوّن وقت ملاحظة المشكلة لأول مرة والوقت المرجّح لبدايتها. استخدم UTC لكل الأوقات حتى تتطابق السجلات والتقارير والأشخاص في أماكن مختلفة.
2. من الدقيقة 5 إلى 10: احمِ الرسائل المعاملاتية. تأكد من أن رسائل إعادة تعيين كلمة المرور ورموز المرور لمرة واحدة والإيصالات ما زالت تُسلَّم، بإرسال بضع رسائل اختبار إلى صناديق بريد تتحكم بها لدى المزوّدين الرئيسيين. وإذا كانت تفشل، فاعدّ الحادث حرجًا.
3. من الدقيقة 10 إلى 15: أوقف الباقي أو خفّف معدله. أوقف الحملات الترويجية والنشرات الإخبارية وأي أتمتة مجدولة يمكنها الانتظار. وللتدفقات التي لا يمكن إيقافها كليًا، خفّض معدل الإرسال. لا تحذف الرسائل المصطفة في الانتظار بعد، لأنها دليل.
4. من الدقيقة 15 إلى 25: صنّف. اقرأ أعداد الارتدادات والتأجيلات والشكاوى بحسب مزوّد البريد لآخر يوم، مقارنةً بالأسبوع السابق. واستخدم جدول القرار أدناه لاختيار العائلة الأرجح من الأسباب.
5. من الدقيقة 25 إلى 30: وزّع المهام وأرسل التحديث الأول. كلّف كل محقق بسؤال محدد، وأرسل تحديثًا داخليًا موجزًا بالحقائق المعروفة حتى الآن وموعد التحديث التالي.

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

جدول ربط الأعراض بالأسباب

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

العَرَض	النطاق	الأسباب المحتملة	الفحوصات الأولى
ارتفاع الارتدادات (رفض 5xx)	جميع المزوّدين، يبدأ في وقت محدد بدقة	مصادقة معطلة، أو سجل DNS منتهي الصلاحية أو محذوف، أو بيانات اعتماد خاطئة، أو الإرسال من نطاق غير موثّق	سجلات DNS الخاصة بـ SPF وDKIM وDMARC؛ تغييرات DNS أو المزوّد الأخيرة؛ نص الخطأ في ردود الارتداد
ارتفاع الارتدادات (رفض 5xx)	مزوّد واحد	حظر بسياسة أو إدراج للسمعة لدى ذلك المزوّد، أو تغيير مفاجئ في الحجم أو المحتوى	نص الارتداد من ذلك المزوّد، وبيانات postmaster الخاصة به، وسجل الإرسال الأخير إليه
ارتفاع الارتدادات مع أخطاء مستخدم غير معروف	غالبًا حملة واحدة أو عملية استيراد واحدة	عناوين قديمة أو مشتراة أو مكتوبة بخطأ أُضيفت إلى قائمة	مصدر القائمة، وعمر العناوين، ونتائج التحقق
ارتفاع التأجيلات (4xx)	مزوّد أو اثنان	تحديد المعدل، أو مخاوف مبكرة بشأن السمعة، أو كثرة الاتصالات	نص التأجيل، ومعدل الإرسال والتزامن الحاليان، وعمر قائمة الانتظار
ارتفاع التأجيلات (4xx)	جميع المزوّدين	مشكلات في الشبكة أو DNS من جانبك، أو أعطال TLS، أو حدود الموارد على خوادم الإرسال	انتهاءات المهلة وأخطاء TLS في السجلات، وحل DNS من مضيفي الإرسال
ارتفاع الشكاوى	حملة أو شريحة واحدة	جمهور غير متوقع، أو مصدر اشتراك غير واضح، أو رابط إلغاء اشتراك يصعب العثور عليه	تعريف الشريحة، ومصدر الاشتراك، ووضوح رابط إلغاء الاشتراك، وبيانات حلقة التغذية الراجعة
انخفاض الفتح والنقر مع ثبات الارتدادات	مزوّد واحد	انتقال البريد إلى مجلد البريد غير المرغوب دون أي رفض	بيانات postmaster، ونتائج صناديق الاختبار الأولية أو اللجنة، والتغييرات الأخيرة في المحتوى أو الحجم
انخفاض الفتح والنقر مع ثبات الارتدادات	جميع المزوّدين	مشكلة في نطاق التتبع، أو حجب الصور، أو روابط معطلة، أو تغيير في القياس	شهادة نطاق التتبع وDNS الخاص به، واختبارات الروابط، وأي تغيير حديث في القالب
رسائل من مصادر غير مألوفة تمرّ باسم نطاقك في تقارير DMARC	تظهر في التقارير المجمّعة	انتحال، أو أداة طرف ثالث منسية ترسل باسمك	مصادر تقارير DMARC المجمّعة، وقائمة المرسلين المعتمدين، وسجلات الوصول لبيانات اعتماد الإرسال لديك

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

الأدلة التي تُجمع قبل تغيير أي شيء

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

الدليل	ما يخبرنا به	كيفية التقاطه
سجلات الأحداث لآخر 7 أيام	أعداد الرسائل المقبولة والمؤجلة والمرتدة والمشتكى منها بحسب المزوّد والتدفق والحملة	صدّرها من لوحة MigoSMTP أو API أو webhooks؛ وراجع حساب MigoSMTP أو وثائق API لمعرفة الخيارات بدقة
ردود الارتداد والتأجيل الخام	الصياغة الدقيقة التي يستخدمها المزوّدون لشرح المشكلة	انسخ عينة من كل رسالة مختلفة، مع رمز الحالة المحسّن، لكل مزوّد
الترويسات الكاملة لرسائل الاختبار المسلَّمة وتلك التي وصلت إلى مجلد البريد غير المرغوب	نتائج المصادقة والتوجيه وأي أحكام للمرشحات	أرسل اختبارات إلى صناديق بريد تتحكم بها واحفظ المصدر الأصلي لكل رسالة
تقارير DMARC المجمّعة	المصادر التي ترسل باسم نطاقك وهل ينجح SPF وDKIM ويتوافقان	اسحب تقارير آخر 7 إلى 14 يومًا وقارنها بالفترة السابقة
بيانات postmaster لدى مزوّد البريد	مؤشرات سمعة النطاق وعنوان IP، ومعدل الرسائل غير المرغوبة، ونتائج المصادقة حيث ينشرها المزوّد	التقط لقطات شاشة أو صدّر اللوحات الخاصة بالنطاقات المتأثرة
فحوصات قوائم الحظر وDNS	هل عناوين IP أو النطاقات المرسِلة مدرجة، وهل السجلات صحيحة اليوم	استعلم عن قوائم الحظر الرئيسية التي تعتمد عليها، وحلّ سجلات SPF وDKIM وDMARC وDNS العكسي والتتبع الخاصة بك
سجل التغييرات	ما نُشر أو عُدّل أو بُدّل في وقت البدء أو قربه	اسأل الفريق كله: إصدارات الشيفرة، وتعديلات DNS، والأدوات الجديدة، وعمليات استيراد القوائم، وتغييرات القوالب

يمكن تنفيذ فحوصات DNS السريعة من أي طرفية. والأوامر أدناه تستخدم نطاقًا ومحدّد DKIM مختلقين لإظهار النمط، فاستبدلها بقيمك.

# Is the SPF record still published and valid?
dig +short TXT example.com

# Is the DKIM key for the selector still published?
dig +short TXT selector1._domainkey.example.com

# What DMARC policy is published?
dig +short TXT _dmarc.example.com

# Does the sending IP have the expected reverse DNS name?
dig +short -x 192.0.2.25

ولقراءة الترويسات، اتبع دليلنا عن قراءة ترويسات البريد الإلكتروني لتشخيص التسليم والمصادقة. وبالنسبة إلى لوحات السمعة، تشرح المقالة عن Google Postmaster Tools معنى المؤشرات وكيفية إعدادها قبل أن تحتاج إليها.

خطوات الاحتواء والتعافي

الاحتواء يوقف الضرر، والتعافي يعيد الحجم بأمان. وهما مرحلتان منفصلتان، وخلطهما هو ما يجعل الفرق تُشعل الحريق من جديد. لا تستأنف التدفقات الموقوفة لمجرد أن المقاييس تبدو أفضل لمدة ساعة.

إجراءات الاحتواء بحسب السبب

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

خطة تعافٍ على مراحل

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

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

قوالب التواصل

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

تحديث لأصحاب المصلحة الداخليين

Subject: Email delivery incident - update 1 (14:30 UTC)

Status: Investigating, contained.
Impact: Promotional emails to one large mailbox provider are being
delayed or filtered. Order confirmations and password resets are
being delivered normally in our tests.
Actions taken: Promotional sends paused at 14:10 UTC. Evidence
collection in progress. No changes made to DNS yet.
Next steps: Review provider responses and authentication reports.
Needed from you: Please do not schedule new campaigns until we confirm.
Next update: 15:30 UTC or sooner if anything changes.
Incident lead: [name]

رسالة لفريق الدعم والفرق المتعاملة مع العملاء

Subject: For support: delayed or missing marketing emails

What customers may report: Some people have not received recent
newsletters or promotions.
What we know: We are investigating a delivery problem affecting one
mailbox provider. Account and transactional emails are working.
What to say: We are aware that some emails are delayed and are working
on it. Please ask the customer to check their spam folder and to add
our sending address to their contacts.
What not to say: Do not name a cause or promise a time until the
incident lead confirms.
Escalate to the incident lead if: a customer reports missing password
reset or payment emails.
Next update: 16:00 UTC.

مثال تطبيقي بأرقام مختلقة

يرسل فريق عادةً نحو 200,000 رسالة ترويجية و15,000 رسالة معاملاتية يوميًا. ويبلغ معدل الارتداد الطبيعي لديه نحو 0.6 في المئة، ومعدل الشكاوى الطبيعي نحو 0.05 في المئة. في يوم ثلاثاء عند 09:00 بتوقيت UTC تنطلق حملة إلى 80,000 جهة اتصال. وبحلول 09:40 تُظهر اللوحة 2,400 ارتداد دائم من تلك الحملة، أي 3 في المئة، ويؤجل مزوّد كبير معظم الرسائل المتبقية.

عند 09:45 يفتح المحقق المناوب الدليل. وبحلول 09:55 يكون التدفق الترويجي موقوفًا ويتأكد تسليم إيصالات الاختبار. ويشير جدول القرار إلى ارتفاع في الارتدادات مع أخطاء مستخدم غير معروف، متركز في حملة واحدة. ويُظهر فحص سجل القائمة أن 30,000 من أصل 80,000 عنوان استُوردت من جدول بيانات قديم لحدث ما قبل يومين ولم يُتحقق منها قط. ويأتي نحو 2,000 من أصل 2,400 ارتداد من تلك العملية.

الاحتواء بسيط: حجب العناوين المرتدة، وإزالة الاستيراد غير المتحقق منه من جميع الشرائح، وتمريره عبر التحقق قبل أي استخدام آخر. يستأنف الفريق التدفق في صباح اليوم التالي بنسبة 10 في المئة من الحجم المعتاد إلى أكثر جهات الاتصال تفاعلًا، ثم يرفعه إلى 25 و50 و100 في المئة خلال الأيام التالية ما دام معدل الارتداد دون 1 في المئة، ويؤكد التعافي بعد ثلاثة أيام نظيفة بالحجم الكامل. وتضيف المراجعة ضابطًا: يجب أن يجتاز أي استيراد جديد التحقق وأن يُستبعد من الحملات إلى أن يوافق عليه شخص معيّن. وكانت كلفة الحادث يومًا واحدًا من الإيقاف وبضع حملات متأخرة، بدلًا من إصلاح طويل للسمعة.

الضوابط وحدود التنبيه القابلة للضبط

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

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

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

أدوار المناوبة

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

الدور	المسؤولية	ما لا يقوم به
قائد الحادث	يعلن الحادث ويغلقه، ويتخذ القرارات، ويحدد مواعيد التحديث	إجراء كل التحقيقات بنفسه
المحقق التقني	يقرأ السجلات والترويسات وDNS، ويختبر الحلول، ويقترح الاحتواء	تغيير إعدادات الإنتاج دون إبلاغ القائد
مسؤول الإرسال أو الحملة	يعرف ما أُرسل ولمن ولماذا؛ ويوقف التدفقات ويستأنفها	استئناف الحركة دون موافقة القائد
مسؤول التواصل	يرسل تحديثات أصحاب المصلحة والدعم، ويحتفظ بالخط الزمني	التكهن بالأسباب

مراجعة ما بعد الحادث

أجرِ المراجعة خلال أيام قليلة، بينما الذكريات والسجلات طازجة. اجعلها بلا لوم: الهدف هو معرفة ما في النظام الذي سمح بمرور المشكلة، لا من ضغط على الزر. ويكفي سجل من صفحة واحدة لمعظم الحوادث.

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

قائمة التحقق للحادث

1. أُعلن الحادث، وعُيّن القائد، وسُجّل وقت البدء بتوقيت UTC.
2. تم التحقق من الرسائل المعاملاتية برسائل اختبار وإبقاؤها في تدفقها المستقل.
3. أُوقف الإرسال الجماعي والترويجي غير الحرج أو خُفّف معدله.
4. صُنّف العَرَض بجدول القرار: ارتداد أو تأجيل أو شكوى أو انخفاض في التفاعل؛ ومزوّد واحد أو الجميع.
5. حُفظت الأدلة: سجلات الأحداث، والردود الخام، والترويسات، وتقارير DMARC، وبيانات postmaster، وفحوصات قوائم الحظر وDNS.
6. جُمع سجل التغييرات من الفريق كله.
7. عولج السبب وتم التحقق منه برسالة اختبار قبل أي استئناف.
8. جرى التعافي على مراحل بدءًا من جهات الاتصال المتفاعلة بحجم مخفّض، مع معايير نجاح متفق عليها.
9. أُرسلت تحديثات أصحاب المصلحة والدعم في مواعيدها.
10. أُجريت المراجعة، وعُيّنت الإجراءات، وحُدّثت الضوابط والتنبيهات.

توفر MigoSMTP الإرسال والسجلات والأحداث التي تساعد في عدد من هذه الخطوات. راجع حساب MigoSMTP أو وثائق API لمعرفة تفاصيل التقارير وwebhooks وعناصر التحكم المتاحة لك بدقة.

مراجع وقراءات إضافية

• RFC 5321: Simple Mail Transfer Protocol (رموز الرد وسلوك إعادة المحاولة)
• RFC 3463: Enhanced Mail System Status Codes
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 6591: Authentication Failure Reporting Using the Abuse Reporting Format
• Google: إرشادات المرسلين للبريد الإلكتروني