이메일이 스팸으로 분류되는 기술적 이유

이메일이 스팸으로 분류되는 이유는 “내용이 광고 같아서”만이 아닙니다. 실제로는 메일 서버(구글, 네이버, 다음 등)가 여러 신호를 점수화해서 이 발신자가 믿을 만한가, 이 메일이 정상적인 전달 방식인가, 수신자에게 도움이 되는가를 종합 판단합니다. 아래는 운영자 관점에서 자주 터지는 “기술적 원인”들입니다.

1) SPF 설정이 없거나 실패한다

SPF는 “이 도메인에서 메일을 보낼 수 있는 서버(IP)가 맞는지”를 증명하는 DNS 기록입니다.
수신 서버는 발신 IP가 SPF에 등록되어 있는지 확인합니다.

스팸으로 가는 대표 상황

• SPF 레코드가 아예 없음
• 발신 서버가 SPF에 포함되지 않음
• SPF가 여러 개로 중복되어 파싱 실패
• ~all(softfail)로 느슨하게 두거나, 반대로 잘못된 -all로 정상 발신도 fail

2) DKIM 서명이 없거나 검증 실패한다

DKIM은 이메일 본문/헤더에 디지털 서명을 붙여 “전송 중 위변조가 없고, 이 도메인이 서명한 메일이 맞다”를 증명합니다.
서명이 없거나 검증이 깨지면 신뢰 점수가 크게 떨어집니다.

자주 발생하는 실패 원인

• DKIM 레코드(공개키) DNS 설정 오류
• 메일 발송 후 중간 시스템이 본문을 수정(푸터 삽입, 링크 변환 등)해 서명이 깨짐
• 잘못된 selector 사용, 키 교체 후 반영 지연

3) DMARC가 없거나 정책이 약하다

DMARC는 SPF/DKIM 결과를 바탕으로 “검증 실패 메일을 어떻게 처리할지” 수신 서버에 지침을 주는 정책입니다. 또한 “From(보내는 사람 주소)” 도메인 사칭을 막는 역할이 큽니다.

스팸으로 가는 패턴

• DMARC가 없어서 도메인 신뢰가 낮음
• p=none만 유지하며 보고서만 받고 실제 보호를 안 함
• 정렬(alignment)이 맞지 않아 DMARC fail (특히 발송 대행/마케팅 툴 사용 시)

4) rDNS(PTR)와 HELO/EHLO가 불일치하거나 이상하다

메일 서버는 연결할 때 자신을 소개(HELO/EHLO)하고, 발신 IP에는 역방향 DNS(PTR)가 붙어 있는 것이 정상적입니다. 이게 없거나 이상하면 “정체가 불분명한 발신”으로 봅니다.

스팸으로 가는 원인

• PTR 레코드 없음(특히 새로 만든 서버, 저가 VPS)
• PTR 도메인과 실제 발송 도메인이 완전히 무관
• HELO 문자열이 IP 그대로이거나 임의 값
• HELO 도메인이 DNS에서 해석되지 않음

5) 발신 IP/도메인 평판(레퓨테이션)이 나쁘다

수신 서버는 발신 IP와 도메인에 대해 “이전에 스팸을 보냈는지, 반송이 많았는지” 같은 평판 데이터를 가지고 있습니다.

평판이 나빠지는 대표 원인

• 예전에 같은 IP를 쓰던 사람이 스팸 발송(공유 IP 문제)
• 새 IP로 갑자기 대량 발송(워밍업 없이)
• 반송(bounce)이 과도함(없는 주소로 발송)
• 스팸 신고율이 높음

6) 메일 본문이 HTML만 있고 텍스트 파트가 없다

정상적인 이메일은 보통

• 텍스트 버전(Plain text)
• HTML 버전
  을 함께 포함합니다(멀티파트). HTML만 있는 메일은 스팸/피싱에 자주 사용되어 감점 요인이 될 수 있습니다.

7) 링크/도메인 구성 자체가 의심 신호를 만든다

본문 링크가 기술적으로 의심스러우면 필터에 걸리기 쉽습니다.

대표 예시

• 단축 URL 남발
• 표시 텍스트와 실제 링크가 다름
• 추적 파라미터가 과도함
• 링크 도메인의 평판이 낮음(새로 만든 도메인, 무료 호스팅 도메인 등)
• HTTPS가 아니거나 인증서가 이상함

8) 첨부파일 정책에 걸린다

실행 파일, 매크로 문서 등은 많은 메일 서버에서 강하게 차단하거나 스팸 처리합니다.

의심을 부르는 패턴

• exe, js, bat 같은 파일(직접 또는 zip 내부)
• 매크로 포함 문서
• 비밀번호 걸린 압축파일(검사 회피로 간주)
• 첨부파일 대비 본문이 너무 짧음

9) 전송 방식/헤더가 비정상적이다

메일은 헤더 구조가 꽤 엄격합니다. 일부 저가 발송 스크립트나 잘못된 설정은 헤더를 비정상적으로 만들어 스팸 점수를 올립니다.

예시

• Date, Message-ID 누락 또는 형식 오류
• From과 Return-Path(반송 주소) 불일치가 심함
• 수신 서버가 보기엔 중계 릴레이처럼 보이는 경로
• 인증되지 않은 SMTP 릴레이 사용

10) 발송량 패턴이 스팸과 비슷하다

기술적으로도 “패턴”은 강력한 신호입니다.

• 새 도메인/새 IP로 갑자기 대량 발송
• 짧은 시간에 동일 본문 대량 발송
• 수신자 반응(열람/클릭) 저조 + 삭제/신고 증가
• 밤 시간대 특정 구간에 폭발적으로 발송

수신 서버 입장에서는 이런 패턴이 “봇이 뿌리는 스팸”과 유사하게 보일 수 있습니다.

운영자 체크리스트(기술 쪽 우선순위)

스팸 분류를 줄이려면 아래 순서로 점검하면 효율적입니다.

1. SPF/DKIM/DMARC 설정과 결과(pass/fail) 확인
2. 발신 IP가 공유인지 전용인지 확인, 평판 문제 점검
3. PTR(rDNS) 설정과 HELO/EHLO 정상 여부 확인
4. HTML+텍스트 멀티파트 구성, 링크/첨부파일 정책 점검
5. 대량 발송이면 워밍업과 반송 관리(리스트 정리) 적용

결론

이메일이 스팸으로 분류되는 기술적 이유는 크게 “인증 실패(SPF/DKIM/DMARC)”, “서버 정체성 문제(PTR/HELO)”, “평판(발신 IP/도메인)”, “콘텐츠/패턴(링크·첨부·발송량)”으로 나뉩니다. 특히 요즘은 인증 3종 세트와 발신 평판이 기본값이 되었기 때문에, 여기서 하나만 흔들려도 스팸함으로 빠질 확률이 크게 올라갑니다.