이메일이 스팸함으로 가는 현상은 문구만의 문제가 아니다. 인프라와 발송 방식이 원인일 수 있다. 청구서, 비밀번호 재설정, 견적서, 온보딩 메일이 스팸함으로 가면 먼저 인증, DNS, 평판, 발송 경로를 확인한다. 플랫폼 선택과 비용은 소규모 기업용 비즈니스 이메일 가이드를 참고하고, 여기서는 필터링 원인과 진단 순서를 다룬다.
잘못된 SPF 레코드, 정렬되지 않은 DKIM 서명, 한 주 동안의 높은 신고율은 이후 발송에 영향을 줄 수 있다. 추측 대신 순서대로 조사해야 한다.
정상적인 이메일도 왜 스팸함으로 갈까?
수신 서버가 발신자를 충분히 신뢰하지 않는 경우가 많다. Gmail, Yahoo, Outlook은 인증, 정렬, DNS 상태, 신고율, 발송 행태뿐 아니라 콘텐츠와 링크도 함께 평가한다.
2025년과 2026년에는 적용 대상 발신자에게 SPF, DKIM, DMARC, TLS, PTR, 적절한 수신 거부 절차가 요구될 수 있다. Google 지침은 미준수가 속도 제한이나 차단에 영향을 줄 수 있다고 설명한다.
오십 개 고객 도메인을 운영한다면 관리 부담이 커진다. 현재 안내 기준 TrekMail은 사용자 정의 도메인, IMAP 사서함, catch-all, 전달, BYO SMTP 또는 관리형 SMTP, IMAP 마이그레이션을 제공한다. 조건은 확인해야 한다. 유료 요금제는 현재 월 $3.50부터이며 Nano는 무료일 수 있고 유료 요금제에는 14일 체험이 적용될 수 있다.
가장 먼저 볼 곳
메시지 헤더가 빠른 기술적 단서를 제공한다. 필터링된 메시지를 열고, 신뢰할 수 있는 수신 측이 추가한 Authentication-Results에서 SPF, DKIM, DMARC와 표시 From 도메인의 정렬을 확인한다.
DMARC는 정렬된 SPF 또는 유효하게 통과하고 정렬된 DKIM으로 통과할 수 있지만, 정렬되지 않은 결과만으로는 부족하다. RFC5322 From과 envelope 또는 서명 도메인의 관계를 확인해야 한다.
먼저 다음을 확인한다.
- Gmail, Outlook, Apple Mail에서 원본 헤더를 연다.
Authentication-Results를 찾는다.spf=pass,dkim=pass,dmarc=pass를 확인한다.- From 도메인이 유효하게 통과한 SPF 또는 DKIM 도메인과 정렬되는지 본다.
- DMARC가 실패하면 정렬부터 고치고 다른 신호도 계속 조사한다.
TrekMail 스팸 문제 해결 FAQ도 참고할 수 있다.
흔한 기술적 실패 세 가지
SPF 조회 초과, DKIM 문제, DMARC 정렬 오류가 자주 관련된다.
1. SPF 조회 제한. RFC 7208은 평가 중 DNS를 조회하는 메커니즘과 수정자를 10개로 제한한다. 공급자와 중첩 include가 늘면 오류가 날 수 있다.
example.com. IN TXT "v=spf1 include:spf.trekmail.net include:sendgrid.net include:_spf.google.com -all"공급자가 중첩 include를 바꾸면 결과도 달라질 수 있다.
2. DKIM은 통과하지만 정렬되지 않는다. d=vendor.com으로 서명하고 표시 From이 yourdomain.com이라고 그 자체로 잘못은 아니다. organizational 또는 strict 모드에 따라 정렬되지 않을 수 있으며, 다른 유효한 정렬 방식이 DMARC를 통과시킬 수도 있다.
3. DMARC가 없거나 관리되지 않는다. Google은 적용 대상 대량 발신자에게 DMARC를 요구한다. 보고서는 불완전한 증거일 수 있으므로 로그와 헤더도 함께 본다.
; baseline records
@ IN TXT "v=spf1 include:spf.trekmail.net -all"
dkim._domainkey IN TXT "v=DKIM1; k=rsa; p=YOUR_PUBLIC_KEY"
_dmarc IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com"이는 예시일 뿐 보편적인 시작 템플릿이 아니다. TrekMail DNS 문서는 다중 도메인 이메일 호스팅의 레코드 관리에 참고가 된다.
DNS와 네트워크 상태
수신자는 PTR, forward-confirmed reverse DNS, 발송 인프라도 볼 수 있다. 오래된 MX는 주로 수신 라우팅 문제이며 그 자체가 발신 스팸 분류의 보편적 원인은 아니다.
Google의 적용 지침은 실제 발송 IP에 PTR과 일치하는 정방향 DNS를 요구한다.
예를 들어 다음을 확인한다.
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short MX example.com
dig +short PTR 203.0.113.10
host mail.example.com결과는 진단 단서다.
| 문제 | 관찰 결과 | 영향 | 대응 |
|---|---|---|---|
| SPF 조회 과다 | 간헐적 SPF 실패 | 유효한 SPF 통과가 없음 | include를 줄이고 flattening 사용 시 지속적으로 갱신 및 검증 |
| 오래된 MX | 혼합 라우팅과 반송 | 수신 메일이 잘못 갈 수 있음 | 확인된 오래된 MX 제거 |
| PTR/rDNS 없음 | 차단 또는 필터링 | 발송 IP의 기대 신호 부족 | IP를 직접 관리하면 PTR을 설정하고, 아니면 공급자에게 요청한 뒤 정방향 DNS 확인 |
| 공급자 도메인 DKIM | DKIM pass, DMARC fail | 정렬이 없을 수 있음 | 지원된다면 자체 도메인 서명 구성 |
현재 기능에 따라 TrekMail IMAP 마이그레이션은 Gmail, Microsoft 365, 일반 IMAP에서 메일을 가져올 수 있지만 DNS, 앱, 발송 경로까지 자동 이전하거나 무중단을 보장하지 않는다. 필수 DNS 레코드를 별도로 확인한다.
DNS 수정 후에도 평판이 남는 이유
평판은 수정에 늦게 반응한다. 공급자는 신고, 참여, 반송, 워밍업, 발송 일관성을 고려할 수 있다.
수정 직후 20,000건으로 급격히 늘리는 상황은 평가를 어렵게 할 수 있다. 결과 하나만으로 수정 효과를 판단할 수 없다.
Google FAQ에 따르면 적용 대상 대량 발신자는 사용자 신고 스팸 비율이 0.3%를 넘으면 그 비율을 연속 일곱 날 동안 기준 아래로 유지할 때까지 완화 대상에서 제외될 수 있다. 이는 보편적인 수신함 경계가 아니다.
1,000건을 보내고 약한 평판 때문에 150건만 받은편지함에 도착했는데 두 사용자가 스팸으로 신고했다면, 받은편지함 기준 예시 비율은 1.33%다. 이 예만으로 다음 전달 결과를 예측할 수는 없다.
기술 수정 후에는 다음을 고려한다.
- 발송량을 일시적으로 줄이고 동의가 확인된 최근의 활성 수신자에게 보낸다.
- 구매 목록은 중단하고 오래되거나 불확실한 세그먼트는 보류한다.
- Google Postmaster Tools의 제한적인 신호를 계속 확인한다.
적용 대상 마케팅 메일에서는 mailto:만으로 원클릭 수신 거부 요건을 충족하지 못한다. RFC 8058은 헤더와 POST 흐름을 규정한다.
List-Unsubscribe: <https://example.com/unsub/abc123>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickList-Unsubscribe=One-Click 신호를 사용하고 관련 헤더를 DKIM 서명 범위에 넣는다.
트랜잭션 메일이 스팸으로 갈 때
계정 접근, 결제, 영수증과 신뢰에 영향을 줄 수 있다. 공유 평판, 정렬, 전달, 프로모션과 같은 경로 사용이 원인일 수 있다.
위험 평가상 필요하다면 별도 도메인이나 하위 도메인, 적절한 워밍업과 모니터링으로 흐름을 구분한다.
TrekMail에서는 중앙화가 운영 선택지가 된다.
기존 방식: 사용자별 제품에 전달, 발송 공급자, 도메인별 DNS를 각각 결합한다.
새 방식: 사서함, 전달, 도메인, SMTP 선택을 함께 관리한다. 현재 조건에서 Nano는 BYO SMTP를 사용하고 유료 요금제는 관리형 SMTP를 제공할 수 있다. 어느 쪽도 평판 이전이나 전달을 보장하지 않는다.
TrekMail 관리형 SMTP, 도메인 이메일 만들기, 최신 문서에서 IMAP 지원과 POP3 미지원 여부를 확인한다.
빠른 운영 점검 순서
헤더, DNS, 평판, 콘텐츠 순서는 유용한 진단 방식이지 원인에 대한 확정은 아니다.
다음 순서로 본다.
- 필터링된 메시지 하나의 원본 헤더를 조사한다.
- SPF, DKIM, DMARC와 정렬을 확인한다.
- SPF, MX, DMARC, DKIM, PTR을 조회한다.
- Postmaster의 평판과 신고 추이를 본다.
- 필요한 경우 트랜잭션과 프로모션 흐름을 구분한다.
- 적용 대상 마케팅에 원클릭 헤더를 추가한다.
- 신고 신호를 보는 동안 발송량을 줄인다.
새 도메인은 상황에 맞게 점진적으로 발송하며 보편적인 기간은 없다. 오래된 목록은 동의와 유효성을 다시 확인한다. 공급자 다섯 곳과 관리자 세 명을 통합하면 작업이 줄 수 있지만 비용 절감이나 평판 회복을 보장하지 않는다.
현재 페이지에서 Nano의 $0 조건은 BYO SMTP로 최대 10개 도메인에 적용될 수 있고, Starter는 월 $3.50, Pro는 월 $10, Agency는 월 $23.25부터다. 연간 결제에는 20% 할인 표기가 있고 Enterprise는 맞춤 조건이다. https://trekmail.net/pricing에서 최신 조건을 확인한다.
결론
스팸 분류는 인증, 정렬, DNS, 신고, 콘텐츠, 발송 행태와 관련될 수 있으며 완전히 예측할 수 없다.
헤더를 읽고 레코드를 수정하며 실제 발송 IP의 PTR을 확인한다. 필요할 때 흐름을 나누고 적용 범위에서 RFC 8058을 사용한다. TrekMail은 도메인과 사서함, SMTP 선택을 묶을 수 있지만 수신함 도착을 보장하지 않는다.
Google 발신자 요구사항 FAQ와 RFC 8058을 참고한다.
