수출 가이드10분 읽기

콜드메일이 스팸함으로 가는 이유 — SPF·DKIM·DMARC 30분 셋업 가이드

정성껏 쓴 콜드메일이 받은편지함에 안 닿는 가장 큰 원인은 도메인 인증 누락입니다. SPF·DKIM·DMARC가 정확히 무엇이고 어떻게 설정하는지, 공식 표준과 Google·Microsoft 발신 정책을 기준으로 정리했습니다.

Pitchr 편집팀
#콜드메일#이메일 도달률#SPF#DKIM#DMARC#도메인 인증

콜드메일이 스팸함으로 가는 가장 흔한 이유는 본문 내용이 아니라 도메인 인증 설정 누락입니다. 같은 메일을 같은 사람에게 보내도, 발신 도메인이 SPF·DKIM·DMARC 인증을 통과하지 못하면 받은편지함이 아니라 스팸함, 심하면 통째로 거부(reject)됩니다.

특히 2024년 2월부터 Gmail과 Yahoo가 발신자 가이드라인을 강화하면서, 일정 규모 이상 발신자에게는 세 가지 인증을 모두 통과하는 것이 사실상 의무가 되었습니다. 본 글은 이 세 가지 표준이 무엇인지, 그리고 정확히 어떻게 셋업하는지를 공식 문서 기준으로 정리합니다.

본 글에 등장하는 DNS 레코드 예시는 일반적인 형태입니다. 실제 값은 본인이 사용하는 메일 발송 서비스(Google Workspace, Microsoft 365, SendGrid, Mailgun 등)가 발급하는 값을 그대로 입력해야 합니다.

왜 도메인 인증이 필요한가

이메일 프로토콜(SMTP)은 1980년대에 만들어졌고, 처음 설계될 때 발신자 신원을 검증하는 기능이 없었습니다. 누구나 임의의 발신자 주소(From: ceo@whitehouse.gov)로 메일을 보낼 수 있다는 뜻입니다. 이 구조는 당연히 스팸·피싱의 온상이 되었고, 받은 편지함을 지키기 위해 후속 표준 세 가지가 만들어졌습니다.

표준검증하는 것답하는 질문
SPF발신 IP이 IP가 우리 도메인 메일을 보낼 권한이 있나?
DKIM메일 본문 서명메일이 전송 도중 변조되지 않았나?
DMARCSPF·DKIM 결과 정책검증 실패 시 어떻게 처리할까? (수신, 격리, 거부)

세 표준은 서로를 보완합니다. SPF만 있으면 메일이 포워딩될 때 깨지고, DKIM만 있으면 발신 IP를 검증할 수 없고, DMARC만 있으면 정작 검증할 데이터가 없어요. 셋이 함께 작동해야 받는 쪽 메일 서버가 "신뢰할 수 있는 발신자"로 판단합니다.

SPF — 발신 IP 화이트리스트

SPF(Sender Policy Framework)는 RFC 7208에 정의된 표준입니다. 도메인 소유자가 "우리 도메인 이름으로 메일을 보낼 수 있는 IP는 이것들이다"라고 DNS에 공개하면, 받는 쪽 메일 서버가 발신 IP를 그 목록과 대조합니다.

DNS 레코드 형태

SPF는 도메인의 TXT 레코드로 등록합니다.

example.com.    IN  TXT  "v=spf1 include:_spf.google.com ~all"

각 부분의 의미:

  • v=spf1 — SPF 버전. 항상 spf1.
  • include:_spf.google.com — 다른 도메인(여기서는 Google)의 SPF 레코드를 포함. Google Workspace를 쓰면 필수.
  • ~all — 위 조건에 해당하지 않는 발신자는 soft fail(받되 의심 처리). 더 강하게 차단하려면 -all을 쓰지만, 처음에는 ~all로 시작하는 것을 권장합니다.

셋업 절차

  1. 본인이 쓰는 메일 발송 서비스의 SPF include 값을 확인합니다.
    • Google Workspace: include:_spf.google.com
    • Microsoft 365: include:spf.protection.outlook.com
    • SendGrid: include:sendgrid.net
    • Mailgun: include:mailgun.org
  2. 도메인 DNS 관리 콘솔(Cloudflare, 가비아, 호스팅케이알 등)에서 TXT 레코드를 추가합니다.
  3. 여러 서비스를 함께 쓰면 하나의 SPF 레코드 안에 모두 include해야 합니다. SPF 레코드는 도메인당 하나만 유효합니다(이중 등록 시 표준상 무효).
"v=spf1 include:_spf.google.com include:sendgrid.net ~all"

흔한 실수

  • SPF 레코드를 두 개 이상 등록 — 표준상 하나만 인정되어 인증 실패
  • DNS lookup 횟수가 10회 초과 — RFC 7208에서 permerror 처리. include 체인이 너무 길면 발생
  • 메일 서비스 변경 후 이전 include 제거 안 함 — 보안 위험

DKIM — 메일에 디지털 서명

DKIM(DomainKeys Identified Mail)은 RFC 6376에 정의되어 있습니다. 발신 서버가 메일 본문과 헤더 일부를 개인 키로 서명하여 헤더에 첨부하고, 도메인의 DNS에 공개 키를 공개합니다. 받는 서버는 공개 키로 서명을 검증해 메일이 전송 도중 변조되지 않았음을 확인합니다.

DNS 레코드 형태

DKIM은 셀렉터(selector)별로 TXT 레코드가 만들어집니다.

google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4..."
  • google — 셀렉터. 메일 서비스가 발급(서비스마다 다름)
  • v=DKIM1 — DKIM 버전
  • k=rsa — 키 알고리즘
  • p=... — 공개 키 (Base64 인코딩)

셋업 절차

  1. 메일 발송 서비스 관리 콘솔에서 DKIM 활성화. 서비스가 셀렉터와 공개 키를 발급해줍니다.
    • Google Workspace: 관리 콘솔 → 앱 → Google Workspace → Gmail → 이메일 인증
    • Microsoft 365: Microsoft 365 Defender → 정책 → 이메일 인증 설정 → DKIM
  2. 발급받은 호스트명(셀렉터._domainkey.도메인)과 값을 DNS에 TXT 레코드로 추가
  3. 서비스 콘솔에서 "검증" 또는 "활성화" 버튼을 눌러 DKIM 서명을 시작

셀렉터를 여러 개 쓰는 이유

같은 도메인에서 여러 서비스로 메일을 보낼 수 있게 하기 위함입니다. 셀렉터가 다르면 DNS 충돌 없이 공존 가능합니다.

google._domainkey.example.com    (Google Workspace 발신용)
sendgrid._domainkey.example.com  (SendGrid 발신용)

DMARC — 검증 실패 시 정책

DMARC(Domain-based Message Authentication, Reporting, and Conformance)는 RFC 7489에 정의되어 있습니다. SPF·DKIM 검증에 실패한 메일을 어떻게 처리할지 도메인 소유자가 정책으로 선언하고, 추가로 인증 결과 리포트를 받을 수 있게 해줍니다.

DNS 레코드 형태

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100; aspf=r; adkim=r"

핵심 태그:

  • v=DMARC1 — DMARC 버전
  • p= — 정책. none(처리 없음, 리포트만), quarantine(스팸함으로), reject(아예 거부)
  • rua=mailto: — 일일 집계 리포트를 받을 이메일
  • pct= — 정책을 적용할 메일 비율(100=전체)
  • aspf=, adkim= — alignment 모드. r(relaxed), s(strict)

권장 도입 순서

처음부터 p=reject로 가지 마세요. 본인 도메인에서 메일을 보내는 정상 시스템(메일 서비스, 마케팅 도구, 내부 자동화 등)이 모두 SPF·DKIM 인증을 통과하는지 확인하는 시간이 필요합니다. Microsoft 공식 가이드에서도 동일한 단계적 도입을 권장합니다.

  1. p=none으로 1~2주 — 리포트만 받고 누가 우리 도메인으로 메일을 보내는지 확인
  2. p=quarantine; pct=10 — 검증 실패 메일 중 10%만 스팸함으로
  3. pct를 50, 100으로 점진적으로 상향
  4. 검증 실패가 안정적으로 0에 가까워지면 p=reject로 전환

정렬(alignment)이 중요한 이유

DMARC는 단순히 SPF·DKIM 통과 여부만 보지 않습니다. From 헤더의 도메인과 SPF·DKIM이 검증한 도메인이 일치(align) 해야 합니다.

예를 들어 From: hello@example.com인 메일이 SPF는 mail.sendgrid.net 도메인 기준으로 통과했다면, DMARC는 실패로 봅니다(From 도메인과 SPF 검증 도메인이 다르므로). 이를 해결하려면 SendGrid에서 발급한 CNAME으로 본인 도메인의 서브도메인을 위임(예: em.example.com → sendgrid)하여 같은 조직 도메인 안에서 인증되도록 해야 합니다.

Gmail·Yahoo 강화 발신자 가이드라인 (2024.02~)

Google이 공식 발표한 발신자 가이드라인에 따르면, 하루 5,000건 이상을 Gmail로 보내는 발신자는 다음을 의무적으로 충족해야 합니다.

  • SPF 그리고 DKIM 인증 통과 (둘 중 하나가 아니라 둘 다)
  • 발신 도메인에 DMARC 정책 발행(최소 p=none)
  • 발신 도메인의 PTR 레코드(역방향 DNS) 일치
  • 마케팅 메일에 원클릭 구독 해지 헤더 포함
  • 스팸 신고율 0.3% 미만 유지

5,000건 미만이라도 일부 항목은 적용되며, 향후 기준이 더 강화될 가능성이 큽니다. 콜드메일을 운영한다면 처음부터 위 기준을 모두 충족하는 게 안전합니다.

셋업 후 검증

DNS 변경은 전파에 보통 수 분~24시간이 걸립니다. 다음 도구로 직접 확인할 수 있습니다.

도구용도
dig TXT example.com (CLI)SPF 레코드 직접 조회
dig TXT 셀렉터._domainkey.example.comDKIM 공개 키 조회
dig TXT _dmarc.example.comDMARC 정책 조회
본인 메일을 Gmail로 발송 → 메시지 → "원본 보기"헤더에서 SPF/DKIM/DMARC pass 여부 확인

Gmail "원본 보기"에서 다음과 같이 표시되면 정상입니다.

SPF:     PASS with IP ...
DKIM:    PASS with domain example.com
DMARC:   PASS

콜드메일 발송 전 체크리스트

본격적으로 콜드메일을 보내기 전, 다음 항목들을 한 번에 점검하세요.

  • SPF 레코드 1개만 존재하고, 사용 중인 모든 발송 서비스가 include 되어 있다
  • 사용 중인 모든 발송 서비스에 DKIM이 활성화되고, DNS에 공개 키가 등록되어 있다
  • DMARC 레코드가 존재하고, 처음에는 p=none으로 시작
  • DMARC 리포트(rua=) 받을 이메일을 모니터링 중이다
  • Gmail로 본인에게 테스트 발송 후 "원본 보기"에서 세 항목 모두 PASS 확인
  • 신규 도메인이라면 발송량을 점진적으로 늘리는 워밍업 일정이 있다(다음 글에서 다룹니다)

마치며

도메인 인증은 콜드메일 운영의 인프라 기초입니다. 본문이 아무리 좋아도 인증이 안 된 도메인에서 보낸 메일은 받은편지함에 닿지 못합니다. 반대로 인증을 제대로 셋업해두면 발송량이 늘어도 도달률이 안정적으로 유지됩니다.

특히 콜드메일을 본격 운영하는 회사는 본 도메인이 아닌 별도의 발송 전용 도메인(예: example.com 본 도메인 → mail.example.io 발송 도메인)을 두는 것을 권장합니다. 발송 도메인의 평판 문제가 본 도메인 메일 발송에 영향을 주지 않도록 격리하기 위함입니다.

Pitchr는 사용자가 연동한 발송 도메인의 인증 상태를 발송 전에 자동으로 점검하고, 누락된 항목을 안내합니다. 인증이 끝나야 발송이 시작되므로, 첫 캠페인부터 도달률이 무너지는 일을 방지합니다.

PITCHR로 시작하기

제품 URL 하나만 넣으면, 해외 바이어를 자동으로 찾고 콜드메일을 보내드립니다.

수출·해외영업 자동화에 필요한 바이어 매칭, 맞춤 메일 작성, 자동 팔로업을 한 곳에서. 무료로 시작하고 카드 등록 없이 직접 써보세요.

무료로 시작하기기능 살펴보기
← 모든 글 보기