메일이 스팸으로 분류되는 이유: DNS 밖의 원인도 확인하기
mail-tester.com 점수가 높고 SPF, DKIM, DMARC도 통과했으며 차단 목록 등재도 찾지 못했다. 그런데 메일은 스팸으로 들어가거나 보이지 않는다. 테스트 결과와 실제 전달이 왜 다른지 이해하는 것이 조사 출발점이다.
2026년의 인증은 기본일 뿐이다. Google, Yahoo, Microsoft는 발신 행동과 이력, 콘텐츠, 공유 IP 평판 등을 함께 평가할 수 있다. 올바른 DNS만으로 수신함을 보장하지는 않는다. 이 글은 그 밖의 원인과 검토할 조치를 설명한다.
대량 발신자 분류가 유지될 수 있다
스팸 분류를 조사할 때는 발신자 분류도 확인한다. Google의 대량 발신 상태는 매일 초기화되는 횟수만이 아니라 과거 발신에 따른 상태다. 계절 캠페인이나 사용자 10,000명에게 보낸 일회성 발송으로 분류되면 이후에도 관련 대량 요구사항이 적용될 수 있다.
강한 규칙이 수백만 건을 보내는 회사에만 해당한다는 생각은 잘못된 판단을 낳을 수 있다. 작은 회사도 기본 요구사항을 확인하고 해당되는 추가 규칙을 따라야 한다.
이를 high-water mark라고 부르기도 한다. 이전에 대량 발신자로 분류된 도메인은 이후 하루 50건만 보내도 해당 상태가 유지될 수 있다. 영구적인 나쁜 평판이나 자동 스팸 처리를 뜻하지는 않지만 발송량 감소만으로 분류가 해제되지는 않을 수 있다.
하위 도메인이 평판을 완전히 보호하지는 않는다
promo.company.com에서 마케팅을 보내면 관리상 분리가 가능하지만 company.com을 완전히 보호하지는 않는다. Google은 기본 도메인 단위로 대량 발신량을 합산하고 공급자는 도메인이나 IP 평판 신호를 함께 볼 수 있다.
promo.company.com의 높은 신고율이 다른 흐름에도 위험이 될 수 있다. 다만 특정 계약 메일의 스팸 분류 원인을 그것만으로 확정하지 않는다. 콘텐츠와 수신자 행동 등도 함께 조사한다.
별도 도메인은 더 명확한 관리 경계를 만들 수 있지만 같은 IP를 쓴다면 완전한 분리 보장은 아니다. Google Workspace의 사용자당 월 $6-$30 같은 가격 예시도 변동될 수 있다. TrekMail의 정액 모델 역시 포함 도메인 수와 비용은 현재 요금제 조건을 따른다. 다섯 도메인을 부서별로 사용하는 예도 실제 요금제 한도를 확인해야 하며 항상 추가 비용이 없다는 뜻은 아니다.
SPF, DKIM, DMARC의 숨은 인증 문제
간단한 테스트의 통과가 모든 경로와 수신자를 포함하지는 않는다. 실제로 영향을 받은 메시지의 인증을 확인한다. 숨은 설정 오류가 가능하지만 좋은 점수만으로 콘텐츠, 평판이나 정책 문제를 배제할 수 없다.
SPF: 조회 항목 10개 제한
SPF는 평가 중 DNS 조회를 일으키는 메커니즘과 수정자를 10개로 제한한다. include:sendgrid.net, include:_spf.google.com, include:mailgun.org의 중첩 항목도 포함될 수 있다. 이 조합이 반드시 초과한다고 가정하지 말고 경로를 측정한다. 관련 항목 11개를 평가하면 PermError가 발생할 수 있다. 전달 서버 IP로 바뀌어 SPF가 실패할 수도 있지만 유효한 정렬 DKIM으로 DMARC가 통과할 수 있다. RFC 7208을 참고한다.
설정 복구는 SPF 레코드 구성 가이드와 공급자의 최신 값을 확인한다.
DKIM: 키 길이와 본문 수정의 영향
Google은 RSA-DKIM의 최소 키 길이로 1024비트를 안내한다. 오래된 512비트 키는 이를 충족하지 않는다. selector 오류나 불완전한 키 교체도 검증을 깨뜨릴 수 있다. 서명 후 푸터 등을 붙이면 본문 해시가 실패할 수 있지만 영향은 서명 범위와 정규화 규칙에 달려 있다. 모든 작은 수정이 모든 서명을 무효화하는 것은 아니다.
DMARC: 도메인 정렬 문제
SPF와 DKIM이 통과해도 정렬이 없으면 DMARC는 실패할 수 있다. SPF에는 봉투 도메인, DKIM에는 서명의 d= 도메인을 From과 비교한다. relaxed는 조직 도메인 기준이고 strict는 정확한 일치가 필요하다. 정렬 SPF 또는 유효한 정렬 DKIM으로 통과하며 둘 다 필요하지는 않다. DMARC 정렬을 참고한다.
예를 들어 Mailchimp의 봉투 도메인 bounce.mailchimp.com으로 SPF를 통과하지만 From은 mycompany.com일 수 있다. 해당 SPF는 정렬되지 않는다. 유효한 정렬 DKIM도 없다면 DMARC는 실패하고 실제 거부는 정책과 수신자 판단에 달려 있다. DMARC.org 설명을 함께 읽는다.
0.3% 신고율 경고
2026년에도 스팸 신고는 중요한 신호다. Google은 사용자 신고 스팸 비율을 0.1% 미만으로 유지하고 0.3% 이상을 피하라고 안내한다. 관련 완화 지원과 정책에 영향을 줄 수 있으나 모든 공급자가 자동으로 즉시 스팸 처리하거나 차단하는 기준은 아니다.
Yahoo는 전체 발송이 아니라 수신함에 도착한 메일을 분모로 설명한다. 예를 들어 1,000건 중 900건이 스팸으로 들어가고 100건만 수신함에 도착하면 한 신고는 1.0%이지 0.1%가 아니다. 계산의 중요성을 보여주는 예이며 즉시 전체 차단이나 최초 필터링 원인을 증명하지 않는다.
따라서 데이터 없이 발송량을 늘리지 않는다. 사용 가능한 수신 측 신호와 로그를 함께 보고 제한된 범위를 고려한다. 도메인 평판과 발신자 평판은 관리 대상이지 모든 거부에 대한 보험은 아니다.
RFC 8058 원클릭 수신 거부
Google은 2024년 유월부터 관련 홍보성 대량 메일에 원클릭 수신 거부를 요구한다. 로그인해야 하는 환경 설정 페이지의 푸터 링크만으로는 대신할 수 없다. 필요한 헤더의 일부는 다음과 같다.
List-Unsubscribe-Post: List-Unsubscribe=One-ClickList-Unsubscribe 헤더 등 다른 조건도 충족하면 클라이언트가 자체 수신 거부 버튼을 표시할 수 있다. POST를 처리하는 HTTPS 엔드포인트와 필수 수신 거부 헤더를 포함하는 유효한 DKIM 서명이 필요하다. 이 헤더 하나만으로 버튼 표시, 해지 처리나 수신함 개선이 보장되지는 않는다.
쉬운 해지 절차는 사용자가 스팸 신고 대신 중단할 수 있게 한다. 신고는 평판에 영향을 줄 수 있다. 해지가 언제나 중립적인 신호라는 보장은 없지만 동의와 목록 관리에 필요하다. Google의 발신자 지침에서 현재 대량 요구사항을 확인한다.
공급자별 필터링 규칙
Google, Microsoft, Yahoo는 서로 다른 신호와 규칙을 사용한다. Gmail의 결과가 Outlook에서도 같지는 않다. 각 공급자의 전체 응답과 사용 가능한 데이터를 확인한다.
| 공급자 | 관련 요소 | 도구 | 주의점 |
|---|---|---|---|
| Google (Gmail) | 인증과 수신자 신호 | Google Postmaster Tools, 데이터가 있는 경우 활용 | 0.3% 기준은 주의가 필요하지만 참여 감소만으로 필터 원인을 확정하지 않음 |
| Microsoft (Outlook) | IP 평판 등 | SNDS (Smart Network Data Services) | 5,000건을 첫날 보낸다는 것은 보편적 차단 기준이 아님. 421 RP-001 응답을 읽고 상황에 맞게 증가 속도 조절 |
| Yahoo (AOL/Verizon) | 콘텐츠와 신고 등 | Complaint Feedback Loop (CFL) | 유효한 ARF 피드백을 처리하고 해당 마케팅을 제외하되 반복 발송이 항상 즉시 전체 차단은 아님 |
확인해야 할 콘텐츠 신호
2010년처럼 단어 목록만으로 판단할 문제는 아니다. 필터는 구조, 링크와 맥락을 함께 볼 수 있다. 다음은 개별적으로 스팸을 증명하는 규칙이 아니라 검토할 요소다.
| 요소 | 확인 이유 |
|---|---|
| Noreply 발신 주소 | 답장을 어렵게 할 수 있으므로 가능한 경우 응답 가능한 주소 사용. 주소만으로 스팸이나 프로모션 분류를 단정하지 않음 |
| bit.ly, tinyurl 같은 공개 단축 링크 | 평판과 안전성 검토 필요. 목적지와 맥락을 확인하며 모든 링크가 자동 차단되지는 않음 |
| 이미지만 있는 메일 | 접근성과 분석이 어려울 수 있어 의미 있는 텍스트 추가. 보편적인 이미지 비율 기준은 없음 |
| 잘못된 HTML | 표시와 분석을 방해할 수 있어 문법을 수정하되 올바른 HTML도 수신함 보장은 아님 |
공유 IP 평판의 인프라 위험
여러 도메인을 관리한다면 발신 구조가 중요하다. 같은 IP의 다른 발신자가 위험을 만들 수 있지만 공유 호스팅 자체가 나쁜 것은 아니다. Spamhaus 등 관련 목록에서 직접 확인하고 어느 수신자가 이를 사용하는지 평가한다. 등재가 영향을 줄 수 있지만 모든 정상 메일의 반송을 보장하지는 않는다.
전용 IP도 선택지이지 모든 문제의 답은 아니다. SendGrid의 월 $89+ 같은 가격 예시는 변동되고 요금제에 달려 있다. 고객 50명이라면 비용뿐 아니라 발송량, 워밍업과 관리도 검토한다. 낮은 발송량의 새 전용 IP도 문제를 겪을 수 있다.
현재 안내상 TrekMail은 모니터링과 오용 방지 정책을 포함한 관리형 SMTP를 제공할 수 있다. 자체 SMTP로 Amazon SES나 Mailgun 계정에서 보내고 사서함은 TrekMail에 호스팅할 수 있다. IP 분리와 평판은 발신 공급자 구성에 달려 있으며 독점적인 기능이나 모든 다른 발신자 영향의 차단 보장은 아니다.
실제로 확인하는 진단 방법
추측 대신 영향을 받은 메시지와 경로를 조사한다. 다음 단계는 가능한 원인을 구분하는 데 도움이 된다.
1. 헤더 확인. Gmail에 보내고 메뉴에서 원본을 표시한다. 신뢰하는 수신 결과의 SPF: PASS, DKIM: PASS, DMARC: PASS를 확인한다. FAIL이나 SOFTFAIL은 관련 경로를 점검할 신호이지 모든 발송을 반드시 중단해야 한다는 뜻은 아니다. 개별 실패와 DMARC 통과가 함께 있을 수 있다.
2. 시드 테스트. GlockApps는 테스트 사서함에서 수신함, 스팸이나 프로모션 분류를 표본으로 볼 수 있다. 프로모션은 정상 수신함의 범주이며 스팸과 다르다. Mail-Tester의 설명된 무료 테스트는 기술과 콘텐츠 신호를 평가하므로 현재 한도를 확인한다. 모든 실제 수신자의 폴더를 증명하지는 않는다. IP 등재와 도구의 현재 기능도 확인한다.
3. 반송 로그. 전체 SMTP 응답을 읽는다. 5xx는 영구 오류이며 550 5.1.1은 알 수 없는 수신자, 550 5.7.1은 다양한 정책 원인일 수 있다. 4xx는 임시 오류이고 421이 항상 과속 발신은 아니다. 오류에 맞춰 제외, 재시도와 구성을 수정한다.
전달 관리를 한 번 설정하고 끝내지 않는다
2026년의 문제에는 DNS, 평판, 콘텐츠, 수신자 행동과 인프라가 모두 관련될 수 있다. 각 계층을 점검하면 피할 수 있는 오류를 줄일 수 있지만 영구적으로 스팸을 벗어난다고 보장하지는 않는다.
수신자의 의사를 존중한다. 중단을 쉽게 하고 해당 요구사항에 따라 RFC 8058을 구현한다. 목록 관리에 도움이 되지만 평판 회복을 약속하지는 않는다.
발신 흐름을 별도로 관리한다. 마케팅, 거래와 업무 메일을 적절히 나눈다. 별도 도메인도 공유 IP 등 연관성의 영향을 완전히 없애지는 않는다.
인프라를 의도적으로 선택한다. 사용자별 가격만으로 설계하지 않는다. 도메인 하나나 고객 100명을 운영하더라도 TrekMail의 현재 정액 요금, 기능과 제한을 검토한다. 요금 방식 자체가 스팸을 막지는 않는다.
책임 있는 발신의 기본은 안전한 업무 이메일 가이드를 함께 읽는다.
