문제

당신 서버가 @daum.net·@hanmail.net(그리고 자주 @kakao.com)으로 보낸 메일이 스팸·차단을 이유로 영구 거부되어 반송되거나, 조용히 도착하지 않습니다. 같은 메시지가 지메일과 아웃룩에는 무리 없이 닿습니다. 다음은 국내 양대 소비자 메일 시스템의 하나이고 — 네이버와 마찬가지로 — 거의 맞게 설정된 도메인의 틈을 벌줄 만큼 깐깐합니다.

증상

  • daum.net / hanmail.net으로 보낸 메일이 스팸·차단 발신자를 언급하는 5xx SMTP 거부로 반송되는데, 다른 제공자는 같은 메시지를 받아들인다.
  • 거부가 아니라 지연된다 — 다음이 몇 통 받아들이다 당신 IP로부터의 접속을 거절하기 시작한다.
  • 지메일/아웃룩에는 (때로 스팸함에) 도착하는데 다음은 즉시 거부한다.
  • 새 메일 서버, 새 호스팅, 새 IP로 옮긴 직후 시작됐다.
  • 다음 수신자 한 명만 계속 못 받고 나머지 daum.net은 다 받는다 — 도메인 차단이 아니라 그 사람의 수신 필터를 보고 있다는 신호.

다음의 거부가 실제로 뜻하는 것

다음 메일 플랫폼은 SPF로 먼저 수신 여부를 판단하고, 이어서 스팸 필터링 단계를 한 번 더 거칩니다. 그래서 거부는 두 가지 중 하나를 뜻하고, 둘의 해법은 정반대입니다.

영구 차단(5xx)은 다음이 이 IP를 신뢰하지 않는다는 뜻입니다: 평판 저하, 없거나 일반적인 PTR 레코드, 스팸성 발송 이력 때문에 주소가 차단 목록에 오른 것이죠. 다음은 운영 정책(policy.daum.net)을 공개하고, 무엇보다 해제를 직접 신청할 수 있는 경로를 제공합니다 — 추측할 필요가 없습니다. 차단 해제 신청은 cs.daum.net/question/43.html에 있고, 차단된 IP를 제출하면 다음이 검토합니다.

일시 지연(4xx)은 판결이 아니라 속도 제한입니다. 다음은 한 IP가 동시에 열 수 있는 접속 수를 제한하며(White IP 기준 100개), 이를 넘는 접속은 그냥 거절됩니다. 정상적인 메일 서버는 4xx를 “나중에 다시”로 받아들여 알아서 재시도합니다 — 해법은 티켓이 아니라 발송을 늦추는 것입니다. 조치 전에 반송 코드를 읽으면, 애초에 차단이 아니었던 문제로 해제 신청을 넣는 헛수고를 막습니다.

주요 원인 3가지

  1. 발송 IP가 다음 차단 목록에 올랐다. 평판, 없거나 일반적인 역방향 DNS(PTR), 공유 IP의 스팸성 이웃이 주소를 차단시켰다. 신호: 스팸·차단을 언급하는 영구 5xx가 daum.net에 광범위하게 뜨고, 다른 제공자는 재현하지 못한다. 다음의 해제 신청 페이지가 바로 이 경우를 위해 있다 — 단, 인증과 PTR을 먼저 깨끗이 한 뒤에 신청하지 않으면 다시 차단된다.
  2. SPF 누락 또는 From 도메인과 미정렬. 다음이 SPF로 먼저 판단하므로, 실제 발송 서버가 SPF에 없거나 인증된 도메인이 보이는 From과 일치하지 않는 메일은 여기서 실패하고, 관대한 제공자는 통과시킨다. 신호: 헤더 검사에서 발송 소스에 대해 spf=none 또는 spf=fail.
  3. 다음의 접속·속도 제한 초과. 배치 발송이 너무 많은 병렬 접속을 열어 IP당 상한에 걸리면 다음이 지연시킨다. 신호: 4xx이고 물량 의존적이며, 처음 몇 통은 통과하다 배달이 급격히 느려진다.

DechoNet으로 진단

  • 이메일 점검은 발송 도메인의 SPF·DKIM·DMARC 레코드를 가져와 평가합니다 — SPF가 존재하는지, 10회 조회 한도(RFC 7208 §4.6.4) 안에 드는지, 실제로 발송하는 서비스를 include:하는지 확인하세요. 게시된 SPF 레코드는 KISA 화이트도메인 신청의 전제 조건이기도 하니, 어느 쪽이든 이게 첫 단계입니다.
  • 역방향 DNS 조회는 발송 IP가 실제 호스트명으로 되돌아 해석되는 유효한 PTR을 가졌는지 확인합니다. 없거나 일반적인 PTR(클라우드가 기본으로 주는 종류)은 다음이 알아채는 평판 감점 요인이고, 해제 신청 전에 고쳐 둘 값입니다.

해결 체크리스트

  • 반송 코드부터 읽는다: 5xx=차단(해제 신청 + 깨끗한 설정 필요), 4xx=속도 제한(늦추고 서버가 재시도하게 둔다). 4xx에 티켓을 넣지 말 것.
  • 범위 확정: 도메인 전체 반송인가, 반송 없이 다음 한 사서함만 못 받는가? 한 사서함이면 그 사용자의 수신 필터이니 여기서 멈춘다.
  • From 도메인에 이메일 점검을 돌려 SPF·DKIM·DMARC가 존재·유효하고, SPF가 10회 조회 한도 안에서 실제 발송 서버를 포함하는지 확인한다.
  • 발송 IP의 역방향 DNS를 확인하고, 없거나 일반값이면 정방향 확인되는 실제 PTR을 설정한다.
  • 4xx라면 동시 접속을 줄인다 — 다음의 IP당 접속 상한에 여유를 두고, 새 IP는 첫날 전량을 쏘지 말고 점진적으로 워밍업한다.
  • 인증과 PTR을 깨끗이 한 뒤에만, 차단된 IP를 다음 차단 해제 신청(cs.daum.net/question/43.html)에 제출한다.
  • 한국 포털로의 지속 물량이라면 도메인과 발송 IP를 KISA 화이트도메인 서비스(spam.kisa.or.kr)에 등록한다. SPF부터 게시하라.
  • 테스트 메일을 보내 정상 발송 재개 전에 헤더에서 spf=pass와 DKIM 정렬을 확인한다.

에스컬레이션 시점

  • 도메인 인증이 깨끗하고 IP의 역방향 DNS·평판도 좋고 해제 신청까지 마쳤는데 다음이 여전히 지속 발송을 거부한다면, 전체 반송문과 함께 다음 고객센터로 후속 문의하세요 — 이 지점의 결정은 수신자 측이고 다음만 설명할 수 있습니다.
  • 반송 없는 다음 수신자 한 명이라면 발송 측에서 escalate할 것이 없습니다: 그 사용자가 자기 수신·차단 설정을 직접 관리합니다.

내 도메인에서 바로 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.