SPF, DKIM, DMARC 세 가지가 다 필요한가요?

Gmail이나 Outlook.com 주소로 하루 5,000통 정도 이상 보낸다면 그렇습니다. 두 곳 모두 SPF, DKIM, DMARC 레코드를 요구합니다. 그보다 적으면 Gmail은 SPF나 DKIM 중 하나 이상을 요구하지만, 실무에서는 셋 다 설정하는 것이 맞습니다. DNS 레코드 몇 개로 가장 흔한 거부 사유를 없앨 수 있습니다.

DMARC p=none으로도 Gmail·Yahoo 요건을 충족하나요?

충족합니다. 대량 발송자 요건은 DMARC 레코드를 요구하면서 p=none을 인정합니다. 다만 From: 헤더의 도메인으로 SPF나 DKIM이 통과해야(정렬) 한다는 조건도 있는데, 이 부분을 많이 놓칩니다.

SPF, DKIM, DMARC가 모두 통과하는데 왜 스팸함으로 가나요?

인증은 누가 보냈는지만 증명합니다. 받은편지함에 들어가는지는 그다음 평판이 정합니다. 스팸 신고율, 반송률, 발송량 패턴, 수신자의 반응, 메일 속 링크의 평판 등입니다. 새로 만든 도메인이나 갑자기 늘어난 발송량도 불리하게 작용합니다.

SPF는 ~all로 끝내야 하나요, -all로 끝내야 하나요?

DMARC가 있으면 둘 다 괜찮습니다. 실패한 메일을 어떻게 할지는 DMARC가 정하기 때문입니다. +all은 절대 쓰지 마세요. 인터넷의 모든 서버가 내 도메인으로 메일을 보내도 된다는 뜻입니다.

이메일 전달률 설정: SPF·DKIM·DMARC와 대량 발송 요건

인증이 해 주는 것과 해 주지 않는 것

SPF, DKIM, DMARC는 수신 메일 서버의 질문 하나에 답합니다. 이 메일이 정말 주장하는 도메인에서 왔는가. 그 메일을 받고 싶게 만들어 주지는 않습니다.

이 구분이 전달률에 관한 혼란 대부분을 설명합니다. 인증이 없으면 대형 수신 서버는 메일 내용이 아무리 좋아도 거부하거나 스팸함에 넣습니다. 인증이 있으면 심사를 받을 자격이 생기고, 수신 서버는 그다음 평판을 봅니다. 수신자가 내 메일에 어떻게 반응하는지, 반송이 얼마나 나는지, 발송량이 정상적으로 보이는지입니다. 인증을 통과한 스팸도 스팸함으로 갑니다.

그래서 일은 두 부분입니다. 아래 설정은 기계적인 절반이고, 한 번 해 두고 가끔 점검하면 됩니다. 평판은 계속 관리해야 하는 나머지 절반이고, 설정 다음에 다룹니다.

0단계: 내 도메인으로 메일을 보내는 것을 모두 적기

DNS를 건드리기 전에 이것부터 하세요. From: 헤더에 내 도메인을 넣는 시스템은 하나도 빠짐없이 챙겨야 합니다.

메일함 서비스(Google Workspace, Microsoft 365, 직접 운영하는 메일 서버)
마케팅 메일(뉴스레터, 캠페인)
서비스가 보내는 트랜잭션 메일(비밀번호 재설정, 영수증). Amazon SES, SendGrid, Postmark, Mailgun 같은 서비스를 거치는 경우가 많습니다
CRM, 고객 문의, 청구, 인사, 설문 도구
직접 메일을 보내는 웹 서버와 장비: 문의 폼, 모니터링 알림, 사무실 복합기

잊어버리는 것은 대개 세 번째와 네 번째 묶음이고, DMARC를 강화할 때 반송되기 시작하는 것도 바로 이것들입니다. 이미 rua=가 들어간 DMARC 레코드가 있다면 집계 보고서가 발송처를 모두 보여 줍니다.

1단계: SPF, 보낼 수 있는 곳을 적은 레코드 하나

SPF는 내 도메인에 두는 TXT 레코드로, 이 도메인의 메일을 보내도 되는 서버 목록입니다.

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

include:에 넣을 값은 업체마다 문서에 나와 있습니다. 중요한 규칙은 이렇습니다.

레코드는 하나만. v=spf1로 시작하는 TXT 레코드가 두 개면 영구 오류(PermError)이고, 수신 서버는 SPF가 없는 것처럼 처리합니다. 하나로 합치세요.
DNS 조회는 최대 10회. include, a, mx, ptr, exists, redirect가 하나씩 조회를 쓰고, include 안의 include도 셉니다. 10회를 넘으면 SPF가 PermError로 실패합니다. 업체 몇 개만 넣어도 넘을 수 있습니다. 세는 법과 줄이는 법은 SPF PermError: DNS 조회 10회 초과에 있습니다.
끝은 ~all 또는 -all. DMARC가 강제 정책이 되면 둘의 차이는 크지 않습니다. +all은 누구나 내 도메인으로 보내도 된다는 뜻이니 절대 쓰지 마세요.

SPF를 보는 관점을 바꾸는 사실이 하나 있습니다. SPF는 사람들이 보는 From: 주소가 아니라 봉투 발신자(Return-Path, MAIL FROM)를 검사합니다. 메일 발송 서비스 대부분은 기본으로 자기 반송 도메인을 쓰기 때문에, SPF는 내 도메인이 아니라 업체 도메인으로 통과합니다. 내 SPF에 업체 include를 추가해도 이것은 달라지지 않습니다. DMARC에 도움이 되는 것은 업체 대시보드에서 사용자 반송 도메인(custom MAIL FROM, bounce.example.com 같은 bounce domain)을 설정하는 것이고, 그래야 SPF가 내 도메인으로 통과합니다.

SPF는 단순 전달(forwarding)에서도 깨집니다. 전달하는 서버가 내 목록에 없기 때문입니다. DKIM이 더 중요한 이유입니다.

2단계: DKIM, 모든 메일에 서명하기

DKIM은 메일마다 개인키로 서명하고, 수신 서버는 내가 DNS의 셀렉터._domainkey.example.com에 게시한 공개키로 확인합니다. 대부분은 키를 직접 만들 필요가 없습니다. 발송 서비스가 넣을 레코드를 줍니다.

Google Workspace: 관리 콘솔(Gmail, 이메일 인증)에서 키를 만들고, google._domainkey에 TXT 레코드를 게시한 뒤 “인증 시작”을 누릅니다. 누르기 전까지 Google은 DMARC에 도움이 되지 않는 gappssmtp.com 도메인으로 서명합니다.
Microsoft 365: Defender 포털이 알려 주는 대상으로 selector1._domainkey, selector2._domainkey CNAME 두 개를 게시하고, 도메인의 DKIM을 켭니다. 그전까지는 onmicrosoft.com 도메인으로 서명합니다.
메일 발송 서비스: “도메인 인증”이나 “발신자 인증” 메뉴를 찾으세요. 추가할 CNAME이나 TXT 레코드를 줍니다.
직접 운영하는 서버(OpenDKIM, Rspamd 등): 키 쌍을 만들고, 공개키를 게시하고, 서명 프로그램을 설정합니다.

2048비트 RSA 키를 쓰세요. Google도 이것을 권장합니다. 2048비트 키는 TXT 문자열 하나의 한도인 255자보다 길어서, 따옴표로 묶인 문자열 여러 개를 담은 레코드 하나로 게시합니다. 알아서 나눠 주는 DNS 관리 화면도 있고, 직접 나눠야 하는 곳도 있고, 레코드를 두 개로 만들어 망가뜨리는 곳도 있습니다. dig +short TXT google._domainkey.example.com으로 결과를 확인하세요. 응답이 하나여야 하고, 그 안이 따옴표로 묶인 여러 조각일 수는 있습니다.

DMARC에 중요한 것은 서명의 d= 도메인입니다. 업체 도메인이 아니라 내 도메인(또는 그 서브도메인)이어야 합니다. 0단계의 모든 발송처가 이렇게 되어야 합니다.

서명은 붙어 있는데 실패한다면 DKIM 실패와 “body hash did not verify” 원인 찾기를 보세요.

3단계: DMARC, From: 주소와 묶기

DMARC는 _dmarc.example.com에 두는 TXT 레코드입니다.

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

하는 일은 두 가지입니다. SPF나 DKIM이 From: 헤더의 도메인으로 통과할 때만 인증된 메일로 보라고 수신 서버에 알리고(이것이 “정렬”입니다), 실패한 메일을 어떻게 할지 알립니다. rua=를 넣어 p=none으로 시작해 보고서를 받고, 보고서를 보며 0단계의 정상 발송처를 모두 고친 다음 quarantine, reject로 올립니다. 보고서 읽는 법을 포함한 전체 전환 과정은 DMARC p=none·quarantine·reject 차이와 올리는 시점에 있습니다.

메일을 아예 보내지 않는 도메인은 처음부터 v=spf1 -all과 v=DMARC1; p=reject를 게시하세요. 정상적으로 쓰는 곳이 없으니 깨질 것도 없고, 사칭하는 쪽은 쉬운 표적을 잃습니다.

4단계: 직접 운영하는 서버라면 서버 쪽 설정

메일이 전부 Google Workspace, Microsoft 365, 메일 발송 서비스를 거친다면 이 부분은 업체가 처리합니다. 발신 메일 서버를 직접 운영하거나 VPS에서 바로 보낸다면 내 몫입니다.

역방향 DNS. 발신 IP에 호스트명을 가리키는 PTR 레코드가 있어야 하고, 그 호스트명이 다시 같은 IP로 해석되어야 합니다. Gmail은 모든 발신자에게 이것을 요구합니다. PTR은 내 도메인 DNS가 아니라 IP를 소유한 곳(호스팅이나 클라우드 업체)에서 설정합니다. 역방향 DNS·PTR 설정 가이드를 보고, 역방향 DNS 조회로 왕복이 맞는지 확인하세요.
일치하는 HELO 이름. 서버가 자기소개할 때 같은 호스트명을 써야 합니다.
TLS. Gmail은 발신자에게 TLS를 요구합니다. 요즘 메일 서버는 모두 STARTTLS를 지원하니, 유효한 인증서로 켜져 있는지 확인하세요.
나가는 25번 포트. 많은 클라우드 업체가 새 계정에서 기본으로 막습니다. 서버가 25번으로 밖에 연결하지 못하면 다른 설정은 의미가 없습니다.

Gmail·Yahoo·Microsoft가 요구하는 것

Gmail과 Yahoo는 2024년 2월부터 발신자 요건을 공개하고 적용해 왔고, Microsoft도 2025년에 Outlook.com, Hotmail, Live 주소에 대해 비슷한 요건을 발표했습니다. 핵심은 같습니다.

요건	Gmail 전체 발신자	Gmail 대량 발신자	Yahoo 대량 발신자	Outlook.com 대량 발신자
SPF와 DKIM	SPF 또는 DKIM	둘 다	둘 다	둘 다
DMARC 레코드(p=none 인정)	권장	필수, SPF나 DKIM과 정렬	필수, 정렬	필수, SPF나 DKIM과 정렬
발신 IP의 정방향·역방향 DNS	필수	필수	필수	—
SMTP 연결의 TLS	필수	필수	—	—
마케팅 메일의 원클릭 수신 거부	—	필수	필수	권장
스팸 신고율	0.3% 미만	0.3% 미만	0.3% 미만	—

대시(—)는 저희가 아는 한 그 업체가 밝힌 요건 목록에 없다는 뜻입니다. 그래도 하세요. 실무에서는 어느 것도 생략할 수 있는 항목이 아닙니다.

알아 둘 세부 사항입니다.

Gmail의 대량 발신 기준은 개인 Gmail 계정으로 24시간에 약 5,000통이고, 기본 도메인에서 나가는 메일을 모두 합쳐 셉니다. Google 안내에 따르면 한 번 이 기준을 넘으면 이후 발송량이 줄어도 계속 대량 발신자로 취급됩니다.
Microsoft의 기준도 Outlook.com 개인 주소로 하루 5,000통입니다. Microsoft는 요건을 충족하지 못한 메일을 처음에는 정크 메일함으로 보내고, 이후 550 5.7.515로 거부하겠다고 발표했습니다.
Yahoo는 저희가 아는 한 고정된 발송량 기준을 공개하지 않았습니다. 핵심 요건은 Google과 같습니다. 최신 문구는 Yahoo Sender Hub에서 확인하세요.
원클릭 수신 거부는 RFC 8058을 말합니다. DKIM 서명에 포함된 헤더 두 개와, 본문에 보이는 수신 거부 링크가 필요합니다. 요청은 2일 안에 처리해야 합니다. 마케팅·구독 메일에 해당하고, 영수증이나 비밀번호 재설정 메일은 대상이 아닙니다.

List-Unsubscribe: <https://example.com/unsub?u=8f3a2c>, <mailto:unsub@example.com?subject=unsub-8f3a2c>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

스팸 신고율은 Google Postmaster Tools에 나오는 사용자 신고 비율입니다. Google은 0.1% 미만을 유지하고 0.3%에는 절대 도달하지 말라고 합니다. Postmaster Tools는 Gmail로 보내는 양이 충분해야 데이터를 보여 줍니다.

적용은 요건이 시작된 뒤 단계적으로 강해져 왔습니다. 일시 오류에서 시작해 실제 거부까지 갑니다. 요건 자체도 가끔 바뀝니다. 큰 발송을 앞두고 있다면 요약 글(이 글 포함)에 기대지 말고 각 업체의 발신자 가이드라인 페이지를 직접 확인하세요.

모두 통과하는데 스팸함으로 갈 때

SPF, DKIM, DMARC가 정렬된 채 통과한다면 남은 원인은 평판과 내용입니다. 실제로 원인으로 밝혀지는 빈도를 대략 순서로 놓으면 이렇습니다.

스팸 신고. “스팸 신고” 클릭 하나하나가 셉니다. 받겠다고 분명히 하지 않은 메일, 쉽게 끊을 수 없는 메일은 신고를 부릅니다. 눈에 잘 띄는 수신 거부 링크는 구독자 한 명을 잃게 하지만, 스팸 신고는 그 업체의 모든 수신자 앞에서 평판을 잃게 합니다.

주소 목록의 품질. 존재하지 않는 주소(오래된 목록, 오타, 사거나 긁어 모은 목록)로 보내면 하드 바운스가 나고, 오래된 주소 일부는 스팸 트랩으로 재활용됩니다. 하드 바운스는 즉시 지우고, 오랫동안 아무것도 열어 보지 않은 사람에게는 그만 보내세요.

새 도메인·새 IP, 갑작스러운 발송량. 수신 서버는 새 도메인이나 IP에 대한 이력이 없어서 조심스럽게 다룹니다. 반응이 좋은 수신자부터 보내고, 몇 주에 걸쳐 양을 늘리세요. 발송량이 적은 전용 IP는 업체가 잘 관리하는 공유 IP 풀보다 못한 경우가 많습니다.

링크와 내용. 메일 속 모든 링크 도메인의 평판이 반영됩니다. 공개 단축 URL, 스패머와 같이 쓰는 추적 도메인, 갓 등록한 도메인으로 가는 링크는 모두 불리합니다. 글은 거의 없고 이미지만 있는 메일도 마찬가지입니다.

블랙리스트. 발신 IP나 도메인이 DNS 블랙리스트에 올라 있으면 바로 거부하는 수신 서버도 있습니다. 해제 절차는 메일 서버 블랙리스트 해제 체크리스트에 있습니다. 저희 도구에 관해 주의할 점이 하나 있습니다. 이메일 점검은 도메인을 넣으면 MX 호스트(최대 4개)의 IP를 SpamCop, Barracuda, PSBL, Spamhaus에 조회합니다. 즉 메일을 받는 서버에 대한 정보입니다. 메일을 다른 서비스로 보낸다면 실제 발신 IP를 같은 도구에 넣어 확인하세요. Spamhaus는 공용 DNS 리졸버를 거친 조회에 답하지 않아서 여기서는 항상 “확인 불가”로 나옵니다. Spamhaus 자체 조회 페이지에서 확인하세요.

전체를 시험하는 방법

도메인을 이메일 점검에 넣습니다. MX, SPF(최상위 레코드의 조회 메커니즘 개수 포함), DMARC 정책, 흔한 셀렉터 18개로 찾은 DKIM, BIMI, MTA-STS, TLS-RPT, DANE를 보여 줍니다. 여기서 DKIM “감지 안 됨”은 쓰는 업체의 셀렉터가 목록 밖이라는 뜻일 수도 있습니다.
각 발송 시스템에서 Gmail 주소와 Outlook.com 주소로 실제 메일을 보냅니다. Gmail의 “원본 보기” 맨 위에 SPF, DKIM, DMARC 결과가 나옵니다. DKIM이 업체 도메인이 아니라 내 도메인으로 통과하는지 확인하세요.
헤더를 이메일 헤더 분석에 붙여 넣어 판정 결과와 메일이 거친 홉을 모두 봅니다.
Gmail로 보내는 양이 많아지면 Google Postmaster Tools에 도메인을 등록하고 스팸 신고율을 지켜봅니다.

이미 쓰고 있는 도메인을 dig로 레코드별로 빠르게 확인하려면 MX·SPF·DKIM·DMARC 레코드 확인법을 보세요.

내 도메인에서 바로 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.