지금 해결하려는 것

메일이 반송되는 게 아닙니다. 보내지고, 겉보기엔 성공했는데, 수신자의 정크함에 들어갑니다 — 더 나쁘게는 수신자가 확인하는 어떤 폴더에도 닿기 전에 조용히 걸러집니다. 이건 반송과는 다른 실패이고 다른 접근이 필요합니다. 로그의 어떤 것도 이 일이 일어났다고 알려주지 않기 때문입니다. 수신 서버는 메일을 수락한 다음, 받은편지함에 넣을 만큼 신뢰하지 않기로 조용히 결정한 것입니다.

그 결정은 대체로 세 가지에 달려 있습니다. 당신이 주장하는 그 사람이 맞는지(인증), 발송 출처가 얌전히 굴어온 이력이 있는지(평판), 그리고 메일 받는 사람이 실제로 그걸 원하는지(참여도). 그 목록에 없는 것에 주목하세요. 메일 속 정확한 단어입니다. 이 가이드는 앞의 둘을 바로잡는 글입니다. 진짜 전달률 문제는 거의 전부 거기 있으니까요.

인증: 통과만으로는 부족하다 — 정렬돼야 한다

모든 전달률 체크리스트가 SPF, DKIM, DMARC를 설정하라고 합니다. 대부분 거기서 멈추고, 그래서 그토록 많은 “완전 인증” 도메인이 여전히 스팸함에 갑니다. 빠지는 부분이 **정렬(alignment)**입니다.

  • SPF는 당신 도메인을 대신해 어떤 서버가 발송할 수 있는지 말합니다. 수신자에게 보이는 From: 주소가 아니라 봉투(envelope) 발신자(숨은 반송 경로 주소)를 검사합니다.
  • DKIM은 서명 도메인에 묶인 암호 서명을 붙여, 메일이 전송 중 위조되지 않았음을 증명합니다.
  • DMARC는 이 둘을 묶고 — 이게 핵심입니다 — SPF나 DKIM이 검증한 도메인이 보이는 From: 주소의 도메인과 실제로 일치하는지 확인합니다.

함정은 여기 있습니다. 마케팅 플랫폼이나 트랜잭션 서비스를 통해 보냅니다. 그들 서버는 SPF를 통과하지만 그들의 반송 도메인으로 통과합니다. DKIM으로 서명하지만 그들의 서명 도메인으로 서명합니다. 둘 다 통과하고 — 둘 다 DMARC 정렬에 실패합니다. 어느 것도 당신 From: 주소와 일치하지 않기 때문이죠. 엄격한 필터에게 SPF도 DKIM도 통과했지만 어느 쪽과도 정렬되지 않은 메일은 인증 안 된 것이고, 스푸핑과 똑같이 취급됩니다. 통과가 결승선이 아닙니다. 정렬이 결승선입니다.

2024년 2월부터 Gmail과 Yahoo가 이걸 명시했습니다. 대량 발송자(자사 사용자에게 하루 5,000통 이상)는 DMARC 레코드를 게시하고 From: 도메인을 SPF나 DKIM과 정렬해야 합니다. 그 미만 볼륨에서는 강제 규칙이 아니지만, 같은 필터가 같은 잣대로 채점합니다.

평판: IP와 도메인은 이력을 짊어진다

필터는 기억합니다. 발송 IP와 From: 도메인은 각각 누적 평판을 짊어지고, 나쁜 평판은 개별 메일이 아무리 깨끗해도 당신을 스팸함에 떨어뜨립니다.

가장 흔한 평판 함정은 이력이 없는 갓 만든 발송 출처입니다 — 새 VPS, 이제 막 워밍업하는 마케팅 계정, 한 번도 발송한 적 없는 도메인. 사업자는 알 수 없는 발신자를 기본적으로 의심하고, 첫 수천 통이 어떻게 굴러가는지 지켜봅니다. 첫날 대량 콜드 리스트를 쏘면, 새 도메인이 평판을 쌓을 기회를 갖기도 전에 그 평판을 오염시킬 수 있습니다.

여기서 실제로 중요한 숫자는 스팸 신고율입니다. Gmail과 Yahoo는 이걸 0.3% 미만으로 원하고, Google은 안정적인 받은편지함 도달을 위해 0.1% 미만을 권합니다 — 0.3%는 안전한 목표가 아니라 제재가 시작되는 지점입니다. 배달된 천 통당 신고 세 건이면 가라앉기 시작하기에 충분합니다. 해법은 화려하지 않습니다. 받길 원한 사람에게만 보내고, 수신 거부를 아주 쉽게 만들고(대량 발송자에게 요구되는 작동하는 List-Unsubscribe 헤더), 반송되거나 한 번도 안 여는 주소는 제거하세요.

사람들이 잊는 인프라 한 조각

자체 메일 서버를 운영한다면 역방향 DNS를 확인하세요. 발송 IP에는 호스트명이 그 같은 IP로 되돌아 해석되는 PTR 레코드가 필요합니다 — 정방향 확인 역방향 DNS(FCrDNS). Gmail을 포함한 많은 수신자가 rDNS가 없거나 어긋나는 IP의 메일을 조용히 강등하거나 거부합니다. 정상 메일 서버는 거의 항상 이걸 갖췄고 스팸 출처는 흔히 없기 때문이죠. PTR 없는 새 서버는 전형적인 조용한 스팸함 원인이고, 이건 평소 쓰는 DNS 패널이 아니라 IP·클라우드 제공자 쪽에서 설정합니다.

DechoNet으로 진단

  • 이메일 점검은 수신 서버가 하는 그대로 도메인의 SPF, DKIM, DMARC를 읽습니다 — 대부분 도구가 건너뛰는, From: 도메인과의 정렬 여부까지 포함해서요. 다른 걸 손대기 전에 먼저 돌리세요. 문제가 인증인지, 그 하류의 무언가인지 알려줍니다.
  • 역방향 DNS 점검은 발송 IP가 메일 호스트명과 일치하는 유효한 PTR 레코드를 갖췄는지 확인합니다. 이메일 점검은 깨끗한데 메일이 여전히 스팸행이면, 없거나 잘못된 rDNS가 다음으로 배제할 대상입니다.

확인 체크리스트

  • SPF가 존재하고, 실제로 메일을 보내는 서버들을 나열하는지 확인 — 서드파티 플랫폼은 IP를 붙여넣지 말고 그들의 include: 메커니즘으로 추가.
  • DKIM이 서명하고 있는지, 그 서명 도메인이 From: 도메인과 일치(정렬)하는지 확인.
  • DMARC 레코드가 게시됐는지 확인(강제하기 전에 리포트를 읽을 수 있도록 p=none에서 시작).
  • 통과가 아니라 정렬을 검증: SPF나 DKIM이 검증한 도메인이 보이는 From: 주소와 일치해야 함.
  • 발송 IP의 PTR 레코드가 메일 호스트명으로 되돌아 해석되는지 확인.
  • 놓친 사업자(Gmail, Outlook) 계정으로 테스트 발송 후 원본 헤더를 열어 Authentication-Results 줄을 읽기 — 수신자 관점의 spf=, dkim=, dmarc= 판정이 보임.
  • 대량 발송한다면 사업자의 포스트마스터·발신자 대시보드를 설정하고 신고율을 0.3% 상한과 대조해 지켜보기.

내 설정 문제가 아닐 때

인증이 정렬되고, IP의 rDNS가 깨끗하고, 신고율이 낮은데도 특정 수신자 한 명만 여전히 메일을 스팸함에서 발견한다면, 결정이 그쪽으로 넘어간 것입니다. 회사 메일 시스템과 개인 스팸 필터는 발신자 위생으로 뒤집을 수 없는 수신자별 판단을 내립니다. 그 지점에서 확실한 해법은 받는 쪽에 있습니다. 수신자가 당신을 주소록에 추가하거나 메일 하나를 “스팸 아님”으로 표시하게 하세요. 발신 쪽에서 할 수 있는 무엇보다 그들의 필터를 훨씬 빨리 학습시킵니다.

내 도메인에서 바로 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.