이 도구가 조회하는 블랙리스트
이 도구는 입력한 IPv4 주소를 아래 공개 DNSBL(DNS 기반 블랙리스트)에 병렬로 질의하고, API 키가 설정된 경우 평판 데이터베이스도 함께 확인합니다.
| 소스 | 유형 | 특징 |
|---|---|---|
| Spamhaus ZEN | DNSBL | 가장 널리 참조되는 종합 목록 |
| Barracuda | DNSBL | 발송 평판 기반 등재 |
| SpamCop | DNSBL | 스팸 신고(트랩) 기반 등재 |
| AbuseIPDB | 평판 API | 신고 점수 25% 초과 시 등재로 판정(최근 90일 기준) |
DNSBL 조회는 IP의 옥텟을 역순으로 뒤집어 각 목록의 존 뒤에 붙인 이름을 DNS로 질의하는 표준 방식으로 동작합니다. 응답이 있으면 등재, 없으면 정상으로 판정합니다. AbuseIPDB는 사용자 신고를 집계한 신뢰도 점수를 제공하며, 이 도구는 점수가 25%를 넘을 때 등재로 표시합니다.
등재되는 대표 사유
RBL에 오르는 원인은 대부분 아래 중 하나입니다.
- 감염·봇넷: 서버나 PC가 악성코드에 감염돼 스팸·공격 트래픽을 자동 발송.
- 오픈 릴레이/오픈 프록시: 인증 없이 외부 메일을 중계하도록 잘못 설정된 서버.
- 스팸 트랩 발송: 수신용으로만 존재하는 함정 주소로 메일을 보내 스팸 발신자로 분류.
- 과도한 발송 패턴: 짧은 시간에 대량 발송, 반송률 급증 등 정상 발신과 다른 행태.
- 동적 대역 정책 등재: 가정용 IP 대역이라는 이유로 일괄 등재.
메일 발송과의 관계
RBL 등재가 실무에서 문제가 되는 지점은 대부분 메일 도달률입니다. 수신 측 메일 서버는 발신 IP를 하나 이상의 RBL과 대조해, 등재돼 있으면 메일을 거부하거나 스팸함으로 보냅니다. 그래서 자체 메일 서버를 운영한다면 발신 IP의 RBL 상태를 주기적으로 점검하고, 다음을 함께 관리해야 합니다.
- SPF·DKIM·DMARC 정합성: DNS 레코드 조회로 인증 설정이 올바른지 확인.
- 발송량·반송률 관리: 급격한 발송 증가와 높은 반송률은 신규 등재를 부릅니다.
- PTR(역방향 DNS) 정합: 발신 IP의 역방향 이름이 정방향과 일치하는지 확인.
해제 절차 개요
등재를 확인했다면 다음 순서로 대응합니다.
- 등재 소스 확인: 이 도구 결과에서 어떤 RBL에 올랐는지 파악합니다.
- 사유 확인: 해당 RBL 사이트에서 IP를 검색해 구체적 등재 이유를 확인합니다.
- 원인 제거: 감염 정리, 릴레이 차단, 발송 정책 교정 등 근본 원인을 먼저 해결합니다.
- 해제 요청: RBL 사업자의 delisting 창구에 해제를 신청합니다. 일부는 원인만 사라지면 자동 만료됩니다.
원인을 제거하지 않고 해제만 반복하면 즉시 재등재되므로, 반드시 근본 원인 제거가 우선입니다. 무료 한도가 있는 소스는 응답이 누락될 수 있어 결과에 ‘일부 소스 확인 불가’가 표시될 수 있으며, 이때는 확인된 소스만으로 판단하세요. 해제 신청 후에는 보통 몇 시간에서 며칠 사이에 목록에서 빠지므로, 신청 직후보다는 하루 이상 지난 뒤 이 도구로 재조회해 실제 반영 여부를 확인하는 것이 합리적입니다.
RBL마다 성격이 다르다
같은 “블랙리스트”라도 등재 기준과 영향력이 제각각입니다. 이 도구가 참조하는 소스의 성격을 이해하면 결과를 더 정확히 해석할 수 있습니다.
- Spamhaus ZEN: 여러 목록을 통합한 종합 리스트로, 수신 서버 채택률이 매우 높습니다. 여기에 오르면 실제 차단 영향이 가장 큽니다.
- Barracuda: 발송 IP의 평판을 종합해 판단합니다. 평판 점수가 낮으면 등재됩니다.
- SpamCop: 스팸 트랩과 사용자 신고를 근거로 하며, 신고가 멈추면 비교적 빠르게 자동 만료되는 편입니다.
- AbuseIPDB: 사용자 신고를 집계한 신뢰도 점수를 제공합니다. 이 도구는 점수가 25%를 넘을 때만 등재로 표시하므로, 낮은 점수의 소수 신고는 등재로 잡지 않습니다.
따라서 “하나에만 올랐다”와 “Spamhaus에 올랐다”는 실무적 무게가 다릅니다. 어느 소스에 올랐는지에 따라 대응 우선순위를 정하세요.
등재를 예방하는 발송 위생
메일 서버를 운영한다면 등재를 사후에 푸는 것보다 애초에 오르지 않게 관리하는 편이 훨씬 효율적입니다. 핵심 수칙은 다음과 같습니다.
- 인증 삼종 세트 게시: SPF·DKIM·DMARC를 모두 올바르게 설정합니다. DNS 조회 도구로 실제 게시 상태를 정기 점검하세요.
- 역방향 DNS(PTR) 정합: 발신 IP의 PTR이 정방향 이름과 일치하도록 설정합니다.
- 발송량 점진 증가(워밍업): 신규 IP로 갑자기 대량 발송하면 스팸으로 오인됩니다. 발송량을 서서히 늘립니다.
- 반송·불만 관리: 존재하지 않는 주소로의 발송과 스팸 신고율을 낮게 유지합니다. 수신 거부 요청은 즉시 반영합니다.
- 감염·릴레이 차단: 서버가 오픈 릴레이가 되지 않도록 인증을 강제하고, 정기적으로 악성코드 감염 여부를 점검합니다.
이 도구로 발송 IP를 주기적으로 조회해 두면, 등재를 조기에 발견해 도달률 급락 전에 대응할 수 있습니다. 특히 대량 메일을 보내기 직전과 직후에 상태를 확인하는 습관이 도움이 됩니다.
결과를 해석할 때 주의할 점
블랙리스트 조회 결과는 “이 순간, 이 소스 기준”의 스냅샷이라는 점을 기억해야 합니다. RBL은 실시간으로 등재·해제가 반복되므로, 몇 시간 전 정상이던 IP가 지금 등재돼 있을 수 있고 그 반대도 가능합니다. 또한 이 도구는 동일 IP 결과를 일정 시간 캐시하므로, 방금 해제 신청을 마쳤다면 캐시가 만료된 뒤 다시 조회해야 최신 상태가 반영됩니다. ‘일부 소스 확인 불가’ 안내가 뜬 경우, 그 소스가 정상이라는 뜻이 아니라 단지 확인하지 못했다는 의미이므로 확인된 소스만으로 신중히 판단해야 합니다. 등재 여부가 중요한 발송 인프라라면, 단발성 조회보다 정기 점검으로 추세를 관리하는 편이 훨씬 안정적입니다. 조회는 IPv4 주소를 기준으로 동작하므로, 메일 서버가 여러 발신 IP를 쓴다면 각 IP를 개별적으로 점검해야 전체 도달률을 온전히 관리할 수 있습니다.
자주 묻는 질문
제 메일 서버 IP가 등재됐습니다. 어떻게 해제하나요?
등재한 RBL 사업자마다 별도의 해제(delisting) 신청 창구가 있습니다. 해당 RBL 사이트에서 IP를 검색해 등재 사유를 확인하고, 원인(감염·오픈릴레이·과도한 발송 등)을 먼저 제거한 뒤 해제를 요청해야 합니다. 원인을 그대로 두고 해제만 반복하면 재등재됩니다.
여러 RBL 중 하나만 등재됐는데도 메일이 안 갑니다. 왜인가요?
많은 수신 서버가 Spamhaus처럼 영향력 큰 RBL 한 곳만 참조해도 차단하도록 설정돼 있기 때문입니다. RBL마다 수신 측 채택률이 다르므로, 어느 목록에 올랐는지에 따라 실제 차단 범위가 크게 달라집니다.
동적(가정용) IP는 왜 자주 등재되나요?
일부 RBL은 통신사가 가정용으로 배정한 동적 대역 전체를 정책적으로 등재합니다. 가정용 회선은 정상적인 메일 서버를 운영하지 않는다는 전제이기 때문입니다. 자체 메일 발송은 고정 IP나 인증된 발송 서비스를 쓰는 것이 정석입니다.
일부 소스를 확인할 수 없다는 안내는 무엇인가요?
AbuseIPDB 같은 소스는 무료 사용량 한도가 있어 요청이 많으면 일시적으로 응답하지 않을 수 있습니다. 이때 결과에 '일부 소스 확인 불가'로 표시되며, 나머지 확인된 소스 기준으로만 판단해야 합니다.
조회 횟수 제한이 있나요?
블랙리스트 조회 API는 요청 출발지 기준 분당 10회로 제한됩니다. 동일 IP 결과는 일정 시간 캐시되어 반복 조회 시 즉시 응답합니다.