아무리 잘 만든 B2B 뉴스레터라도 스팸함으로 빠지면 존재하지 않는 것과 같습니다. 2026년 현재 구글(Gmail), 야후(Yahoo), 마이크로소프트(Outlook) 모두 SPF·DKIM·DMARC 인증을 필수로 요구하며, 미설정 도메인의 이메일은 아예 수신 거부(550 오류)됩니다. 이 글에서는 이메일 발신자 인증 3가지 기술의 개념을 초보자도 이해할 수 있게 풀어드리고, DNS에 직접 적용할 수 있는 단계별 세팅법과 실무 점검 항목을 정리합니다.
마케팅팀이 공들여 작성한 제안서 이메일, 신제품 소개 뉴스레터, 웨비나 초대장. 이 모든 것이 수신자의 받은편지함이 아닌 스팸함으로 분류되고 있다면, 발송 자체가 무의미해집니다.
문제는 대부분의 담당자가 이 사실을 모른다는 점입니다. 발송 솔루션의 대시보드에는 "발송 완료"라고 표시되지만, 실제로는 상대방 서버에서 조용히 거부되거나 스팸 폴더에 묻히고 있을 수 있습니다.
구글과 야후는 하루 5,000통 이상 발송 도메인에 대해 2024년 2월부터 SPF·DKIM·DMARC 인증을 강제 시행하고 있으며, 2026년 현재 이 정책은 완전히 정착되어 인증 실패 시 SMTP 수준에서 전면 차단됩니다.
이 세 가지 기술은 모두 하나의 질문에 답하기 위해 존재합니다.
"이 이메일은 정말 저 회사가 보낸 게 맞나요?"
이메일은 구조적으로 발신자 주소를 위조하기 매우 쉬운 통신 방식입니다. 마치 편지 봉투에 아무 이름이나 써서 보낼 수 있는 것처럼요. 이 취약점을 막기 위해 도입된 기술이 SPF, DKIM, DMARC입니다.
SPF(Sender Policy Framework) 는 "우리 회사 이메일을 보낼 수 있는 서버 목록"을 DNS에 미리 등록해두는 방식입니다.
쉽게 말하면 회사 정문에 붙여놓는 공식 배달원 명단 같은 것입니다. 수신 서버는 메일을 받으면 "이 서버가 명단에 있나?"를 확인하고, 없으면 의심합니다.
DKIM(DomainKeys Identified Mail) 은 이메일 헤더에 암호화된 디지털 서명을 붙여서 보내는 방식입니다.
봉투에 회사 직인을 찍는 것과 같습니다. 수신 서버는 DNS에 등록된 공개키로 서명을 검증하여, 전송 중에 내용이 위변조되지 않았는지 확인합니다.
DMARC(Domain-based Message Authentication, Reporting & Conformance) 는 SPF 또는 DKIM 검사에서 문제가 발생했을 때 수신 서버가 어떻게 행동해야 하는지를 알려주는 정책입니다.
세 가지 옵션이 있습니다.
p=none: 일단 받아두고 보고서만 보냄 (모니터링 단계)p=quarantine: 의심 메일을 스팸함으로 분류p=reject: 인증 실패 메일을 완전히 차단2025년 5월, 마이크로소프트(Outlook.com 및 Microsoft 365)가 구글·야후와 동일한 기준을 강제 시행하기 시작했습니다. B2B 거래처의 대다수가 아웃룩 환경을 사용한다는 점을 고려하면, 이제 SPF·DKIM·DMARC 설정은 마케팅 뉴스레터뿐 아니라 일상적인 업무 이메일 전달을 위해서도 필수입니다.
p=none은 임시방편입니다초기 모니터링용으로 p=none을 설정하는 것은 괜찮습니다. 하지만 2026년 현재 PCI DSS v4.0 보안 표준 및 글로벌 보안 협회 가이드라인은 p=quarantine 또는 p=reject로의 전환을 강력히 요구하고 있습니다. p=none만으로는 도메인 사칭(스푸핑) 공격을 막을 수 없기 때문입니다.
구글과 야후의 공식 가이드라인에 따르면, 스팸 신고 비율은 최대 0.3% 미만으로 유지해야 합니다. 안정적인 수신율을 보장받으려면 평소 0.1% 미만으로 관리해야 합니다. 0.3%를 초과하는 순간 AI 필터가 해당 도메인 전체를 블랙리스트로 처리합니다.
참고로 지메일의 AI 방어 시스템은 하루 평균 약 150억 건의 스팸·피싱 메일을 차단합니다. 이 방어막을 통과하려면 발신자 인증은 선택이 아닌 입장권입니다.
DNS 설정은 도메인을 구매한 호스팅 사이트(가비아, 후이즈, AWS Route 53, Cloudflare 등)의 관리 페이지에서 진행합니다.
도메인 루트(@)에 TXT 레코드 하나를 추가합니다.
설정 예시:
v=spf1 include:_spf.google.com include:servers.mcsv.net ~all
include: 뒤에는 실제로 사용하는 메일 발송 서비스의 호스트명을 입력합니다 (구글 워크스페이스, 메일침프, 센드그리드 등)~all은 목록에 없는 서버에서 발송 시 소프트 실패(SoftFail) 처리를 의미합니다⚠️ 주의사항 두 가지:
include: 항목이 많아져 10회를 초과하면 SPF PermError가 발생하고 이메일이 거부됩니다.사용 중인 메일 솔루션(예: Google Workspace 관리자 콘솔, HubSpot, Mailchimp)에서 DKIM 키 생성 메뉴를 찾아 고유 서명 키를 생성합니다.
설정 예시:
google._domainkey (서비스마다 선택자 이름이 다릅니다)v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A... (발급받은 공개키 전체 입력)키 값이 길어서 잘릴 수 있으니, 호스팅 업체의 TXT 레코드 입력란에 따옴표 없이 전체 값을 정확히 붙여넣는 것이 중요합니다.
SPF와 DKIM이 정상 작동하는 것을 확인한 뒤에만 DMARC를 설정합니다.
설정 위치: 호스트 이름 칸에 반드시 _dmarc 입력
초기 권장 설정값 (모니터링 모드):
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com;
p=none: 인증 실패해도 일단 수신 허용 (초기 모니터링 단계)rua=mailto:...: 인증 현황 보고서를 받을 관리자 이메일 주소단계적 강화 로드맵:
p=none → 2~4주간 보고서 모니터링p=quarantine으로 전환p=reject로 최종 강화수신자가 보는 '보낸 사람' 주소의 도메인이 SPF 또는 DKIM에 등록된 도메인과 반드시 일치해야 합니다. 예를 들어 sender@company.com으로 보냈는데 DKIM 서명이 mailservice.com 도메인으로 되어 있으면 DMARC 검사를 통과하지 못합니다.
아래 항목들을 DNS 설정 완료 후 순서대로 점검하세요.
[ ] SPF 레코드가 도메인에 단 1개만 존재하는가[ ] SPF의 include: 항목 수가 10개(DNS Lookup 기준) 이하인가[ ] DKIM 공개키가 메일 솔루션의 선택자 이름과 정확히 일치하는가[ ] DMARC 레코드의 호스트 이름이 _dmarc로 시작하는가[ ] DMARC rua 태그에 실제 확인 가능한 이메일 주소가 입력되어 있는가[ ] 보낸 사람 도메인이 SPF 또는 DKIM 도메인과 정렬되어 있는가[ ] 테스트 발송 후 MXToolbox 또는 mail-tester.com에서 인증 결과를 확인했는가name@company.com 같은 대표 도메인으로 대량 뉴스레터를 발송하는 것은 위험합니다. 스팸 신고가 누적되면 비즈니스 파트너와의 일상적인 이메일 연락조차 차단될 수 있습니다.
마케팅 발송용으로는 marketing.company.com 같은 서브도메인이나 전용 도메인을 별도로 운영하는 것이 안전합니다.
이메일 하단에 수신 거부 링크를 넣는 것은 법적 의무이자 스팸 신고율 관리의 핵심입니다. 구글·야후 가이드라인은 List-Unsubscribe 헤더(RFC 8058 규격)를 통한 원클릭 탈퇴 기능을 명시적으로 요구합니다.
수신 거부 절차가 복잡할수록 사람들은 '스팸 신고' 버튼을 누릅니다. 그리고 그 신고 하나하나가 도메인 평판을 갉아먹습니다.
DMARC rua 설정을 해두면 매일 XML 형식의 원시 보고서가 쏟아집니다. 이를 수작업으로 분석하기는 사실상 불가능합니다. DMARC Analyzer, Postmark, Dmarcian 같은 전문 모니터링 도구를 활용해 주 1회 이상 정상/이상 발송 현황을 점검하는 것이 좋습니다.
Q1. SPF, DKIM, DMARC 중 하나만 설정해도 되나요?
아닙니다. 세 가지 모두 설정해야 합니다. SPF와 DKIM은 각각 독립적인 인증 방법이고, DMARC는 이 둘의 결과를 기반으로 작동합니다. 특히 구글·야후·마이크로소프트의 현행 정책은 세 가지 모두를 요구합니다.
Q2. 하루 5,000통 미만으로 보내면 이 설정이 필요 없나요?
발송량이 적더라도 SPF와 DKIM은 반드시 설정해야 합니다. 구글의 공식 가이드라인은 발송량과 무관하게 모든 발신자에게 SPF·DKIM 설정을 요구합니다. DMARC는 대량 발신자(5,000통 이상)에게 추가로 요구되지만, 도메인 보안을 위해 소량 발신자도 설정하는 것을 강력히 권장합니다.
Q3. DNS 설정 후 얼마나 기다려야 적용되나요?
DNS 변경 사항은 전파(Propagation)에 보통 수 분에서 최대 48시간이 걸립니다. 설정 후 MXToolbox나 Google Admin Toolbox에서 조회하면 실시간으로 반영 여부를 확인할 수 있습니다.
Q4. 이미 스팸함으로 분류되기 시작했다면 어떻게 해야 하나요?
즉시 SPF·DKIM·DMARC 설정 여부를 점검하고, 스팸 신고율을 확인하세요. 도메인 평판이 이미 낮아진 경우라면 회복에 수 주가 걸릴 수 있습니다. 이 경우 발송량을 줄이고 수신 동의를 받은 명단만 대상으로 소량씩 발송하며 평판을 서서히 회복하는 워밍업(Warm-up) 과정이 필요합니다.
Q5. 메일침프나 스티비 같은 발송 솔루션을 쓰면 자동으로 설정되나요?
아닙니다. 발송 솔루션은 DKIM 키를 생성해 줄 수 있지만, 실제 DNS에 등록하는 작업은 도메인 소유자가 직접 해야 합니다. 솔루션 내 설정 가이드를 따라 생성된 레코드 값을 복사하여 도메인 호스팅 관리 페이지에 직접 입력해야 합니다.
| 용어 | 설명 |
|---|---|
| SPF | 이메일 발송 서버가 도메인 소유자가 승인한 서버인지 확인하는 DNS 기반 인증 기술 |
| DKIM | 이메일에 디지털 서명을 추가하여 전송 중 위변조 여부를 검증하는 암호화 기술 |
| DMARC | SPF·DKIM 인증 실패 시 수신 서버의 처리 방식을 지정하고 보고서를 받는 정책 프레임워크 |
| DNS | 도메인 네임 서버. 도메인 주소와 서버 정보를 연결하는 인터넷 전화번호부 역할 |
| TXT 레코드 | DNS에 텍스트 형태의 정보를 등록하는 레코드 유형. SPF와 DMARC 설정에 사용됨 |
| 도메인 정렬(Alignment) | 발신자 이메일 주소의 도메인이 SPF 또는 DKIM 서명 도메인과 일치하는지 확인하는 DMARC 검증 조건 |
| 스팸 신고율(Spam Complaint Rate) | 발송된 이메일 중 수신자가 스팸으로 신고한 비율. 0.1% 미만 유지 권장 |
| DNS Lookup | SPF 검증 시 다른 도메인 정보를 조회하는 횟수. 최대 10회로 제한됨 |
이메일 발신자 인증(SPF·DKIM·DMARC)은 더 이상 IT 팀만의 전문 영역이 아닙니다. B2B 마케터라면 반드시 이해하고 직접 점검할 수 있어야 합니다.
오늘 바로 실행할 수 있는 3가지 액션:
MXToolbox(mxtoolbox.com)에서 자사 도메인의 SPF·DKIM·DMARC 설정 현황을 무료로 조회하세요rua 태그에 담당자 이메일을 등록하고 2주간 보고서를 모니터링하세요글로벌 보안 데이터에 따르면 현재 전 세계 기업 도메인의 84% 이상이 DMARC를 설정하지 않은 상태입니다. 지금 설정하는 것만으로도 경쟁사 대비 이메일 전달력에서 확실한 우위를 점할 수 있습니다.
DNS 설정과 이메일 전달력 최적화는 한 번만 제대로 잡아두면 이후 B2B 마케팅 전반의 성과가 달라집니다. 에이달(ADALL) 은 이메일 마케팅 인프라 점검부터 발송 전략 수립까지 실무 중심으로 지원합니다.
설정 방법이 복잡하게 느껴지거나, 현재 이메일 도달률에 문제가 있다면 부담 없이 문의해 주세요.
📞 02-2664-8631 | ✉️ master@adall.co.kr
무료 컨설팅 받아보고 싶다면?
무료 컨설팅 신청하기