DNSBL(RBL)이란? DNS 블랙리스트의 작동 원리

게시일 2026-11-03 ／ 업데이트 2026-11-03 ／ 작성 Yuki Nakazawa

DNSBL(DNS 기반 블랙리스트. DNS 차단 목록 또는 RBL이라고도 함)은 리스트 운영자가 스팸이나 남용의 출처로 판단한 IP 주소나 도메인 이름의 목록으로, 누구나 일반적인 DNS 조회로 확인할 수 있도록 공개되어 있습니다. 메일 서버는 접속해 오는 각 발신자를 하나 이상의 DNSBL에서 조회한 뒤, 메시지를 거부하거나 수락하거나 결과를 스팸 점수에 반영합니다.

이 가이드에서는 DNSBL 조회의 작동 방식(IP 주소 역순 표기, A 레코드와 TXT 레코드, IPv6 니블 형식), IP 기반 리스트와 도메인 기반 리스트의 차이, 수신 측이 응답을 실제로 활용하는 방법, 블랙리스트와 화이트리스트의 차이, 주소가 등재되는 이유, 그리고 이메일이 전달되지 않을 때 등재가 어떤 위치를 차지하는지를 설명합니다. 이 내용은 2026년 11월 기준 RFC 5782와 주요 리스트 운영자의 공식 문서를 바탕으로 합니다.

도메인이나 IP 주소가 약 345개 블랙리스트 중 어디에 등재되어 있는지 무료로 확인할 수 있습니다.

DNSBL과 RBL의 의미

RFC 5782 "DNS Blacklists and Whitelists"는 리스트에 오른 호스트를 레코드로 식별하는 DNS 존을 가리키는 포괄적인 용어로 DNSxL을 사용합니다. 블랙리스트는 DNSBL, 화이트리스트는 DNSWL입니다. 둘은 같은 방식으로 구성되며, 일치했을 때 수신 측이 부여하는 의미만 다릅니다.

RBL은 Real-time Blackhole List의 약자입니다. RFC에 따르면 이런 종류의 첫 리스트는 1997년에 시작되어 이 이름으로 알려졌습니다. 엄밀히 말해 RBL은 그 원조 리스트와 그 후속 리스트를 가리키며, RFC는 이 용어가 미국에서 등록된 서비스 마크라고 언급합니다. 하지만 일상적으로는 'RBL'과 'DNSBL'이 거의 같은 뜻으로 쓰이므로, 'RBL이란 무엇인가'와 'DNSBL이란 무엇인가'는 사실상 같은 질문입니다.

RFC 5782는 인터넷 표준이 아니라 정보성(Informational) 문서입니다. IRTF Anti-Spam Research Group이 작성했으며, DNS 블랙리스트와 화이트리스트 간의 상호 운용성을 높이는 관행에 대한 이 그룹의 합의를 담고 있습니다. 주소를 추가하거나 제거하는 정책은 설명하거나 권고하지 않으며, RFC는 이를 별도 문서에서 다룰 것으로 예상합니다. 실제로는 운영자마다 자체 등재·해제 정책을 정합니다.

DNSBL 조회의 작동 방식

DNSBL 조회는 일반적인 DNS 쿼리이므로, 수동으로 확인할 때는 특별한 소프트웨어가 필요 없습니다. 이름을 해석할 수 있는 것이라면 무엇이든 리스트를 조회할 수 있습니다. 다만 리스트 운영자가 이용 조건을 정할 수 있습니다. 예를 들어 Spamhaus의 공개 서버는 소량의 비상업적 이용에 한해 무료이며, 공개 리졸버를 통한 쿼리에는 안정적으로 응답하지 않습니다(아래 참조).

IPv4: 주소를 뒤집고 존을 붙인다

IPv4 주소는 네 개의 옥텟을 역순으로 적고 리스트의 존 이름을 붙입니다. 이 구조는 역방향 DNS에서 빌려 온 것입니다. RFC 5782의 예에서는 bad.example.com 리스트에 대해 192.0.2.99를 확인하기 위해 다음 이름을 조회합니다.

99.2.0.192.bad.example.com

A 레코드는 '등재됨'을, TXT 레코드는 그 이유를 알려 준다

A 레코드. 등재된 모든 항목에는 A 레코드가 있어야 합니다. 관례상 값은 127.0.0.2입니다. 이 값은 주소가 아니라 신호이므로 주소로 사용해서는 안 됩니다. 리스트가 127.0.0.0/8 범위를 쓰는 이유는 실수로 이 값이 사용되더라도 원치 않는 네트워크 트래픽이 생기지 않도록 하기 위해서입니다.
등재되지 않은 경우. 주소가 리스트에 없으면 해당 레코드가 없으므로, 쿼리는 보통 NXDOMAIN을 반환합니다.
TXT 레코드. DNSBL은 등재 이유를 설명하는 TXT 레코드를 공개하는 것이 바람직합니다. 클라이언트는 A 레코드를 확인해야 하며, TXT 레코드도 확인할 수 있습니다.
하위 리스트별로 다른 값. 통합 리스트는 어느 하위 리스트에 해당하는지 보여 주기 위해 서로 다른 127.0.0.x 값을 반환하거나, 여러 A 레코드를 한꺼번에 반환할 수 있습니다. 의미는 리스트마다 다르므로 항상 운영자의 문서를 읽으십시오. 흔히 볼 수 있는 값은 DNSBL 응답 코드 가이드에서 다룹니다.

터미널에서는 다음과 같이 조회합니다(여기서 존은 자리표시자입니다).

dig +short 99.2.0.192.bad.example.com A
dig +short 99.2.0.192.bad.example.com TXT

테스트 항목

RFC 5782는 IPv4 리스트에 127.0.0.2 항목을 포함하고 127.0.0.1 항목은 포함하지 않도록 요구합니다. 클라이언트는 존을 신뢰하기 전에 이 테스트 항목을 확인하고, 잘못 응답하는 존은 사용하지 않아야 합니다.

IPv6: 니블 형식

IPv6 주소는 32자리 십육진수로 생략 없이 모두 적은 다음, 한 자리(니블 하나)씩 역순으로 뒤집어 각 자리 사이에 점을 넣고 리스트의 존을 붙입니다. RFC의 예로, ugly.example.com 리스트에서 2001:db8:1:2:3:4:567:89ab를 조회하는 경우는 다음과 같습니다.

b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ugly.example.com

IPv6 리스트에는 테스트 항목 ::FFFF:7F00:2(IPv4 매핑 주소로 표현한 127.0.0.2)가 있어야 하며, ::FFFF:7F00:1은 없어야 합니다. 모든 리스트가 IPv6를 지원하는 것은 아니므로, IPv6 조회에 의존하기 전에 운영자의 문서를 확인하십시오.

IP 기반 리스트와 도메인 기반 리스트

리스트는 담고 있는 내용에 따라 크게 두 종류로 나뉩니다.

유형	조회하는 이름	수신 측이 주로 확인하는 대상
IP 기반	역순 IP 주소 + 존	접속한 서버의 IP, Received 헤더 필드에 있는 IP
도메인 기반(RHSBL)	도메인 이름 + 존	HELO 이름, MAIL FROM 도메인, 메시지 본문 링크의 도메인

RFC 5782의 도메인 예에서는 invalid.edu 도메인을 doms.example.net 리스트에서 확인하며, 조회하는 이름은 invalid.edu.doms.example.net 형태가 됩니다. 도메인 기반 리스트는 RHSBL(right-hand-side blacklist)이라고 불리기도 합니다. 테스트 항목에는 예약된 이름을 사용합니다. 리스트에는 TEST가 있어야 하며 INVALID는 없어야 합니다.

Spamhaus Domain Blocklist(dbl.spamhaus.org)는 널리 쓰이는 예이며, 그 문서에는 실무상 알아 둘 점이 몇 가지 있습니다.

도메인 전용입니다. IP 주소로 조회하면 항상 '등재됨' 코드가 반환되므로, 일반적인 IP DNSBL로 설정해서는 안 됩니다. Spamhaus는 IP 조회에 ZEN(zen.spamhaus.org)을 권장합니다.
전체 호스트 이름으로 조회할 수 있으며, 그 호스트의 도메인이 등재되어 있으면 일치합니다.
SMTP 세션 중에는 HELO 문자열과 MAIL FROM 도메인을 대상으로 확인합니다. 메시지가 수락된 뒤에는 URL이나 연락처 주소처럼 헤더와 본문에 있는 도메인을 대상으로 확인합니다.

실무상의 결론은 이렇습니다. 발신 IP가 깨끗하다고 전달이 보장되지는 않습니다. 발신 도메인이나 메시지에 링크된 도메인이 등재되어 있으면 여전히 차단될 수 있습니다.

수신 서버가 DNSBL을 사용하는 방식

RFC 5782는 일반적인 구성을 다음과 같이 설명합니다. 메일 서버는 들어오는 모든 SMTP 연결에 대해 설정된 DNSxL 목록을 확인합니다. 블랙리스트에 일치하면 연결을 거부하고, 화이트리스트에 일치하면 수락합니다. 또는 그 결과를 다른 신호와 함께 평가하는 점수 함수에 반영합니다. 메시지를 받은 뒤에 실행되는 필터는 보통 Received 헤더 필드나 본문의 URI에서 확인할 IP를 추출합니다.

거부할 것인가, 점수를 매길 것인가

그 선택은 수신 측의 몫입니다. SpamCop은 자체 FAQ에서 자신의 리스트를 공격적인 도구라고 부르며, 메일을 곧바로 거부하기보다 스팸 의심 메일에 태그를 붙이거나 따로 분류하거나, 점수의 한 요소로 사용할 것을 권장합니다. 거부 설정은 더 세밀한 방법을 쓸 수 없는 관리자를 위한 정보라고 설명합니다.

수신 측이 주의해야 할 함정

판단을 위임하는 것입니다. DNSxL을 사용하면 서버 관리의 일부를 리스트 운영자에게 넘기게 됩니다. RFC는 리스트의 정책이 자신의 정책과 맞는지 확인해야 한다고 말합니다.
운영이 중단된 리스트. 리스트를 종료하는 운영자가 모든 주소를 등재하는 와일드카드를 설정할 수도 있습니다. 앞에서 설명한 테스트 항목은 클라이언트가 이를 알아차리기 위한 장치입니다.
캐싱. 서버는 결과를 캐시할 수 있지만 TTL을 지키고 만료된 레코드는 폐기해야 합니다.
공개 리졸버. Spamhaus FAQ에 따르면 Google Public DNS를 통한 쿼리는 대부분의 경우 '등재되지 않음'을 반환하므로 실제 등재를 놓치게 됩니다. 127.255.255.x 형식의 코드는 오류이며(예: 차단된 공개 리졸버를 통한 쿼리에는 127.255.255.254), '등재됨'으로 해석해서는 안 됩니다. Spamhaus는 이 때문에 일부 서버가 실수로 모든 메일을 거부하고 있다고 지적하며, 자체 리졸버를 운영할 것을 권장합니다.

두 검사 도구가 같은 주소에 대해 다른 결과를 내는 이유 중 하나도 이것입니다. 서로 다른 리졸버를 통해 조회하고 있을 수 있기 때문입니다.

블랙리스트와 화이트리스트(DNSBL과 DNSWL)

DNSBL과 DNSWL은 조회 방식은 같지만, 일치의 의미는 정반대입니다. RFC 5782에 따르면 네트워크 관리자는 보통 DNSBL로 트래픽을 차단하고 DNSWL로 트래픽을 우선 수락합니다. 같은 리스트가 어떤 상황에서는 블랙리스트로, 다른 상황에서는 화이트리스트로 쓰일 수도 있습니다.

항목	DNSBL(블랙리스트)	DNSWL(화이트리스트)
목적	거부 또는 감점	수락 또는 가점
TXT 레코드	등재 이유를 설명하는 것이 바람직함	SMTP로는 클라이언트에게 수락 이유를 알릴 수 없어 덜 유용함(그래도 공개하는 리스트도 있음)
A 레코드 값	등재 여부와 해당 하위 리스트	평판 점수나 신뢰도 점수를 담을 수 있음

dnswl.org(list.dnswl.org)는 화이트리스트의 한 예입니다. 문서에 따르면 응답은 127.0.x.y 형식이며, x는 카테고리, y는 0(없음)부터 3(높음)까지의 신뢰 수준입니다. 등재된 호스트에는 그레이리스팅과 블랙리스트 검사를 건너뛰게 하고, 신뢰 수준이 중간·높음인 호스트에는 스팸 필터링을 건너뛰게 하되, 바이러스 검사는 절대 건너뛰지 말 것을 제안합니다. 화이트리스트 항목으로 무엇을 얼마나 면제할지는 여전히 수신 측이 결정합니다.

IP나 도메인이 등재되는 흔한 이유

운영자마다 자체 기준을 정하며, 정확한 등재 조건을 공개하지 않는 곳도 많습니다. 아래 이유는 운영자가 공개한 문서에 근거합니다.

스팸 신고와 스팸트랩. SpamCop Blocking List에는 SpamCop 사용자가 신고한 메일을 보낸 IP가 들어가며, 스팸트랩(스패머가 수집했거나 만들어 낸 주소)으로 보낸 메일에는 가중치가 더해집니다. FAQ에 따르면 추가 신고가 없으면 등재는 24시간만 유지되며, 신고가 멈추면 주소는 자동으로 제거됩니다.
감염되거나 침해된 기기. Spamhaus XBL은 악성코드, 다른 사람의 트래픽을 기기를 통해 중계하는 '무료 VPN' 앱, 무차별 대입 공격 참여, 탈취한 자격 증명을 이용한 메일 중계 시도 등의 증거를 바탕으로 IP를 자동 등재합니다. 원인이 남아 있으면 다음에 접속할 때 IP가 다시 등재됩니다.
잘못된 설정과 부실한 리스트 관리. Spamhaus CSS는 정방향 DNS와 일치하지 않는 HELO 이름, 침해된 웹사이트와 CMS 설치본, 안전하지 않은 구성, 관리가 부실한 메일링 리스트를 이유로 듭니다. 해제 전에 원인을 파악하고 바로잡아야 한다고 명시합니다.
정책에 따른 등재. Spamhaus PBL은 메일을 직접 보내서는 안 되는 주소 공간(주로 가정용 광대역 회선)을 다룹니다. Spamhaus는 PBL 등재가 최종 사용자의 어떤 행위 때문이 아니며, 이런 대역에서 나가는 메일은 인증된 SMTP 서버를 거쳐 발송되어야 한다고 설명합니다.
공유 인프라. 공유 호스팅에서는 다른 고객의 발송이 내가 쓰는 IP에 영향을 줄 수 있습니다. 공유 호스팅 IP가 블랙리스트에 올랐을 때의 대처법을 참고하십시오.

메일이 전달되지 않을 때 DNSBL의 위치

DNSBL 등재는 메일이 전달되지 않는 여러 원인 중 하나일 뿐입니다. 잘못된 주소, 가득 찬 메일함, 수신 측 문제, 인증 누락도 반송의 원인이 될 수 있습니다. 리스트가 관련된 경우, 반송 메시지에 리스트 이름이나 조회 URL이 포함되어 있는 경우가 많습니다.

반송 메시지를 읽습니다. 응답 코드와 본문에 있는 리스트 이름이나 URL을 기록하십시오.
발신 IP와 도메인을 확인합니다. 헤더의 Received 줄을 보거나 서버 운영자에게 문의하십시오.
주요 리스트를 한 번에 확인합니다. 블랙리스트 검사 도구를 사용한 뒤, 걸린 항목은 운영자의 공식 조회 페이지에서 확인하십시오.
원인을 해결합니다. 위에서 설명한 원인을 하나씩 점검하십시오. 원인을 해결하기 전에 요청하면 대개 다시 등재되는 것으로 끝납니다.
해당 운영자의 절차를 따릅니다. 저절로 만료되는 리스트도 있고, 해제 요청을 받는 리스트도 있으며, 네트워크 소유자의 요청만 받는 리스트도 있습니다. 해제 결정은 언제나 리스트 운영자에게 있으며, 요청했다고 해서 해제가 약속되는 것은 아닙니다.

수신 측도 자체 필터링을 운영하므로, 등재가 끝나는 즉시 메일이 다시 흐르지 않을 수도 있습니다. 전체 문제 해결 순서는 메일이 블랙리스트에 걸렸을 때: 반송 메시지 읽는 법을, 인증에 대해서는 SPF, DKIM, DMARC 설정을 참고하십시오. 원인을 직접 찾기 어렵다면 저희에게 도움을 요청하실 수 있습니다.

직접 처리하기 어려우신 경우

블랙리스트 해제 신청 대행, 컨설팅, 자문(JPY 50,000부터)을 맡아 주는 업체를 소개해 드립니다. 해제 여부는 각 리스트 운영자가 결정하므로 해제를 약속할 수는 없습니다.

상담하기

이 사이트는 소개한 업체로부터 소개 수수료를 받을 수 있습니다. About

자주 묻는 질문

RBL과 DNSBL은 같은 것입니까?

실무적으로는 그렇습니다. RBL은 1997년에 시작된 원조 리스트의 이름이었고, RFC 5782는 DNSBL을 일반 용어로 사용합니다. 오늘날에는 대부분의 사람이 두 용어를 같은 뜻으로 씁니다.

조회 결과 127.0.0.2가 반환되었습니다. 무슨 뜻입니까?

RFC 5782에 설명된 관례에 따르면 127.0.0.2는 해당 주소가 등재되었다는 뜻입니다. 통합 리스트는 하위 리스트별로 다른 값을 사용하며, Spamhaus의 127.255.255.x 코드처럼 등재가 아니라 오류를 뜻하는 값도 있습니다. 정확한 의미는 운영자의 문서를 확인하십시오.

DNSBL에 오르면 모든 이메일이 반송됩니까?

반드시 그렇지는 않습니다. 어떤 리스트를 사용할지, 일치했을 때 거부할지 아니면 스팸 점수에만 반영할지는 수신 측마다 정합니다. 그래서 일부 수신자에게는 메일이 실패하고 다른 수신자에게는 여전히 도착할 수 있습니다.

IPv6 주소도 DNSBL로 확인할 수 있습니까?

RFC 5782는 전체 주소를 십육진수 한 자리씩 역순으로 뒤집는 IPv6 형식을 정의합니다. 모든 리스트가 IPv6를 지원하는 것은 아니므로, 확인하려는 리스트가 IPv6를 지원하는지 확인하십시오.

화이트리스트에 오르면 메일이 절대 필터링되지 않습니까?

아니요. 화이트리스트 항목은 수신 측이 판단에 따라 활용할 수 있는 신호입니다. 예를 들어 dnswl.org 문서는 신뢰 수준이 중간·높음인 항목에 한해서만 스팸 필터링을 건너뛰고, 바이러스 검사는 절대 건너뛰지 말 것을 제안합니다.

참고한 공식 페이지

이 글의 사실 관계는 게시 시점에 아래 공식 페이지와 대조하여 확인했습니다. 정책과 동작은 예고 없이 바뀔 수 있으므로 중요한 판단을 내리기 전에 공식 페이지를 확인하시기 바랍니다.