SPF를 설정했습니다. DKIM도 구성했습니다. DMARC도 적용되어 있습니다. 그런데도 메시지가 스팸 폴더에 들어가거나 아예 도착하지 않습니다. 이메일이 스팸으로 분류되는 이유를 이해하려면 인증 레코드만 살펴봐서는 안 됩니다. 서로 겹치는 필터, 행동 신호, 인프라의 특이점이 복합적으로 작용하며, 대부분의 발신자는 이미 문제가 생긴 뒤에야 이를 알아차립니다. 이 모든 판단의 바탕이 되는 평판 신호는 이메일 발신자 평판 가이드에서 자세히 알아볼 수 있습니다.
문제는 대부분의 안내서가 설명하는 것보다 훨씬 깊습니다. Google이나 Yahoo 같은 사서함 제공업체는 헤더가 검사를 통과했는지만 확인하지 않습니다. 발신자가 누구인지, 과거에 어떻게 발송했는지, 인프라가 스팸 발신자의 것처럼 보이는지, 수신자가 해당 메일을 실제로 원하는지도 확인합니다. 설정 하나만 잘못되어도 수개월 동안 쌓은 좋은 발송 평판이 크게 훼손될 수 있습니다.
실제로 스팸 폴더 분류를 유발하는 원인을 하나씩 살펴보고, 진단 단계와 재발을 막는 구조적 해결책을 알아보겠습니다.
영구적인 대량 발신자 분류의 함정
대량 발신자의 이메일이 스팸으로 분류되는 이유: 하루 동안 Gmail 주소로 메시지를 5,000개 보내면 Google은 해당 발신자를 영구적으로 대량 발신자로 분류합니다. 이 기준은 한 번이라도 도달한 최고치로 판단하며 매일 초기화되지 않습니다. 그때부터 모든 마케팅 이메일에 RFC 8058 원클릭 수신 거부 기능이 필요하고, 최소 p=none 정책을 적용한 DMARC가 필수이며, 신고율은 항상 0.3% 이하로 유지해야 합니다. 비대량 발신자 상태로 되돌아가는 경로는 없습니다.
대부분의 발신자는 자신도 모르는 사이 이 기준을 넘습니다. 적당한 규모의 목록을 대상으로 프로모션 캠페인을 한 번만 진행해도 몇 분 안에 5,000개를 넘습니다. 이후에는 규칙이 영구적으로 바뀝니다. 이미 요건을 충족한 상태가 아니라면 Google의 경고 이메일도 없이 메시지가 스팸 폴더에 쌓이기 시작합니다.
해결 방법은 복잡하지 않지만 빠짐없이 적용해야 합니다. 모든 메시지에 RFC 8058 헤더가 있어야 하고, DMARC 레코드는 정렬 검사를 통과해야 하며, 신고율을 지속적으로 0.1% 미만으로 유지해야 합니다. 이 중 하나라도 놓치면 나머지가 정상으로 보여도 이메일이 스팸으로 분류될 수 있습니다.
0.3% 신고율의 절벽
신고율이 0.3%일 때 이메일이 스팸으로 분류되는 이유: Google은 안정적인 발송의 기준을 0.1%로 보고 0.3%를 명확한 실패 지점으로 삼습니다. Yahoo도 같은 수치를 사용하지만 분모가 다릅니다. 이 차이는 매우 중요합니다. Yahoo는 전체 발송 메시지가 아니라 받은편지함에 도착한 메시지를 기준으로 신고율을 계산합니다. 이미 전송 성공률이 낮다면 더 작은 분모 때문에 신고율이 빠르게 치솟습니다.
Yahoo의 받은편지함 기준 계산: 메시지를 1,000개 보냅니다. 900개는 스팸으로 분류되고 100개는 받은편지함에 도착합니다. 수신자 한 명이 "스팸 신고"를 누릅니다. 신고 1건 ÷ 받은편지함 도착 100건 = 신고율 1.0%로, 한도를 세 배 넘습니다. 1,000건을 발송해 신고가 단 한 건뿐이어도 그렇습니다.
이것이 악순환입니다. 받은편지함 도착률이 낮아지면 분모가 작아집니다. 분모가 작아지면 신고 한 건만으로도 신고율 기준을 위반할 수 있습니다. 신고율이 높아지면 도착률이 더 나빠질 수 있고, 도착률이 나빠지면 분모가 다시 줄어듭니다. 이 악순환에 빠졌을 때 일반적으로 필요한 대응은 반응이 없는 연락처를 적극적으로 제외하고 평판 신호가 회복되기를 기다리는 것입니다. 회복에는 보통 몇 시간이 아니라 몇 주가 걸립니다.
다음 캠페인을 보내기 전에 Google Postmaster Tools에서 신고율을 확인하세요. 0.08%를 넘는다면 긴급 상황으로 다뤄야 합니다.
DMARC 정렬의 함정
SPF와 DKIM을 통과했는데도 이메일이 스팸으로 분류되는 이유: DMARC는 SPF와 DKIM의 통과 여부만 확인하지 않습니다. 두 인증이 From 도메인과 정렬되는지도 확인합니다. ESP의 공유 인프라를 통해 발송하면 SPF와 DKIM을 모두 통과하고도 DMARC 정렬에는 실패할 수 있습니다. 인증 결과가 모두 "정상"으로 표시되는데도 이메일이 스팸으로 분류되는 가장 흔한 원인 중 하나입니다.
| 검사 | ESP 기본 동작 | DMARC 정렬 결과 |
|---|---|---|
| SPF | bounces.mailchimp.com에 대해 통과 |
정렬 실패 - mailchimp.com ≠ yourcompany.com |
| DKIM | d=mailchimp.com으로 통과 |
정렬 실패 - 서명 도메인 ≠ From 도메인 |
| DMARC | 두 검사 모두 정렬 실패 | 실패 → 메시지가 스팸으로 분류되거나 거부됨 |
해결책은 사용자 지정 도메인 인증입니다. 하위 도메인을 ESP 인프라로 연결하는 CNAME 레코드와 SPF가 자체 도메인 기준으로 통과하게 하는 사용자 지정 return-path 하위 도메인을 구성해야 합니다. 주요 ESP는 모두 이 기능을 지원하지만 기본으로 활성화되어 있지 않을 수 있습니다. 다음 발송 전에 활성화하세요.
현재 정렬 요건은 Google 이메일 발신자 가이드라인에서 확인하세요. Google은 2024년에 이 규칙을 업데이트했으며 현재 대량 발신자 기준을 엄격하게 적용하고 있습니다.
Microsoft의 신규 IP 장벽
Outlook과 Hotmail에서 이메일이 스팸으로 분류되는 이유: Microsoft는 발송 이력이 없는 IP를 기본적으로 의심스럽게 취급합니다. 도메인 평판이 깨끗해도 새로운 전용 IP를 사용하거나 제공업체를 변경하면 IP 수준의 신뢰도가 최저 상태로 초기화됩니다. 이때 표시되는 SMTP 오류는 인증 실패가 아닙니다. 발송량과 평판에 따른 차단이며 적절한 워밍업을 거쳐야만 해소됩니다.
451 4.7.500 - Server busy, try again later (throttle signal - slow down)
421 RP-001 - Reputation limitation; this IP has no sending history
550 5.7.515 - Message volume exceeds IP reputation (not an auth failure)Microsoft의 워밍업 곡선은 엄격합니다. 실행 가능한 일정은 1일 차에 메시지 50개, 2일 차에 100개, 3일 차에 200개를 보내고 이후 2-3일마다 두 배로 늘리는 것입니다. 점진적인 증가 과정을 건너뛰어도 시간은 절약되지 않습니다. 오히려 자동 지연이 발생해 첫날부터 다시 시작하게 됩니다.
421 RP-001이 계속 표시된다면 DNS 수정이 아니라 전용 워밍업 계획이 필요합니다. IP에 이력이 없으므로 수주 동안 문제없는 발송 이력을 쌓기 전까지 Microsoft는 해당 IP를 신뢰하지 않습니다. 워밍업을 서두르는 것은 도메인 평판이 양호한데도 Outlook에서 이메일이 스팸으로 분류되는 흔한 원인입니다.
누락된 원클릭 수신 거부
사용자가 쉽게 수신 거부할 수 없을 때 이메일이 스팸으로 분류되는 이유: 수신자가 눈에 잘 띄는 수신 거부 기능을 찾지 못하면 대신 "스팸 신고" 버튼을 사용합니다. 이는 신고로 기록됩니다. 대량 발신자에게 RFC 8058 원클릭 수신 거부는 선택 사항이 아닙니다. 2024년 유월부터 Google과 Yahoo 모두 이를 요구합니다.
모든 마케팅 메시지에는 두 개의 헤더가 필요합니다.
List-Unsubscribe: <mailto:unsub@yourdomain.com>, <https://yourdomain.com/unsubscribe?id=123>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickHTTPS URL은 로그인 페이지, 확인 단계, 리디렉션 없이 POST 요청을 직접 받아야 합니다. Google 받은편지함 UI에는 이 헤더에서 가져온 "수신 거부" 링크가 표시됩니다. 헤더가 없거나 형식이 잘못되면 링크가 나타나지 않습니다. 나갈 방법을 찾지 못한 사용자는 메시지를 스팸으로 신고하고, 이로 인해 이메일이 스팸으로 분류되는 악순환이 생겨 끊기가 어려워집니다.
전달로 인한 SPF 손상
이메일 전달 후 스팸으로 분류되는 이유: 이메일 전달은 대부분의 수신 서버에서 SPF를 눈에 띄지 않게 손상시킵니다. 정확한 실패 과정은 다음과 같습니다.
you@yourcompany.com에서 Gmail 주소로 메시지를 보냅니다. 서버 IP가 허용되어 있으므로 SPF를 통과합니다.- 해당 Gmail 계정에서 Yahoo 주소로 전달을 설정했습니다. Gmail은 Gmail의 IP를 사용해 메시지를 Yahoo로 다시 전송합니다.
- Yahoo가 SPF를 확인합니다. 이제 발송 IP는 원래 서버의 IP가 아니라 Gmail의 IP입니다. Gmail의 IP는 원래 도메인의 SPF 레코드에 없습니다. SPF가 실패합니다.
- DKIM도 실패하면(예: Gmail이 전달 과정에서 헤더를 수정한 경우) DMARC도 실패합니다. Yahoo는 메시지를 스팸으로 분류하거나 완전히 거부합니다.
DKIM은 발송 서버가 아니라 메시지 콘텐츠와 선택된 헤더에 서명하므로 전달 후에도 유효한 경우가 많습니다. 2048-bit DKIM 키는 더 강한 암호화 보안을 제공하므로 권장됩니다. 다만 서명된 콘텐츠나 헤더가 수정되면 키 크기와 관계없이 서명이 무효화될 수 있습니다. 전달 시나리오에서는 SRS(Sender Rewriting Scheme)가 return-path를 다시 작성해 전달 경로에서 SPF가 통과할 수 있도록 합니다. 올바른 설정 방법은 SRS 이메일 전달 가이드를 참조하세요.
15분 진단 절차
무언가를 변경하기 전에 실제로 무엇이 실패하는지 확인하세요. 이 절차를 따르면 이미 보유한 도구만으로 15분 안에 이메일이 스팸으로 분류되는 이유를 찾을 수 있습니다.
1단계: 인증 헤더 확인(0-5분)
직접 관리하는 Gmail 주소로 테스트 메시지를 보냅니다. 메시지를 열고 점 세 개 메뉴를 클릭한 다음 "원본 보기"를 선택합니다. Authentication-Results까지 아래로 이동합니다. SPF, DKIM, DMARC 각각의 통과 또는 실패 여부가 표시됩니다. 하나라도 fail로 표시된다면 가장 먼저 수정해야 할 대상입니다.
2단계: DNS 레코드 확인(5-10분)
# Check SPF record
dig txt yourdomain.com +short
# Check DMARC record
dig txt _dmarc.yourdomain.com +short
# Check DKIM (replace 'default' with your actual selector)
dig txt default._domainkey.yourdomain.com +short표시된 내용을 ESP가 요구하는 레코드와 비교하세요. SPF 레코드 설정 가이드에는 일반적인 구성에 맞는 올바른 구문과 조회 한도 10회에 도달한 과도한 SPF 레코드를 평탄화하는 방법이 나와 있습니다.
3단계: IP 및 도메인 평판 확인(10-15분)
Google Postmaster Tools를 열고 도메인 평판과 IP 평판 그래프를 확인하세요. "High"보다 낮은 결과는 모두 조사가 필요합니다. 또한 Spamhaus(SBL 및 XBL)에서 발송 IP를 조회하세요. 인증 상태와 관계없이 이곳에 단 한 번 등재되는 것만으로도 거의 모든 곳에서 차단될 수 있습니다.
구조적 해결책: 호스팅과 발송 분리
인프라가 분리되지 않았을 때 이메일이 스팸으로 분류되는 이유: 대부분의 경우 근본 원인은 누락된 레코드가 아닙니다. 마케팅 트래픽, 트랜잭션 메일, 고객 이메일이 모두 같은 IP와 도메인 평판을 공유한다는 점이 문제입니다. 잘못된 캠페인 하나가 모든 메일에 영향을 줍니다. 격리가 적용되지 않은 공유 인프라에서 손상된 도메인 평판이 연쇄적으로 퍼지는 방식을 알아보세요.
| 상황 | 기존 방식(통합) | TrekMail(분리) |
|---|---|---|
| 마케팅으로 IP 평판 손상 | 트랜잭션 메일도 스팸으로 분류됨 | 별도 SMTP 자격 증명 - 트랜잭션 메일에 미치는 직접적인 영향 축소 |
| 새 고객 도메인 추가 | 기존 발신자와 평판 풀 공유 | 격리된 도메인, 첫날부터 별도의 평판 구축 |
| 고객에게 평판 문제 발생 | 공유 인프라로 영향 확산 | SMTP 자격 증명 교체, 사서함은 그대로 유지 |
| 도메인 10개의 비용 | 사용자별 요금이 빠르게 누적됨($72+/user/year) | $3.50/mo 정액제 - 모든 도메인, 사용자별 요금 없음 |
TrekMail의 BYO SMTP 모델을 사용하면 사서함은 정액제 요금제에 유지하면서 Amazon SES, SendGrid 또는 Mailgun을 아웃바운드 발송에 연결할 수 있습니다. 트랜잭션 메일에는 한 SMTP 자격 증명을, 마케팅에는 별도의 자격 증명을 사용하세요. 서로 다른 IP와 별도의 평판 풀을 사용하면 상호 영향을 줄일 수 있습니다. 에이전시는 사서함 구성을 변경하거나 데이터를 이전하지 않고도 고객별로 SMTP 자격 증명을 교체할 수 있습니다.
내장된 SPF/DKIM/DMARC 마법사가 각 도메인의 정렬 설정을 개별적으로 안내합니다. 다중 도메인 대시보드에서는 모든 도메인의 인증 상태를 한 화면에서 확인할 수 있습니다.
Nano 요금제: $0, 도메인 10개, 저장 공간 5GB, BYO SMTP, 신용카드 없이 항상 무료입니다. Starter: $3.50/mo 정액제, 도메인 50개, 15GB, 관리형 SMTP 포함, 14일 무료 체험(체험에 신용카드 필요).
무료로 시작하세요 - 신용카드와 체험 없이 첫날부터 도메인 10개와 BYO SMTP를 사용할 수 있습니다. 관리형 SMTP가 필요하다면 요금제를 확인하고 14일 Starter 체험을 시작하세요.
이메일이 스팸으로 분류되는 이유를 묻는 데서 그치지 말고 구조를 바로잡으세요
이메일이 스팸으로 분류되는 이유는 거의 언제나 누락된 레코드 하나로 설명되지 않습니다. 공유 ESP를 통한 정렬 실패, 알지 못했던 전달 경로 때문에 높아진 신고율, 워밍업을 건너뛰어 발생한 Microsoft의 IP 차단, 또는 모든 메일이 같은 인프라를 사용해 마케팅 평판이 트랜잭션 발송까지 오염시키는 문제 등이 함께 작용하는 경우가 많습니다.
위의 진단 절차로 기술적 문제를 해결하세요. TrekMail의 BYO SMTP 아키텍처로 구조적 문제를 해결하세요. 첫 번째 방법은 화재를 예방하고, 두 번째 방법은 그래도 화재가 발생했을 때 피해가 번지지 않게 합니다.
신용카드 없이 도메인 10개로 무료로 시작하거나, 사용자별 요금 없이 도메인마다 발송 평판을 격리하고 모든 항목을 하나의 대시보드에서 관리할 수 있는 $3.50/mo 정액제 Starter 요금제를 살펴보세요.
