होम › गाइड

ईमेल ब्लैकलिस्ट में? बाउंस कैसे पढ़ें और ब्लैकलिस्ट से कैसे हटें

प्रकाशित 2026-11-03 ／ अपडेट 2026-11-03 ／ लेखक Yuki Nakazawa

अगर आपका ईमेल ब्लैकलिस्ट में है, तो बाउंस संदेश आम तौर पर यह बता देता है। वापस आए अस्वीकृति संदेश को खोलें और तीन चीज़ें देखें: तीन अंकों वाला कोड, उसके बाद आने वाला बिंदुओं वाला कोड (जैसे 5.7.1), और टेक्स्ट। 4 से शुरू होने वाला कोड अस्थायी विफलता है; 5 से शुरू होने वाला कोड स्थायी है। अगर टेक्स्ट में किसी ब्लॉकलिस्ट का नाम है, तो सबसे पहले उसी लिस्ट से निपटना है।

ब्लैकलिस्ट के पीछे भागने से पहले आसान कारणों को क्रम से जाँच लें: पते में टाइपिंग की गलती, भरा हुआ मेलबॉक्स, प्राप्तकर्ता की तरफ़ की कोई समस्या, और SPF, DKIM या DMARC का न होना। ब्लैकलिस्ट से हटने का तरीका लगभग हर जगह एक जैसा है: कारण ढूँढें और उसे रोकें, अगर लिस्ट को ज़रूरत हो तो हटाने का एक अनुरोध भेजें, फिर प्रतीक्षा करें। कोई भी delisting का वादा नहीं कर सकता, और समस्या ठीक किए बिना बार-बार अनुरोध भेजने से स्थिति अक्सर और बिगड़ जाती है।

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

बाउंस संदेश कैसे पढ़ें

बाउंस (non-delivery report) में प्राप्त करने वाले सर्वर का दिया गया जवाब उद्धृत होता है। ब्लैकलिस्ट की वजह से होने वाली एक सामान्य अस्वीकृति ऐसी दिखती है:

<user@example.com>: host mx.example.com[203.0.113.25] said:
    550 5.7.1 Service unavailable; Client host [203.0.113.10]
    blocked using bl.example.org (in reply to RCPT TO command)

1. रिप्लाई कोड (550)। RFC 5321 के अनुसार, 4yz रिप्लाई का मतलब है कि एरर अस्थायी है और वही अनुरोध दोबारा आज़माया जा सकता है। 5yz रिप्लाई स्थायी विफलता है, और भेजने वाले सर्वर को वही अनुरोध बस दोहराना नहीं चाहिए।
2. एन्हांस्ड स्टेटस कोड (5.7.1)। RFC 3463 में इसे class.subject.detail के रूप में परिभाषित किया गया है। बीच की संख्या क्षेत्र बताती है: 1 पता, 2 मेलबॉक्स, 4 नेटवर्क और रूटिंग, 7 सुरक्षा या नीति। 5.7.x कोड का मतलब है कि प्राप्तकर्ता ने आपको नीति के आधार पर अस्वीकार किया है, और ब्लॉकलिस्ट व रेप्युटेशन यहीं दिखाई देते हैं।
3. फ़्री टेक्स्ट। प्राप्तकर्ता अक्सर लिस्ट का नाम बताते हैं (blocked using bl.example.org) या कोई lookup URL देते हैं। पूरा बाउंस कॉपी कर लें; हटाने के किसी भी अनुरोध या सपोर्ट टिकट के लिए इसकी ज़रूरत पड़ेगी।

आम कोड और वे किस ओर इशारा करते हैं। 5.7.25, 5.7.26 और 4.7.x के विवरण Gmail की प्रकाशित एरर सूची से लिए गए हैं; दूसरे प्रोवाइडर इन्हीं कोड को अलग शब्दों में या अलग तरह से इस्तेमाल कर सकते हैं।

4xx एरर होने पर आपका सर्वर अपने-आप दोबारा कोशिश करता रहता है। RFC 5321 प्रयासों के बीच कम से कम 30 मिनट प्रतीक्षा करने की सलाह देता है और कहता है कि हार मानने का समय आम तौर पर कम से कम 4 से 5 दिन होना चाहिए, इसीलिए अंतिम विफलता से काफ़ी पहले आपको "delayed" चेतावनी मिल सकती है।

कारणों को इस क्रम में जाँचें

सबसे सस्ते और सबसे आम कारणों से शुरू करके कम आम कारणों की ओर बढ़ें। शुरुआती जाँचों में कुछ ही सेकंड लगते हैं, इसलिए बाकी सब से पहले इन्हें करें।

1. पते में टाइपिंग की गलती। 5.1.1 का ब्लैकलिस्ट से कोई लेना-देना नहीं है। पता ठीक करें।
2. भरा हुआ मेलबॉक्स। 4.2.2 या 5.2.2 प्राप्तकर्ता की समस्या है। उनसे किसी दूसरे तरीके से संपर्क करें।
3. केवल एक प्राप्तकर्ता पर विफलता। अगर दूसरी कंपनियों और Gmail पर मेल पहुँच रहा है, तो संभावित कारण प्राप्तकर्ता के अपने फ़िल्टर हैं। उनके एडमिनिस्ट्रेटर को बाउंस का पूरा टेक्स्ट भेजें।
4. SPF, DKIM और DMARC। Gmail हर सेंडर से SPF या DKIM सेट करने की अपेक्षा करता है, और प्रतिदिन 5,000 से ज़्यादा संदेश भेजने वालों से SPF, DKIM और DMARC तीनों सेट करने की। Yahoo की आवश्यकताएँ मिलती-जुलती हैं, जिनमें बल्क सेंडर के लिए कम से कम p=none वाली DMARC नीति ज़रूरी है। Outlook.com ने 5 मई 2025 से प्रतिदिन 5,000 से ज़्यादा संदेश भेजने वाले डोमेन पर यही आवश्यकताएँ लागू करनी शुरू कीं। SPF, DKIM और DMARC सेटअप गाइड देखें।
5. भेजने वाले IP और डोमेन की रेप्युटेशन। जाँचें कि भेजने वाले IP का मान्य forward और reverse DNS (PTR) है, आप TLS पर भेजते हैं, और शिकायतें कम हैं। Gmail और Yahoo दोनों सेंडर से स्पैम दर 0.3% से नीचे रखने को कहते हैं; Gmail 0.10% या उससे कम रहने की सलाह देता है।
6. ब्लैकलिस्ट जाँच। अगर किसी बाउंस में किसी लिस्ट का नाम है, या कई असंबंधित प्राप्तकर्ता 5.7.1 लौटाते हैं, तो ब्लैकलिस्ट चेकर से अपने भेजने वाले IP और डोमेन को देखें।
7. कंटेंट और मात्रा। देखें कि क्या कुछ बदला है: अचानक बहुत बड़ी संख्या में भेजना, किसी पुरानी लिस्ट पर एक साथ मेल भेजना, किसी वेब फ़ॉर्म का दुरुपयोग करके अनजान लोगों को मेल भेजा जाना।

अगर केवल Gmail आपको अस्वीकार करता है, तो Gmail डिलीवरी समस्या निवारण गाइड उसके खास कोड को और विस्तार से समझाती है।

ईमेल ब्लैकलिस्ट (DNSBL) क्या है और इसे कैसे जाँचें

ज़्यादातर ईमेल ब्लैकलिस्ट DNSBL होती हैं: DNS के ज़रिए प्रकाशित की जाने वाली लिस्ट। जब आपका सर्वर कनेक्ट करता है, तो प्राप्त करने वाला सर्वर उन लिस्टों में आपका IP देखता है जिन पर वह भरोसा करता है, और फिर जवाब के आधार पर संदेश को अस्वीकार करता है, स्कोर देता है या टैग करता है।

RFC 5782 इस lookup का वर्णन करता है। IPv4 के लिए octets को उल्टे क्रम में रखकर लिस्ट के डोमेन से पहले जोड़ा जाता है। लिस्ट में मौजूद पता एक A रिकॉर्ड लौटाता है, परंपरागत रूप से 127.0.0.2, और उसके साथ कारण बताने वाला TXT रिकॉर्ड भी हो सकता है। जो पता लिस्ट में नहीं है, उसका कोई रिकॉर्ड नहीं होता। IPv6 में पूरे पते का nibble-reversed रूप इस्तेमाल होता है।

$ dig +short 10.113.0.203.bl.example.org A
127.0.0.2
$ dig +short 10.113.0.203.bl.example.org TXT
"Listed - see https://bl.example.org/lookup"

कुछ बातें जिनमें लोग अक्सर गलती करते हैं:

• उस सर्वर का IP जाँचें जो आपका मेल भेजता है, अपने लैपटॉप या ऑफ़िस के कनेक्शन का नहीं। इसे बाउंस (Client host [...]) में या अपने भेजे किसी संदेश के Received हेडर में देखें।
• डोमेन भी लिस्ट हो सकते हैं। कुछ लिस्ट भेजने वाले डोमेन या लिंक में आने वाले डोमेन को कवर करती हैं। IP और डोमेन दोनों जाँचें।
• लिस्टिंग का असर वहीं होता है जहाँ उस लिस्ट का उपयोग होता है। हर प्राप्तकर्ता खुद तय करता है कि कौन-सी लिस्ट देखनी है। अगर आप ऐसी लिस्ट में हैं जिसका आपके प्राप्तकर्ता उपयोग नहीं करते, तो उनके लिए कुछ नहीं बदलता।

दर्जनों लिस्टों को हाथ से क्वेरी करना थकाऊ है; ब्लैकलिस्ट चेकर यह एक ही बार में कर देता है और दिखाता है कि किन लिस्टों में hit मिला।

कौन-सी लिस्टिंग सच में मायने रखती है

हर लिस्टिंग पर एक जैसा ध्यान देने की ज़रूरत नहीं होती। प्राथमिकता का मोटा-मोटा क्रम:

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

नवंबर 2026 की स्थिति में उनके आधिकारिक पेजों के अनुसार, कुछ जानी-मानी लिस्ट अपने बारे में क्या बताती हैं:

दो बातें ध्यान में रखें। पहली, जो लिस्ट पूरी रेंज को कवर करती हैं, जैसे UCEPROTECT Levels 2 और 3, वे उसी नेटवर्क के दूसरे पतों की वजह से आपके IP को भी शामिल कर सकती हैं, भले ही आपने कभी स्पैम न भेजा हो। दूसरी, जहाँ कोई लिस्ट सशुल्क express removal देती है, वहाँ आम तौर पर साथ में मुफ़्त स्वचालित समाप्ति भी होती है, और भुगतान करने से लिस्टिंग का कारण ठीक नहीं होता। अगर कारण बना रहता है, तो लिस्टिंग वापस आ जाती है। Spamhaus की कई लिस्ट हैं जिनके हटाने के रास्ते अलग-अलग हैं; Spamhaus से कैसे हटें देखें।

ब्लैकलिस्ट से कैसे हटें

प्रक्रिया हर लिस्ट के लिए लगभग एक जैसी है:

1. कारण ढूँढें और उसे रोकें। आम तौर पर दोषी होते हैं: किसी मेलबॉक्स का लीक हुआ पासवर्ड, malware से संक्रमित मशीन, ऐसा संपर्क फ़ॉर्म जो डाले गए किसी भी पते पर मेल भेज देता है, open relay, या ऐसे लोगों को मेल भेजना जिन्होंने कभी opt-in नहीं किया। बाकी सब से पहले पासवर्ड बदलें और खामी बंद करें।
2. ऑपरेटर का lookup पेज पढ़ें। ज़्यादातर लिस्ट आपको IP डालकर यह देखने देती हैं कि वह क्यों लिस्ट है और हटाने का रास्ता क्या है। उसी का पालन करें, किसी तीसरे पक्ष के अनुमान का नहीं।
3. अगर लिस्ट प्रविष्टियाँ अपने-आप समाप्त करती है, तो प्रतीक्षा करें। SpamCop रिपोर्ट बंद होने के 24 घंटे बाद लिस्टिंग हटा देता है; UCEPROTECT Level 1 नए स्पैम के बिना 7 दिन बाद।
4. अगर लिस्ट अनुरोध लेती है, तो एक अनुरोध भेजें। साफ़-साफ़ बताएँ कि क्या हुआ और आपने क्या बदला। उदाहरण के लिए, Barracuda कहता है कि दोहराए गए अनुरोधों पर ध्यान नहीं दिया जाता।
5. दोबारा भेजें और नज़र रखें। हटाए जाने का असर फैलने में समय लग सकता है। SpamCop बताता है कि इसके mirror सर्वरों और लिस्ट का उपयोग करने वाले सर्वरों तक पहुँचने में 4 घंटे तक लग सकते हैं।

एक ही अनुरोध बार-बार भेजना, या कारण ठीक होने से पहले हटाने की माँग करना, उल्टा असर करता है। अगर इससे काम बन भी जाए, तो समस्या दोबारा होते ही लिस्टिंग लौट आती है, और दोनों ही स्थितियों में अंतिम निर्णय ऑपरेटर का होता है।

यह भी याद रखें कि DNSBL केवल एक कारक है। जब Gmail आपके भेजने वाले IP या डोमेन की बहुत कम रेप्युटेशन का हवाला देकर 550 5.7.1 के साथ मेल अस्वीकार करता है, तो वह Gmail का अपना आकलन है। DNSBL से हटने से वह नहीं बदलेगा; बेहतर ऑथेंटिकेशन, साफ़ लिस्ट और कम शिकायतों से बदलेगा।

शेयर्ड होस्टिंग और VPS: जब IP सिर्फ़ आपका नहीं होता

शेयर्ड होस्टिंग पर कई ग्राहक एक ही outbound IP से मेल भेजते हैं। किसी दूसरे की हैक हुई साइट उस IP को लिस्ट करवा सकती है, और उनके साथ आपका मेल भी ब्लॉक हो जाता है।

• शेयर्ड होस्टिंग। IP होस्ट के नियंत्रण में होता है, इसलिए खुद हटाने के अनुरोध भेजने के बजाय पूरे बाउंस और लिस्ट हुए IP के साथ सपोर्ट टिकट खोलें। रेंज या नेटवर्क की लिस्टिंग, जैसे UCEPROTECT Levels 2 और 3, को केवल प्रोवाइडर ही संभाल सकता है।
• VPS या डेडिकेटेड सर्वर। नए दिए गए IP पर किसी पिछले उपयोगकर्ता का इतिहास हो सकता है। भेजना शुरू करने से पहले उसे जाँच लें, और उसका reverse DNS (PTR) अपने मेल सर्वर के hostname से मेल खाता हुआ सेट करें, आम तौर पर प्रोवाइडर के कंट्रोल पैनल से।
• घर या dynamic IP से सीधे भेजना। Spamhaus PBL ऐसी ही रेंज के लिए है। मेल को अपने प्रोवाइडर या मेल सेवा के submission सर्वर के ज़रिए पोर्ट 587 या 465 पर ऑथेंटिकेशन के साथ भेजें।

अगर IP आपके नियंत्रण में नहीं है और प्रोवाइडर उसे ठीक नहीं कर सकता, तो outbound मेल को किसी दूसरे ऑथेंटिकेटेड सेंडिंग सर्वर पर ले जाना अक्सर व्यावहारिक समाधान होता है।

दोबारा लिस्ट होने से कैसे बचें

Delisting तभी टिकती है जब कारण ठीक ही रहे। ये आदतें बनाए रखें:

• ऑथेंटिकेशन और बुनियादी बातें। SPF, DKIM और DMARC को मान्य रखें, reverse DNS सही रखें, और TLS पर भेजें। जब भी कोई नई सेंडिंग सेवा जोड़ें, SPF अपडेट करें।
• अकाउंट की सुरक्षा। मज़बूत पासवर्ड और two-factor authentication का उपयोग करें, और outbound मात्रा या queue के आकार में अचानक उछाल पर नज़र रखें।
• फ़ॉर्म सुरक्षित करें। संपर्क और साइन-अप फ़ॉर्म पर rate limit लगाएँ, ताकि उनका इस्तेमाल मनचाहे पतों पर मेल भेजने के लिए न हो सके।
• लिस्ट की साफ़-सफ़ाई। केवल उन्हीं लोगों को मेल भेजें जिन्होंने इसके लिए कहा हो, और बाउंस होने वाले पते हटा दें। Gmail और Yahoo बल्क सेंडर से one-click unsubscribe का समर्थन करने की अपेक्षा करते हैं।
• अचानक उछाल से बचें। सामान्य से बहुत ज़्यादा मेल भेजने पर rate limit और शिकायतें ट्रिगर हो सकती हैं।
• समय-समय पर जाँचें। बीच-बीच में अपने भेजने वाले IP और डोमेन को देखते रहने से आप ग्राहकों के मेल न मिलने की शिकायत करने से पहले ही लिस्टिंग पकड़ सकते हैं।

अक्सर पूछे जाने वाले प्रश्न

उपयोग किए गए आधिकारिक पेज

इस लेख के तथ्य प्रकाशन के समय नीचे दिए गए आधिकारिक पेजों से मिलाए गए थे। नीतियाँ और व्यवहार बिना सूचना के बदल सकते हैं, इसलिए किसी महत्वपूर्ण बात पर भरोसा करने से पहले आधिकारिक पेज देख लें।

• RFC 5321: Simple Mail Transfer Protocol
• RFC 3463: Enhanced Mail System Status Codes
• RFC 5782: DNS Blacklists and Whitelists
• Google Workspace: Gmail SMTP errors and codes
• Google: Email sender guidelines
• Yahoo Sender Hub: Best Practices
• Microsoft: Outlook.com Postmaster
• Spamhaus: Policy Blocklist (PBL)
• SpamCop FAQ: SpamCop Blocking List delisting
• SpamCop Blocking List
• Barracuda Central: Removal Request
• UCEPROTECT: Removal Policy Level 1
• UCEPROTECT: Removal Policy Level 2
• UCEPROTECT: Removal Policy Level 3

संबंधित गाइड

सभी गाइड →