Blacklists (DNSBL): Why Your IP Gets Listed and How to Get Off
2026-09-02 · 6 min
Every email you send is checked against several public blocklists before it reaches an inbox. If your sending IP appears on one of the major ones, your message can be silently quarantined or bounced - often with no visible error on your side. For anything that sends mail (a company server, a self-hosted box, a VPS), knowing your blocklist status is basic hygiene.
The good news: the mechanism is simple, checking it takes seconds, and getting delisted is usually quick once you understand why you were listed in the first place.
1995
The first RBL
Paul Vixie and the Mail Abuse Prevention System launch the Real-time Blackhole List, the first widely used spam blocklist - already distributed through DNS, which made it trivially cheap to query.
1998
Spamhaus appears
The Spamhaus Project launches in the UK and grows into the most operationally influential blocklist: its zones (today the combined ZEN) are checked by a majority of the world's mail servers.
2000s
An ecosystem of dozens
Barracuda, SpamCop, SORBS, UCEPROTECT and many others launch their own zones, each with its own listing policy and delisting process - checking just one list is never the whole picture.
2010
RFC 5782 standardizes it
The DNSBL mechanism itself - reversed-octet DNS queries, 127.0.0.0/8 result codes - is documented as an IETF standard, which is how every checking tool queries every list today.
How a DNSBL works (it is just DNS)
A blocklist is an ordinary DNS zone. To check an address, you reverse its four octets and prepend them to the list's zone: checking 1.2.3.4 against zen.spamhaus.org is a DNS query for 4.3.2.1.zen.spamhaus.org. If the name resolves, the IP is listed - and the returned address (always inside 127.0.0.0/8) encodes the reason, such as Spam or hijacked space.
That is the whole trick: no special protocol, no API key. It is why a checker can query seven lists in parallel with ordinary DNS and why results come back in milliseconds. The same trick powers the 'check failed' state you sometimes see - one list not answering is that list's own DNS having a bad day, not your IP being clean or dirty.
A DNSBL query is an ordinary DNS lookup of the reversed IP inside the blocklist's zone; a resolved name means listed, NXDOMAIN means clean.
Why clean IPs get listed anyway
The most common story: you rent a VPS or get a new broadband address, and it is already listed - not because of anything you did, but because the previous tenant sent spam from it. IP reputation attaches to the address, not the person. Shared hosting is similar: one misbehaving neighbour on a shared address drags everyone's reputation down.
The second story is the compromised server: an unpatched web form or a weak password turns your machine into a spam relay for a few days, and the listings arrive within hours. This is why blocklist checks are useful as an early warning, not just a post-incident chore - a sudden new listing is often the first visible symptom of a compromise.
Getting delisted (and staying off)
Every list runs its own delisting process - Spamhaus uses a web form and typically responds within hours to a well-founded request, while automated lists like UCEPROTECT delist on a timer that you cannot rush. What is universal: the listing page tells you the reason, and delisting without fixing that reason guarantees you are back within days.
Before requesting removal, close the hole: make sure no open relay or compromised script is sending mail, verify SPF/DKIM/DMARC so your legitimate mail is authenticated, and confirm the volume you send looks like a mail server, not a spam run. Then request delisting from the specific lists your check flagged - never pay third-party 'delisting services', which is a known scam pattern.
What blocklists can and cannot tell you
A listing on a major list (Spamhaus, Barracuda) has real operational impact and deserves immediate attention. A listing on a small, rarely-used list may mean nothing at all for your deliverability - which is why a good checker reports each list separately and marks unreachable zones as inconclusive instead of folding them into 'clean'.
Treat blocklists as one signal among several: a clean result does not certify an IP, and a minor listing does not condemn one. The aggregate picture - which lists, what codes, how stable over time - is what actually informs the decision.
सार में
Check your sending IPs before there is a problem, read a listing as a symptom rather than a verdict, and fix the cause before asking for removal. The DNSBL system is blunt, but it moves fast for operators who understand it.
आपका सार्वजनिक IP पता और नेटवर्क स्थान, स्वचालित रूप से पता लगाया गया।
NetChecks खोलते ही यह स्वतः लोड हो जाता है — किसी इनपुट की आवश्यकता नहीं। नेटवर्क या VPN बदलने के बाद रीफ़्रेश बटन का उपयोग करें।
आपका ब्राउज़र
ऑल-इन-वन स्कैन
एक ही पास में एक IP या होस्टनेम पर सभी प्रासंगिक जांच चलाता है: DNS, whois, ping, traceroute, सुविज्ञात पोर्ट स्कैन (1-1024), HTTP हेडर और SSL प्रमाणपत्र।
एक डोमेन या IP पता दर्ज करें और चलाएँ ताकि DNS, whois, ping, traceroute, सामान्य पोर्ट, HTTP हेडर और SSL प्रमाणपत्र एक साथ जांचे जा सकें।
अधिकांश जांचें समानांतर में चलती हैं - आमतौर पर लगभग 30 सेकंड में पूरी हो जाती हैं, यदि लक्ष्य धीमा या अनुपलब्ध है तो अधिक समय लग सकता है।
पोर्ट स्कैन चरण तभी चलता है जब ऊपर दिया गया सहमति चेकबॉक्स चेक किया गया हो - बाकी सभी जांचें वैसे भी चलती हैं।
पिंग (Ping)
किसी होस्ट की पहुंच और विलंबता जांचने के लिए ICMP echo अनुरोध भेजें।
एक होस्टनाम या IP पता दर्ज करें और ICMP इको अनुरोध भेजकर राउंड-ट्रिप विलंबता मापने के लिए Ping दबाएँ।
अधिक जानें: पिंग (Ping)
परिभाषा
Ping किसी होस्ट को ICMP Echo Request पैकेट भेजता है और मापता है कि ICMP Echo Reply वापस आने में कितना समय लगता है। यह सबसे बुनियादी नेटवर्क कनेक्टिविटी टेस्ट है: यह सिर्फ एक सवाल का जवाब देता है, "क्या यह मशीन पहुंच योग्य है, और कितनी जल्दी?" ICMP प्रोटोकॉल (RFC 792) को 1981 में खासतौर पर IP नेटवर्क पर कंट्रोल और डायग्नोस्टिक मैसेज ले जाने के लिए डिज़ाइन किया गया था, किसी भी एप्लिकेशन ट्रैफिक से अलग - Ping इसका सबसे जाना-पहचाना और सबसे ज़्यादा उपलब्ध implementation है, जो लगभग हर ऑपरेटिंग सिस्टम और नेटवर्क डिवाइस में शुरुआत से ही मौजूद है।
यह कैसे काम करता है
हर ICMP पैकेट में एक TTL (Time To Live) फ़ील्ड होता है जो हर राउटर से गुज़रने पर एक-एक करके घटता है; अगर टारगेट तक पहुंचने से पहले यह शून्य पर पहुंच जाए, तो पैकेट ड्रॉप कर दिया जाता है और भेजने वाले को एक एरर वापस भेजा जाता है। मिलीसेकंड में मापा गया राउंड-ट्रिप टाइम (RTT) पूरे राउंड-ट्रिप में जमा हुई कुल नेटवर्क लेटेंसी दर्शाता है, न कि सिर्फ टारगेट के पास वाले आखिरी हिस्से की - यह बात अक्सर गलत समझी जाती है, क्योंकि धीमे ping नतीजों की असली वजह रास्ते में कहीं भी हो सकती है, ज़रूरी नहीं कि टेस्ट किए जा रहे सर्वर के पास ही हो। Ping आमतौर पर एक की बजाय लगातार कई पैकेट भेजता है, जिससे एक बार की लेटेंसी स्पाइक और बार-बार होने वाली समस्या के बीच फर्क किया जा सकता है, और उस सैंपल पर पैकेट लॉस रेट भी निकाला जा सकता है।
नतीजों को समझें
एक स्थिर, कम RTT - लोकल नेटवर्क पर कुछ मिलीसेकंड, एक ही देश के भीतर किसी डेस्टिनेशन के लिए 10 से 50 मिलीसेकंड, और इंटरकॉन्टिनेंटल लिंक के लिए काफी ज़्यादा - एक स्वस्थ कनेक्शन दिखाता है। थोड़ा सा भी पैकेट लॉस (1-2% से ऊपर) VoIP या इंटरैक्टिव रिमोट सेशन जैसे लेटेंसी-सेंसिटिव इस्तेमाल के लिए खासतौर पर नुकसानदेह होता है, जहां हर ड्रॉप हुआ पैकेट किसी गड़बड़ी या सुनाई देने वाले कट के रूप में सामने आता है। एक पैकेट से दूसरे पैकेट के बीच बहुत ज़्यादा बदलती लेटेंसी (jitter) अक्सर इन्हीं इस्तेमालों के लिए ऊंची लेकिन बिल्कुल स्थिर लेटेंसी से भी बड़ी समस्या होती है। "Request timed out" का मतलब है कि तय समय में कोई जवाब नहीं आया - हो सकता है होस्ट सच में डाउन हो, फायरवॉल चुपचाप ICMP ब्लॉक कर रहा हो, या रास्ते में कहीं कोई रूट टूटा हो; "Destination unreachable" इससे अलग और ज़्यादा जानकारी देने वाला है: इसका मतलब है कि रास्ते के बीच के किसी राउटर ने साफ तौर पर बता दिया कि वह पैकेट को आगे नहीं भेज सका, जिससे समस्या की जगह पहचानने में मदद मिलती है।
आम गलतियां
सबसे आम गलतफहमी यह है कि ping फेल होते ही होस्ट को "डाउन" मान लिया जाए, जबकि बहुत से सर्वर और डिवाइस - खासकर सख्त फायरवॉल के पीछे या बड़े क्लाउड प्रोवाइडर्स के यहां होस्ट किए गए - जानबूझकर नीति के तहत इनबाउंड ICMP ब्लॉक करते हैं, जबकि उनकी असली सेवाएं (HTTP, डेटाबेस, वगैरह) पूरी तरह काम कर रही होती हैं और पहुंच योग्य होती हैं। इसलिए ping का जवाब न मिलना सिर्फ तभी डाउनटाइम का सबूत माना जा सकता है जब इसे दूसरे संकेतों के साथ मिलाकर देखा जाए, जैसे कि एप्लिकेशन का खुद भी जवाब न देना। इसके उलट, ping सफल होना इस बात की कोई गारंटी नहीं देता कि उस मशीन पर चल रही एप्लिकेशन सर्विस सही से काम कर रही है - ये नेटवर्क स्टैक की दो बिल्कुल अलग परतें हैं।
कब उपयोग करें
किसी टिकट को आगे बढ़ाने से पहले सबसे पहले जांचने वाली बात: गहराई में जाने से पहले क्या मशीन बिल्कुल भी जवाब दे रही है? फायरवॉल रूल या रूटिंग टेबल में बदलाव के बाद कनेक्टिविटी की पुष्टि करना, ताकि यह तय हो सके कि बदलाव से एक्सेस टूटा नहीं है। VoIP रोलआउट या कैरियर लिंक फेलओवर से पहले एक बेसलाइन लेटेंसी माप स्थापित करना, ताकि बाद में कॉल क्वालिटी की शिकायत आने पर तुलना के लिए कोई ठोस आधार मौजूद हो। एक साथ कई क्लाइंट साइट्स पर नज़र रखने वाले MSP के लिए एक हल्की, कम ओवरहेड वाली नियमित हेल्थ चेक, लेकिन हमेशा गहरी एप्लिकेशन-लेवल मॉनिटरिंग के पूरक के तौर पर, कभी उसके विकल्प के तौर पर नहीं।
Traceroute
किसी गंतव्य होस्ट तक नेटवर्क पथ (हॉप दर हॉप) का पता लगाएं।
एक होस्टनाम या IP पता दर्ज करें और चलाएँ ताकि इस सर्वर और गंतव्य के बीच हर नेटवर्क हॉप, प्रत्येक हॉप की विलंबता के साथ, देखा जा सके।
DNS लुकअप (Nslookup)
DNS रिकॉर्ड क्वेरी करें: A, AAAA, MX, TXT, NS, CNAME, SOA, PTR, SRV, CAA।
एक डोमेन दर्ज करें, एक रिकॉर्ड प्रकार चुनें (A, AAAA, MX, TXT, NS, CNAME, SOA, PTR, SRV, या CAA), फिर खोजें।
Whois
किसी डोमेन या IP पते की पंजीकरण जानकारी देखें।
किसी डोमेन या IP पते की पंजीकरण जानकारी देखने के लिए उसे दर्ज करें — रजिस्ट्रार, स्वामी संगठन और महत्वपूर्ण तिथियाँ।
ब्लैकलिस्ट जांच
जांचें कि कोई IP पता या डोमेन सार्वजनिक स्पैम/दुरुपयोग ब्लैकलिस्ट (DNSBL) में सूचीबद्ध है या नहीं।
एक IPv4 पता या डोमेन दर्ज करें और चलाएं ताकि एक साथ 7 सार्वजनिक DNSBL/RBL ब्लैकलिस्ट जांची जा सकें - प्रत्येक को सूचीबद्ध, असूचीबद्ध या जांच विफल के रूप में दिखाया जाता है।
TCP पोर्ट स्कैन
जांचें कि किसी होस्ट या IP पर TCP पोर्ट खुले हैं: सामान्य पोर्ट, कस्टम सूची, या पूरी 1-65535 रेंज।
एक होस्ट या IP दर्ज करें, सामान्य पोर्ट, कस्टम सूची, या पूरी रेंज चुनें, फिर स्कैन करें कि कौन से TCP पोर्ट प्रतिक्रिया देते हैं।
पूर्ण रेंज स्कैन में लगभग 100 सेकंड तक लग सकते हैं। बड़े स्कैन (100 से अधिक पोर्ट, कस्टम रेंज/सूचियाँ सहित) प्रति विज़िटर प्रति मिनट 1 बार तक सीमित हैं।
खुले पोर्ट (0)
HTTP हेडर इंस्पेक्टर
किसी URL के लिए HTTP प्रतिक्रिया स्थिति और हेडर प्राप्त करें।
किसी URL की HTTP प्रतिक्रिया स्थिति कोड और सर्वर द्वारा भेजे गए सभी प्रतिक्रिया हेडर प्राप्त करने के लिए उसे दर्ज करें।
SSL / TLS प्रमाणपत्र जांचकर्ता
किसी होस्ट के TLS प्रमाणपत्र की जांच करें: जारीकर्ता, वैधता तिथियां और शेष दिन।
किसी होस्टनाम का TLS प्रमाणपत्र जांचने के लिए उसे दर्ज करें — जारीकर्ता, वैधता तिथियाँ, और समाप्ति तक शेष दिन।
Geo-IP लुकअप
किसी IP पते का भौगोलिक स्थान और नेटवर्क जानकारी देखें। अपना सार्वजनिक IP देखने के लिए खाली छोड़ें।
कोई भी IP पता दर्ज करें, या अपना खुद का पता देखने के लिए खाली छोड़ें, ताकि उसका अनुमानित स्थान और नेटवर्क/ISP जानकारी देखी जा सके।
पूरी तरह से आपके ब्राउज़र में गणना की जाती है — सर्वर को कोई डेटा नहीं भेजा जाता।
तुरंत नेटवर्क रेंज, ब्रॉडकास्ट पता, और उपयोग योग्य होस्ट संख्या की गणना करने के लिए एक IP पता और CIDR प्रीफ़िक्स (जैसे 192.168.1.0/24) दर्ज करें।
स्पीड टेस्ट
इस सर्वर के साथ बुनियादी डाउनलोड/अपलोड थ्रूपुट परीक्षण (सटीकता सर्वर के अपने कनेक्शन पर निर्भर करती है)।
इस सर्वर के विरुद्ध डाउनलोड और अपलोड गति मापने के लिए स्टार्ट दबाएँ। सटीकता इस सर्वर के अपने कनेक्शन पर निर्भर करती है।
देश कोड शब्दकोश
ISO 3166-1 alpha-2 देश कोड — पूरी तरह से आपके ब्राउज़र में खोजे जाते हैं।
ISO 3166-1 alpha-2 देश कोड की सूची खोजें या ब्राउज़ करें, जो पूरी तरह से आपके ब्राउज़र में खोजी जाती है।
देश
ISO कोड
फ़ोन डायलिंग कोड शब्दकोश
देश के अनुसार अंतरराष्ट्रीय कॉलिंग कोड — पूरी तरह से आपके ब्राउज़र में खोजे जाते हैं।
देश के अनुसार अंतरराष्ट्रीय डायलिंग कोड खोजें या ब्राउज़ करें, जो पूरी तरह से आपके ब्राउज़र में खोजे जाते हैं।
देश
डायलिंग कोड
विश्व घड़ी
वर्तमान समय देखने के लिए एक टाइम ज़ोन चुनें — ग्लोब को घुमाने के लिए खींचें।
सूची से एक समय क्षेत्र चुनें, या ग्लोब को घुमाएँ, ताकि वहाँ का वर्तमान समय देखा जा सके।
आपका समय
--:--:--
—
—
चयनित समय
--:--:--
—
—UTC±00:00
आपसे समय का अंतर—
—
ग्लोब घुमाने के लिए खींचें।
फ्रांस मोबाइल नेटवर्क स्थिति
फ्रांस में ऑपरेटर (Orange, Free, SFR, Bouygues Telecom) के अनुसार खराब या रखरखाव में मोबाइल एंटीना साइटें, Arcep के सार्वजनिक डेटा से। दिन में एक बार अपडेट होने वाला स्नैपशॉट - मिनट-दर-मिनट फीड नहीं।
फ्रांसीसी ऑपरेटर के अनुसार मोबाइल एंटीना और फाइबर आउटेज डेटा ब्राउज़ करें — किसी इनपुट की आवश्यकता नहीं, ARCEP के सार्वजनिक डेटा से स्वतः अपडेट होता है।
स्रोत: Arcep, "Sites indisponibles" डेटासेट, Licence Ouverte / Etalab 2.0 के तहत प्रकाशित - व्यावसायिक पुन:उपयोग की स्पष्ट रूप से अनुमति है, पहले इस्तेमाल किए गए IODA/CAIDA डेटा के विपरीत। Normal/Watch/Alert बैज एक अनुमानित संकेतक है (आज की गड़बड़ियों की संख्या बनाम पिछले दिनों का औसत), Arcep का आधिकारिक वर्गीकरण नहीं। स्रोत लिंक नीचे।
सबसे अधिक प्रभावित विभाग
वर्तमान में खराब या रखरखाव में साइटों की संख्या, विभाग अनुसार। फ़िल्टर के लिए ऐपर किसी ऑपरेटर पर क्लिक करें।
ऑपरेटर अनुसार फ़ाइबर (FTTH) नेटवर्क गुणवत्ता: रिपोर्ट की गई खराबी दर और कनेक्शन विफलता दर, Arcep के सार्वजनिक डेटा से। मासिक संकेतक, 6 महीने का औसत - मोबाइल सेक्शन की तरह लाइव फीड नहीं।
स्रोत: Arcep, "Qualité des réseaux en fibre optique" डेटासेट, Licence Ouverte / Etalab 2.0 के तहत प्रकाशित - व्यावसायिक पुन:उपयोग की स्पष्ट रूप से अनुमति है। स्रोत लिंक नीचे।
ऑपरेटर अनुसार (मूल कंपनी)
पिछले 6 उपलब्ध महीनों का औसत, इन्फ्रास्ट्रक्चर ऑपरेटर की मूल कंपनी अनुसार।
NetChecks केवल वैध नेटवर्क डायग्नोस्टिक्स और शैक्षणिक उद्देश्यों के लिए प्रदान किया गया है, केवल उन सिस्टम, डोमेन और IP पतों पर जिनके आप स्वामी हैं या जिन्हें परीक्षण के लिए स्पष्ट रूप से अधिकृत किया गया है।
बिना अनुमति के तीसरे पक्ष के सिस्टम के खिलाफ पोर्ट स्कैन, DNS/whois लुकअप, traceroute या अन्य जांच चलाना आपके क्षेत्राधिकार में कंप्यूटर दुरुपयोग कानूनों का उल्लंघन कर सकता है (उदाहरण के लिए अमेरिका में Computer Fraud and Abuse Act, फ्रांस में "Loi Godfrain", या समकक्ष स्थानीय कानून)। यह सुनिश्चित करना पूरी तरह से आपकी ज़िम्मेदारी है कि आपके पास यहां दर्ज किए गए किसी भी लक्ष्य का परीक्षण करने का अधिकार है।
यह साइट और इसके परिणाम "जैसे हैं वैसे" उपलब्ध कराए गए हैं, बिना किसी प्रकार की वारंटी के। इस साइट का संचालक इस साइट के उपयोग से उत्पन्न किसी भी प्रत्यक्ष, अप्रत्यक्ष या परिणामी नुकसान, कानूनी परिणाम, या दुरुपयोग के लिए कोई ज़िम्मेदारी स्वीकार नहीं करता।
दुरुपयोग रोकने के लिए अनुरोधों की दर सीमित की जाती है। इस इंस्टेंस का संचालक वैकल्पिक रूप से अनुरोध-गतिविधि लॉगिंग सक्षम कर सकता है - यदि ऐसा हो, तो प्रत्येक टूल अनुरोध (आपका आईपी पता, समय-मुह्र, उपयोग किया गया टूल, और दर्ज किया गया लक्ष्य/क्वेरी) सुरक्षा, दुरुपयोग-रोकथाम और उपयोग-विश्लेषण के उद्देश्यों के लिए डेटाबेस में दर्ज किया जा सकता है। यह डिफ़ॉल्ट रूप से अक्षम है। इस साइट का उपयोग करके आप इन शर्तों से सहमत होते हैं; यदि आप सहमत नहीं हैं, तो कृपया इस साइट का उपयोग न करें।
इस साइट का प्रोग्रामैटिक (एपीआई) उपयोग भी इन्हीं शर्तों के अधीन है, जिसमें उपरोक्त प्राधिकरण आवश्यकता भी शामिल है।
प्रतिक्रिया भेजें
समस्या बताएं, टिप्पणी करें, या नई सुविधा का सुझाव दें।
यह साइट विज्ञापन दिखाती है और यदि आप सहमत हों, तो होस्टिंग को वित्तपोषित करने में मदद के लिए विज्ञापन-भागीदार कुकीज़ का उपयोग करती है। आप मना कर सकते हैं और सभी टूल्स का विज्ञापन-मुक्त उपयोग जारी रख सकते हैं।