
IP 블랙리스트를 조회할 때 화면에 뜬 빨간색 표시 개수부터 세느라 당황할 필요는 없습니다. 그보다 훨씬 중요한 것은 '정확히 어떤 목록에 등재되었는가'를 파악하는 것입니다. Spamhaus의 SBL, XBL, PBL, CSS는 각각 전혀 다른 유형의 문제를 다루기 때문입니다.
그중에서도 가장 오해하기 쉬운 항목이 바로 PBL입니다. 가정용 초고속 인터넷, 유동 IP 및 일반 엔드유저 주소가 PBL에 포함되는 것은 매우 흔한 일입니다. 이는 이메일 발송 정책 관리를 위한 것일 뿐, 해당 IP에 악의적인 행위 이력이 있다고 단정할 근거가 되지 않습니다. 조회 결과를 확인했다면 먼저 목록의 이름과 용도를 명확히 파악한 뒤, 다른 평판 지표와 종합하여 계속 사용할지, 추가 점검할지, 교체할지를 결정해야 합니다.
1. IP 블랙리스트 조회 결과, 무엇부터 확인해야 할까?
MXToolbox 같은 툴은 한 번에 수많은 DNSBL/RBL을 조회하므로 보고서에 수십, 수백 개의 항목이 뜨는 것이 정상입니다. 해당 도구의 Blacklist Check 기능은 수많은 DNS 기반 이메일 블랙리스트를 일괄 점검하기 때문에 대다수의 정상 결과 사이에 소수의 이상 항목이 함께 나타나는 것은 흔한 현상입니다.
문제는 이러한 목록들이 단일화된 'IP 평판 점수 시스템'이 아니라는 점입니다. 어떤 목록은 스팸 메일 발신지를 기록하고, 어떤 목록은 해킹·감염된 기기를 추적하며, 또 어떤 목록은 단순 이메일 발송 정책을 반영합니다. 모두 똑같이 'Listed'로 표시되더라도 실제 의미는 완전히 다를 수 있습니다.
따라서 빨간색 경고가 한두 개 떴다면 구체적으로 어떤 리스트인지 확인해야 합니다. 예를 들어 같은 Spamhaus 소속이라도 다음과 같이 나뉩니다.

- · PBL Listed: 해당 IP 대역의 단순 메일 발송 정책에 따른 분류일 수 있습니다.
- · XBL Listed: 기기 해킹, 악성코드 감염, 제3자에 의한 프록시 악용 등의 정황이 감지되었음을 의미합니다.
- · SBL Listed: 스팸 발송지나 관련 네트워크로 등록된 내역이므로 상세 등재 사유(listing)를 반드시 확인해야 합니다.
단순히 빨간색 개수만으로 판단하면 서로 다른 성격의 결과를 한데 뭉뚱그려 오판하기 쉽습니다. "블랙리스트 1개는 괜찮고, 3개 이상이면 무조건 교체"와 같은 일괄적인 기준은 실무적으로 큰 의미가 없습니다.
2. Listed, Not Listed, 그리고 조회 실패의 차이점은?
Listed는 현재 IP가 해당 특정 리스트에 등재되어 있음을 나타냅니다. 이것이 구체적으로 어떤 의미인지는 리스트 자체의 용도와 기준을 함께 확인해야 합니다.
Not Listed는 조회가 정상적으로 완료되었으며 해당 리스트에 등재 내역이 없음을 의미합니다. 온라인 툴마다 UI에 표시되는 단어가 Clean, OK 등으로 다를 수 있으나 용어 자체에 얽매일 필요 없이, 핵심은 '정상 조회 후 내역 없음'과 '조회 자체가 실패함'을 명확히 구분하는 것입니다.
DNS 타임아웃, 파싱 오류, 접근 제한 등으로 인한 실패를 곧바로 Not Listed로 받아들여서는 안 됩니다. Spamhaus는 DNSBL 쿼리 방식에 명확한 기준을 두고 있어 일부 공개/오픈 리졸버(public/open resolver)를 통해 쿼리할 경우 에러 코드(예: 127.255.255.254)를 반환할 수 있습니다. 이는 조회 경로상의 문제일 뿐, 대상 IP가 블랙리스트에 올랐다는 뜻이 아닙니다. 이러한 상태 코드를 교차 검증하려면 Spamhaus DNSBL 쿼리 가이드를 직접 참조하시기 바랍니다.
Spamhaus에서 등재되지 않은 정상 IP를 쿼리하면 NXDOMAIN이 반환됩니다. 현재 자주 사용되는 주요 리턴 코드(Return Codes)는 다음과 같습니다.

- ·
127.0.0.2: SBL - ·
127.0.0.3: CSS - ·
127.0.0.4: XBL - ·
127.0.0.10 / 127.0.0.11: PBL
127.0.0.5–7은 XBL용으로 예약되어 있으나 현재는 사용되지 않습니다. 따라서 '결과 없음'이 떴을 때는 정상적인 Not Listed인지, 조회 과정 자체에 문제가 발생한 것인지 먼저 짚고 넘어가야 합니다.
3. Spamhaus의 SBL, XBL, PBL, CSS, ZEN 완벽 분석
Spamhaus는 IP 블랙리스트 조회 시 단골로 등장합니다. 약어가 비슷해 보여도 실제 초점을 맞추는 영역은 크게 다릅니다. 각 리스트를 개별 툴처럼 여길 필요는 없으며, 각각 어떤 데이터를 기록하는지 이해하는 것이 핵심입니다.
1. SBL: Spamhaus Blocklist
SBL은 Spamhaus가 식별한 스팸 발송 출처와 관련 네트워크를 기록합니다. 직접적인 스팸 발신지, 스팸 조직(spam operations) 및 이러한 활동에 연루된 인프라가 포함됩니다. 현재 Spamhaus DNSBL에서 127.0.0.2는 SBL에 해당합니다.
SBL Listed가 확인된다면 PBL처럼 단순하게 넘기지 말고 Spamhaus에서 제공하는 구체적인 등재 사유와 상세 기록을 반드시 확인해야 합니다.
2. XBL: Exploits Blocklist
XBL은 기기 및 네트워크 보안 위협에 초점을 맞춥니다. 악성코드 감염, 보안 취약점 노출, 제3자에 의한 오픈 프록시 악용, 무차별 대입(Brute-force) 공격 가담 등 침해(compromise) 징후가 있는 IPv4 및 IPv6 주소를 기록합니다.
현재 DNS 리턴 코드 중 127.0.0.4가 XBL에 해당합니다. 따라서 XBL Listed를 단순히 '스팸 IP'로 단정 지을 수는 없지만, 해당 IP에 최근 보안 위협이나 어뷰징 이력이 있었는지 면밀히 검토해 볼 필요가 있습니다.
3. PBL: Policy Blocklist
PBL은 가장 흔하게 오해받는 리스트입니다. 네트워크 및 메일 발송 정책상 원칙적으로 인터넷 메일 서버(MX)로 메일을 직접 발송해서는 안 되는 IP 대역을 기록합니다. 가정용 인터넷, 유동 IP 및 기타 엔드유저 네트워크가 정상적으로 여기에 포함될 수 있습니다.
Spamhaus는 현재 127.0.0.10(ISP 관리)과 127.0.0.11(Spamhaus 관리)을 PBL 코드로 사용합니다.
PBL이 SBL, XBL과 구별되는 가장 결정적인 차이점은 PBL에 등재되었다는 사실 자체만으로 해당 IP가 악의적인 활동을 했다고 증명할 수 없다는 점입니다.
4. CSS: Combined Spam Sources
CSS는 낮은 평판을 지닌 메일 발송 출처를 다룹니다. 무단 스팸 메일(unsolicited email), 메일링 리스트 관리 부실, 또는 계정·CMS·서버가 탈취되어 발생한 악의적인 대량 발송 행위 등이 여기에 해당합니다. 스노우슈 스팸(snowshoe spam) 및 기타 저평판 발송지도 포함됩니다.
현재 리턴 코드는 127.0.0.3입니다. CSS는 독립된 데이터 세트이지만 DNS 쿼리 레벨에서는 Spamhaus의 통합 쿼리 영역에 포함되어 있으므로 별도의 분리된 툴로 생각할 필요는 없습니다.
5. ZEN: 통합 쿼리 엔트리포인트
많은 검사 툴에서 Spamhaus ZEN이라는 이름을 바로 표기합니다. ZEN은 새로운 유형의 위험 요소가 아니라 Spamhaus가 여러 IP 기반 DNSBL(SBL, CSS, XBL, PBL 등)을 한 번에 쿼리할 수 있도록 묶어둔 통합 존(Zone)입니다.
따라서 ZEN Listed라는 결과만 보고 판단을 끝내선 안 됩니다. 실제로 SBL, CSS, XBL, PBL 중 어디에서 반환된 등재 내역인지 세부 목록을 파악해야만 결과에 실질적인 해석 가치가 생깁니다.
4. PBL Listed가 '악성 IP'를 의미하지 않는 이유는?
주거용 프록시(Residential Proxy)를 점검할 때 MXToolbox에서 Spamhaus PBL Listed가 떴다고 가정해 보겠습니다. 단순히 빨간색 표시만 보고 이 IP에 문제가 있다고 판단한다면 PBL의 본래 용도를 잘못 짚은 것입니다.

Spamhaus Policy Blocklist 공식 정의에 따르면, PBL 등재는 엔드유저의 악의적인 행위로 인해 발생하는 것이 아닙니다. 인터넷 메일 서버로 직접 메일을 보내선 안 되는 주소 대역을 정의한 것으로, ISP가 일반 초고속 인터넷이나 다이얼업 사용자에게 할당하는 대다수의 IP 대역이 자연스럽게 포함됩니다.
또한 PBL은 일반 웹 방문자의 신뢰도를 평가하는 기준이 될 수 없습니다. 즉, 주거용 프록시나 일반 웹 서핑의 평판 지표가 아닌 순수한 '이메일 발송 정책 관리용' 데이터입니다.
따라서 주거용 프록시가 다음과 같은 상태라면 안심해도 좋습니다.
- · PBL Listed 상태이지만,
- · SBL, XBL에 이상이 없고,
- · 기타 위험도 검사에서도 별다른 문제가 발견되지 않는 경우
단지 PBL에 등재되었다는 이유만으로 해당 IP를 '오염된 IP'로 분류할 필요는 전혀 없습니다.
만약 해당 프록시가 실제 주거용 네트워크가 맞는지, ISP, ASN 및 Residential 속성이 일치하는지 확인하고 싶다면 주거용 IP 순도 판별법을 참고해 점검해 보시기 바랍니다. 이는 네트워크 식별 정보에 관한 문제로, PBL과는 별개의 영역입니다.
5. MXToolbox에서 블랙리스트 경고가 떴을 때 대처법
MXToolbox의 장점은 방대한 DNSBL 결과를 한눈에 볼 수 있다는 것이지만, 반대로 정보가 너무 많다는 단점도 있습니다. 초록색 정상 결과들 사이에 빨간색 표시가 하나만 섞여 있어도 그 심각성을 과대평가하기 쉽습니다.
이런 상황에서는 다음 순서대로 차근차근 확인하면 충분합니다.
- 1. 등재가 발생한 정확한 리스트 이름 확인
- 2. 해당 리스트를 관리하는 운영 주체 파악
- 3. 리스트의 주요 기록 목적과 기준 분석
- 4. 필요 시 리스트 운영처가 제공하는 상세 내역 확인
- 5. 기타 평판 데이터와 종합하여 조치 여부 결정
블랙리스트를 굳이 1티어, 2티어, 3티어로 나누어 분류할 필요는 없습니다. 실질적으로 도움 되는 것은 다음 두 가지입니다. '해당 리스트가 무엇을 기록하는가', 그리고 '내 현재 사용 목적과 직접적인 연관이 있는가'입니다.
공개 DNSBL의 가장 대표적인 활용 분야는 여전히 이메일 필터링이며, 특히 PBL은 SMTP 사용에 특화된 명확한 기준을 가집니다. 따라서 DNSBL 결과를 일반 웹사이트, SNS, 이커머스 플랫폼의 자체 리스크 관리 등급으로 일대일 매칭하여 환산하는 것은 적절하지 않습니다.
결론적으로 MXToolbox에 빨간 불이 하나 떴다고 해서 바로 못 쓰는 IP인 것은 아닙니다. 그렇다고 특정 리스트를 무조건 무시해도 된다는 뜻은 아닙니다. 빨간색 표시 개수만 세기보다는 리스트의 용도를 살피고 독립적인 위험 신호가 더 있는지 종합적으로 확인하는 것이 훨씬 신뢰할 수 있는 방법입니다.
Spamhaus 결과가 제대로 반환되지 않았더라도 곧바로 복잡한 커맨드라인 디버깅으로 넘어갈 필요는 없습니다. DNS에 익숙한 고급 사용자라면 Spamhaus ZEN 쿼리 포맷에 맞춰 추가 검증을 진행할 수 있지만, 일반 사용자라면 조회가 정상 완료되었는지, 유효한 등재 내역인지만 확인하면 충분합니다.
6. 블랙리스트 결과가 서로 충돌할 때 해석하는 법
데이터베이스마다 결과가 다르게 나오는 것은 매우 흔한 일입니다. 애초에 동일한 대상을 동일한 기준으로 측정하는 것이 아니기 때문입니다.
| 조회 결과 조합 | 실제 의미 | 다음 단계 권장 조치 |
|---|---|---|
| 주요 공개 리스트 모두 Not Listed | 현재 조회된 DNSBL에 등재 내역 없음 | 기타 지표에도 이상이 없다면 유지 및 모니터링 |
| PBL만 Listed | 메일 발송 정책 속성일 가능성이 높으며 악의적 이력 증거 아님 | PBL 단독 등재 확인 시, 비이메일 업무 환경에서는 제외할 필요 없음 |
| SBL, XBL 또는 CSS Listed | 스팸, 기기 침해(해킹/감염) 또는 발송 평판 관련 위험 신호 감지 | Spamhaus 상세 사유 확인 및 독립적 보안 지표와 교차 검증 |
| 용도가 명확한 복수의 리스트에 동시 Listed | 서로 다른 데이터 소스에서 동시다발적 이상 징후 포착 | 유효성 재확인 후, 일관된 이상 징후 지속 시 우선순위 높여 교체/조치 |
| Spamhaus는 정상이지만 MXToolbox 타 리스트에 Listed | DNSBL 제공처마다 수집 데이터 및 판별 규칙 상이 | 해당 리스트의 신뢰도 및 상세 내용 확인 (Spamhaus 결과로 무조건 덮어쓰기 금지) |
| 블랙리스트는 정상이지만 Fraud Score가 높은 경우 | DNSBL 등재 내역이 없다고 해서 리스크 점수가 반드시 낮은 것은 아님 | Fraud Score 및 이상 필드 항목 추가 점검 |
| 블랙리스트는 정상이지만 AbuseIPDB에 최근 신고 이력이 있는 경우 | DNSBL과 어뷰징 신고 DB는 서로 다른 체계로 운영됨 | 신고 일시, 유형 및 최근 활동성 상세 확인 |
블랙리스트는 전부 정상이지만 사기 점수(Fraud Score)가 높게 나오는 현상은 모순이 아닙니다. DNSBL은 특정 리스트 등재 여부만을 확인하는 반면, IPQS나 Scamalytics 같은 서비스는 자체 데이터와 알고리즘 모델로 위험도를 계산하기 때문입니다. 두 결과가 반드시 일치해야 할 이유는 없습니다.
Fraud Score가 높은 이유나 Recent Abuse, Bot Status 등의 항목을 체계적으로 분석하고 싶다면 IP 사기 점수와 위험도 필드 분석법을 참고하시기 바랍니다. 블랙리스트 개수에만 얽매여 있을 필요가 없습니다.
AbuseIPDB 역시 독자적인 데이터 풀을 가집니다. Spamhaus에는 기록이 없더라도 AbuseIPDB에 최근 신고가 등록되어 있을 수 있습니다. 신고 일시, 빈도, 구체적 유형은 해당 사이트의 상세 페이지를 통해 독립적으로 확인하는 것이 좋습니다.
7. 언제 유지하고, 언제 재검증하며, 언제 교체해야 할까?
Listed 표시를 보았다면 먼저 어떤 리스트인지, 사유가 무엇인지 명확히 짚고 다음 단계를 진행해야 합니다.
PBL만 등재되어 있고 해당 IP를 직접 메일 발송 용도로 쓰는 것이 아니라면, 단지 이 항목 하나 때문에 악성 이력이 있는 IP로 취급해 폐기할 필요는 없습니다.
만약 SBL, XBL, CSS에 등재되었거나 현재 운영 중인 비즈니스와 직접 관련된 리스트라면 상세 내역을 꼼꼼히 확인해야 합니다. 자체 서버를 직접 운영하는 경우 계정 유출, 악성코드 감염, 비정상 메일 발송, 프록시 서비스 어뷰징 여부 등을 점검해야 합니다. 근본적인 원인이 해결되지 않은 상태에서 리스팅 해제 요청만 진행하는 것은 밑 빠진 독에 물 붓기입니다.
프록시 IP 환경은 상황이 조금 다릅니다. 사용자가 해당 IP의 과거 이력까지 통제하기는 어렵기 때문입니다.
서로 독립된 여러 데이터베이스에서 일관되게 이상 징후가 나타나고 여분의 프록시가 있다면, 굳이 문제 있는 IP 하나를 붙잡고 씨름하기보다는 깔끔하게 새 IP로 교체하여 재검증하는 편이 훨씬 효율적입니다.
반대로 주요 리스트에 이상이 없거나 단독 등재 사유가 명확히 설명되는 경우(예: PBL만 등재), 그리고 다른 리스크 지표가 양호하다면 빨간색 표시 하나만 보고 섣불리 버릴 필요가 없습니다.
단순한 블랙리스트 조회를 넘어 '이 프록시의 전반적인 품질과 순도'를 제대로 파악하고 싶다면 프록시 IP 순도 완벽 검증 가이드를 통해 실제 아웃바운드, IP 유형, ASN, Fraud Score, 블랙리스트, 어뷰징 기록, WebRTC, DNS, IPv6 누수를 통합적으로 점검해 보시기 바랍니다.
프록시 IP가 네트워크 출구 문제를 해결한다면, 안티디텍트 브라우저는 브라우저 환경 및 지문(Fingerprint) 격리 문제를 해결합니다. 다계정 운영이나 멀티 비즈니스 환경 구축 시 두 솔루션은 상호보완적으로 사용되어야 합니다. 먼저 프록시 IP 품질을 검증한 뒤 각각의 프록시를 독립된 지문 브라우저 프로필에 매핑하여 여러 업무가 브라우저 상태나 네트워크 출구를 공유하지 않도록 완벽히 분리해야 합니다.
비트브라우저(BitBrowser)는 개별 브라우저 창마다 서로 다른 프록시를 지정할 수 있으며 쿠키, 로컬 스토리지 등 환경 데이터를 완벽하게 독립 보관합니다. 이를 통해 다수의 계정, 쇼핑몰 스토어, 멀티 업무 환경을 관리할 때 '어떤 프록시가 어떤 브라우저 프로필과 연결되어 있는지'를 고정할 수 있어, 추후 IP 재점검이나 계정 전환, 팀 협업 관리가 훨씬 수월해집니다. 현재 무료 브라우저 프로필 10개를 제공하므로 소규모 독립 환경부터 손쉽게 구축하여 테스트해 보실 수 있습니다.



