먼저 두 가지를 확인하세요: 어느 리스트, 어느 IP
블랙리스트 문제에 드는 시간 대부분은 엉뚱한 것을 확인하는 데 쓰입니다. 다른 무엇보다 먼저 어느 리스트에, 어느 IP 주소가 올랐는지부터 확정하세요.
어느 리스트인가. 대개 반송 메일에 적혀 있습니다. DNS 블록리스트(DNSBL, RBL이라고도 함)로 거부하는 수신 서버는 보통 SMTP 응답에 리스트 이름을 넣습니다. “blocked using zen.spamhaus.org” 같은 문구나 리스트 조회 페이지 URL입니다. 반송 메일 원문을 통째로 복사해 두세요. 가장 정확한 증거입니다.
어느 IP인가. 중요한 IP는 도메인의 A나 MX 레코드가 가리키는 주소가 아니라, 실제로 수신 서버에 접속한 주소입니다. Gmail 주소로 메일을 보낸 뒤 “원본 보기”에서 Google이 붙인 첫 Received: 헤더를 찾으세요.
Received: from mail.example.com (mail.example.com. [203.0.113.10])
by mx.google.com with ESMTPS id ...대괄호 안의 주소가 발송 IP입니다. 서버에서 직접 curl -4 -s https://ifconfig.me를 실행하면 나가는 트래픽이 실제로 쓰는 공인 주소가 나옵니다. 서버가 NAT 뒤에 있으면 서버 자신의 주소와 다릅니다.
이것이 중요한 이유는 흔한 혼동 세 가지 때문입니다.
- 수신과 발신. MX 서버는 메일을 받는 서버이고, 꼭 메일을 보내는 서버는 아닙니다. 한 호스트로 둘 다 한다면 같지만, 아니라면 MX IP를 점검해도 발신 평판에 대해서는 아무것도 알 수 없습니다.
- 공유 제공자. Google Workspace, Microsoft 365, SES나 SendGrid 같은 발송 서비스로 보낸다면 메일은 제공자의 IP로 나갑니다. 그 IP를 해제할 수도 없고 해제하라는 사람도 없습니다. 이 경우 문제는 도메인의 인증 설정과 평판입니다.
- 사무실 NAT. 사무실 전체가 공인 IP 하나를 함께 쓰는 경우가 많습니다. 감염된 노트북 한 대가 스팸을 보내거나 봇넷과 통신하면 그 공유 IP가 등재되고, 그 뒤의 메일 서버는 잘못한 것이 없어도 차단됩니다.
블랙리스트 직접 조회하기
DNSBL은 그냥 DNS 존입니다. 203.0.113.10이 등재됐는지 알려면 네 자리를 뒤집어 리스트의 존 아래 이름으로 조회합니다.
$ dig +short 10.113.0.203.bl.spamcop.net
$ dig +short 10.113.0.203.b.barracudacentral.org
127.0.0.2응답이 없으면(NXDOMAIN) 미등재입니다. 127.0.0.0/8 범위의 응답이 오면 등재이고, 리스트에 따라 마지막 자리로 사유를 구분합니다. 같은 이름으로 TXT를 조회하면 짧은 사유나 URL이 오는 경우가 많습니다.
dig +short TXT 10.113.0.203.b.barracudacentral.orgRFC 5782를 따르는 DNSBL은 모두 127.0.0.2를 영구 테스트 항목으로 등재해 둡니다. 그래서 dig +short 2.0.0.127.bl.spamcop.net은 항상 응답해야 합니다. 응답이 없으면 조회가 리스트까지 닿지 않는 것이고, 내 IP에 대한 빈 응답도 아무 의미가 없습니다.
Spamhaus는 꼭 알아 둬야 할 예외입니다. Spamhaus는 8.8.8.8이나 1.1.1.1 같은 대형 공용 리졸버를 거쳐 온 조회를 거부하고, 실제 결과 대신 127.255.255.0/24 범위의 코드로 답합니다. 127.255.255.254는 “공용 리졸버를 거친 조회”라는 뜻이지 등재가 아닙니다. 이를 처리하지 않는 점검 도구는 모든 IP를 Spamhaus 등재로 보여 줍니다. Spamhaus 자체의 IP·도메인 평판 조회(check.spamhaus.org)를 쓰거나, 자체 재귀 리졸버가 있는 서버에서 조회하세요. 조회가 제대로 통과하면 zen.spamhaus.org의 주요 응답 코드는 다음과 같습니다.
| 응답 | 리스트 | 의미 |
|---|---|---|
127.0.0.2 | SBL | Spamhaus 담당자가 확인한 스팸 발송원·스팸 조직 |
127.0.0.3 | CSS | 자동으로 탐지된 저평판 발송 |
127.0.0.4 | XBL | 감염되거나 악용된 호스트(악성코드, 프록시, 봇넷) |
127.0.0.10, 127.0.0.11 | PBL | 인터넷으로 직접 메일을 보내도록 되어 있지 않은 주소 범위 |
이메일 점검이 이 조회를 대신 해 줍니다. IP 주소를 넣으면 SpamCop, Barracuda, PSBL을 조회하고 그 IP의 역방향 DNS도 보여 줍니다. Spamhaus는 위 이유로 “확인 불가”로 나오니 따로 확인하세요. 도메인을 넣으면 그 도메인 MX 서버, 즉 수신 서버의 IP를 점검합니다. 발신 주소는 IP로 넣어 확인하세요. IP 확인은 그 페이지를 연 기기의 공인 IP와 네트워크를 보여 줍니다.
등재 사유가 원인을 알려 준다
리스트마다 등재 이유가 다르고, 그 이유가 해결 방향을 가리킵니다.
- XBL(Spamhaus): 그 IP에서 무언가가 감염됐거나 프록시로 악용되고 있습니다. 전용 메일 서버라면 서버가 침해된 것입니다. 사무실이나 가정 회선이라면 대개 메일 서버가 아니라 NAT 뒤의 PC, 휴대폰, 카메라, 공유기입니다.
- PBL(Spamhaus): 벌점이 아닙니다. ISP가 그 범위를 동적·일반 사용자 대역으로, 즉 직접 메일을 보내지 않는 대역으로 표시해 둔 것입니다. 가정용이나 유동 IP 회선에서 메일 서버를 돌린다면 ISP나 제공자의 릴레이(스마트호스트)를 거쳐 보내세요. 메일용으로 정당하게 쓰는 고정 IP라면 Spamhaus 조회 페이지에서 PBL 제외 요청 방법을 안내합니다.
- SBL·CSS(Spamhaus), SpamCop, Barracuda, PSBL: 실제로 스팸 트랩에 도착했거나 스팸으로 신고된 메일에 반응합니다. 무언가가 그 메일을 보냈습니다. 할 일은 그게 무엇인지 찾는 것입니다.
- 대역 등재: 일부 리스트는 이웃 주소의 행동을 이유로 제공자 대역이나 네트워크 전체를 등재합니다. UCEPROTECT의 레벨 2·3이 대표적입니다. 내 서버에서 할 수 있는 일은 없습니다. 호스팅 제공자에 대한 등재입니다.
- 도메인 리스트(Spamhaus DBL, SURBL, URIBL)는 IP가 아니라 메일 본문에 나오는 도메인을 등재합니다. 여기에 내 도메인이나 메일 속 링크가 올랐다면 IP를 해제해도 소용없습니다. 문제는 도메인이나 URL이고, 단축 URL이나 내 사이트의 침해된 페이지인 경우도 있습니다.
옛 체크리스트에 자주 나오는 SORBS는 2024년에 종료했습니다. 존이 더 이상 응답하지 않으므로, 아직 SORBS를 조회하는 도구는 모든 IP를 깨끗하다고 보여 줍니다.
대형 메일 서비스는 별개입니다. Gmail과 Microsoft는 공개 리스트에만 기대지 않고 자체 평판 시스템을 운영합니다. 거부 메시지에 자체 코드가 붙고, Microsoft의 거부 문구에는 자체 해제 절차 안내가 들어 있습니다. 공개 DNSBL에서 모두 깨끗하게 나와도 Gmail이나 Outlook이 나를 신뢰한다는 뜻은 아닙니다.
해제 요청 전에 무엇이 보내고 있는지 찾기
원인을 고치기 전에 해제부터 요청하는 것이 가장 흔한 실수이고, 역효과가 납니다. 발송원이 여전히 보내고 있으니 IP는 다시 등재됩니다. 흔한 원인은 다음과 같습니다.
메일 계정 비밀번호 탈취
스패머가 훔친 계정으로 로그인해 인증된 SMTP로 내 서버를 통해 보냅니다. 양만 빼면 모든 것이 정상으로 보입니다. Postfix라면 사용자별 인증 로그인 수를 세 보세요.
grep -oE 'sasl_username=[^ ,]+' /var/log/mail.log | sort | uniq -c | sort -rn | head한 계정의 로그인이 수천 건이거나 직원이 없는 나라에서 로그인했다면 그것이 답입니다. 비밀번호를 바꾸고 세션을 끊고, 지원한다면 MFA를 켜고, 보낸편지함에서 무엇이 나갔는지 확인하세요.
스크립트나 웹 폼
속도 제한이나 CAPTCHA 없는 문의 폼, 취약한 플러그인, 업로드된 PHP 웹셸은 로그인 없이 로컬 메일 시스템으로 메일을 보낼 수 있습니다. 먼저 메일 큐를 보세요.
postqueue -p | tail -n 1 # 예: "-- 2048 Kbytes in 3150 Requests."
postqueue -p | head -n 40 # 누가 보냈고 누구에게 가는가평소 몇 건뿐이던 서버의 큐가 수천 건이면 강한 신호입니다. 발신 주소와 본문 몇 개(postcat -q <QUEUE_ID>)를 확인한 뒤, 같은 시각대의 웹 서버 접근 로그에서 해당 스크립트를 찾으세요.
감염된 호스트
XBL 유형의 등재라면 메일 서버가 아닌 무언가가 원격 25번 포트로 연결하는지 보세요.
ss -tnp state established '( dport = :25 )'메일 서버에서는 MTA 프로세스만 보여야 합니다. 사무실 네트워크라면 방화벽에서 내부 호스트의 외부 25번 포트 연결을 확인하세요. 장기적인 해결은 메일 서버를 뺀 모든 호스트의 외부 25번 포트를 막는 것입니다.
오픈 릴레이
내 네트워크 밖의 장비에서, 로그인하지 않고, 내 도메인이 아닌 주소에서 내 도메인이 아닌 주소로 보내 보세요.
swaks --server mail.example.com --from test@example.net --to someone@example.org554 5.7.1 <someone@example.org>: Relay access denied 같은 거부가 정답입니다. 메일이 받아들여지면 서버가 누구에게나 중계해 주고 있는 것이고, 다른 무엇보다 이것부터 고쳐야 합니다. Postfix라면 postconf smtpd_relay_restrictions에 reject_unauth_destination이 있어야 합니다.
백스캐터(backscatter)
서버가 존재하지 않는 주소로 온 메일을 일단 받은 뒤 반송 메일을 보내면, 그 반송은 스팸에 위조된 발신 주소, 즉 나에게 메일을 보낸 적 없는 실제 사람에게 갑니다. 이것이 백스캐터이고, 이를 이유로 등재하는 리스트도 있습니다. 받은 뒤 반송하지 말고 SMTP 대화 중에 없는 수신자를 거부하세요.
내가 보낸 대량 메일
위 어디에도 해당하지 않으면 의도적으로 보낸 메일을 보세요. 구매했거나 아주 오래된 수신자 목록, 동의하지 않은 사람에게 보낸 뉴스레터, 새 IP에서 갑자기 늘어난 발송량. 스팸 트랩은 오래 방치된 주소나 한 번도 배포되지 않은 주소이고, 동의 없이 모은 목록에 섞여 들어갑니다. 고칠 것은 서버가 아니라 목록입니다.
해제 요청하기
발송원을 없애고 하루이틀 서버를 지켜보며 확인했다면, 등재된 리스트를 하나씩 찾아가세요. 무엇을 발견했고 무엇을 고쳤는지 구체적으로 적으세요.
- Spamhaus: check.spamhaus.org에서 조회하세요. 등재마다 사유를 설명하고, 직접 해제할 수 있는 경우 그 자리에서 안내합니다. XBL과 CSS는 원인이 실제로 해결돼야 해제가 유지됩니다.
- SpamCop: 그 IP에 대한 신고가 멈추면 등재가 저절로 만료됩니다. SpamCop은 대략 하루 안에 만료된다고 안내합니다. 요청할 것은 없습니다. 원인을 고치고 기다리세요.
- Barracuda: Barracuda Central에 해제 요청 양식이 있습니다. 사람이 검토하므로 무엇을 고쳤는지 함께 적으세요.
- PSBL: 웹사이트에서 IP를 조회하고 직접 해제할 수 있습니다.
- Microsoft, Gmail 등 메일 서비스: 거부 메시지에 있는 링크나 코드를 따라가세요. DNSBL이 아니고 절차도 각자의 것입니다.
원래 무료인 리스트를 돈을 받고 해제해 주겠다는 서비스는 피하세요. 대역 등재라면 요청은 리스트가 아니라 호스팅 제공자에게 해야 합니다.
다시 오르지 않게
- 발송량에 제한을 걸고 급증하면 알림을 받으세요. Postfix 기본 기능인
smtpd_client_message_rate_limit은 클라이언트 IP 단위이고, 사용자 단위 제한은 정책 서비스(policy service)가 필요합니다. - 메일 서버를 뺀 모든 호스트의 외부 25번 포트를 방화벽에서 막으세요.
- 메일을 보내는 모든 웹 폼에 속도 제한과 CAPTCHA를 거세요.
- 발송 IP에 일치하는 역방향 DNS 이름을 주고 SPF, DKIM, DMARC가 통과하도록 유지하세요. 이것으로 등재를 막을 수는 없지만, 기본이 빠져 있으면 모든 수신 서버가 덜 관대해집니다. 역방향 DNS(PTR) 설정과 이메일 전달률 가이드를 보세요.
- 사고가 있었다면 이메일 점검으로 발송 IP를 다시 확인하고, Spamhaus는 Spamhaus 사이트에서 확인하세요.
내 도메인에서 바로 확인
무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.