12CODE
지금 읽는 곳 왜 콘텐츠가 아니라 DNS 레코드부터 봐야 하는가 1 / 6
12code 라이브러리 아티클 표지. 도달률 최적화 엔지니어링: 스팸함 분류를 방지하기 위한 도메인 인증(SPF, DKIM, DMARC) DNS 레코드 세팅의 정석

도달률 최적화 엔지니어링: 스팸함 분류를 방지하기 위한 도메인 인증(SPF, DKIM, DMARC) DNS 레코드 세팅의 정석

콘텐츠를 아무리 잘 써도 DNS 레코드 세 줄이 빠지면 그 메일은 애초에 받은편지함에 도착하지 못합니다.

이 과목 03 / 11편 고급 3분
과목 ID125
트랙STEP 3 고급·전략
모듈3-3. 그로스해킹·CRM 전략
레슨03
난이도고급
플랫폼이메일 마케팅(ESP)
발행일2026-08-29
검토일2026-08-29
관련 과목124 · 126
출처1건
핵심요약5개
01

SPF·DKIM·DMARC는 "우리가 이 메일의 진짜 발신자다"를 수신 서비스에 기술적으로 증명하는 3단계 인증이다

02

SPF는 이 도메인 이름으로 메일을 보낼 수 있는 서버 목록을 등록하는 것이다

03

DKIM은 메일 내용에 디지털 서명을 붙여 발송 중 변조되지 않았음을 증명한다

04

DMARC는 SPF·DKIM을 통과하지 못한 메일을 어떻게 처리할지 정하는 정책이며, 반드시 p=none으로 시작해 점진적으로 강화한다

05

이 세 가지 설정 자체가 KISA 화이트 도메인 등록(레슨 11)의 전제조건이기도 하다

01

왜 콘텐츠가 아니라 DNS 레코드부터 봐야 하는가

스팸함 분류는 메일 제목이나 본문 내용만으로 결정되지 않습니다. 수신 서비스(지메일, 네이버메일 등)는 메일을 받기 전에 먼저 "이 메일이 정말 발신 도메인의 소유자가 보낸 것이 맞는가"를 기술적으로 검증하고, 이 검증을 통과하지 못하면 본문이 아무리 정상적이어도 스팸함으로 보내거나 아예 반송시킵니다. SPF·DKIM·DMARC는 바로 이 발신자 검증을 위한 세 단계 인증 표준이며, ESP 도움말들이 공통으로 이 설정 완료를 스팸 분류 확률을 낮추는 가장 기본적인 조치로 안내하는 이유입니다.

02

SPF — 이 도메인으로 보낼 수 있는 서버 목록

SPF(Sender Policy Framework)는 도메인의 네임서버(DNS)에 TXT 레코드로 "이 도메인 이름을 걸고 메일을 보낼 수 있는 서버는 이 목록뿐이다"를 선언하는 방식입니다. 예를 들어 자사 도메인으로 스티비를 통해 메일을 보낸다면, SPF 레코드에 스티비의 발송 서버 정보를 포함시켜야 합니다. 이 레코드가 없거나 실제 발송 서버(ESP)가 누락되어 있으면, 수신 서버는 "이 메일은 등록되지 않은 서버에서 온 것"으로 판단해 위조 가능성을 의심합니다.

03

DKIM — 발송 중 변조되지 않았음을 증명하는 서명

DKIM(DomainKeys Identified Mail)은 SPF와 목적은 비슷하지만 방식이 다릅니다. SPF가 "어느 서버에서 보냈는가"를 확인하는 것이라면, DKIM은 메일 헤더에 암호화된 디지털 서명을 붙여 "이 메일 내용이 발송 이후 중간에 조작되지 않았다"는 것을 증명합니다. 이 서명 역시 도메인 관리 서비스의 DNS에 TXT 레코드로 공개키를 등록하는 방식으로 설정합니다. SPF와 DKIM은 별개의 레코드이므로 둘 중 하나만 설정해서는 안 되고, ESP가 안내하는 두 레코드를 모두 등록해야 온전한 인증이 완료됩니다.

04

DMARC — SPF·DKIM 실패 시 처리 방침을 정하는 정책

DMARC(Domain-based Message Authentication, Reporting and Conformance)는 SPF·DKIM 인증에 실패한 메일을 수신 서버가 어떻게 처리할지 지시하는 정책 레코드입니다. 실무 순서는 명확합니다 — 먼저 SPF·DKIM 설정을 완료하고 48시간 정도 지난 뒤에 DMARC TXT 레코드를 추가하며, 처음에는 발송 흐름에 영향을 주지 않는 p=none(모니터링만 하고 아무 조치도 하지 않음) 정책으로 시작합니다. 이후 리포트를 통해 정상 발송 메일이 인증에 실패하는 사례가 없는지 확인한 다음, quarantine(스팸함 처리) 또는 reject(수신 거부)로 점진적으로 강화하는 것이 정석입니다. SPF·DKIM 없이 곧바로 강한 DMARC 정책부터 걸면 정상 메일까지 전량 차단될 수 있으므로, 이 순서를 건너뛰면 안 됩니다.

05

세 레코드가 각각 무엇을 막아주는지 다시 정리하면

세 인증을 혼동하지 않으려면 각자 막아주는 문제가 다르다는 점을 기준으로 구분하는 것이 좋습니다. SPF는 "허용되지 않은 서버가 우리 도메인 이름으로 메일을 보내는 것"을 막고, DKIM은 "발송된 메일 내용이 중간에 조작되는 것"을 막으며, DMARC는 "SPF·DKIM을 통과하지 못한 메일을 수신 서버가 어떻게 취급할지"를 결정합니다. 셋 중 하나만 설정하고 나머지를 미루면, 예를 들어 SPF만 있고 DMARC가 없는 경우 SPF를 우회하는 위조 메일(발신자 표시 위조, 스푸핑)에 대한 방어가 약해집니다. 세 가지를 순서대로(SPF→DKIM→DMARC) 모두 완료해야 도달률 관점에서 의미 있는 인증 체계가 완성됩니다.

06

실무 세팅 순서와 흔한 실수

실제 세팅은 ① ESP가 제공하는 SPF·DKIM용 TXT 레코드 값을 확인 → ② 도메인 네임서버 관리 화면(가비아, 카페24 등)에 해당 값을 등록 → ③ 반영까지 대기(전파에 시간이 걸릴 수 있음) → ④ ESP의 인증 상태 확인 화면에서 통과 여부 확인 → ⑤ 48시간 뒤 DMARC를 p=none으로 추가 → ⑥ 리포트를 모니터링하며 정책을 강화하는 순서로 진행합니다. 가장 흔한 실수는 두 가지입니다. 하나는 SPF·DKIM 설정 직후 곧바로 대량 캠페인을 발송하는 것 — 인증 반영에는 시간이 걸리므로 설정 완료 후 ESP 화면에서 통과 상태를 확인한 뒤 발송해야 합니다. 다른 하나는 DMARC를 처음부터 reject로 설정하는 것으로, 이 경우 SPF·DKIM 설정에 사소한 오류가 있었다면 정상 메일까지 전부 거부되는 사고로 이어집니다.

다음 행동

현재 발송 도메인의 SPF·DKIM 설정 여부를 ESP 관리 화면에서 확인하고, 아직 없다면 이번 주 안에 등록하세요. 이 인증이 완료되어야 다음 레슨(자동화 트리거)에서 발송량을 늘려도 도달률이 함께 무너지지 않습니다. 특히 도메인을 여러 부서·여러 발송 도구(뉴스레터 ESP, 영업팀 메일머지 도구, 트랜잭션 메일 서버 등)가 나눠 쓰는 조직이라면, SPF 레코드 하나에 그 모든 발송 서버를 빠짐없이 등록해야 합니다 — 한 도구만 등록하고 다른 도구를 빠뜨리면 그 도구가 보낸 메일만 인증에 실패해 도달률이 부분적으로 무너지는데, 원인을 찾기까지 시간이 오래 걸리는 흔한 함정입니다.

다음 글 · 레슨 04→유저 세그먼트 자동화 트리거: [가입 후 3일간 미구매자], [최근 30일간 로그인 없는 자] 등 행동 데이터 기반 자동 발송(Automation)

← 이전 글 · 레슨 02 이메일 전송 인프라(ESP) 선정: 스티비, 메일침프, 브레보 등 플랫폼별 API 연동성 및 대량 발송 서버 스펙 비교

출처

facts 항목 기준 · 본문 인라인 미표기1건
F-01스티비 도움말 — SPF, DKIM 설정 이해하기 / DMARC 설정 이해하기 (facts/125_이메일뉴스레터마케팅.json: stibee-spf-dkim-domain-verification, stibee-dmarc-staged-rollout)업계

플랫폼 기능·심의 기준·가격·법률은 바뀝니다. 이 글은 2026-08-29에 위 출처를 기준으로 확인했습니다.

CHALLENGE

배운 걸 실전 문제로 확인

카테고리별 Level Test로 실무 레벨을 점검해보세요.

챌린지 보기 →
이 과목의 게시글11편
01CRM의 클래식: 타 매체 단가 상승 대안으로서 100% 퍼스트 파티 동의 기반 이메일 마케팅의 ROI 가치02이메일 전송 인프라(ESP) 선정: 스티비, 메일침프, 브레보 등 플랫폼별 API 연동성 및 대량 발송 서버 스펙 비교03도달률 최적화 엔지니어링: 스팸함 분류를 방지하기 위한 도메인 인증(SPF, DKIM, DMARC) DNS 레코드 세팅의 정석04유저 세그먼트 자동화 트리거: [가입 후 3일간 미구매자], [최근 30일간 로그인 없는 자] 등 행동 데이터 기반 자동 발송(Automation)05HTML/CSS 반응형 뉴스레터 디자인: 모바일 앱(Gmail, 네이버메일 등) 화면 크기별 폰트/이미지 깨짐 방지 레이아웃 규칙06오픈율(Open Rate) 부스팅 실험: 메일 제목 내 유저 이름 자동 치환 기능({{name}}), 이모지 배치, 제목 길이별 A/B 테스트07클릭률(CTR)과 CTA 연동: 줄글 형태 뉴스레터 내에서 유저가 가장 많이 클릭하는 링크 영역 히트맵 추적 및 버튼 디자인08한계 정의: 애플의 메일 사생활 보호(MPP) 정책 도입 이후 정확한 '오픈율' 측정이 불가능해진 기술적 한계와 대체 지표 활용09실패 사례 분석: 동의를 얻지 않은 외부 이메일 DB를 대량 임포트해 발송했다가 도메인 자체가 '스팸 블랙리스트'에 등록되어 공식 메일 발송이 전면 차단된 사례10법률 컴플라이언스 체크: 정보통신망법에 따른 이메일 제목 시작 부분 (광고) 명시 및 본문 하단 원클릭 수신거부 링크 필수 구현11발행 전 확인 항목: 자사 도메인의 KISA(한국인터넷진흥원) 화이트 도메인 등록 여부 및 ESP 플랫폼의 월별 발송 쿼터 가격표 확인 과목 전체 보기 →

MKT TOOLS

실무자를 위한 무료 도구

카피 글자수 검사, CPC·ROAS 계산기, UTM 생성기까지.

워크스페이스 열기 →