प्रोडक्ट टीम की नज़र से “Sent but Not Received” डिबग कैसे करें (End-to-End गाइड)

“ईमेल भेज दिया गया” और “यूज़र को ईमेल मिला नहीं”—यह गैप प्रोडक्ट टीम के लिए सबसे महँगा बग बन जाता है। सपोर्ट टिकट बढ़ते हैं, OTP/वेरिफिकेशन फेल होते हैं, और सबसे बुरा: यूज़र आपके सिस्टम पर भरोसा खो देता है। पर इस केस में एक महत्वपूर्ण बात समझनी होती है: “Sent” आमतौर पर सिर्फ यह बताता है कि आपकी ऐप/सर्वर ने ईमेल को आउटबाउंड सिस्टम (SMTP/ESP) तक सौंप दिया—यह डिलिवरी की गारंटी नहीं है। यह लेख प्रोडक्ट टीम को एक व्यावहारिक, end-to-end डिबग प्लेबुक देता है: किस लेयर पर कौन सा सिग्नल देखना है, किस तरह triage करना है, और स्थायी रूप से दोबारा न हो इसके लिए क्या सेटअप चाहिए।

1) पहले भाषा साफ करें: “Sent” कहाँ तक का स्टेटस है?

अलग-अलग सिस्टम में “Sent” का मतलब अलग होता है। कई उत्पादों में “Sent” का अर्थ सिर्फ queue accepted या provider accepted होता है। डिबग शुरू करने से पहले अपनी टीम के अंदर स्टेटस की डिक्शनरी तय करें:

Queued: आपका सिस्टम ने संदेश बनाया और queue में रखा।
Submitted / Accepted: आपका सिस्टम/ESP ने SMTP पर संदेश स्वीकार किया।
Delivered: रिसीविंग सर्वर (ISP) ने संदेश स्वीकार किया (यह भी inbox placement नहीं है)।
In Inbox / Seen: यह क्लाइंट-साइड है, सर्वर-साइड से हमेशा साबित नहीं होता।
Bounced / Rejected: रिसीविंग सर्वर ने हार्ड/सॉफ्ट कारण से अस्वीकार किया।
Deferred: रिसीविंग सर्वर ने बाद में retry करने को कहा।
Suppressed: आपके ESP/सिस्टम ने जानबूझकर इस रिसीपिएंट को रोक दिया (past bounce/complaint आदि)।

प्रोडक्ट टीम की गलती अक्सर यह होती है कि UI/लॉग में “Sent” दिखते ही वे मान लेते हैं कि “Deliver हो गया”। आपका लक्ष्य है: Sent → Delivered → Inbox placement इस पूरे पाइप में सबसे पहले कहाँ टूट रहा है, वह पहचानना।

2) Incident triage: 5 सवाल जो 5 मिनट में दिशा दे देंगे

सपोर्ट या QA से जब रिपोर्ट आती है, तो तुरंत इन सवालों से scope तय करें:

कौन सा email type? OTP/verify, password reset, invoice, newsletter, transactional?
कौन सा domain/ISP? Gmail, Outlook/Hotmail, Yahoo, corporate domain, custom domain?
क्या यह हर यूज़र के साथ है या कुछ के साथ? 1% बनाम 80% बहुत अलग समस्या है।
क्या timeframe? अभी-अभी शुरू हुआ या हमेशा से intermittent?
क्या आपके सिस्टम में event chain complete है? queue → provider accepted → delivered/bounce?

अगर समस्या सिर्फ एक ISP (जैसे Gmail) पर है, तो deliverability/auth या reputation suspect है। अगर सिर्फ OTP मेल miss हो रहे हैं, तो template/latency/queue priority और rate-limits suspect हैं। अगर एक खास ग्राहक के डोमेन पर है, तो corporate filtering या DNS/policy suspect है।

3) End-to-End observability: एक “Message ID” से सब कुछ trace करो

“Sent but Not Received” को reliably debug करने के लिए आपको हर ईमेल पर एक globally traceable ID चाहिए। प्रोडक्ट टीम के लिए best practice यह है कि:

ऐप/बैकएंड एक internal_message_id बनाए (UUID)।
यह ID provider request में जाए और email headers में भी शामिल हो (जैसे X-Message-Id)।
UI/CS टूल में यह ID दिखे ताकि सपोर्ट “एक क्लिक” में trace निकाल सके।

सही event model कैसा दिखे?

न्यूनतम स्तर पर आपके पास ये इवेंट होने चाहिए:

message_created (template + recipient + type)
queued (queue name, priority)
provider_accepted (provider message id, response code)
delivered या bounced या deferred
complaint / unsubscribe (marketing flows में)
suppressed (यदि भेजने से पहले रोक दिया गया)

अगर आपके पास “provider_accepted” के बाद कोई data नहीं है, तो आप blind हैं। उस स्थिति में आपका पहला fix होगा: webhook/events ingestion को सही करना।

4) सबसे आम कारण: बाउंस, डिफरल, और सप्रेशन

4.1 Hard bounce (स्थायी अस्वीकार)

Hard bounce अक्सर गलत एड्रेस, non-existent mailbox, या policy rejection से होता है। अगर hard bounce आया, तो आपका ESP उस recipient को suppression list में डाल सकता है। फिर बाद में चाहे यूज़र ठीक email दे, पर वही address suppressed रह सकता है।

अपने ESP में recipient को search करें: suppressed तो नहीं?
बाउंस reason code निकालें और top reasons का histogram बनाएं।
UI/सपोर्ट में “यह एड्रेस बाउंस हुआ था” का संकेत दें।

4.2 Soft bounce / deferral (रीट्राय मोड)

Soft bounce या deferral का मतलब है रिसीविंग server ने कहा: “अभी नहीं, बाद में कोशिश करो”। कारण हो सकता है: throttling, temporary greylisting, या content scanning delay। OTP जैसे flows में यह खास दर्द देता है क्योंकि यूज़र को सेकंड्स में चाहिए।

OTP traffic के लिए अलग IP/सबडोमेन या कम से कम अलग stream रखें।
queue priority दें ताकि OTP, newsletter के पीछे न फंसे।
डिफरल rate बढ़े तो ISP-wise alerting सेट करें।

4.3 Suppression (आपका सिस्टम ही भेज नहीं रहा)

कई बार आपका सिस्टम “Sent” दिखाता है क्योंकि product layer ने action complete माना, लेकिन underlying layer ने suppression के कारण request ही नहीं भेजी। यह बहुत common है जब past में complaint या bounce हुआ हो।

UI/लॉग में suppression को “Sent” से अलग दिखाएं।
CS के लिए एक “unsuppress request” प्रक्रिया रखें (guardrails के साथ)।
सप्रेशन के कारणों को स्पष्ट categorise करें: bounce, complaint, manual block, policy block।

5) Authentication की लेयर: SPF, DKIM, DMARC (और alignment)

ईमेल deliverability की असली नींव authentication है। अगर SPF/DKIM fail हो रहा है या DMARC policy strict है, तो ईमेल reject/spam में जा सकता है। प्रोडक्ट टीम को यह समझना जरूरी है क्योंकि अक्सर “Sent” से आगे failure इसी लेयर पर आता है।

5.1 SPF

SPF बताता है कि कौन से servers आपके domain की ओर से भेज सकते हैं। अगर आपका sending provider/IP SPF में शामिल नहीं, तो fail की संभावना बढ़ती है। खासकर corporate domains SPF fail पर कड़े होते हैं।

5.2 DKIM

DKIM cryptographic signature है जो message integrity और domain ownership साबित करता है। DKIM miss/invalid होने पर inbox placement गिरती है और reject भी हो सकता है।

5.3 DMARC और alignment

DMARC policy तय करती है कि SPF/DKIM fail होने पर क्या करना है। “Alignment” का अर्थ है: From: domain और SPF/DKIM domains मेल खाते हैं या नहीं। कई टीमों में कॉन्फ़िग गलती यही होती है कि DKIM किसी subdomain से sign हो रहा है, जबकि From किसी और domain से है।

Practical rule: Transactional email के लिए हमेशा consistent From domain, DKIM signing और SPF alignment रखें। Random From बदलाव reputation और filtering दोनों बिगाड़ते हैं।

6) Content & Template pitfalls: भेजा गया लेकिन फिल्टर हो गया

बहुत बार deliver हो जाता है, पर inbox में नहीं आता—spam/promotions में चला जाता है या quarantine हो जाता है। Content-level issues खासकर नए domain/IP के साथ तेजी से असर दिखाते हैं।

6.1 Subject/Body patterns

Excessive caps, बहुत सारे symbols, over-promotional भाषा
URL shorteners या suspicious links
Image-only content (text कम)
अजीब HTML, broken tags, hidden text
Misleading From name या reply-to mismatch

6.2 OTP मेल की खास गलतियाँ

OTP को image में डाल देना (कॉपी/ऑटोफिल टूटता है)
बहुत heavy HTML जिससे mobile clients में टूटे
लिंक-आधारित verification में deep link गलत या expired
OTP TTL बहुत कम, जबकि deliverability delay हो रही

6.3 Localization और encoding

हिन्दी कंटेंट में encoding/charset issues भी आ सकते हैं। गलत charset से कुछ clients मेल को suspicious मान सकते हैं या content render fail हो सकता है। Minimum: UTF-8 consistently रखें, और template rendering pipeline में headers सही सेट हों।

7) Flow-level bugs: ईमेल पहुँचा, पर यूज़र ने देखा नहीं

कभी-कभी ईमेल deliver हो जाता है, लेकिन product experience यूज़र को “नहीं मिला” महसूस कराता है। प्रोडक्ट टीम को end-user reality देखनी चाहिए:

7.1 गलत address capture

यूज़र ने typo किया, और आपने validation नहीं किया।
auto-trim/auto-lowercase/encoding की वजह से address बदल गया।
plus addressing (user+tag@domain) को गलत तरीके से reject कर दिया।

7.2 Resend logic गलत

“Resend OTP” पर नया OTP generate हुआ, लेकिन पुराना OTP message deliver हो रहा है।
यूज़र नया OTP डालता है, पर server पुराने को expected मान रहा है (state desync)।
Resend rate-limit इतना tight है कि user को लगता है भेजा नहीं गया।

7.3 Timing और timezones

कई dashboards “sent time” दिखाते हैं जो server timezone में है। सपोर्ट को लगता है मेल अभी भेजा, पर वास्तव में पहले भेजा था। UI में timezone स्पष्ट करें और relative timestamps (“2 minutes ago”) दें।

8) Provider/ESP layer: quota, rate limits, और policy blocks

बड़े पैमाने पर भेजते समय ESP की rate limits, daily quotas, या policy enforcement भी “Sent but not received” का कारण बन सकती है। खासकर अगर अचानक spikes आएँ (launch day, marketing blast, या bot-driven signups)।

Spike detection: signups/OTP requests में abnormal jump?
Rate limiting: क्या provider throttling दे रहा है?
Shared IP reputation: shared pools में दूसरे senders का असर पड़ सकता है।
Dedicated stream: critical transactional/OTP को अलग stream/IP पर रखें।

प्रोडक्ट टीम के लिए actionable कदम: OTP और transactional को marketing से अलग करो—यह सिर्फ deliverability नहीं, user experience और trust का भी सवाल है।

9) Reproduction playbook: “एक केस” को कैसे पकड़ें

डिबग का सबसे तेज़ तरीका है: एक failing case को end-to-end reproduce करना। टीम में यह standard operating procedure रखें:

रिसीपिएंट address और ISP नोट करें (Gmail/Outlook/corporate)।
email type नोट करें (OTP/reset/invite)।
internal_message_id निकालें (UI/CS tool से)।
अपने logs में trace करें: created → queued → accepted → delivered/bounced/deferred/suppressed।
provider dashboard में उसी message को search करें और event timeline देखें।
अगर delivered है, तो user को spam/promotions/all mail में check कराएँ और headers screenshot लें।
अगर deferred है, तो retry schedule देखें और OTP TTL/UX adjust करें।
अगर suppressed है, तो reason fix करें और controlled unsuppress करें।

इस प्रक्रिया को लिखित runbook में रखें और सपोर्ट/QA के साथ शेयर करें ताकि हर बार इंजीनियर को interrupt न करना पड़े।

10) Metrics & alerts: अगली बार “पहले” पकड़ें

“Sent but Not Received” को स्थायी रूप से कम करने का रास्ता है: सही metrics और alerts। प्रोडक्ट टीम के लिए dashboard में ये KPI रखें:

Provider accepted rate (submitted vs accepted)
Delivery rate (delivered / accepted)
Bounce rate (hard/soft अलग-अलग)
Deferral rate (ISP-wise)
Suppression rate (reason breakdown)
Time-to-deliver p50/p90 (OTP के लिए critical)
OTP completion rate और “resend clicks per session”

Alerting rules (उदाहरण)

Gmail delivery rate 15 मिनट में baseline से X% गिर जाए
Deferrals 2x हो जाएँ
Hard bounces spike करें
OTP time-to-deliver p90 बढ़ जाए

जब alerts meaningful हों, तो टीम issue को user-reported होने से पहले पकड़ सकती है।

11) Prevention fixes: प्रोडक्ट टीम क्या बदल सकती है?

इस समस्या का समाधान सिर्फ DNS रिकॉर्ड या SMTP config नहीं है। Product design भी बड़ा फर्क बनाता है। कुछ high-impact सुधार:

11.1 UX सुधार

“Didn’t receive?” helper: spam/promotions check, resend timer, सही domain instructions
ईमेल address confirm step: typo रोकने के लिए instant validation
Resend policy: controlled resend + explain rate-limit
Fallback: OTP के लिए optional secondary channel (यदि आपका प्रोडक्ट allow करे)

11.2 Traffic separation

OTP/transactional और marketing को अलग stream/IP/subdomain पर रखें
High priority queue OTP के लिए
Template linting और safe HTML subset

11.3 Data hygiene

Invalid domains detection (common typos: gmial.com जैसे)
Suppression transparency: support tool में clear reason
Recipient preferences और unsubscribe compliance (marketing में)

12) एक छोटा केस-स्टोरी: “Sent” था, फिर भी OTP नहीं आया

मान लीजिए एक नए यूज़र ने ऐप में signup किया। स्क्रीन पर “OTP भेज दिया गया” दिखा। यूज़र ने 3 बार resend किया, फिर भी कुछ नहीं आया। सपोर्ट टिकट खुला।

टीम ने internal_message_id से trace निकाला: message_created और queued तो था, provider_accepted भी था, लेकिन आगे delivered नहीं मिला—deferrals की सीरीज़ थी। उसी समय dashboard में Gmail deferrals spike दिखा। कारण निकला: launch day पर bot signups बढ़े, OTP traffic ने rate limits hit कर दिए। Fix यह हुआ: OTP के लिए अलग priority queue + throughput control + suspicious traffic throttling, और UI में resend cooldown + “check spam/promotions” helper add किया गया।

अगले हफ्ते OTP completion rate सुधर गया, और support tickets आधे रह गए। यही वजह है कि product, infra, और deliverability—तीनों को एक साथ देखना पड़ता है।