이메일이 스팸으로 분류되어도 처음에는 성공적으로 전송된 것처럼 보일 수 있습니다. 서버 로그에는 250 OK가 반환됩니다. 메시지가 도착했다고 생각합니다. 이틀 뒤에야 제안서가 정크 메일함에 방치되어 있었거나, 더 심한 경우 수신자가 로그인하기도 전에 게이트웨이 필터가 아무 알림 없이 삭제했다는 사실을 알게 됩니다.
대부분은 이메일이 스팸으로 분류되면 제목을 고쳐 쓰거나 이미지를 제거합니다. 하지만 이는 시간 낭비입니다. 2026년에는 특정 단어 때문에 스팸으로 분류되는 경우가 드뭅니다. 핵심은 인프라, 인증, 평판입니다. 이 요소들이 잘못되면 다른 것은 아무 소용이 없습니다.
Google, Yahoo, Microsoft가 2024년 초부터 엄격한 기술 표준을 적용하면서 규칙은 영구적으로 바뀌었습니다. 요건을 충족하지 못하면 메일이 들어가지 않습니다. 이 가이드는 메시지가 실패하는 정확한 이유를 찾고 각각의 근본 원인을 빠르게 해결하는 엄격한 단계별 진단 절차를 제공합니다.
스팸은 증상이지 근본 원인이 아닙니다
“내 이메일이 스팸으로 갔다”는 말은 실제로 서로 다른 세 가지 기술적 실패를 아우릅니다. 이메일이 스팸으로 가는 것을 막으려면 먼저 어느 범주에 해당하는지 파악해야 합니다. 설정을 하나라도 건드리기 전에 반송 로그나 메시지 헤더를 확인해 해당 범주를 찾으세요.
| 실패 유형 | 증상 | 가능성이 높은 근본 원인 |
|---|---|---|
| 배치 성능 저하 | 메시지는 도착하지만 정크/스팸 메일함에 들어감 | 평판 또는 콘텐츠 문제입니다. 인증은 통과하지만 수신 측이 발신자를 신뢰하지 않습니다. |
| 게이트웨이 거부(5xx) | 550 5.7.1 오류와 함께 즉시 반송됨 |
정책 또는 차단 목록 문제입니다. DMARC에 실패했거나 IP가 Spamhaus에 등재되어 있습니다. |
| 블랙홀 | 서버는 250 OK라고 하지만 수신자에게 아무것도 보이지 않음 |
격리 문제입니다. Microsoft 365에서 흔하며, 메시지를 수락한 뒤 아무 알림 없이 삭제합니다. |
실패 유형마다 해결책이 다릅니다. 이메일을 스팸으로 보내는 원인이 어느 것인지 알면 문제의 절반은 해결한 셈입니다. 잘못된 문제를 다루면 메시지가 계속 사라지는 동안 며칠씩 헛된 원인을 쫓게 됩니다.
되돌릴 수 없는 대량 발신자 기준
진단 절차를 실행하기 전에 적용되는 기준을 알아야 합니다. 개인 Gmail 계정으로 보내는 이메일이 Google의 기준인 약 5,000개를 단일 24시간 동안 넘으면 영구적으로 “대량 발신자”로 분류됩니다. 나중에 발송량이 줄어도 더 엄격한 준수 기준이 계속 적용됩니다. 이의를 제기할 절차는 없습니다.
이메일이 자주 스팸으로 가는 소규모 기업은 하루에 50개만 보내므로 DMARC가 적용되지 않는다고 생각하곤 합니다. 이는 사실이 아닙니다. Microsoft와 Yahoo는 발송량과 관계없이 새 도메인에서 온 인증되지 않은 메일을 거부합니다. SPF와 DKIM을 올바르게 설정하지 않으면 수신 메일 서버는 해당 도메인을 봇넷과 구분할 수 없습니다.
스팸으로 가는 이메일을 위한 15분 진단 절차
이메일이 스팸으로 갈 때 따라야 할 핵심 진단 순서입니다. 단계를 건너뛰거나 앞 단계보다 먼저 진행하지 마세요. 인증이 잘못되었다면 아무리 평판이 좋아도 소용없습니다. 반드시 인증, 평판, 콘텐츠 순으로 점검하세요.
1단계: 인증(철의 삼각형), 5분
SPF, DKIM, DMARC의 세 가지 검사를 모두 통과해야 합니다. 삼각형의 어느 한 축이라도 잘못되면 평판을 따지기도 전에 입구에서 차단됩니다. 명령줄의 dig 또는 MXToolbox로 각각을 확인하세요.
1. SPF(Sender Policy Framework)
검사 항목: 이메일을 실제로 보내는 IP 주소가 도메인의 DNS TXT 레코드에 나열된 IP와 일치합니까?
실패 원인: 10회 조회 제한입니다. SPF 레코드에는 DNS 조회를 10회까지만 허용하는 엄격한 상한이 있습니다. Google Workspace, Outlook, Mailchimp, Zendesk와 CRM을 모두 include:하면 쉽게 한도를 넘습니다. 그 결과 PermError가 발생합니다. 수신 측은 SPF 레코드 전체를 유효하지 않은 것으로 처리하며, 이는 레코드가 아예 없는 것보다 더 나쁩니다. 이 설정 오류 하나가 이메일이 스팸으로 가는 주요 원인 중 하나입니다.
해결 방법: include: 메커니즘을 점검하고 더 이상 사용하지 않는 서비스를 제거하세요. 전체 절차가 필요하다면 SPF 레코드 설정 가이드를 참고하세요.
2. DKIM(DomainKeys Identified Mail)
검사 항목: 발신 이메일의 암호화 서명이 유효하고 온전합니까?
실패 원인:
- 키 길이: Google은 최소 1024비트 키를 요구하며 2048비트를 강력히 권장합니다. 기존의 512비트 키는 보안 위험일 뿐 아니라 도달률에 문제가 있다는 신호이기도 합니다.
- 선택자 불일치: DNS에는
s=selector1아래에 키가 게시되어 있지만 메일 서버가s=selector1-2026으로 메시지에 서명한다면 DKIM 검증은 아무 알림 없이 실패합니다. 이메일은 서명되지 않은 것처럼 보이며, 이런 이메일이 스팸으로 가는 것은 예상되는 결과입니다.
3. DMARC(정책 집행자)
검사 항목: 최소한 p=none이 지정된 DMARC DNS 레코드를 게시했습니까?
실패 원인: 정렬 문제입니다. 대다수 소규모 기업은 SPF와 DKIM이 각각 통과하더라도 이 지점에서 DMARC에 실패합니다. 설정이 올바르게 보이는데도 이메일이 스팸으로 가게 됩니다.
DMARC 정렬이란 사용자에게 보이는 보낸 사람 주소의 도메인이 SPF 또는 DKIM을 통과한 도메인과 일치해야 한다는 뜻입니다. Mailchimp 같은 ESP를 통해 보내면 반송 처리를 위해 Return-Path(봉투 발신자)가
mailchimp.com을 가리키는 경우가 많습니다. Mailchimp 서버의 SPF는 통과하지만 SPF 정렬은 실패합니다.mailchimp.com이yourcompany.com과 일치하지 않기 때문입니다.
해결 방법: 대신 DKIM 정렬을 사용하세요. 자체 도메인에 연결된 DKIM 키로 발신 이메일에 서명하도록 ESP를 설정합니다. 대부분의 서비스는 설정 화면에서 이를 “Custom Domain Authentication” 또는 “Domain Verification”이라고 부릅니다.
2단계: 평판(0.3% 절벽), 5분
인증을 모두 문제없이 통과한다면 다음에는 발신자 평판을 확인합니다. 도메인의 신용 점수라고 생각하면 됩니다. 이 점수가 떨어지면 이메일은 결국 스팸으로 갑니다. Google Postmaster Tools를 열고 도메인 평판 등급을 확인하세요. 등급은 High, Medium, Low 또는 Bad입니다.
0.3% 규칙: 스팸 신고율을 확인하세요. 0.3%, 즉 신고 3건을 이메일 1,000개당 넘으면 제재 대상이 됩니다. Google은 마케팅 트래픽을 제한하거나 곧바로 스팸으로 보낼 수 있습니다.
복구 방법: 모든 마케팅 발송을 즉시 중단하세요. 2-4주 동안 참여도가 가장 높은 사용자에게 청구서, 비밀번호 재설정, 주문 확인 같은 트랜잭션 메일만 보내세요. 신뢰를 서서히 회복할 수 있습니다.
Yahoo의 받은편지함 분모 함정
Yahoo는 Google과 다르게 스팸 비율을 계산하므로 예상치 못한 문제가 생길 수 있습니다. 분모로 받은편지함에 도착한 수를 사용하며, 전체 발송량을 사용하지 않습니다. 이것이 위험한 이유는 다음과 같습니다.
- Yahoo 주소로 이메일 1,000개를 보냅니다.
- 900개는 스팸으로 갑니다. 받은편지함에는 100개만 도착합니다.
- 1명이 그 100명 중에서 “스팸 신고”를 클릭합니다.
- 신고율: 1 / 100 = 1.0%이며 안전 기준의 세 배가 넘습니다.
Yahoo의 계산 방식에서는 예상보다 훨씬 빨리 제재 기준에 도달하며, 그 결과 이메일이 스팸으로 분류되면서 피해가 더 빠르게 커집니다.
3단계: 기술적 건전성과 콘텐츠, 5분
인증과 평판을 고친 뒤에도 이메일이 계속 스팸으로 간다면 기술적 건전성을 확인하세요. 최신 스팸 필터는 정상 발신자는 포함하지만 스팸 발신자는 대개 생략하는 표지를 검사합니다.
1. FCrDNS(Forward-Confirmed Reverse DNS)
모든 발신 IP에는 호스트 이름으로 확인되는 PTR 레코드(역방향 DNS)가 필요하며, 그 호스트 이름은 다시 같은 IP를 가리켜야 합니다. 이런 양방향 확인은 해당 인프라를 제어하고 있음을 증명합니다.
검사: dig -x <your-sending-IP>를 실행하고 결과를 확인하세요.
실패: IP가 NXDOMAIN이나 ip-192-168-1-1.cloudprovider.com 같은 일반 호스트 이름으로 확인되면 메일 서버는 해당 서버를 침해되었거나 일회용인 호스트로 취급합니다.
2. RFC 8058: 원클릭 수신 거부
Google과 Yahoo는 2024년 유월부터 모든 마케팅 및 홍보 메일에 기계가 읽을 수 있는 원클릭 수신 거부 헤더를 요구합니다. 이메일 헤더에는 다음 두 줄이 모두 있어야 합니다.
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://yourdomain.com/unsubscribe...>
이 헤더가 없으면 Gmail에서 발신자 이름 옆에 “수신 거부” 버튼이 표시되지 않습니다. 사용자는 대신 “스팸 신고”를 클릭하며, 이메일 발신자 평판이 직접 타격을 받습니다. 전체 규격은 IETF RFC 8058에 정의되어 있습니다.
3. 링크 평판
링크 평판은 이메일이 스팸으로 가는 원인 중 쉽게 놓치는 항목입니다. 필터는 이메일 본문에 포함된 모든 URL을 실시간 차단 목록과 대조합니다.
- URIBL/SURBL: 수상한 제휴 URL, 침해된 WordPress 사이트, 광고가 게시된 만료 도메인처럼 차단 목록에 오른 도메인으로 연결하면 이메일 전체가 차단됩니다.
- 공용 단축 URL: 이메일에서
bit.ly나tinyurl을 사용하지 마세요. 스팸 발신자가 이를 심하게 악용하므로 필터는 실제 연결 대상과 관계없이 단축 URL에 기본적으로 불이익을 줍니다.
헤더 포렌식: 사실 확인하기
이메일이 스팸으로 가는 이유를 확실히 진단해야 할 때는 원본 메시지 헤더가 정확히 무슨 일이 있었는지 알려 줍니다. Gmail에서 의심되는 메시지를 열고 점 세 개 메뉴를 클릭한 다음 “원본 보기”를 선택하세요. Authentication-Results 헤더를 찾습니다.
시나리오 A: 정렬 실패
이 이메일은 기술적으로 SPF와 DKIM을 통과했지만 도메인이 정렬되지 않아 DMARC에는 실패했습니다.
Authentication-Results: mx.google.com;
dkim=pass header.i=@sendgrid.net;
spf=pass (sendgrid.net designates 167.89.x.x as permitted);
dmarc=fail header.from=yourcompany.com
DKIM 서명은 자체 도메인이 아닌 SendGrid에서 왔습니다. SPF 역시 SendGrid를 가리킵니다. 어느 쪽도 From 헤더의 yourcompany.com과 정렬되지 않으므로 DMARC가 실패합니다.
시나리오 B: Microsoft 평판 제재
Microsoft의 헤더는 더 상세합니다. X-Forefront-Antispam-Report 필드를 찾으세요.
X-Forefront-Antispam-Report: ... SCL:5 ... CAT:SPM ...
SCL:9 값은 IP가 강력하게 차단되었을 가능성이 높다는 뜻입니다. SCL:5는 콘텐츠 또는 평판 기반 필터에 걸렸음을 나타냅니다.
빠른 해결 방법 표
진단 절차를 통해 근본 원인을 찾아냈다면 아래 표에서 그에 맞는 해결 방법을 적용하세요.
| 근본 원인 | 해결 방법 |
|---|---|
| 인증/정렬 실패 | ESP에서 사용자 지정 도메인 인증을 설정하세요. DKIM d= 태그가 보낸 사람 주소의 도메인과 일치하는지 확인합니다. |
| Google 평판(Low/Bad) | 모든 마케팅 발송을 중단하세요. 신뢰를 회복하기 위해 2-4주 동안 참여도가 높은 사용자에게 트랜잭션 메일만 보냅니다. |
| 차단 목록(Spamhaus 등) | Spamhaus에서 IP와 도메인을 확인하세요. 목록 삭제를 요청하고 근본 문제를 해결했다는 증거를 제시합니다. |
| 콘텐츠/링크 | URL 단축 서비스를 제거하세요. RFC 8058에 따른 원클릭 수신 거부 헤더를 추가하고 유효한 실제 우편 주소를 포함합니다. |
| Microsoft 발송 제한 | 시간당 발송량을 줄이세요. 공유 IP를 사용한다면 전용 IP를 요청하거나 더 깨끗한 인프라를 갖춘 서비스로 전환합니다. |
DNS와 씨름하지 말고 TrekMail에 인프라를 맡기세요
이메일이 반복적으로 스팸으로 가는 경우 헤더를 진단하고 DNS 레코드를 직접 관리하는 것은 어려운 방법입니다. 계속 신경을 써야 하며 TXT 레코드에서 문자 하나만 틀려도 누군가 알아차리기 전까지 며칠 동안 전체 이메일 흐름이 조용히 중단될 수 있습니다.
TrekMail은 이 전체 인프라 구성을 간소화하여 실제 이메일 발송에 집중할 수 있게 합니다.
- SPF/DKIM/DMARC 마법사: 도메인에 필요한 정확한 DNS 레코드를 생성합니다. 복사해서 등록기관에 붙여 넣으면 끝입니다.
- 관리형 SMTP(Starter 월 $3.50): IP 평판, 전송 헤더, 워밍업을 관리합니다. 이메일 작성에 집중하고 사라진 이유를 디버깅할 필요가 없습니다.
- BYO SMTP: 발신에 Amazon SES나 SendGrid를 사용하고 싶나요? TrekMail은 기본적으로 연동됩니다. 대용량 서비스의 도달률 인프라를 바탕으로 TrekMail의 깔끔한 받은편지함 인터페이스를 이용할 수 있습니다.
- 도메인 워밍업: 새 도메인인가요? 첫날부터 평판을 망치는 대신 좋은 평판을 쌓도록 몇 주에 걸쳐 발송량을 서서히 높입니다.
- SRS 전달: SPF 인증을 깨뜨리지 않고 도메인 사이에서 메일을 전달합니다. Sender Rewriting Scheme 가이드에서 작동 방식을 알아보세요.
이메일이 스팸으로 가서 비즈니스에 비용이 발생한다면 요금제는 Free($0, 신용카드 불필요)부터 Agency(월 $23.25)까지 제공되며, 단일 대시보드에서 100+개 고객 도메인을 관리할 수 있습니다. 모든 유료 요금제에는 14일 무료 체험이 포함됩니다.
이메일이 스팸으로 간다면 추측을 멈추고 진단을 시작하세요. 위의 15분 진단을 실행하고 실제 근본 원인을 해결한 다음 중요한 업무로 돌아가세요.
TrekMail 무료로 사용해 보기를 통해 DNS로 인한 골칫거리를 완전히 덜어 보세요.
