होम › गाइड

Shared hosting IP blacklist में? क्या आप ठीक कर सकते हैं, क्या नहीं

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

जब shared hosting का IP blacklist में हो, तो पहला काम यह तय करना है कि उस IP का नियंत्रण किसके पास है और वह ठीक-ठीक किस सूची में, किस return code के साथ है। फिर अपनी तरफ़ की हर समस्या साफ़ करें और अपने hosting provider को lookup के सबूत भेजें ताकि वे कार्रवाई कर सकें। shared IP पर कारण पूरी तरह किसी दूसरे ग्राहक का हो सकता है, और कुछ सूचियों में removal का अनुरोध केवल network का मालिक कर सकता है।

नया बनाया गया VPS या cloud IP भी पहले दिन से "blacklisted" दिख सकता है, या तो पिछले उपयोगकर्ता के इतिहास की वजह से, या इसलिए कि वह range ऐसी range के रूप में सूचीबद्ध है जिससे सीधे मेल नहीं भेजा जाना चाहिए। स्थिति जो भी हो, delist करने का फ़ैसला हमेशा सूची के operator के पास होता है।

यह गाइड नवंबर 2026 तक के Spamhaus, AWS, Google Cloud और Microsoft Azure के आधिकारिक पेजों पर आधारित है। प्रतिबंध और प्रक्रियाएँ बदलती रहती हैं, इसलिए कदम उठाने से पहले मौजूदा शब्दों की पुष्टि करें। blacklist से जुड़े bounces की पूरी तस्वीर के लिए blacklist के कारण ब्लॉक हुए ईमेल पर हमारी गाइड देखें।

पहले पता करें: कौन-सा IP और कौन-सी सूची

"मेरा server blacklist में है" के बहुत अलग-अलग मतलब हो सकते हैं, और समाधान विवरण पर निर्भर करता है। कुछ भी करने से पहले तीन सवालों के जवाब दें।

1. वास्तव में कौन-सा IP आपका मेल भेजता है? आपकी website होस्ट करने वाला IP ज़रूरी नहीं कि वही हो जो आपका ईमेल deliver करता है। bounce संदेश पढ़ें, जिसमें अक्सर reject हुआ IP लिखा होता है, और असली outbound पते की पुष्टि के लिए अपने भेजे गए किसी संदेश के Received headers देखें।
2. उस IP का नियंत्रण किसके पास है? shared hosting पर यह दूसरे ग्राहकों के साथ साझा पता होता है। dedicated server, VPS या cloud instance पर यह आपको आवंटित होता है, हालाँकि आसपास की range फिर भी provider की होती है। आपका hosting plan या control panel बताएगा कि आपका outgoing मेल साझा पते का उपयोग करता है या नहीं।
3. यह किस सूची में है? सूचियों के अर्थ अलग होते हैं, और उन्हें ठीक कौन कर सकता है यह भी। सभी प्रमुख सूचियाँ एक साथ देखने के लिए IP को हमारे blacklist checker में डालें, और सूचियों के नाम और return codes लिख लें।

इन तीनों जवाबों के बाद आमतौर पर साफ़ हो जाता है कि यह ऐसी चीज़ है जिसे आप खुद ठीक कर सकते हैं, जिसे आपके provider को ठीक करना होगा, या यह संकेत है कि आपको मेल भेजने का तरीका ही बदल देना चाहिए।

lookup परिणाम और return codes कैसे पढ़ें

Spamhaus ZEN (zen.spamhaus.org) Spamhaus की संयुक्त IP सूची है। सूचीबद्ध IP 127.0.0.x range का पता लौटाता है, और आख़िरी संख्या बताती है कि कौन-सी अंदरूनी सूची match हुई। shared hosting और cloud IPs के लिए इन codes में फ़र्क समझना ज़रूरी है:

PBL entry कोई आरोप नहीं है। यह एक policy कथन है कि इस पते से आने वाला मेल authentication के साथ ऐसे server को submit किया जाना चाहिए जो उसे आगे relay करे। Spamhaus ISPs और दूसरे networks को सक्रिय रूप से प्रोत्साहित करता है कि वे हर ऐसी range सूचीबद्ध करें जिससे मेल नहीं भेजा जाना चाहिए, और इसमें web servers स्पष्ट रूप से शामिल हैं।

codes 127.255.255.252, 127.255.255.254 और 127.255.255.255 errors हैं, listings नहीं। Spamhaus का DNSBL usage FAQ यह चेतावनी भी देता है कि Google Public DNS (8.8.8.8) जैसा मुफ़्त public resolver ज़्यादातर मामलों में "not listed" लौटाएगा, इसीलिए अलग-अलग tools के परिणाम मेल नहीं खा सकते। संदेह हो तो परिणाम Spamhaus के अपने reputation checker पर जाँचें। हर सूची की पूरी प्रक्रिया के लिए Spamhaus removal कैसे काम करता है देखें।

आप खुद क्या ठीक कर सकते हैं और क्या नहीं

आप कितना बदल सकते हैं, यह इस पर निर्भर करता है कि आप किस सेवा के लिए भुगतान कर रहे हैं।

shared hosting पर अपने account को कारण के रूप में खारिज करना

• Compromised mailboxes. sending logs और sent folders में ऐसे मेल के झुंड देखें जो आपने नहीं भेजे। कुछ मिले तो तुरंत passwords बदलें।
• hack हुई website. पुराने CMS installs और plugins हमलावरों के लिए मेल भेजने वाली scripts upload करने का आम रास्ता हैं।
• दुरुपयोग किए गए forms. ऐसे contact forms जिनके auto-reply में visitor प्राप्तकर्ता या संदेश का पाठ चुन सकता है, spam भेजने की मशीन बन सकते हैं।
• सूची की गुणवत्ता. खरीदी गई सूचियों पर या ऐसे पतों पर मेल भेजना जिन्होंने कभी opt-in नहीं किया, shared IP को सबके लिए, आपके लिए भी, नुकसान पहुँचाने का पक्का तरीका है।

अगर इनमें से कुछ नहीं मिलता, तो संभावित कारण उसी पते पर कोई और है। Spamhaus का port 25 FAQ यह बात सीधे कहता है: shared IP pools पर listing से प्रभावित ज़्यादातर लोग वे नहीं होते जिनका device संक्रमित है। ऐसे में आपका काम सबूत इकट्ठा करके provider को सौंपना है।

अपने hosting provider को कैसे रिपोर्ट करें

Spamhaus कहता है कि SBL removal अनुरोध सूचीबद्ध IP के ज़िम्मेदार ISP द्वारा भेजे जाने चाहिए, और वह आम उपयोगकर्ताओं से समाधान के लिए अपने ISP से बात करने को कहता है। shared hosting ग्राहक के लिए वह ISP आपकी hosting कंपनी है। केवल "मेरा ईमेल नहीं पहुँच रहा" कहने वाला support ticket इधर-उधर घूमता रहता है। नीचे दी गई जानकारी वाला ticket आमतौर पर जल्दी आगे बढ़ता है:

1. भेजने वाला IP, जैसा headers या bounce से पुष्टि हुई।
2. सूची और return code, उदाहरण के लिए zen.spamhaus.org का 127.0.0.2 लौटाना।
3. आपने कब और किससे जाँचा, और अगर आधिकारिक reputation checker इस्तेमाल किया तो उसमें क्या दिखा।
4. bounce का पाठ, खासकर वह पंक्ति जिसमें receiving server rejection का कारण बताता है।
5. आप क्या पहले ही खारिज कर चुके हैं, जैसे password reset और साइट का साफ़ scan।
6. आप क्या माँग रहे हैं: जाँच, उचित हो तो सूची के operator को removal अनुरोध, या आपके account के outbound मेल को दूसरे IP पर ले जाना।

एक छोटा उदाहरण:

Our outbound IP 192.0.2.10 returns 127.0.0.2 (SBL) on zen.spamhaus.org.
We confirmed this on the official Spamhaus checker at 10:00 UTC on 2026-11-03.
We have reset all mailbox passwords and found no unexpected files on our site.
Please investigate, request removal if appropriate, or advise whether our mail
can be sent from a different IP.

आपके provider को समय लग सकता है, और उनके कार्रवाई करने के बाद भी अंतिम फ़ैसला सूची का operator करता है। अगर कोई मेल इंतज़ार नहीं कर सकता, तो साथ-साथ के उपाय के रूप में नीचे बताया गया relay विकल्प देखें। अगर आप यह तय नहीं कर पा रहे कि समस्या कहाँ है, तो आप हमसे मदद भी माँग सकते हैं।

VPS और cloud पर port 25 प्रतिबंध और reverse DNS

अगर आप VPS या cloud instance पर अपना मेल server चलाते हैं, तो किसी blacklist से पहले ही आपको एक समस्या आ सकती है: कई providers outbound TCP port 25 को प्रतिबंधित करते हैं, जो server-से-server मेल delivery का port है। AWS, Google Cloud और Microsoft Azure का आधिकारिक documentation यह कहता है।

• Amazon EC2 (AWS). डिफ़ॉल्ट रूप से EC2 outbound port 25 ट्रैफ़िक केवल private IPv4 पतों पर जाने देता है; public IPv4 और IPv6 पतों पर ट्रैफ़िक ब्लॉक रहता है। आप यह प्रतिबंध हटाने का अनुरोध कर सकते हैं। तीसरे पक्षों को ईमेल के लिए AWS Elastic IP addresses लेने और उन्हें static reverse DNS records देने की सलाह देता है, और बताता है कि इससे मेल के spam चिह्नित होने से बचने में मदद मिल सकती है। reverse record बनाने से पहले Elastic IP पर resolve होने वाला forward DNS (A) record मौजूद होना चाहिए।
• Google Cloud (Compute Engine). external IP पतों पर TCP port 25 का egress डिफ़ॉल्ट रूप से ब्लॉक है। जब Google Cloud तय करता है कि कोई project कम जोखिम वाला है, तो यह block अपने-आप हट जाता है, और आप console के VPC networks या firewall policies पेजों पर banner से project की स्थिति देख सकते हैं। ports 465 और 587 पर SMTP over TLS इस block से बाहर है। Google किसी भरोसेमंद third-party email provider का उपयोग करने की सलाह देता है, और कहता है कि इससे आपकी IP reputation बेहतर होती है।
• Microsoft Azure (virtual machines). standard Enterprise Agreement और Microsoft Customer Agreement for enterprise (MCA-E) को छोड़कर हर subscription प्रकार के लिए outbound port 25 ब्लॉक है। Enterprise Dev/Test subscriptions डिफ़ॉल्ट रूप से ब्लॉक हैं, लेकिन portal के diagnostic के ज़रिए छूट पा सकती हैं। Authenticated SMTP relay services, आमतौर पर port 587 पर, किसी भी subscription प्रकार के लिए प्रतिबंधित नहीं हैं, और Microsoft इनकी सलाह देता है। जहाँ port 25 खुला है, वहाँ भी Microsoft बताता है कि इस बात की कोई गारंटी नहीं कि external domains मेल स्वीकार करेंगे।

ब्लॉक हुआ port 25 delivery की समस्या है, reputation की नहीं, और port खोलने से आपके IP की साख पर कोई असर नहीं पड़ता। अगर आप किसी cloud या VPS पते के लिए Spamhaus PBL exclusion चाहते हैं, तो IP static होना चाहिए, उस पर वास्तव में outbound मेल server चलना चाहिए, उसका सही forward और reverse DNS होना चाहिए, और वह आपको आवंटित होना चाहिए। Spamhaus यह भी माँगता है कि उसके पीछे के हर दूसरे device के लिए outbound port 25 बंद हो।

dedicated IP या authenticated SMTP relay पर जाना

अगर shared IP बार-बार पड़ोसियों की वजह से नीचे खिंचता रहता है, या आपका cloud provider port 25 नहीं खोलेगा, तो delisting के पीछे भागने के बजाय मेल भेजने का तरीका बदलना अक्सर ज़्यादा व्यावहारिक है।

external, authenticated SMTP relay

आपका server मेल सीधे प्राप्तकर्ता तक पहुँचाने के बजाय हर संदेश एक authenticated sending server को सौंपता है, जो आपकी ओर से उसे deliver करता है। PBL में सूचीबद्ध ranges के लिए Spamhaus ठीक यही मॉडल बताता है: मेल authentication के साथ किसी relay को submit किया जाना चाहिए, जिसे जोड़ने वाला ISP या कोई external mail service चला सकती है। Spamhaus का port 25 FAQ आगे कहता है कि end users को SMTP AUTH के साथ ports 587 या 465 इस्तेमाल करने चाहिए। Azure और Google Cloud दोनों authenticated relay या third-party email services की सलाह देते हैं, और Microsoft बताता है कि ऐसी services का उपयोग आंशिक रूप से उस IP reputation को बनाए रखने के लिए होता है जिस पर delivery निर्भर करती है।

• relay का host name, port (आमतौर पर 587) और credentials वैसे ही configure करें जैसे आपका provider बताता है।
• अपने domain का SPF record update करके उसमें relay शामिल करें और उसके लिए DKIM signing सेट करें। देखें SPF, DKIM और DMARC कैसे सेट करें।
• ज़्यादा मात्रा वाले मेल को relay पर ले जाने से पहले उसकी sending limits जाँच लें।

dedicated IP

dedicated IP आपको दूसरे ग्राहकों के व्यवहार से बचाता है, लेकिन यह reputation में अपने-आप सुधार नहीं है। Spamhaus की sender guidelines reputation को प्रभावित करने वाले कारकों की सूची देती हैं, जिनमें service provider, IP का पड़ोस, पते के पीछे का infrastructure और IP का इतिहास शामिल हैं।

• नए पतों की ज़्यादा जाँच होती है। वही guidelines कहती हैं कि बिना sending इतिहास वाले HELO domains पर अतिरिक्त filtering लागू होती है, और बदले गए IP या HELO hostname को नया मानकर धीरे-धीरे warm up करना चाहिए। कृत्रिम ट्रैफ़िक पैदा करने वाली warm-up services निषिद्ध हैं।
• सार्थक reverse DNS सेट करें। Spamhaus चेतावनी देता है कि dedicated IPs पर generic या auto-generated reverse DNS reputation को नुकसान पहुँचा सकता है।
• इस्तेमाल से पहले नया IP जाँचें। किसी पते पर पिछले उपयोगकर्ता की listing हो सकती है, इसलिए मेल भेजना शुरू करने से पहले उसे जाँच लें।

दोबारा ऐसा होने से कैसे रोकें

• hostname, HELO और reverse DNS को एक जैसा रखें। Spamhaus का CSS FAQ कहता है कि आपके IP का forward DNS आपके server पर सेट HELO मान से मेल खाना चाहिए और HELO एक fully qualified domain name होना चाहिए। वह localhost.localdomain जैसे मानों को आम गलतियाँ बताता है।
• port 25 को मेल servers तक सीमित रखें। दूसरे workloads भी चलाने वाले VPS पर, मेल server के अलावा हर चीज़ के लिए outbound port 25 बंद करें।
• साइटें और accounts सुरक्षित रखें। अपना CMS और plugins update करें, passwords दोबारा इस्तेमाल करना बंद करें और जहाँ हो सके two-factor authentication चालू करें।
• अपने control panel की outgoing मेल settings की समीक्षा करें। CSS FAQ एक Plesk विकल्प का वर्णन करता है जो SMTP greeting में हर domain का अपना नाम डालता है। वह चेतावनी देता है कि जब server पर एक से ज़्यादा domains एक IP साझा करते हैं, तो Spamhaus XBL इस्तेमाल करने वाले receivers उनमें से कुछ या सभी domains के मेल को spam चिह्नित कर सकते हैं, और इस विकल्प का उपयोग बेहद सावधानी से किया जाना चाहिए। अपने panel में इसके समकक्ष setting देखें और अपने provider या panel vendor के मार्गदर्शन का पालन करें।
• नियमित रूप से निगरानी करें। shared IP की स्थिति किसी और के कामों से बदल सकती है। हमारे blacklist checker से समय-समय पर जाँचें और कुछ बदलने पर जल्दी अपने provider को बताएँ।

delisting के बाद भी receivers अपनी filtering लागू करते हैं, इसलिए delivery तुरंत ठीक न हो, ऐसा हो सकता है। CSS listings आमतौर पर आख़िरी बार पकड़े जाने के लगभग तीन दिन बाद expire होती हैं, लेकिन समस्या अब भी पकड़ी जाने पर IP फिर से सूचीबद्ध हो जाता है, और self-removals सीमित हैं।

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

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

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

• Spamhaus: Policy Blocklist (PBL)
• Spamhaus: Spamhaus Blocklist (SBL)
• Spamhaus FAQ: DNSBL Usage (return codes and public resolvers)
• Spamhaus FAQ: Combined Spam Sources (CSS)
• Spamhaus FAQ: Port 25 General Questions
• Spamhaus: Sender Guidelines
• AWS: Amazon EC2 service quotas (Restriction on email sent using port 25)
• AWS: Create a reverse DNS record for email on Amazon EC2
• Google Cloud: Sending email from an instance
• Google Cloud: VPC firewall rules (Blocked and limited traffic)
• Microsoft Learn: Troubleshoot outbound SMTP connectivity in Azure

संबंधित गाइड

सभी गाइड →