ईमेल डिलीवरेबिलिटी इंसिडेंट रनबुक: अचानक गिरावट पर कैसे प्रतिक्रिया दें

एक ईमेल डिलीवरेबिलिटी इंसिडेंट रनबुक वह लिखित योजना है जिसका पालन आपकी टीम तब करती है जब डिलीवरी अचानक गिर जाए: बाउंस बढ़ जाएँ, मेल क्यू में अटका रहे, शिकायतें बढ़ें या ग्राहक कहें कि संदेश पहुँच ही नहीं रहे। चरणों का पहले से तय होना इसलिए मायने रखता है कि पहले घंटे में ही ज़्यादातर नुकसान या तो सीमित हो जाता है या और बिगड़ जाता है। यह गाइड हमें एक व्यावहारिक रनबुक देती है: 30 मिनट का ट्रायाज, एक निर्णय तालिका, जुटाए जाने वाले साक्ष्य, रिकवरी के चरण, संदेश टेम्पलेट, रिव्यू का प्रारूप और गार्डरेल।

डिलीवरेबिलिटी इंसिडेंट किसे माना जाए

हर गिरावट इंसिडेंट नहीं होती। सामान्य ट्रैफ़िक कैलेंडर, ऑडियंस और कंटेंट के साथ ऊपर-नीचे होता रहता है। हम तब इसे इंसिडेंट कहते हैं जब कोई प्रमुख माप तेज़ी से अपनी सामान्य रेंज से बाहर चला जाए और कारण स्पष्ट न हो: बाउंस दर, डिफ़रल की मात्रा, शिकायत दर, महत्वपूर्ण संदेशों का डिलीवरी समय, या किसी बड़े मेलबॉक्स प्रोवाइडर पर इनबॉक्स प्लेसमेंट। रनबुक जल्दी खोलने की लागत बहुत कम है। इंतज़ार करने की कीमत रेप्युटेशन से चुकानी पड़ती है।

अपने सीवियरिटी स्तर पहले से लिख लें। तीन स्तरों की एक सरल योजना अच्छी चलती है: निगरानी का निम्न स्तर, जिसे एक व्यक्ति देखता है; मानक इंसिडेंट, जिसमें नामित लीड हो और हर घंटे अपडेट मिले; और क्रिटिकल इंसिडेंट, जिसमें पासवर्ड रीसेट या भुगतान रसीद जैसा ट्रांज़ैक्शनल मेल प्रभावित हो या कोई क्रेडेंशियल समझौता हुआ हो सकता हो। नीचे दी गई परिभाषाएँ अपनाने के लिए उदाहरण हैं, कोई मानक नहीं।

स्तर	उदाहरण ट्रिगर (अपने ट्रैफ़िक के अनुसार ट्यून करें)	प्रतिक्रिया
निगरानी	किसी एक भेजने पर एक मेट्रिक अपनी सामान्य रेंज से बाहर जाए	ओनर एक घंटे के भीतर जाँचे और निष्कर्ष दर्ज करे
इंसिडेंट	कोई मेट्रिक अपने बेसलाइन से दोगुनी हो जाए, या कोई प्रमुख प्रोवाइडर मेल के बड़े हिस्से को डिफ़र या रिजेक्ट करे	रनबुक खोलें, लीड नामित करें, गैर-ज़रूरी बल्क रोकें, हितधारकों को हर घंटे अपडेट दें
क्रिटिकल	ट्रांज़ैक्शनल मेल में देरी या रिजेक्शन, क्रेडेंशियल के समझौते का संदेह, या किसी मुख्य भेजने वाले IP या डोमेन की ब्लॉकलिस्ट में एंट्री	पूरा रनबुक, चारों भूमिकाओं में स्टाफ़, नियंत्रण होने तक हर 30 मिनट में अपडेट

पहले 30 मिनट: ट्रायाज और नियंत्रण

पहले आधे घंटे का लक्ष्य मूल कारण खोजना नहीं है। लक्ष्य है नुकसान को बढ़ने से रोकना और समस्या का इतना वर्गीकरण करना कि पता चले कहाँ देखना है। इन चरणों को क्रम से पूरा करें और हर चरण का समय दर्ज करें।

1. मिनट 0 से 5: घोषणा करें। एक साझा चैनल खोलें, इंसिडेंट लीड नामित करें, और वह समय लिखें जब समस्या पहली बार दिखी तथा वह समय जब वह संभवतः शुरू हुई। हर टाइमस्टैम्प के लिए UTC का उपयोग करें, ताकि अलग-अलग जगहों के लॉग, रिपोर्ट और लोग एक-दूसरे से मेल खाएँ।
2. मिनट 5 से 10: ट्रांज़ैक्शनल मेल की सुरक्षा करें। प्रमुख प्रोवाइडर पर अपने नियंत्रण वाले मेलबॉक्स में कुछ टेस्ट संदेश भेजकर पुष्टि करें कि पासवर्ड रीसेट, वन-टाइम कोड और रसीदें अब भी डिलीवर हो रही हैं। अगर वे विफल हो रही हैं, तो इंसिडेंट को क्रिटिकल मानें।
3. मिनट 10 से 15: बाकी को रोकें या थ्रॉटल करें। प्रमोशनल कैंपेन, न्यूज़लेटर और टाले जा सकने वाले शेड्यूल्ड ऑटोमेशन रोकें। जिन स्ट्रीम को पूरी तरह रोका नहीं जा सकता, उनकी भेजने की दर घटाएँ। क्यू में लगे मेल अभी न हटाएँ, क्योंकि वे साक्ष्य हैं।
4. मिनट 15 से 25: वर्गीकरण करें। पिछले हफ़्ते की तुलना में पिछले एक दिन के बाउंस, डिफ़रल और शिकायत की गिनती मेलबॉक्स प्रोवाइडर के अनुसार पढ़ें। नीचे दी गई निर्णय तालिका से कारणों का सबसे संभावित परिवार चुनें।
5. मिनट 25 से 30: काम बाँटें और पहला अपडेट भेजें। हर जाँचकर्ता को एक विशिष्ट प्रश्न दें, और अब तक के ज्ञात तथ्यों तथा अगले अपडेट के समय के साथ एक छोटा आंतरिक अपडेट भेजें।

ट्रांज़ैक्शनल मेल को उसकी अपनी स्ट्रीम, डोमेन और IP पूल पर रखने से यह ट्रायाज बहुत आसान हो जाता है, क्योंकि आप रसीदों को छुए बिना प्रमोशन रोक सकते हैं। अगर आपने अभी तक ऐसा नहीं किया है, तो ट्रांज़ैक्शनल और मार्केटिंग ईमेल स्ट्रीम को अलग करना देखें और इंसिडेंट खत्म होने के बाद इसे एक प्रोजेक्ट बनाएँ।

लक्षण से कारण तक की निर्णय तालिका

जो आप देख रहे हैं उसे पहली जाँच में बदलने के लिए इस तालिका का उपयोग करें। इसमें संभावित कारण हैं, निश्चित नहीं, और कई एक साथ हो सकते हैं। पहला कॉलम बताता है कि आपके डैशबोर्ड क्या दिखा रहे हैं। दूसरा बताता है कि कौन-सा प्रश्न पूछना है। तीसरा उस जाँच की ओर इशारा करता है जो इसकी पुष्टि करती है या इसे खारिज करती है।

लक्षण	दायरा	संभावित कारण	पहली जाँचें
बाउंस स्पाइक (5xx रिजेक्शन)	सभी प्रोवाइडर, एक निश्चित समय से शुरू	टूटा हुआ ऑथेंटिकेशन, एक्सपायर हुआ या हटाया गया DNS रिकॉर्ड, गलत क्रेडेंशियल, असत्यापित डोमेन से भेजना	SPF, DKIM और DMARC के DNS रिकॉर्ड; हाल के DNS या प्रोवाइडर बदलाव; बाउंस जवाबों में एरर टेक्स्ट
बाउंस स्पाइक (5xx रिजेक्शन)	एक प्रोवाइडर	उस प्रोवाइडर पर पॉलिसी ब्लॉक या रेप्युटेशन लिस्टिंग, मात्रा या कंटेंट में अचानक बदलाव	उस प्रोवाइडर का बाउंस टेक्स्ट, उसका postmaster डेटा, उस प्रोवाइडर को हाल का भेजने का इतिहास
अज्ञात उपयोगकर्ता एरर के साथ बाउंस स्पाइक	ज़्यादातर एक कैंपेन या इम्पोर्ट	लिस्ट में जोड़े गए पुराने, खरीदे हुए या गलत टाइप किए गए पते	लिस्ट का स्रोत, पतों की उम्र, वैलिडेशन के नतीजे
डिफ़रल स्पाइक (4xx)	एक या दो प्रोवाइडर	रेट लिमिटिंग, रेप्युटेशन को लेकर शुरुआती चिंता, बहुत अधिक कनेक्शन	डिफ़रल टेक्स्ट, मौजूदा भेजने की दर और कन्करेंसी, क्यू की उम्र
डिफ़रल स्पाइक (4xx)	सभी प्रोवाइडर	आपकी ओर नेटवर्क या DNS की समस्या, TLS विफलताएँ, भेजने वाले सर्वरों पर संसाधन सीमाएँ	लॉग में टाइमआउट और TLS एरर, भेजने वाले होस्ट से DNS रेज़ोल्यूशन
शिकायत स्पाइक	एक कैंपेन या सेगमेंट	अप्रत्याशित ऑडियंस, अस्पष्ट साइन-अप स्रोत, मुश्किल से मिलने वाला अनसब्सक्राइब लिंक	सेगमेंट की परिभाषा, साइन-अप स्रोत, अनसब्सक्राइब लिंक की दृश्यता, फ़ीडबैक लूप डेटा
ओपन और क्लिक गिरे, बाउंस स्थिर	एक प्रोवाइडर	बिना किसी रिजेक्शन के मेल का स्पैम फ़ोल्डर में जाना	Postmaster डेटा, सीड या पैनल टेस्ट इनबॉक्स के नतीजे, कंटेंट या मात्रा में हाल के बदलाव
ओपन और क्लिक गिरे, बाउंस स्थिर	सभी प्रोवाइडर	ट्रैकिंग डोमेन की समस्या, इमेज ब्लॉकिंग, टूटे लिंक, या माप में बदलाव	ट्रैकिंग डोमेन का सर्टिफ़िकेट और DNS, लिंक टेस्ट, हाल में टेम्पलेट का कोई बदलाव
DMARC रिपोर्ट में आपके डोमेन से अपरिचित स्रोतों का मेल पास होना	एग्रीगेट रिपोर्ट में दिखता है	स्पूफ़िंग, या कोई भूला हुआ थर्ड-पार्टी टूल जो आपके नाम से भेज रहा है	DMARC एग्रीगेट रिपोर्ट के स्रोत, अनुमोदित सेंडर की सूची, आपके भेजने वाले क्रेडेंशियल के एक्सेस लॉग

दो पैटर्न पर विशेष ध्यान दें। अगर आपने जो शेड्यूल नहीं किया था उस मात्रा में अचानक वृद्धि हो और साथ में शिकायत स्पाइक हो, तो इसका मतलब किसी समझौता किए गए अकाउंट या लीक हुई की का आपके नाम से भेजना हो सकता है। यह पहले एक सुरक्षा घटना है और उसके बाद डिलीवरेबिलिटी घटना। दूसरा, किसी एक प्रोवाइडर की समस्या अक्सर उसी प्रोवाइडर पर रेप्युटेशन का मामला होती है, जबकि सभी प्रोवाइडर की ऐसी समस्या जो ठीक किसी मिनट से शुरू हुई हो, आमतौर पर किसी ऐसी चीज़ की ओर इशारा करती है जिसे आपने बदला या जो एक्सपायर हो गई। हर परिवार पर गहराई से पढ़ने के लिए, हमारी SMTP बाउंस कोड की गाइड 4xx और 5xx जवाब पढ़ना सिखाती है, और स्पैम फ़ोल्डर ट्रबलशूटिंग चेकलिस्ट प्लेसमेंट की समस्याओं को चरण-दर-चरण समझाती है।

कुछ भी बदलने से पहले जुटाए जाने वाले साक्ष्य

साक्ष्य जल्दी गायब हो जाते हैं। लॉग रोटेट हो जाते हैं, क्यू खाली हो जाती हैं और रिपोर्ट ओवरराइट हो जाती हैं। पहले जुटाएँ, फिर ठीक करें। सब कुछ एक साझा फ़ोल्डर में सहेजें जिसके नाम में इंसिडेंट का शुरुआती समय हो, और हर एक्सपोर्ट का टाइम ज़ोन दर्ज करें।

साक्ष्य	यह हमें क्या बताता है	इसे कैसे सहेजें
पिछले 7 दिनों के इवेंट लॉग	प्रोवाइडर, स्ट्रीम और कैंपेन के अनुसार स्वीकार, डिफ़र, बाउंस और शिकायत की गिनती	अपने MigoSMTP डैशबोर्ड, API या वेबहुक से एक्सपोर्ट करें; सटीक विकल्पों के लिए अपना MigoSMTP अकाउंट या API दस्तावेज़ देखें
रॉ बाउंस और डिफ़रल जवाब	प्रोवाइडर समस्या को समझाने के लिए जो सटीक शब्द उपयोग करते हैं	हर प्रोवाइडर के लिए हर अलग संदेश का एन्हांस्ड स्टेटस कोड सहित नमूना कॉपी करें
डिलीवर हुए और स्पैम फ़ोल्डर में गए टेस्ट संदेशों के पूरे हेडर	ऑथेंटिकेशन नतीजे, रूटिंग और कोई भी फ़िल्टर निर्णय	अपने नियंत्रण वाले मेलबॉक्स में टेस्ट भेजें और हर एक का मूल सोर्स सहेजें
DMARC एग्रीगेट रिपोर्ट	कौन-से स्रोत आपके डोमेन के नाम से भेजते हैं और SPF तथा DKIM पास और अलाइन होते हैं या नहीं	पिछले 7 से 14 दिनों की रिपोर्ट निकालें और पिछली अवधि से तुलना करें
मेलबॉक्स प्रोवाइडर का postmaster डेटा	डोमेन और IP रेप्युटेशन संकेत, स्पैम दर और ऑथेंटिकेशन नतीजे, जहाँ प्रोवाइडर प्रकाशित करता है	प्रभावित डोमेन के डैशबोर्ड का स्क्रीनशॉट लें या एक्सपोर्ट करें
ब्लॉकलिस्ट और DNS जाँच	भेजने वाले IP या डोमेन लिस्टेड हैं या नहीं, और रिकॉर्ड आज सही हैं या नहीं	जिन मुख्य ब्लॉकलिस्ट पर आप भरोसा करते हैं उन्हें क्वेरी करें और अपने SPF, DKIM, DMARC, रिवर्स DNS और ट्रैकिंग रिकॉर्ड रेज़ॉल्व करें
बदलाव का इतिहास	शुरुआती समय के आसपास क्या डिप्लॉय, एडिट या बदला गया	पूरी टीम से पूछें: कोड रिलीज़, DNS एडिट, नए टूल, लिस्ट इम्पोर्ट, टेम्पलेट बदलाव

त्वरित DNS जाँच किसी भी टर्मिनल से की जा सकती है। नीचे की कमांड पैटर्न दिखाने के लिए एक काल्पनिक डोमेन और सिलेक्टर का उपयोग करती हैं; इन्हें अपने मानों से बदलें।

# 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 तक प्रमोशनल स्ट्रीम रोक दी जाती है और टेस्ट रसीदों के डिलीवर होने की पुष्टि हो जाती है। निर्णय तालिका एक कैंपेन में केंद्रित, अज्ञात उपयोगकर्ता एरर वाले बाउंस स्पाइक की ओर इशारा करती है। लिस्ट का इतिहास जाँचने पर पता चलता है कि 80,000 में से 30,000 पते दो दिन पहले एक पुरानी इवेंट स्प्रेडशीट से इम्पोर्ट किए गए थे और कभी वैलिडेट नहीं हुए थे। 2,400 में से लगभग 2,000 बाउंस इसी इम्पोर्ट से आते हैं।

नियंत्रण सरल है: बाउंस हुए पते सप्रेस करें, अवैलिडेटेड इम्पोर्ट को सभी सेगमेंट से हटाएँ और आगे किसी भी उपयोग से पहले उसे वैलिडेशन से गुज़ारें। टीम अगली सुबह अपने सबसे ज़्यादा जुड़े संपर्कों के लिए सामान्य मात्रा के 10 प्रतिशत पर स्ट्रीम फिर शुरू करती है, और अगले दिनों में बाउंस दर 1 प्रतिशत से नीचे रहने तक इसे 25, 50 और 100 प्रतिशत तक बढ़ाती है, और पूरी मात्रा पर तीन साफ़ दिनों के बाद रिकवरी की पुष्टि करती है। रिव्यू एक गार्डरेल जोड़ता है: कोई भी नया इम्पोर्ट वैलिडेशन पास करे और जब तक कोई नामित व्यक्ति मंज़ूरी न दे, कैंपेन से बाहर रखा जाए। इंसिडेंट की कीमत एक रोका हुआ दिन और कुछ देरी से गए कैंपेन रही, लंबी रेप्युटेशन मरम्मत की जगह।

ट्यून करने के लिए गार्डरेल और अलर्ट थ्रेशोल्ड

ज़्यादातर इंसिडेंट ग्राहकों द्वारा पकड़े जाते हैं क्योंकि कोई सही संख्या पर नज़र नहीं रख रहा था। गार्डरेल पहचान को पहले ले आते हैं। नीचे दिए मान उदाहरण हैं, जो समझदार अलर्ट का स्वरूप दिखाने के लिए चुने गए हैं। ये सार्वभौमिक मानक नहीं हैं, और सही संख्याएँ आपकी ऑडियंस, आपके प्रोवाइडर और आपके इतिहास पर निर्भर करती हैं। कई हफ़्तों तक अपना बेसलाइन मापें, फिर उसके सापेक्ष थ्रेशोल्ड तय करें। जिन मेलबॉक्स प्रोवाइडर की आपको परवाह है उनके वर्तमान सेंडर दिशानिर्देशों में प्रकाशित सीमाएँ देखें, और क्या ट्रैक करना है यह तय करने के लिए मापी जाने वाली मेट्रिक पर हमारी गाइड पढ़ें।

संकेत	उदाहरण अलर्ट (अपने बेसलाइन के अनुसार ट्यून करें)	सुझाई गई स्वचालित कार्रवाई
प्रति कैंपेन हार्ड बाउंस दर	अपने बेसलाइन के 2 गुना से ऊपर चेतावनी, 4 गुना से ऊपर रोकें, या जब आपकी अपनी निरपेक्ष सीमा पार हो	कैंपेन रोकें और ओनर को अलर्ट करें
प्रति प्रोवाइडर शिकायत दर	प्रोवाइडर द्वारा प्रकाशित सीमा के आधे पर चेतावनी, तीन चौथाई पर पेज करें	सेगमेंट रोकें और साइन-अप स्रोत की समीक्षा करें
प्रति प्रोवाइडर डिफ़रल हिस्सा	जब डिफ़रल उस हिस्से से अधिक हों जो आप सामान्यतः कभी नहीं देखते, जैसे 15 मिनट के लिए 10 प्रतिशत, तब चेतावनी	उस प्रोवाइडर को भेजने की दर घटाएँ
ट्रांज़ैक्शनल मेल की क्यू आयु	जब सबसे पुराना संदेश कुछ मिनट से ज़्यादा प्रतीक्षा करे तब चेतावनी	ऑन-कॉल जाँचकर्ता को पेज करें
भेजने की मात्रा	जब प्रति घंटा मात्रा उस घंटे की सामान्य मात्रा के किसी गुणज से अधिक हो तब चेतावनी	समझौता किए गए क्रेडेंशियल या बेकाबू जॉब की जाँच करें
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 दस्तावेज़ देखें।

आगे पढ़ें और स्रोत

• 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: Email sender guidelines