인증 3종이 모두 pass인데도 스팸함에 들어갑니다. 왜 그런가요?

인증은 통과 조건이지 도달 보장이 아닙니다. 인증이 맞으면 수신 서버는 다음으로 그 도메인과 발송 IP의 평판을 봅니다. 최근에 수신 거부나 스팸 신고가 늘었거나, 도메인이 메일을 보낸 이력이 거의 없는 신규 도메인이면 인증과 무관하게 보류될 수 있습니다.

특정 회사로 보낼 때만 스팸함에 들어갑니다.

수신 측 자체 필터나 차단 규칙일 가능성이 큽니다. 그 회사에서 쓰는 필터의 격리 로그를 확인해 달라고 요청하고, 반송 메일에 표시된 사유 코드를 보세요. 우리 쪽 인증과 평판이 정상이라면 수신 측 허용 목록 등록이 가장 빠른 해결입니다.

PTR 레코드는 우리가 직접 설정할 수 있나요?

정방향 DNS는 도메인 소유자가 설정하지만, PTR은 IP 주소를 할당한 쪽에서 설정합니다. 그래서 서버를 임대해 쓰는 경우 제공자에게 요청해야 합니다. 메일 서비스를 빌려 쓰는 경우에는 서비스 쪽에서 이미 맞춰 두므로 확인할 필요가 없습니다.

블랙리스트에 올라갔으면 어떻게 해야 하나요?

먼저 원인을 제거해야 합니다. 계정 탈취로 인한 대량 발송, 잘못된 전달 설정, 감염된 단말이 흔한 원인입니다. 원인을 고친 뒤 각 목록의 해제 요청 양식으로 신청하며, 목록에 따라 해제까지 수 시간에서 수 일이 걸립니다.

안내 메일을 한 번에 수천 통 보내야 합니다. 업무 메일 계정으로 보내도 되나요?

권장하지 않습니다. 업무 메일 서비스는 대량 발송을 전제로 만들어져 있지 않아 발송 제한에 걸리거나, 수신 거부 신고가 쌓여 임직원의 일상 메일까지 영향을 받습니다. 전용 발송 서비스를 쓰고 발송용 서브도메인을 따로 두는 편이 안전합니다.

보낸 메일이 스팸함에 들어갈 때 점검 순서

보낸 메일이 스팸함으로 분류될 때는 위에서부터 순서대로 좁히는 것이 빠릅니다. 첫째로 인증 3종(SPF, DKIM, DMARC)이 실제로 통과하는지 메일 헤더에서 확인하고, 둘째로 발송 서버의 PTR과 IP 평판을 보고, 그다음에 콘텐츠와 발송 습관을 봅니다. 원인의 대부분은 첫 번째 단계에서 드러납니다.

인증이 통과해도 스팸함에 들어갈 수 있습니다. 인증은 "누가 보냈는지 확인되었다"는 뜻이고, 받을지 말지는 그 도메인과 IP의 평판이 결정하기 때문입니다. 아래 순서로 하나씩 지우면서 내려가세요.

점검 순서 요약

순서	확인할 것	결과가 나쁠 때
1	메일 헤더의 `Authentication-Results` 에 `spf=pass`, `dkim=pass`, `dmarc=pass`	레코드 설정 문제. 여기서 대부분 끝납니다
2	From 도메인과 인증 도메인의 정렬(alignment)	DMARC만 실패하는 전형적인 원인
3	발송 IP의 PTR과 정방향 DNS 일치	자체 메일 서버 운영 시 자주 누락
4	발송 IP와 도메인의 평판, 블랙리스트 등재	원인 제거 후 해제 요청
5	본문, 링크, 첨부, 발송 패턴	문구와 링크 도메인 정리
6	수신 거부 처리와 바운스 관리	목록 위생이 평판을 좌우합니다

각 레코드의 문법과 설정 방법은 SPF, DKIM, DMARC 설정에 있으니, 여기서는 진단에 집중합니다.

1. 헤더에서 인증 결과를 읽습니다

외부 메일 계정(Gmail 등)으로 테스트 메일을 보낸 뒤 "원본 보기"를 열어 Authentication-Results 헤더를 봅니다. 이 한 줄에 수신 서버가 내린 판단이 모두 들어 있습니다.

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=sel1;
       spf=pass (google.com: domain of bounce@example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounce@example.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

세 항목을 이렇게 읽습니다.

spf=fail 또는 spf=softfail 발송 서버 IP가 SPF 목록에 없습니다. smtp.mailfrom 도메인의 SPF 레코드에 그 경로를 추가해야 합니다. 괄호 안에 나오는 IP가 실제 발송 IP입니다.
spf=permerror SPF 문법 오류이거나 DNS 조회가 10회를 넘었습니다. 레코드가 두 개 있는 경우도 여기에 해당합니다.
dkim=none 서명이 아예 붙지 않았습니다. 공개키만 게시하고 메일 서비스 관리 화면에서 서명을 켜지 않은 경우가 가장 많습니다.
dkim=fail 서명은 있지만 검증에 실패했습니다. 공개키가 잘못 들어갔거나, 중간 경로에서 본문이 수정된 경우(일부 메일링 리스트, 일부 보안 게이트웨이)입니다.
dmarc=fail 아래 정렬 문제입니다.

헤더 윗부분의 Received 줄들을 따라가면 메일이 실제로 거쳐 온 서버와 IP를 확인할 수 있습니다. 우리가 안다고 생각한 발송 경로와 다른 IP가 보이면, 그 경로가 SPF에 빠져 있을 가능성이 큽니다.

2. From 정렬을 확인합니다

SPF와 DKIM이 pass 인데 dmarc=fail 이면 거의 항상 정렬(alignment) 문제입니다. DMARC는 인증이 통과한 도메인이 수신자에게 보이는 From 주소의 도메인과 같은지까지 봅니다.

헤더	누가 쓰는가	DMARC가 보는 관계
`smtp.mailfrom` (Return-Path)	발송 서버가 지정	SPF 결과의 기준. From 도메인과 맞아야 SPF 정렬 성공
`header.from` (From)	수신자에게 보이는 주소	정렬의 기준점
`header.i` / `d=` (DKIM 서명 도메인)	서명한 서버가 지정	From 도메인과 맞아야 DKIM 정렬 성공

전형적인 실패 사례는 이렇습니다.

발송 도구가 bounce@tool-domain.com 을 Return-Path로 쓰고 From은 우리 도메인입니다. SPF는 pass지만 정렬은 실패합니다. 발송 도구에서 Return-Path 도메인을 우리 서브도메인으로 바꾸는 설정(사용자 지정 반송 도메인)을 켜면 해결됩니다.
DKIM 서명 도메인이 발송 도구의 도메인입니다. 도구 쪽에서 우리 도메인으로 서명하도록 DKIM 키를 발급받아 DNS에 게시해야 합니다.
DMARC에 adkim=s, aspf=s 를 넣어 엄격 모드로 둔 상태에서 서브도메인으로 보내고 있습니다. 기본값인 느슨한 모드(r)에서는 상위 도메인이 같으면 정렬로 인정되므로 우선 r 로 두고 확인합니다.

3. PTR과 정방향 DNS, 그리고 IP 평판

메일 서비스를 빌려 쓰고 있다면 이 단계는 서비스 쪽 책임이므로 건너뛰어도 됩니다. 자체 서버에서 메일을 보낸다면 여기서 걸리는 경우가 많습니다.

많은 수신 서버가 발송 IP에 대해 역방향 조회와 정방향 조회가 서로 맞는지(FCrDNS) 확인합니다. 아래 세 값이 한 줄로 이어져야 합니다.

# 1) 발송 IP의 PTR
dig +short -x 203.0.113.10
# → mail.example.com.

# 2) 그 이름의 A 레코드가 다시 같은 IP인지
dig +short A mail.example.com
# → 203.0.113.10

# 3) SMTP 인사(HELO/EHLO) 이름도 같은 이름인지
#    메일 서버 설정에서 myhostname 또는 HELO 이름을 확인합니다

PTR은 IP를 할당한 쪽에서 설정합니다. 임대한 IP라면 제공자에게 요청해야 하고, 요청 방법과 반영 시간은 제공자마다 다릅니다. PTR이 제공자의 기본 이름(예: host-203-0-113-10.example-isp.net)으로 남아 있으면 인증과 별개로 감점 요인이 됩니다.

다음은 평판입니다. 발송 IP가 공개 블랙리스트에 올라갔는지 확인합니다.

# 주요 목록 등재 여부 (IP를 거꾸로 적습니다)
dig +short 10.113.0.203.zen.spamhaus.org
dig +short 10.113.0.203.bl.spamcop.net
# 응답이 있으면 등재, 비어 있으면 미등재

등재되었다면 원인을 먼저 없애야 합니다. 계정 탈취로 인한 대량 발송, 사용자 계정의 자동 전달로 스팸이 재발송되는 구성, 사내 감염 단말이 흔한 원인입니다. 원인을 고친 뒤 각 목록의 해제 요청 양식으로 신청합니다. 고치지 않고 해제만 반복하면 다시 등재되고 해제가 점점 어려워집니다.

발송 IP와 별개로 도메인 자체의 평판도 누적됩니다. 대형 수신 서비스가 제공하는 발신자 도구(Google Postmaster Tools, Microsoft SNDS 등)에 도메인을 등록해 두면 스팸 신고율과 인증 실패율을 볼 수 있습니다.

4. 콘텐츠와 링크

인증과 평판이 정상인데도 일부 메일만 분류된다면 메일 자체를 봅니다. 필터가 싫어하는 특징은 대체로 정해져 있습니다.

짧은 본문과 큰 이미지 하나. 텍스트 없이 이미지 한 장만 있는 메일은 내용을 검사할 수 없어 불리합니다. 텍스트 본문을 함께 넣고 대체 텍스트를 채웁니다.
링크 도메인이 본문과 다름. 단축 URL, 추적용 리다이렉트 도메인, 평판이 낮은 공유 도메인이 섞이면 점수가 떨어집니다. 추적 링크는 우리 도메인의 서브도메인으로 설정하는 편이 좋습니다.
HTML만 있고 텍스트 파트가 없음. HTML과 평문을 함께 담은 형태(multipart)로 보냅니다.
실행 가능한 첨부나 암호가 걸린 압축 파일. 검사할 수 없는 첨부는 보류되기 쉽습니다. 파일은 링크로 공유합니다.
수신자 주소를 숨긴 대량 발송. 수백 명을 숨은 참조로 한 번에 보내는 방식은 스팸 패턴과 구분되지 않습니다.
제목과 본문의 과장된 표현. 금전, 긴급, 당첨 같은 어휘가 몰려 있으면 점수가 올라갑니다.

문구를 다듬는 것보다 효과가 큰 것은 발송 경로 분리입니다. 안내나 마케팅 메일은 news.example.com 처럼 별도 서브도메인에서 보내고, 그 서브도메인에 SPF와 DKIM, DMARC를 따로 설정합니다. 그 경로의 평판이 나빠져도 임직원 업무 메일에는 영향이 적습니다.

5. 수신 거부, 바운스, 워밍업

장기적인 전달률은 목록 위생이 결정합니다. 보내는 쪽에서 관리할 수 있는 부분이 여기입니다.

수신 거부를 즉시 반영합니다. 본문 하단에 수신 거부 링크를 두고, 거부한 주소로는 다시 보내지 않습니다. 대형 수신 서비스는 한 번 누르면 끝나는 방식(List-Unsubscribe 헤더)을 요구합니다. 거부한 사람이 다시 받으면 스팸 신고로 이어지고, 신고율은 평판에 가장 직접적으로 작용합니다.
하드 바운스는 목록에서 제거합니다. 존재하지 않는 주소(5xx 영구 실패)로 계속 보내면 수신 서버는 목록을 구매했거나 관리하지 않는다고 판단합니다. 소프트 바운스(4xx, 일시적 실패)는 몇 번 재시도한 뒤 중단합니다.
반송 메일을 읽습니다. 반송에는 사유 코드와 설명이 들어 있습니다. 속도 제한, 평판 거부, 주소 없음, 정책 위반 중 어느 쪽인지에 따라 대응이 완전히 다릅니다.
신규 도메인과 신규 IP는 워밍업이 필요합니다. 메일 이력이 없는 도메인에서 갑자기 대량 발송이 나가면 그 자체가 의심 신호입니다. 첫 주에는 반응이 좋은 수신자에게 소량으로 시작해, 2~4주에 걸쳐 하루 발송량을 단계적으로 늘립니다. 서비스를 옮긴 직후에도 발송 경로가 바뀌므로 같은 주의가 필요합니다. 이전 절차는 메일 서비스 옮기기에 있습니다.
발송 간격을 고르게 둡니다. 같은 양이라도 한꺼번에 몰아 보내면 속도 제한에 걸립니다. 시간 단위로 나누어 보냅니다.

여기까지 확인해도 원인이 잡히지 않으면 수신 측의 개별 정책일 가능성이 큽니다. 반송 메일의 사유 코드를 모아 수신 측 담당자에게 전달하고, 우리 쪽 인증 결과를 함께 보여 주는 것이 가장 빠릅니다. 받는 쪽 문제로 메일이 들어오지 않는 상황은 메일이 오지 않을 때에서, 수신 경로 설정은 MX 레코드 이해하기에서 다룹니다.