메일 서버 블랙리스트(DNSBL) 확인과 제거 절차

어제까지 잘 나가던 메일이 갑자기 554 5.7.1 Service unavailable; client host blocked 같은 반송(bounce)과 함께 돌아오기 시작했다면, 발송 서버의 IP가 DNSBL(DNS 블랙리스트, 스팸 블록리스트)에 등재됐을 가능성이 큽니다. Gmail·네이버·Outlook 같은 대형 수신 서버는 물론, 회사 메일 게이트웨이 대부분이 연결을 받자마자 발신 IP를 Spamhaus·Barracuda 같은 블랙리스트에 조회하고, 등재돼 있으면 본문을 보기도 전에 거절합니다. 즉 내용이 아무리 정상이어도 IP가 리스트에 있는 한 메일은 도착하지 않습니다.

이 가이드는 실제 운영 순서 그대로 4단계로 정리했습니다. ① 어떤 리스트에 올랐는지 DNSBL 조회 도구로 확인 → ② 등재 원인을 먼저 제거 → ③ 리스트별 절차에 따라 해제(delist) 요청 → ④ SPF/DKIM/DMARC와 모니터링으로 재발 방지. 특히 ②를 건너뛰고 해제부터 신청하면 며칠 안에 다시 등재되고, 재등재는 해제가 훨씬 어려워진다는 점을 꼭 기억하세요.

DNSBL이란 무엇이고 수신 서버는 어떻게 쓰나

DNSBL(DNS-based Blackhole List)은 스팸 발송 이력이 있는 IP 주소 목록을 DNS 질의로 조회할 수 있게 공개한 데이터베이스입니다. 수신 서버는 SMTP 연결이 들어오면 발신 IP의 옥텟을 뒤집어 리스트 도메인 앞에 붙인 이름을 조회합니다. 예를 들어 203.0.113.25가 Spamhaus ZEN에 올랐는지 보려면 25.113.0.203.zen.spamhaus.org의 A 레코드를 질의하고, 127.0.0.x대 응답이 오면 "등재됨"으로 판정해 메일을 거절하거나 스팸함으로 보냅니다.

등재를 의심할 만한 전형적인 증상은 다음과 같습니다.

• 반송 메일에 554 5.7.1, 550 5.7.606 등의 코드와 함께 listed at zen.spamhaus.org, Blocked using Barracuda 같은 문구가 포함됨 — 어느 리스트인지 반송문이 직접 알려주는 경우가 가장 많습니다.
• 특정 수신 도메인(예: Outlook 계열)으로만 메일이 반송되고 다른 곳은 정상 — 그 수신자가 쓰는 리스트에만 등재된 상태.
• 반송은 없는데 수신자 스팸함으로 직행 — 점수형 필터(SpamAssassin 등)가 DNSBL 등재를 감점 요소로 반영하는 경우.
• 메일 발송량이 늘지 않았는데 갑자기 발생 — 계정 탈취·웹폼 악용 등 "내가 모르는 발송"이 있었다는 신호.

STEP 1 — 어떤 리스트에 올랐는지 한 번에 확인

DNSBL은 수십 개가 운영되고 각각 등재 기준·영향력이 다르므로, 먼저 발송 IP를 주요 리스트 전체에 대해 일괄 조회해야 합니다. DNSBL 블랙리스트 조회에 발송 서버의 공인 IP를 넣으면 Spamhaus·Barracuda·SpamCop 등 주요 리스트 등재 여부를 한 번에 확인할 수 있습니다. 이때 확인할 것은 두 가지입니다.

1. 어느 리스트에 올랐나 — Spamhaus ZEN(SBL/XBL/PBL 통합)이나 Barracuda처럼 대형 수신자가 실제로 참조하는 리스트인지, 아니면 영향력이 거의 없는 군소 리스트인지에 따라 대응 우선순위가 달라집니다.
2. 어떤 코드(사유)로 올랐나 — 응답 값이 원인을 알려줍니다. 예: Spamhaus에서 127.0.0.4~7(XBL)은 악성코드·탈취 계정 발송, 127.0.0.2~3(SBL)은 스팸원 지정, 127.0.0.10~11(PBL)은 "애초에 메일을 직접 보내면 안 되는 동적/일반 IP 대역"이라는 뜻입니다.

발송 IP가 정확히 무엇인지 헷갈리면(NAT·클라우드 환경) 자신에게 테스트 메일을 보내 헤더의 마지막 Received: 줄에 찍힌 IP를 확인하는 것이 가장 확실합니다.

STEP 2 — 해제 신청 전에 원인부터 제거 (가장 중요)

블랙리스트 운영사는 "해제 → 재등재"가 반복되는 IP를 상습 발송원으로 간주해 해제를 점점 어렵게 만듭니다. 원인을 남겨둔 채 해제만 하면 스팸 트랩이 다시 메일을 받는 즉시 재등재되므로, 반드시 아래 항목을 먼저 점검하고 고쳐야 합니다.

• 계정 탈취·비밀번호 유출 — 가장 흔한 원인. 메일 로그에서 평소와 다른 시간대·국가의 인증 성공, 특정 계정의 발송량 급증을 확인하고, 해당 계정 비밀번호 재설정 + 발송 큐에 쌓인 스팸 삭제.
• 웹폼/CMS 악용 — 문의 폼, 워드프레스 wp-mail, 취약한 플러그인을 통한 발송. 웹 서버 로그에서 폼 POST 급증을 확인하고 CAPTCHA·rate limit 적용, 취약 플러그인 제거.
• 오픈 릴레이 — 인증 없이 외부→외부 중계를 허용하는 설정. Postfix라면 smtpd_relay_restrictions에 reject_unauth_destination이 있는지 확인.
• PTR(역방향 DNS) 미설정 — 발송 IP에 PTR이 없거나 HELO 이름과 불일치하면 그 자체로 감점되고 일부 리스트의 등재 사유가 됩니다. 역방향 DNS 조회로 현재 PTR을 확인하고, 없다면 호스팅/VPS 업체 콘솔에서 발송 도메인과 일치하는 호스트명 (예: mail.example.com)으로 설정하세요. PTR은 도메인 DNS가 아니라 IP 소유자(ISP/호스팅)가 관리합니다.
• 스팸 트랩 적중·오래된 리스트 발송 — 수년 묵은 주소록, 구매한 리스트에는 트랩 주소가 섞여 있습니다. 하드바운스 주소 즉시 제거, 구매 리스트 발송 중단, 더블 옵트인 도입.
• 공유 IP의 이웃 문제 — 공유 호스팅·공유 발송 IP라면 다른 고객의 스팸으로 함께 등재될 수 있습니다. 이 경우 호스팅 업체에 신고하거나 전용 IP/전문 발송 서비스로 이전이 근본 해결책입니다.

STEP 3 — 리스트별 해제(delist) 절차

원인을 제거했다면 각 리스트의 해제 페이지에서 요청합니다. 리스트마다 방식이 다릅니다 — 즉시 셀프서비스형, 일정 시간 후 자동 만료형, 그리고 "유료 즉시 해제"를 내세우는 곳도 있습니다.

실전 예시 — VPS IP가 Spamhaus XBL에 등재된 경우. 어느 날 Gmail 수신자에게서 554 5.7.1 ... listed at zen.spamhaus.org 반송이 옵니다. ① DNSBL 조회 결과 응답이 127.0.0.4— XBL, 즉 "악성코드/탈취 계정에 의한 발송"입니다. ② 메일 로그를 보니 새벽 3시에 해외 IP가 직원 계정으로 SMTP 인증에 성공해 수만 통을 발송한 기록 발견 → 해당 계정 비밀번호 즉시 변경, 발송 큐의 스팸 3만 통 삭제, 전 계정 강제 재인증 + 그 계정에 2단계 인증 적용. ③ 유출 경로였던 피싱 메일을 확인하고 조치 완료 후 Spamhaus 조회 페이지에서 XBL 해제 신청 — 몇 분 내 해제. ④ 이후 24시간 동안 발송 큐와 DNSBL 재조회로 재등재 여부를 모니터링. 만약 ②를 건너뛰고 해제만 했다면 봇이 발송을 재개하는 즉시 재등재됐을 것입니다.

STEP 4 — 재발 방지: 인증 체계와 상시 모니터링

해제는 끝이 아니라 시작입니다. 재등재를 막으려면 발송 환경 자체를 신뢰할 수 있게 만들어야 합니다.

• SPF·DKIM·DMARC 정렬 — 도메인 인증이 갖춰지면 IP 평판 의존도가 줄고, 위조 발송으로 인한 평판 훼손도 차단됩니다.
• PTR ↔ HELO ↔ 발송 도메인 일치 — 세 값이 맞아야 정상 서버로 인정받습니다.
• 발송 위생 — 하드바운스 자동 제거, 수신거부 즉시 반영, 신규 IP는 소량부터 워밍업.
• 정기 점검 — 주 1회 이상 DNSBL 재조회를 습관화하고, Google Postmaster Tools 등으로 평판 추이를 관찰.

현재 도메인의 SPF/DKIM/DMARC/PTR가 한 번에 제대로 구성돼 있는지는 이메일 전송 상태 진단으로 종합 점검할 수 있습니다. 블랙리스트 해제 직후 이 진단에서 남은 문제를 마저 정리해 두면 같은 일이 반복될 확률이 크게 줄어듭니다.