발신 도메인 SPF DKIM 설정: 스팸함 피하는 4단계 기준

발신 도메인의 SPF·DKIM 설정은 기술팀이 해야 하는 선택 작업이 아닙니다. 이메일이 받은편지함에 들어갈지 스팸함으로 갈지를 정하는 첫 번째 조건입니다.

발신 도메인 설정에서 가장 중요한 건 SPF와 DKIM을 각각 통과시키는 것보다, 두 결과가 '내 발신 도메인'과 정렬(alignment)되게 맞추는 것입니다. 설정을 마쳤다고 생각했는데도 스팸함으로 빠지는 경우 상당수는 레코드가 아예 없어서가 아니라, 인증은 통과했지만 발송 서비스의 도메인 이름으로 통과한 경우입니다.

아래에서 SPF·DKIM·DMARC의 역할 구분, 실제 DNS 설정 순서, 자주 깨지는 지점과 검증 방법을 단계별로 설명합니다.

1. 발신 도메인 SPF DKIM 설정 전에 알아야 할 기본 구조

CRM 이메일을 처음 세팅할 때 "SPF 넣었으니 됐다"로 끝내는 경우가 많습니다.

그런데 수신 서버가 확인하는 건 하나가 아니라 세 가지입니다.
각각 확인하는 대상이 다르기 때문에, 어느 하나만으로는 인증이 완성되지 않습니다.

① SPF (Sender Policy Framework)

"이 도메인 이름으로 메일을 보낼 수 있는 서버(IP)가 어디인지"를 DNS에 공개하는 방식입니다.

• 도메인의 DNS에 TXT 레코드로 등록

• 수신 서버는 메일을 보낸 서버 IP가 목록에 있는지 확인

• 확인 대상은 화면에 보이는 보낸사람 주소가 아니라 Return-Path(봉투 발신자) 도메인

-> 서버 허가 목록 역할

② DKIM (DomainKeys Identified Mail)

메일에 전자서명을 붙이고, 그 서명을 검증할 공개키를 DNS에 올려두는 방식입니다.

• 발송 서버가 개인키로 메일 헤더·본문에 서명

• 수신 서버는 셀렉터._domainkey.도메인 위치의 공개키로 서명 검증

• 메일이 중간에 변조되지 않았고, 서명한 도메인이 어디인지를 증명

-> 위변조 방지 + 서명 도메인 증명 역할

③ DMARC (Domain-based Message Authentication, Reporting and Conformance)

SPF와 DKIM 결과를 보낸사람(From) 주소 도메인과 비교하고, 맞지 않을 때 어떻게 처리할지 정하는 정책입니다.

• _dmarc.도메인 위치에 TXT 레코드로 등록

• SPF 또는 DKIM 중 하나 이상이 From 도메인과 정렬된 상태로 통과해야 DMARC 통과

• 실패 시 처리 방식을 none(모니터링) / quarantine(스팸함) / reject(거부) 중에서 지정

-> 최종 판정 규칙 + 리포트 수집 역할

세 가지를 한 표로 정리하면 이렇습니다.

왜 2026년 기준으로는 '선택'이 아닌가

2024년 2월부터 Gmail과 Yahoo는 대량 발신자 요건을 적용하고 있습니다.
Google 공식 가이드라인 기준으로, 개인 Gmail 계정에 하루 5,000건 이상 보내는 발신자는 다음을 갖춰야 합니다.

• SPF와 DKIM 모두 설정

• DMARC 레코드 게시 (최소 p=none)

• From 도메인과 SPF 또는 DKIM 도메인 정렬

• 마케팅 메일에 원클릭 수신거부 지원

• Postmaster Tools 기준 스팸 신고율 0.3% 미만 유지 (권장은 0.1% 미만)

Microsoft도 2025년 5월부터 Outlook.com 계열에 하루 5,000건 이상 보내는 도메인에 SPF·DKIM·DMARC를 요구하고 있습니다. (출처: Google Workspace 관리자 고객센터 '이메일 발신자 가이드라인', Microsoft Defender for Office 365 공지)

5,000건이 기준이라 작은 브랜드는 상관없다고 생각하기 쉽습니다.
하지만 이 기준을 넘지 않더라도 인증이 없는 메일은 신뢰 점수 자체가 낮게 시작합니다. 회원 수가 늘어 처음으로 전체 발송을 하는 날 기준을 넘기는 경우도 흔하고요.

2. SPF DKIM 설정 순서: DNS에 넣기까지 4단계

실무에서는 아래 순서로 진행하면 대부분의 실수를 미리 막을 수 있습니다.

1단계: 우리 도메인으로 메일을 보내는 서비스 목록부터 적기

SPF는 "허용 목록"이기 때문에, 빠진 서비스가 하나라도 있으면 그 서비스로 나가는 메일은 SPF에서 실패합니다.

생각보다 발송 주체가 많습니다.

• 업무용 메일 (Google Workspace, Microsoft 365, 국내 웹메일 등)

• CRM·뉴스레터 발송 서비스 (ESP)

• 쇼핑몰 솔루션의 주문·배송 알림 메일

• 고객센터·헬프데스크 툴

• 결제·회원가입 인증 메일을 보내는 자체 서버

쇼핑몰을 운영하는 브랜드라면 업무 메일, CRM 툴, 쇼핑몰 솔루션 이 세 가지가 같은 도메인을 쓰는 경우가 많습니다.
이 중 쇼핑몰 솔루션의 시스템 메일이 SPF 목록에서 빠져 있어 주문 확인 메일만 스팸함으로 가는 경우도 실무에서 자주 보입니다.

2단계: SPF 레코드는 하나로 합쳐서 작성

SPF에서 가장 흔한 실수는 서비스마다 SPF 레코드를 따로 추가하는 것입니다.

한 도메인에 v=spf1로 시작하는 TXT 레코드가 두 개 이상 있으면, 수신 서버는 둘 다 무시하고 오류(permerror)로 처리합니다.
"두 개 넣었으니 두 배로 안전하겠지"가 아니라, 두 개 넣는 순간 SPF가 없는 것과 같아집니다.

올바른 형태는 하나의 레코드에 include를 나열하는 방식입니다.

v=spf1 include:_spf.google.com include:발송서비스A include:발송서비스B ~all

작성할 때 확인할 기준은 아래와 같습니다.

• DNS 조회 10회 제한: include, a, mx, redirect 등은 조회 1회로 계산됩니다. include 안에 또 include가 들어 있는 경우도 합산되기 때문에, 서비스 4~5개만 넣어도 10회를 넘는 경우가 있습니다. 넘으면 permerror입니다.

• 끝 처리: 처음에는 ~all(소프트 실패)로 시작하고, 누락 서비스가 없다는 걸 확인한 뒤 -all(하드 실패)을 검토합니다. 확인 없이 -all부터 넣으면 빠진 서비스 메일이 바로 거부됩니다.

• +all 금지: 모든 서버를 허용한다는 뜻이라 SPF를 설정하지 않은 것보다 나쁩니다.

3단계: DKIM은 '우리 도메인'으로 서명되게 설정

DKIM에서 가장 많이 놓치는 부분이 여기입니다.

대부분의 발송 서비스는 기본값으로 서비스 자체 도메인으로 DKIM 서명을 합니다.
이 상태에서도 DKIM은 "pass"로 찍힙니다. 그런데 서명 도메인(d=)이 발송 서비스 도메인이라 From 주소의 도메인과 정렬되지 않습니다.

그래서 발송 서비스 관리 화면에서 "도메인 인증", "발신 도메인 등록", "커스텀 DKIM" 같은 메뉴를 찾아 우리 도메인으로 서명하도록 바꿔야 합니다.
보통 서비스가 알려주는 레코드를 DNS에 그대로 추가하는 방식입니다.

• TXT 방식: 셀렉터._domainkey.도메인에 v=DKIM1; k=rsa; p=공개키 형태로 등록

• CNAME 방식: 셀렉터._domainkey.도메인을 발송 서비스의 키 주소로 연결 (키 교체를 서비스가 대신 해줌)

키 길이는 2048비트를 권장합니다. 1024비트도 아직 동작은 하지만 보안상 권장 수준에서 밀려나는 추세입니다.

TXT 방식에서 자주 깨지는 지점도 있습니다.
2048비트 공개키는 길어서 DNS 관리 화면에 붙여넣을 때 줄바꿈·공백·따옴표가 섞여 들어가는 경우가 있습니다. 이러면 레코드는 존재하는데 키가 깨져서 DKIM이 실패합니다.

4단계: DMARC는 p=none으로 시작해서 단계적으로 올리기

SPF와 DKIM이 정렬된 상태로 통과하는 걸 확인했다면 DMARC를 게시합니다.

v=DMARC1; p=none; rua=mailto:dmarc-report@도메인

처음부터 reject로 거는 건 위험합니다.
1단계에서 미처 파악하지 못한 발송 주체가 있으면, 그 메일이 전부 거부되기 때문입니다.

실무에서 많이 쓰는 단계는 이렇습니다.

rua 주소로 들어오는 리포트는 XML 형식이라 그대로 읽기 어렵습니다.
DMARC 리포트 분석 도구를 연결해 "어떤 IP가 우리 도메인 이름으로 얼마나 보내고 있는지"를 확인하는 게 2단계 이후 판단의 근거가 됩니다.

3. SPF DKIM 설정 후 스팸함 가는 경우: 자주 깨지는 5가지 지점

설정을 마쳤는데도 도달률이 안 오르는 경우는 대부분 아래 다섯 가지 중 하나입니다.

1) SPF는 통과했는데 정렬이 안 된 경우

SPF가 확인하는 건 Return-Path 도메인입니다.
발송 서비스 대부분은 반송 메일 처리를 위해 Return-Path를 서비스 도메인으로 설정합니다.

이러면 SPF는 "pass"지만, 통과한 도메인이 From 도메인과 달라 DMARC 관점에서는 SPF 정렬 실패입니다.
이 경우 DKIM 정렬로 DMARC를 통과시키거나, 발송 서비스에서 커스텀 Return-Path(바운스 도메인) 설정을 지원하면 그것까지 맞추는 게 좋습니다.

-> DMARC는 SPF·DKIM 중 하나만 정렬되면 통과하지만, 둘 다 맞춰두면 포워딩 같은 예외 상황에서도 버틸 수 있습니다.

2) 발송 서비스를 바꾸고 SPF·DKIM을 업데이트하지 않은 경우

CRM 이메일 오픈율이 어느 날부터 급격히 떨어진 브랜드를 따라가 보면, 발송 서비스를 교체하면서 DNS 작업이 빠진 경우가 흔합니다.

새 서비스의 include를 추가하지 않았거나, 기존 서비스의 DKIM 레코드만 남아 있는 상태입니다.
반대로 해지한 서비스의 include를 지우지 않아 조회 10회 제한에 걸리는 경우도 있습니다.

발송 서비스 교체는 마케팅 팀이 결정하고 DNS는 개발·IT 담당이 관리하는 구조라면, 이 연결이 끊기기 쉽습니다.

3) 마케팅 메일과 업무 메일이 같은 도메인을 쓰는 경우

마케팅 메일은 스팸 신고가 일정 비율로 발생할 수밖에 없습니다.
이 평판이 업무 메일과 같은 도메인에 쌓이면, 거래처에 보내는 견적 메일까지 영향을 받습니다.

그래서 대량 발송은 하위 도메인으로 분리하는 방식을 많이 씁니다.

• 업무 메일: brand.co.kr

• 마케팅·뉴스레터: news.brand.co.kr 또는 mail.brand.co.kr

• 주문·배송 알림: notice.brand.co.kr

하위 도메인마다 SPF·DKIM을 따로 설정해야 한다는 점은 기억해야 합니다.
DMARC는 상위 도메인 정책이 하위 도메인에 상속되는데, sp= 태그로 하위 도메인 정책을 따로 지정할 수도 있습니다.

4) DNS 반영 시간을 기다리지 않고 판단한 경우

DNS 레코드는 등록 즉시 전 세계에 반영되지 않습니다.
TTL 설정에 따라 수 분에서 길게는 48시간까지 이전 값이 조회될 수 있습니다.

등록 직후 테스트 메일 한 통을 보내 "실패"를 보고 레코드를 계속 수정하면, 어느 값이 반영된 건지 알 수 없게 됩니다.
레코드를 수정한 뒤에는 DNS 조회로 새 값이 보이는지 먼저 확인하고, 그다음에 발송 테스트를 하는 순서가 맞습니다.

5) 인증은 완벽한데 평판이 무너진 경우

SPF·DKIM·DMARC는 "이 메일이 진짜 이 도메인에서 왔다"를 증명할 뿐, "이 메일이 원하는 메일이다"를 증명하지는 않습니다.

인증을 다 갖췄는데도 스팸함으로 가는 경우는 대부분 평판 문제입니다.

• 오래된 리스트에 한 번에 대량 발송 (휴면 주소·스팸트랩 포함)

• 수신 동의 근거가 약한 리스트 사용

• 수신거부 링크를 찾기 어렵게 배치

• 신규 도메인으로 첫날부터 전체 회원에게 발송

특히 새로 만든 하위 도메인은 평판 이력이 없습니다.
처음 몇 주는 최근 구매·최근 오픈 고객부터 발송량을 단계적으로 늘리는 워밍업이 필요합니다.

수신 동의 기준이 걱정된다면 광고성 정보 수신 동의 문구: 필수 항목과 채널별 예시에서 채널별 동의 문구와 필수 항목을 함께 확인하는 게 좋습니다.

4. 발신 도메인 인증 검증 방법과 운영 점검 기준

설정은 한 번이지만 점검은 계속 필요합니다.
아래 순서로 확인하면 "설정했다"와 "제대로 동작한다"를 구분할 수 있습니다.

1) DNS 조회로 레코드 존재 확인

터미널에서 바로 확인할 수 있습니다.

nslookup -type=TXT brand.co.kr
nslookup -type=TXT 셀렉터._domainkey.brand.co.kr
nslookup -type=TXT _dmarc.brand.co.kr

확인할 것은 세 가지입니다.

• v=spf1 레코드가 정확히 한 개인가

• DKIM 공개키가 잘리거나 공백 없이 조회되는가

• DMARC 레코드가 _dmarc 위치에 있는가

웹 기반 DNS·이메일 인증 진단 도구를 쓰면 SPF 조회 횟수까지 자동으로 계산해줘서 10회 제한 확인에 편합니다.

2) 실제 수신 메일 헤더로 결과 확인

레코드가 있다고 끝이 아닙니다. 실제 받은 메일에서 결과를 확인해야 합니다.

Gmail 기준으로는 받은 메일의 "원본 보기"에서 SPF, DKIM, DMARC 결과가 각각 PASS인지 바로 보입니다.
여기서 볼 핵심은 PASS 여부보다 어느 도메인으로 통과했는지입니다.

• dkim=pass header.d=brand.co.kr → 정렬 성공

• dkim=pass header.d=발송서비스도메인 → 통과했지만 정렬 실패

• dmarc=pass → 최종 통과

테스트는 Gmail, Outlook, 국내 포털 메일 등 고객 비중이 높은 메일 서비스별로 한 통씩 보내보는 걸 권장합니다.
수신 서버마다 판정 방식이 조금씩 달라서 한 곳만 보고 판단하면 놓치는 경우가 생깁니다.

3) 운영 중 정기 점검 지표

설정 이후에는 아래 지표를 주기적으로 봅니다.

Postmaster Tools는 Gmail로 일정량 이상 발송해야 데이터가 표시되기 때문에, 발송량이 적은 초기에는 비어 있을 수 있습니다.
이때는 발송 서비스의 오픈율·바운스율 변화와 DMARC 리포트를 함께 보는 방식으로 대신합니다.

4) 변경 관리: 누가, 언제 DNS를 바꿨는지 남기기

인증 문제의 상당수는 설정 자체보다 이후 변경에서 생깁니다.

• 홈페이지 리뉴얼하면서 DNS 업체를 옮기다 TXT 레코드 누락

• 다른 서비스 도메인 인증을 하다가 SPF 레코드를 덮어씀

• 담당자 교체 후 어떤 include가 무슨 서비스인지 아무도 모름

DNS 레코드마다 "어떤 서비스용인지, 누가 언제 추가했는지"를 표 하나로 관리해두면, 문제가 생겼을 때 원인 추적 시간이 크게 줄어듭니다.
메타 도메인 인증처럼 다른 마케팅 툴도 같은 DNS에 TXT 레코드를 추가하는 경우가 많아서, 함께 정리해두는 게 좋습니다. 인증 방식 비교는 메타 도메인 인증: 방식별 선택 기준과 실패 원인 정리에서 다뤘습니다.

이메일 채널 자체의 효율을 다른 채널과 비교해보고 싶다면 CRM 문자 이메일 채널 비용 비교: 건당 단가보다 먼저 볼 3가지 기준도 함께 참고하시면 좋습니다. 도달률이 안정된 뒤에야 건당 비용 비교가 의미를 가지기 때문입니다.

자주 묻는 질문

SPF 레코드를 두 개 넣으면 어떻게 되나요?
한 도메인에 v=spf1 레코드가 두 개 이상 있으면 수신 서버는 SPF 오류(permerror)로 처리합니다. 사실상 SPF가 없는 것과 같은 상태가 됩니다. 여러 서비스를 쓴다면 하나의 레코드 안에 include를 나열해야 합니다.

DKIM pass인데 스팸함으로 가는 이유는?
DKIM 서명 도메인이 From 주소 도메인과 다르면 DKIM은 통과해도 DMARC 정렬에서 실패할 수 있습니다. 메일 원본에서 header.d= 값이 내 도메인인지 확인하세요. 정렬까지 맞췄다면 그다음은 스팸 신고율·리스트 품질 같은 평판 문제를 봐야 합니다.

DMARC 정책은 처음부터 reject로 설정해도 되나요?
권장하지 않습니다. 파악하지 못한 발송 서비스가 있으면 그 메일이 전부 거부됩니다. p=none으로 리포트를 몇 주 모아 모든 발송 소스를 확인한 뒤 quarantine, reject 순으로 올리는 게 안전합니다.

SPF DKIM 설정 후 반영까지 얼마나 걸리나요?
DNS TTL 설정에 따라 다르지만 보통 수 분에서 몇 시간이면 조회되고, 길게는 48시간까지 걸릴 수 있습니다. 수정 직후 실패 결과만 보고 레코드를 다시 고치기보다, DNS 조회로 새 값이 반영됐는지 먼저 확인하는 게 맞습니다.

하루 발송량이 5,000건 미만이면 DMARC는 안 해도 되나요?
Gmail·Microsoft의 의무 기준은 5,000건 이상이지만, 그 미만이라도 인증이 없는 메일은 신뢰도가 낮게 평가됩니다. 또 DMARC가 없으면 누군가 내 도메인을 사칭해 메일을 보내도 막을 수단이 없습니다. 최소 p=none이라도 게시해두는 게 좋습니다.

마무리

발신 도메인 SPF·DKIM 설정은 레코드를 "넣는 것"보다 "맞추는 것"이 핵심입니다.

• SPF: 발송 서비스를 빠짐없이, 레코드는 하나로, 조회 10회 이내로

• DKIM: 발송 서비스 도메인이 아닌 우리 도메인으로 서명

• DMARC: p=none으로 시작해 리포트를 근거로 단계적 강화

• 검증: 레코드 존재가 아니라 실제 메일 헤더의 정렬 결과로 판단

인증은 받은편지함에 들어갈 자격을 주는 것일 뿐, 그 자리를 지키는 건 발송 리스트의 품질과 수신자의 반응입니다.
설정을 마쳤다면 발송 서비스 교체나 DNS 변경이 있을 때마다 이 네 가지를 다시 점검하는 루틴을 만들어두세요. 그래야 어느 날 갑자기 오픈율이 떨어지는 일을 미리 막을 수 있습니다.

CRM 툴을 새로 도입하거나 교체할 계획이라면 CRM 자동화 툴 비교: 도입 전 따져볼 4가지 기준에서 도메인 인증 지원 범위까지 함께 비교해보시길 권합니다.