회사 메일 스팸함 방지: SPF, DKIM, DMARC 설정
회사 도메인으로 보낸 메일이 스팸함에 들어가지 않으려면 DNS에 SPF, DKIM, DMARC 세 레코드를 넣어야 합니다. 각 레코드의 역할, 설정 절차, 검증 방법, 흔한 실수를 정리했습니다.
작성
회사 도메인으로 보낸 메일이 스팸함으로 들어가는 문제는 대부분 DNS에 SPF, DKIM, DMARC 세 레코드를 넣으면 해결됩니다. SPF는 "이 도메인으로 메일을 보낼 수 있는 서버 목록", DKIM은 "메일이 위변조되지 않았다는 서명", DMARC는 "둘 다 실패한 메일을 어떻게 처리할지 정한 정책"입니다. 세 가지 모두 도메인의 DNS에 TXT 레코드로 추가하며, 메일 서버 자체를 바꿀 필요는 없습니다.
Google과 Yahoo는 2024년 2월부터 모든 발신 도메인에 SPF 또는 DKIM을, 하루 5,000통 이상 보내는 도메인에는 DMARC까지 요구하고 있습니다. 회사 메일이라면 세 가지를 모두 갖추는 것이 기본입니다.
세 레코드가 각각 하는 일
SPF(Sender Policy Framework) 는 도메인 소유자가 "이 도메인 이름으로 메일을 보내도 되는 서버(IP 또는 다른 도메인의 SPF)"를 DNS에 선언하는 방식입니다. 수신 서버는 메일을 보낸 서버의 IP가 그 목록에 있는지 확인합니다. 봉투 발신자(Return-Path) 도메인을 검사하므로, 메일이 다른 주소로 자동 전달되면 실패하기 쉽다는 한계가 있습니다.
DKIM(DomainKeys Identified Mail) 은 메일 서버가 발신 메일의 헤더와 본문에 개인키로 서명을 붙이고, 도메인 DNS에 공개키를 올려 두는 방식입니다. 수신 서버는 공개키로 서명을 검증해 메일이 도중에 바뀌지 않았는지, 정말 그 도메인에서 서명했는지 확인합니다. 공개키는 선택자._domainkey.도메인 이름의 TXT 또는 CNAME 레코드에 둡니다.
DMARC(Domain-based Message Authentication, Reporting and Conformance) 는 SPF와 DKIM의 결과를 발신자 표시 주소(From 헤더)의 도메인과 맞춰 보고, 둘 다 통과하지 못한 메일을 그냥 받을지(none), 스팸함으로 보낼지(quarantine), 거부할지(reject) 정하는 정책입니다. 수신 서버가 검증 결과를 집계해 보내 주는 리포트 기능이 있어, 누가 우리 도메인을 사칭하는지도 알 수 있습니다.
설정 절차
레토에 등록한 도메인이 레토 네임서버를 쓰고 있다면 대시보드 도메인 상세의 DNS 및 포워딩 탭에 있는 DNS 레코드 카드에서 아래 레코드를 추가합니다. 다른 네임서버를 쓰고 있다면 그 서비스의 DNS 화면에서 같은 값을 넣습니다. 레코드 종류별 입력 방법은 DNS 레코드 종류와 입력 방법을 참고하세요.
발신 경로를 모두 적어 둡니다
회사 도메인 이름으로 메일을 보내는 곳을 전부 목록으로 만듭니다. 메일 서비스(구글 워크스페이스, Microsoft 365, 네이버 웍스 등)뿐 아니라 마케팅 발송 도구, CRM, 헬프데스크, 청구서 발행 시스템, 사내 서버의 알림 메일, 복합기 스캔 메일까지 포함합니다. 여기서 빠진 경로는 나중에 DMARC 정책을 올렸을 때 반송됩니다.
SPF 레코드를 하나 추가합니다
호스트 이름은 도메인 자체(
@), 종류는 TXT입니다. 구글 워크스페이스만 쓰는 경우의 예시는 다음과 같습니다.v=spf1 include:_spf.google.com ~all발신 경로가 여럿이면
include:를 한 레코드 안에 나열합니다. 자체 서버가 있으면ip4:203.0.113.10처럼 IP를 직접 적습니다.v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all~all(softfail)로 시작해 발신 경로가 모두 확인되면-all(fail)로 바꿉니다.DKIM 키를 만들고 공개키를 게시합니다
DKIM 키는 메일 서비스의 관리 화면에서 만듭니다. 키 길이는 2048비트를 선택합니다. 서비스가 알려 주는 선택자(selector)와 값을 DNS에 넣습니다. 형태는 서비스마다 다릅니다.
# TXT 방식 (예: 구글 워크스페이스, 선택자 google) google._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...(공개키)" # CNAME 방식 (예: Microsoft 365, 선택자 selector1) selector1._domainkey.example.com. CNAME selector1-example-com._domainkey.tenant.onmicrosoft.com.레코드가 전파된 뒤 메일 서비스 관리 화면에서 "인증 시작" 또는 "DKIM 사용"을 켜야 실제로 서명이 붙습니다.
DMARC 레코드를 p=none으로 추가합니다
호스트 이름은
_dmarc, 종류는 TXT입니다. 처음에는 정책을none으로 두고 집계 리포트(rua)만 받습니다.v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=rrua주소로 수신 서버들이 하루 단위 XML 리포트를 보내옵니다. 양이 많으므로 전용 메일함을 만들거나 DMARC 리포트 분석 서비스를 쓰는 편이 편합니다.전파를 기다린 뒤 검증합니다
정책은 none, quarantine, reject 순서로 올립니다
DMARC 정책을 한 번에 reject로 올리면 파악하지 못한 발신 경로의 메일이 바로 반송됩니다. 각 단계에서 2~4주 리포트를 보면서 올리는 것이 안전합니다.
| 단계 | 정책 | 기간 | 할 일 |
|---|---|---|---|
| 1 | p=none | 2~4주 | 리포트에서 SPF/DKIM에 실패하는 발신 경로를 찾아 SPF에 추가하거나 DKIM 서명을 켭니다. |
| 2 | p=quarantine; pct=25 → pct=100 | 2~4주 | 실패 메일의 일부만 스팸함으로 보내 영향을 확인하고, 비율을 점차 100%까지 올립니다. |
| 3 | p=reject | 유지 | 실패 메일을 거부합니다. 사칭 메일이 수신자에게 도달하지 않습니다. |
각 단계에서 정상 메일이 실패하는 비율이 0에 가까워졌을 때 다음 단계로 넘어갑니다. 서브도메인 정책은 sp= 로 따로 정할 수 있습니다.
검증 방법
DNS에 레코드가 제대로 올라갔는지는 dig 명령으로 확인합니다.
dig +short TXT example.com # SPF
dig +short TXT google._domainkey.example.com # DKIM 공개키
dig +short TXT _dmarc.example.com # DMARC 정책
실제 메일에 인증이 붙는지는 Gmail 같은 외부 계정으로 테스트 메일을 보낸 뒤 "원본 보기"에서 Authentication-Results 헤더를 읽습니다. 세 항목이 모두 pass 여야 합니다.
Authentication-Results: mx.google.com;
dkim=pass header.i=@example.com header.s=google;
spf=pass (google.com: domain of user@example.com designates 209.85.220.41 as permitted sender);
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com
dkim=pass 인데 dmarc=fail 이면 서명 도메인(header.i)과 From 도메인이 다른 경우이므로 정렬(alignment)을 확인합니다.
흔한 실수
- SPF 조회 10회 제한. SPF 검증은
include,a,mx,redirect를 따라가며 DNS를 조회하는데, 총 10회를 넘으면permerror로 실패합니다. 메일 서비스 하나가 내부적으로 3~4회를 쓰기도 하므로, 발신 경로가 3개를 넘으면 조회 횟수를 세어 봐야 합니다. 쓰지 않는 include를 지우고, 고정 IP는ip4:로 직접 적으면 줄어듭니다. - SPF 레코드가 두 개. 이전 담당자가 넣은 레코드와 새 레코드가 같이 있으면 검증이 무조건 실패합니다.
v=spf1로 시작하는 TXT는 도메인당 하나만 둡니다. - DKIM 키가 1024비트. 오래된 기본값입니다. 2048비트로 새로 만들고, 기존 선택자와 다른 선택자를 써서 교체하면 무중단으로 바꿀 수 있습니다.
- DKIM 값을 따옴표째 붙여넣기. 공개키가 길어 255자 단위로 나뉜 경우, DNS 화면에 따라 따옴표를 빼고 한 줄로 넣어야 합니다.
dig로 조회해p=값이 끊기지 않았는지 확인하세요. - DMARC를 빼놓음. SPF와 DKIM만으로는 From 주소 사칭을 막지 못합니다.
p=none이라도 DMARC 레코드를 넣어야 대형 수신 서비스의 요구 조건을 채웁니다. - 서브도메인 방치. 본 도메인에 reject를 걸어도
sp=를 정하지 않으면 서브도메인에도 같은 정책이 적용되는데, 서브도메인에서 보내는 시스템 메일에 SPF/DKIM이 없으면 모두 반송됩니다.
메일 서비스별 구체적인 값은 구글 워크스페이스, Microsoft 365, 네이버 웍스 연결 가이드에 정리했습니다. 이 모든 설정은 도메인이 살아 있어야 의미가 있으므로, 도메인 만료로 메일이 통째로 끊기지 않도록 만료 사고 예방도 함께 확인하세요.
자주 묻는 질문
충분하지 않습니다. SPF는 메일이 전달(포워딩)되면 깨지기 쉽고, 발신자 표시 주소를 검사하지 않습니다. DKIM으로 서명하고 DMARC로 둘을 묶어야 대형 수신 서비스의 요구 조건을 채울 수 있습니다.
권장하지 않습니다. 파악하지 못한 발신 경로(마케팅 도구, 그룹웨어, 복합기 등)가 있으면 그 메일이 바로 반송됩니다. p=none으로 2~4주 리포트를 받아 발신 경로를 모두 확인한 뒤 quarantine, reject 순서로 올리는 편이 안전합니다.
DNS 레코드는 TTL에 따라 보통 수 분에서 최대 48시간 안에 전파됩니다. 다만 도메인의 발신 평판은 인증 설정 뒤 며칠에서 몇 주에 걸쳐 쌓이므로, 설정 직후에 스팸함 분류가 곧바로 사라지지 않을 수 있습니다.
아닙니다. 한 도메인에 SPF 레코드는 하나만 있어야 하고, 두 개 이상이면 검증이 실패합니다. 하나의 레코드 안에 include 항목을 여러 개 나열하세요. 다만 DNS 조회 횟수가 10회를 넘지 않도록 주의해야 합니다.
대량 발송이나 마케팅 메일은 별도 서브도메인(예: news.example.com)에서 보내는 것을 권장합니다. 그 서브도메인의 평판이 나빠져도 임직원이 쓰는 본 도메인의 메일에 영향이 적습니다. 서브도메인에도 SPF, DKIM, DMARC를 각각 설정합니다.
관련 가이드
- DNS 레코드 설정 (A, AAAA, CNAME, MX, TXT, SRV)A, AAAA, CNAME, MX, TXT, SRV 레코드가 각각 무엇을 하고 어떤 값을 넣어야 하는지 예시로 정리했습니다. 루트 도메인에 CNAME을 걸 수 없는 이유와 TTL 기준도 함께 다룹니다.
- 구글 워크스페이스 도메인 연결레토에 등록한 도메인을 구글 워크스페이스(Gmail)에 연결하는 절차입니다. 소유 확인 TXT, MX, SPF, DKIM, DMARC 레코드 값과 전파 시간, 확인 방법을 순서대로 정리했습니다.
- Microsoft 365 도메인 연결하기레토에 등록한 도메인을 Microsoft 365(Exchange Online)에 연결하는 절차입니다. 소유 확인 TXT, MX, autodiscover CNAME, SPF, DKIM CNAME 두 개와 DMARC까지 순서대로 정리했습니다.
- 네이버 웍스 도메인 연결레토에 등록한 도메인을 네이버 웍스(NAVER WORKS) 메일에 연결하는 절차입니다. 도메인 인증 TXT, MX, SPF, DKIM, DMARC 레코드를 순서대로 넣고 확인하는 방법을 정리했습니다.