홈 › 가이드

공유 호스팅 IP 블랙리스트 등재: 직접 고칠 수 있는 것과 없는 것

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

공유 호스팅 IP가 블랙리스트에 올랐다면, 먼저 그 IP를 누가 관리하는지, 정확히 어느 리스트에 어떤 반환 코드로 올라 있는지 확인하십시오. 그런 다음 본인 쪽 문제를 정리하고, 호스팅 제공업체가 조치할 수 있도록 조회 증거를 보내십시오. 공유 IP에서는 원인이 전혀 다른 고객일 수 있으며, 일부 리스트는 네트워크 소유자만 해제를 요청할 수 있습니다.

새로 개설한 VPS나 클라우드 IP도 첫날부터 '블랙리스트에 오른' 것처럼 보일 수 있습니다. 이전 사용자의 이력 때문일 수도 있고, 그 대역이 메일을 직접 보내서는 안 되는 대역으로 등재되어 있기 때문일 수도 있습니다. 어떤 상황이든 해제 여부의 결정은 언제나 리스트 운영자에게 있습니다.

이 가이드는 2026년 11월 기준 Spamhaus, AWS, Google Cloud, Microsoft Azure의 공식 페이지를 바탕으로 합니다. 제한 사항과 절차는 바뀌므로 조치하기 전에 최신 내용을 확인하십시오. 블랙리스트 관련 반송 전반에 대해서는 블랙리스트로 메일이 차단될 때의 가이드를 참고하십시오.

먼저 어느 IP가 어느 리스트에 있는지 파악

'서버가 블랙리스트에 올랐다'는 말은 전혀 다른 상황을 뜻할 수 있으며, 해결 방법은 세부 사항에 따라 달라집니다. 무엇보다 먼저 다음 세 가지 질문에 답해 보십시오.

1. 실제로 메일을 보내는 IP는 무엇입니까? 웹사이트를 호스팅하는 IP가 반드시 이메일을 전달하는 IP인 것은 아닙니다. 반송 메시지에는 거부된 IP가 인용되어 있는 경우가 많으므로 이를 읽고, 직접 보낸 메시지의 Received 헤더도 확인해 실제 발신 주소를 확정하십시오.
2. 그 IP는 누가 관리합니까? 공유 호스팅에서는 다른 고객과 함께 쓰는 주소입니다. 전용 서버, VPS, 클라우드 인스턴스에서는 본인에게 할당된 주소지만, 주변 대역은 여전히 제공업체 소유입니다. 발신 메일이 공유 주소를 쓰는지는 호스팅 요금제나 제어판에서 알 수 있습니다.
3. 어느 리스트에 올라 있습니까? 리스트마다 의미도, 해결할 수 있는 주체도 다릅니다. 저희 블랙리스트 검사 도구로 IP를 조회하면 주요 리스트를 한 번에 확인할 수 있으니, 리스트 이름과 반환 코드를 기록해 두십시오.

이 세 가지 답을 얻으면, 직접 해결할 문제인지, 제공업체가 해결해야 할 문제인지, 아니면 메일 발송 방식 자체를 바꾸라는 신호인지가 대개 분명해집니다.

조회 결과와 반환 코드 읽는 법

Spamhaus ZEN(zen.spamhaus.org)은 Spamhaus의 통합 IP 리스트입니다. 등재된 IP를 조회하면 127.0.0.x 범위의 주소가 반환되며, 마지막 숫자로 어느 하위 리스트에 해당하는지 알 수 있습니다. 공유 호스팅과 클라우드 IP에서는 다음 코드를 구분해 두는 것이 좋습니다.

PBL 등재는 비난이 아닙니다. 이 주소에서 나가는 메일은 인증을 거쳐, 다음 단계로 중계해 주는 서버에 제출되어야 한다는 정책상의 표시입니다. Spamhaus는 ISP와 기타 네트워크에 메일을 보내지 않아야 하는 모든 대역을 등재하도록 적극 권장하며, 여기에는 웹 서버도 명시적으로 포함됩니다.

127.255.255.252, 127.255.255.254, 127.255.255.255 코드는 등재가 아니라 오류입니다. Spamhaus의 DNSBL 사용 FAQ는 Google Public DNS(8.8.8.8) 같은 무료 공개 리졸버를 쓰면 대부분의 경우 '등재되지 않음'이 반환된다고 경고하는데, 도구마다 결과가 다른 이유가 바로 이것입니다. 확신이 서지 않으면 Spamhaus 공식 평판 검사 도구에서 결과를 확인하십시오. 리스트별 전체 절차는 Spamhaus 해제 절차를 참고하십시오.

직접 고칠 수 있는 것과 없는 것

바꿀 수 있는 범위는 어떤 서비스를 이용하느냐에 따라 달라집니다.

공유 호스팅에서 자기 계정이 원인이 아닌지 확인하기

• 탈취된 메일함. 발송 로그와 보낸 편지함에서 직접 보내지 않은 메일이 한꺼번에 나간 흔적이 있는지 살펴보십시오. 발견하면 즉시 비밀번호를 변경하십시오.
• 해킹된 웹사이트. 오래된 CMS 설치본과 플러그인은 공격자가 메일 발송 스크립트를 올리는 흔한 경로입니다.
• 악용된 양식. 방문자가 자동 응답의 수신자나 본문을 정할 수 있는 문의 양식은 스팸 대량 발송 수단으로 악용될 수 있습니다.
• 수신자 목록의 품질. 구입한 목록이나 수신에 동의한 적 없는 주소로 보내면, 본인을 포함한 모든 사용자의 공유 IP를 망가뜨리기 쉽습니다.

이 중 어느 것도 해당하지 않는다면, 원인은 같은 주소를 쓰는 다른 누군가일 가능성이 높습니다. Spamhaus의 25번 포트 FAQ도 공유 IP 풀에서는 등재로 영향을 받는 사람 대부분이 감염된 기기의 주인이 아니라고 단도직입적으로 지적합니다. 이 경우 본인이 할 일은 증거를 모아 제공업체에 전달하는 것입니다.

호스팅 업체에 알리는 방법

Spamhaus는 SBL 해제 요청은 등재된 IP를 관리하는 ISP가 보내야 한다고 명시하며, 일반 사용자에게는 문제 해결을 위해 ISP와 상의하라고 안내합니다. 공유 호스팅 고객에게 그 ISP는 호스팅 업체입니다. '메일이 도착하지 않는다'고만 적은 지원 티켓은 이리저리 떠돌기 쉽습니다. 다음 내용을 담은 티켓은 대개 더 빨리 처리됩니다.

1. 발신 IP: 헤더나 반송 메시지로 확인한 주소
2. 리스트와 반환 코드: 예를 들어 zen.spamhaus.org 조회 결과 127.0.0.2 반환
3. 확인한 시각과 방법: 공식 평판 검사 도구를 사용했다면 그 결과도 포함
4. 반송 문구: 특히 수신 서버가 거부 이유를 설명하는 줄
5. 이미 배제한 원인: 비밀번호 재설정, 사이트 검사 결과 이상 없음 등
6. 요청 사항: 조사, 필요하다면 리스트 운영자에게 해제 요청, 또는 계정의 발신 메일을 다른 IP로 옮기는 것

간단한 예시:

Our outbound IP 192.0.2.10 returns 127.0.0.2 (SBL) on zen.spamhaus.org.
We confirmed this on the official Spamhaus checker at 10:00 UTC on 2026-11-03.
We have reset all mailbox passwords and found no unexpected files on our site.
Please investigate, request removal if appropriate, or advise whether our mail
can be sent from a different IP.

제공업체에도 시간이 필요할 수 있으며, 제공업체가 조치하더라도 최종 결정은 리스트 운영자가 내립니다. 기다릴 수 없는 메일이 있다면 아래에서 설명하는 릴레이 방식을 병행 대안으로 검토하십시오. 문제가 어디에 있는지 파악하기 어렵다면 저희에게 도움을 요청하실 수도 있습니다.

VPS·클라우드의 25번 포트 제한과 역방향 DNS

VPS나 클라우드 인스턴스에서 자체 메일 서버를 운영한다면, 블랙리스트와 상관없이 그 전에 다른 문제에 부딪힐 수 있습니다. 많은 제공업체가 서버 간 메일 전달에 쓰이는 아웃바운드 TCP 25번 포트를 제한합니다. AWS, Google Cloud, Microsoft Azure의 공식 문서는 다음과 같이 설명합니다.

• Amazon EC2 (AWS). 기본적으로 EC2는 아웃바운드 25번 포트 트래픽을 사설 IPv4 주소로만 허용하며, 공인 IPv4 및 IPv6 주소로 가는 트래픽은 차단됩니다. 제한 해제를 요청할 수 있습니다. 외부로 보내는 이메일의 경우 AWS는 Elastic IP 주소를 프로비저닝하고 여기에 정적 역방향 DNS 레코드를 지정할 것을 권장하며, 이렇게 하면 메일이 스팸으로 표시되는 것을 피하는 데 도움이 될 수 있다고 설명합니다. 역방향 레코드를 만들기 전에 Elastic IP로 확인되는 정방향 DNS(A) 레코드가 있어야 합니다.
• Google Cloud (Compute Engine). 외부 IP 주소의 TCP 25번 포트로 나가는 이그레스 트래픽은 기본적으로 차단됩니다. Google Cloud가 프로젝트의 위험도가 낮다고 판단하면 차단이 자동으로 해제되며, 프로젝트의 상태는 콘솔의 VPC 네트워크 또는 방화벽 정책 페이지에 표시되는 배너로 확인할 수 있습니다. 465번 및 587번 포트를 사용하는 SMTP over TLS는 차단 대상에서 제외됩니다. Google은 신뢰할 수 있는 외부 이메일 제공업체를 사용하도록 권장하며, 그렇게 하면 IP 평판이 개선된다고 설명합니다.
• Microsoft Azure (가상 머신). 아웃바운드 25번 포트는 표준 기업계약(Enterprise Agreement)과 엔터프라이즈용 Microsoft 고객 계약(MCA-E)을 제외한 모든 구독 유형에서 차단됩니다. Enterprise Dev/Test 구독은 기본적으로 차단되지만 포털의 진단 기능을 통해 예외를 받을 수 있습니다. 인증된 SMTP 릴레이 서비스(일반적으로 587번 포트)는 어떤 구독 유형에서도 제한되지 않으며, Microsoft는 이를 권장합니다. 25번 포트가 열려 있더라도 외부 도메인이 메일을 수락한다는 보장은 없다고 Microsoft는 밝힙니다.

25번 포트 차단은 평판 문제가 아니라 전달 경로의 문제이며, 포트를 연다고 IP 평판이 나아지지는 않습니다. 클라우드나 VPS 주소에 대해 Spamhaus PBL 제외를 원한다면, 그 IP는 정적이어야 하고, 실제로 발신 메일 서버를 운영해야 하며, 정방향·역방향 DNS가 올바르게 설정되어 있어야 하고, 본인에게 할당된 주소여야 합니다. 또한 Spamhaus는 그 뒤에 있는 다른 모든 기기에 대해 아웃바운드 25번 포트를 닫을 것을 요구합니다.

전용 IP 또는 인증 SMTP 릴레이로 전환

공유 IP가 이웃 사용자 때문에 계속 평판이 떨어지거나 클라우드 제공업체가 25번 포트를 열어 주지 않는다면, 해제를 쫓아다니기보다 발송 방식을 바꾸는 편이 더 현실적인 경우가 많습니다.

인증을 거치는 외부 SMTP 릴레이

서버가 수신자에게 메일을 직접 전달하는 대신, 각 메시지를 인증된 발송 서버에 넘기면 그 서버가 대신 전달합니다. 이는 Spamhaus가 PBL 등재 대역에 대해 설명하는 바로 그 모델입니다. 즉 메일은 인증을 거쳐 릴레이에 제출되어야 하며, 릴레이는 접속 ISP나 외부 메일 서비스가 운영할 수 있습니다. Spamhaus의 25번 포트 FAQ는 최종 사용자는 SMTP AUTH와 함께 587번 또는 465번 포트를 사용해야 한다고 덧붙입니다. Azure와 Google Cloud 모두 인증 릴레이나 외부 이메일 서비스를 권장하며, Microsoft는 이런 서비스를 쓰는 이유 중 하나가 전달에 필요한 IP 평판을 유지하는 것이라고 설명합니다.

• 제공업체 문서에 따라 릴레이의 호스트 이름, 포트(보통 587), 자격 증명을 설정하십시오.
• 도메인의 SPF 레코드에 릴레이를 포함하도록 수정하고, 릴레이용 DKIM 서명을 설정하십시오. SPF, DKIM, DMARC 설정 방법을 참고하십시오.
• 대량 메일을 옮기기 전에 릴레이의 발송 한도를 확인하십시오.

전용 IP

전용 IP는 다른 고객의 행동으로부터 격리해 주지만, 자동으로 평판이 좋아지는 것은 아닙니다. Spamhaus 발신자 가이드라인은 평판에 영향을 주는 요소로 서비스 제공업체, IP 주변 대역, 주소 뒤의 인프라, IP의 이력 등을 꼽습니다.

• 새 주소는 더 엄격하게 검사받습니다. 같은 가이드라인에 따르면 발송 이력이 없는 HELO 도메인은 추가 필터링을 받으며, IP나 HELO 호스트 이름을 바꾸면 새것으로 간주하고 점진적으로 워밍업해야 합니다. 인위적인 트래픽을 만들어 내는 워밍업 서비스는 금지되어 있습니다.
• 의미 있는 역방향 DNS를 설정하십시오. Spamhaus는 전용 IP에 일반적이거나 자동 생성된 역방향 DNS를 쓰면 평판이 나빠질 수 있다고 경고합니다.
• 새 IP는 사용 전에 확인하십시오. 주소에 이전 사용자의 등재가 남아 있을 수 있으므로, 발송을 시작하기 전에 조회해 보십시오.

재발 방지

• 호스트 이름, HELO, 역방향 DNS를 일치시킵니다. Spamhaus CSS FAQ에 따르면 IP의 정방향 DNS는 서버에 설정된 HELO 값과 일치해야 하며, HELO는 FQDN(정규화된 도메인 이름)이어야 합니다. 흔한 실수로 localhost.localdomain 같은 값을 들고 있습니다.
• 25번 포트는 메일 서버에만 허용합니다. 다른 작업도 실행하는 VPS라면 메일 서버가 아닌 모든 것에 대해 아웃바운드 25번 포트를 닫으십시오.
• 사이트와 계정의 보안을 유지합니다. CMS와 플러그인을 업데이트하고, 비밀번호 재사용을 중단하며, 가능한 곳에서는 이중 인증을 켜십시오.
• 제어판의 발신 메일 설정을 점검합니다. CSS FAQ는 각 도메인 자체의 이름을 SMTP 인사말에 넣는 Plesk 옵션을 설명합니다. 서버에서 둘 이상의 도메인이 IP를 공유하는 경우, Spamhaus XBL을 사용하는 수신 측에서 해당 도메인 일부 또는 전부의 메일이 스팸으로 표시될 수 있으므로 이 옵션은 극히 신중하게 사용해야 한다고 경고합니다. 사용 중인 제어판의 해당 설정을 확인하고, 제공업체나 제어판 공급업체의 안내를 따르십시오.
• 정기적으로 모니터링합니다. 공유 IP는 다른 사람의 행동 때문에 상태가 바뀔 수 있습니다. 저희 블랙리스트 검사 도구로 주기적으로 확인하고, 변화가 생기면 일찍 제공업체에 알리십시오.

등재가 해제된 뒤에도 수신 측은 자체 필터링을 적용하므로 전달이 즉시 회복되지 않을 수 있습니다. CSS 등재는 보통 마지막 감지 후 사흘 정도 지나면 만료되지만, 문제가 계속 감지되면 IP는 다시 등재되며, 셀프 해제에는 횟수 제한이 있습니다.

자주 묻는 질문

참고한 공식 페이지

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

• Spamhaus: Policy Blocklist (PBL)
• Spamhaus: Spamhaus Blocklist (SBL)
• Spamhaus FAQ: DNSBL Usage (return codes and public resolvers)
• Spamhaus FAQ: Combined Spam Sources (CSS)
• Spamhaus FAQ: Port 25 General Questions
• Spamhaus: Sender Guidelines
• AWS: Amazon EC2 service quotas (Restriction on email sent using port 25)
• AWS: Create a reverse DNS record for email on Amazon EC2
• Google Cloud: Sending email from an instance
• Google Cloud: VPC firewall rules (Blocked and limited traffic)
• Microsoft Learn: Troubleshoot outbound SMTP connectivity in Azure

관련 가이드

전체 가이드 →