SPF 레코드 확인 — SPF 검증 도구

SPF 조회로 모든 도메인의 SPF 레코드를 수신 메일 서버와 같은 방식으로 확인하세요: include별 DNS 조회 비용, 한도 10회에 대한 누적 횟수, void 조회, 그리고 발신 IP별 결과와 그 결과를 결정한 항목까지 보여 줍니다.

업데이트: 2026년 10월 24일

출처: 도메인의 TXT 레코드와 모든 include(Google Public DNS 경유, 그 뒤에 Cloudflare 1.1.1.1) · RFC 7208 check_host(저희 서버에서 실행) · 아무것도 저장하지 않습니다

입력한 이름 그대로 확인합니다: SPF에는 상속이 없으므로 mail.example.com에는 자체 레코드가 필요합니다.

예시

SPF 레코드란?

SPF 레코드는 도메인을 대신해 메일을 보낼 수 있는 서버를 나열한 TXT 레코드입니다. v=spf1로 시작해 발신자를 항목별로 지정하고, 나머지 모든 발신자를 수신 서버가 어떻게 처리할지를 마지막에 밝힙니다(RFC 7208, 2014년 4월, 지금도 현행 표준).

수신 서버는 접속한 서버의 주소와 봉투 발신자(MAIL FROM 또는 Return-Path)의 도메인을 기준으로 확인하며, 받는 사람이 보는 From: 줄은 기준이 아닙니다. SPF를 From:과 연결하는 것은 DMARC의 역할입니다.

레코드는 게시된 정확한 이름에만 적용됩니다: SPF에는 상속이 없으므로 mail.example.com에는 자체 레코드가 필요합니다. 메일을 보내지 않는 도메인은 v=spf1 -all을 게시해야 합니다.

SPF 레코드를 항목별로 보기google.com · TXT · 2026년 10월 24일 기록 · TTL 5분

v=spf1버전include:_spf.google.com메커니즘 · 조회 1회~all한정자 ~ · 메커니즘 all

이 include는 _spf.google.com을(를) 가리킵니다 · 범위 8개, 추가 조회 없음

ip4:74.125.0.0/16ip4:209.85.128.0/17ip6:2001:4860:4864::/56ip6:2404:6800:4864::/56ip6:2607:f8b0:4864::/56ip6:2800:3f0:4864::/56ip6:2a00:1450:4864::/56ip6:2c0f:fb50:4864::/56~all

버전정확히 v=spf1이 맨 앞에 와야 합니다: 다른 방식으로 시작하는 레코드는 SPF 레코드가 아닙니다.

메커니즘include, a, mx, ip4, ip6, exists, ptr, all을 왼쪽부터 차례로 시도하며, 처음 일치한 것이 결정합니다.

한정자+ pass(기본값), - fail, ~ softfail, ? neutral로, 메커니즘 앞에 씁니다.

수정자redirect=는 확인을 다른 레코드에 넘기고, exp=는 fail의 이유를 설명합니다.

google.com의 레코드 전체는 항목 세 개입니다: 수신 서버는 include를 가져와 발신 IP를 그 범위와 대조하거나 ~all에 이릅니다. 2026년 10월 24일에 Google Public DNS로 기록했습니다.

SPF 레코드 확인 방법

위에 도메인을 입력하면 확인 도구가 TXT 레코드를 읽어 v=spf1로 시작하는 것을 고른 다음, 수신 서버처럼 모든 include와 redirect를 따라가며 DNS 조회를 하나씩 셉니다.

직접 확인하려면 TXT 레코드를 조회합니다: dig TXT example.com +short 또는 nslookup -type=TXT example.com. 응답에는 해당 이름의 모든 TXT 레코드가 들어 있으며, SPF 레코드는 v=spf1로 시작하는 것입니다. 긴 레코드는 따옴표로 묶인 여러 문자열로 나오고, SPF는 이를 공백 없이 이어 붙입니다. include마다 쿼리가 하나씩 더 필요하므로 횟수는 직접 세어야 합니다.

특정 서버가 메일을 보낼 수 있는지 보려면 IP 테스트로 전환하세요: 해당 주소에 같은 확인을 실행하고 일치한 항목을 보여 줍니다.

% dig TXT example.com +short

리졸버가 가진 해당 이름의 모든 TXT 레코드입니다. SPF 레코드는 v=spf1로 시작하는 것입니다. include마다 다시 실행하세요.

dig가 보여 주는 것과 보여 주지 않는 것github.com · dig TXT · 2026년 10월 24일 기록

터미널TXT 레코드 24개 중 1개

$ dig TXT github.com @dns1.p08.nsone.net +norec +noall +answer
github.com.  3300  IN  TXT  1"v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.2"2 "27.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all"

# 그다음 include를 하나씩 질의합니다:
$ dig +short TXT _spf.salesforce.com4
"v=spf1 exists:%{i}._spf.mta.salesforce.com -all"

v=spf1로 시작하는 레코드는 하나입니다. 옆에 있는 다른 TXT 레코드 23개(소유 확인 토큰 등)는 응답 크기를 빼면 SPF와 무관합니다.
문자열 2개을 공백 없이 이어 붙입니다. 255바이트 단위 분할이 ip4:62.253.227.114 안에서 일어나지만, 수신 서버가 문자열을 다시 이어 붙이므로 문제없습니다.
TTL 5분. 변경 후 리졸버가 이 사본을 보관할 수 있는 시간입니다. 도메인 자체 서버는 5분이라고 답하며, 리졸버는 사본에 남은 시간을 보여 줍니다.
include마다 쿼리가 따로 필요합니다. github.com의 레코드를 따라가려면 중첩된 것까지 조회 10회이 필요합니다. dig는 이름 하나씩만 보여 주므로 10회까지의 횟수는 직접 더해야 합니다.

Windows

$ nslookup -type=TXT github.com 8.8.8.8

PowerShell

# Google Public DNS에서 가져온 해당 이름의 모든 TXT 레코드
PS> Resolve-DnsName -Name github.com -Type TXT -Server 8.8.8.8

이 페이지

/ko/spf-checker?domain=github.com

github.com의 자체 네임서버가 준 TXT 응답입니다: SPF 레코드는 도메인의 다른 TXT 레코드와 함께 문자열 두 개로 도착하며, 공백 없이 이어 붙여집니다.

결과 읽는 법: include 트리

판정은 레코드에 없는 발신자에게 수신 서버가 받는 결과를 알려 줍니다: 종료 항목에 따라 유효(~all이면 softfail, -all이면 fail), 원인이 붙은 permerror, 또는 DNS가 응답하지 않았을 때의 "확인 불가"입니다.

남색 열은 조회 예산입니다: DNS 조회 하나가 칸 하나이며, 그 조회를 쓰는 include별로 색이 칠해지고, 10회에 대한 누적 횟수와 void 조회(고리 모양)가 표시됩니다. 10번째를 넘으면 칸이 빨갛게 바뀌고 수신 서버가 멈추는 가지가 표시됩니다.

트리 보기에는 실패한 항목부터 판독 결과가 RFC 절과 해결 방법과 함께 나오고, 그다음 수신 서버가 질의하는 순서대로 모든 조회가 나옵니다.

github.com의 SPF 레코드 확인 결과: DNS 조회 10 / 10회, void 1회, 조회 예산에 표시된 include별 비용 — github.com의 SPF 확인 예시입니다. 판정, 항목별로 나눈 레코드, 판독 항목, include별 비용이 표시된 조회 예산을 보여 줍니다. 번호를 선택하면 각 부분이 무엇을 보여 주는지 확인할 수 있습니다.

조회 10회 한도와 "too many DNS lookups"(permerror)

수신 서버는 DNS 질의가 필요한 모든 항목(include, a, mx, ptr, exists, redirect)을 중첩된 include까지 모두 세며 10회에서 멈춥니다. 11번째는 permerror입니다(RFC 7208 §4.6.4). ip4, ip6, all, exp에는 비용이 들지 않습니다.

이것은 fail이 아니라 permerror입니다: 수신 서버가 어떻게 처리할지는 각자의 선택이지만, DMARC에서는 permerror가 pass로 인정되지 않습니다. 또한 확인은 처음 일치한 항목에서 멈추므로, 한도를 넘은 레코드도 앞쪽에 등록된 발신자에게는 pass하고 뒤쪽에 등록된 발신자에서만 문제가 생깁니다.

비용은 include 안에 숨어 있습니다: include:_netblocks.mimecast.com은 혼자 9회, Yandex 360은 8회, Freshdesk는 7회, Mailgun은 5회를 씁니다. Google과 Microsoft 365의 include는 각각 1회입니다. 10회 이하로 맞추려면 더 이상 쓰지 않는 발신자를 지우고, 대량 발송 업체는 자체 레코드를 가진 서브도메인으로 옮기세요.

10회 조회를 누가 쓰는가2026년 10월 24일 측정 비용 · 실제 include로 만든 가상의 레코드

v=spf1 include:spf.protection.outlook.com include:_netblocks.mimecast.com include:mailgun.org include:sendgrid.net -all

조회 17회 필요

처음 10회 조회 안에 등록됨: passMicrosoft 3651Mimecast2–10

10번째 조회 뒤에 등록됨: permerrorMailgun11–15Twilio SendGrid16–17

나머지 모든 발신자도 레코드의 -all fail이 아니라 permerror를 받습니다: 수신 서버가 거기에 이르기 전에 멈추기 때문입니다.

include 하나의 비용각 제공업체가 직접 안내하는 include · 2026년 10월 24일 측정

_netblocks.mimecast.comMimecast조회 9회
_spf.yandex.netYandex 360조회 8회
email.freshdesk.comFreshdesk조회 7회
mailgun.orgMailgun조회 5회
icloud.comiCloud+조회 5회
spf.titan.emailTitan Email조회 4회
secureserver.netGoDaddy조회 3회
_spf.google.comGoogle Workspace조회 1회
spf.protection.outlook.comMicrosoft 365조회 1회

RFC 7208 §4.6.4와 같은 방식으로 센 조회 횟수입니다: include 자체와 그 안의 모든 것을 합산합니다. 이 페이지의 실시간 횟수는 항상 이 표가 아니라 실제 확인 결과입니다.

void 조회란?

void 조회는 레코드가 하나도 돌아오지 않는 쿼리입니다: 이름이 존재하지 않거나(NXDOMAIN) 이름은 있지만 요청한 레코드가 없는 경우입니다. 수신 서버는 두 번까지 허용해야 하며, 세 번째는 permerror입니다(RFC 7208 §4.6.4).

없어진 호스트를 가리키는 항목 a:old.example.com은 그 자체로는 오류가 아닙니다: 일치하지 않고 void 1회로 셀 뿐입니다. Salesforce가 등록하지 않은 모든 발신자에 대한 exists:%{i}._spf.mta.salesforce.com도 마찬가지이며, 그래서 include의 순서가 중요합니다.

서버 장애나 시간 초과는 void가 아닙니다: temperror이며, 수신 서버는 보통 나중에 다시 시도합니다.

응답 네 가지, 결과 세 가지RFC 7208 §4.6.4

192.0.2.1 기준 salesforce.com의 자체 레코드, 2026년 10월 24일 기록

v=spf1 include:_spf.google.com include:_spf.salesforce.com exists:%{i}._spf.corp.salesforce.com ~all

void 조회2 / 2세 번째: permerror

exists:%{i}._spf.mta.salesforce.com192.0.2.1._spf.mta.salesforce.com → NXDOMAIN · 3번째 조회 · _spf.salesforce.com에서
exists:%{i}._spf.corp.salesforce.com192.0.2.1._spf.corp.salesforce.com → NXDOMAIN · 4번째 조회 · salesforce.com에서

결과: softfail, 허용된 void 2회를 모두 소모

이름은 있지만 레코드는 없음a:mail.example.com이 아직 존재하지만 더 이상 주소가 없는 이름을 가리킵니다: 답이 없는 NOERROR입니다. 일치 없음, void 1회로 세고 확인은 계속됩니다.NODATAvoid 조회

이름이 존재하지 않음exists:%{i}._spf.mta.salesforce.com은 발신 IP마다 이름을 만들며, Salesforce가 등록하지 않은 주소에서는 NXDOMAIN이 돌아옵니다: 매번 void 1회입니다.NXDOMAINvoid 조회

세 번째 voidmx:shop.example.com은 없어진 이름이며, 이미 void가 2회 발생한 뒤입니다: 수신 서버는 여기서 멈춥니다.NXDOMAINpermerror

응답이 전혀 없음include:_spf.vendor.example에 대한 SERVFAIL 또는 시간 초과: DNS 장애이므로 void로 세지 않습니다.SERVFAILtemperror, void 아님

blastmail의 include include:spf.bmv.jp는 이런 exists 항목 두 개로 시작합니다: 등록되지 않은 주소에서는 허용된 void 2회를 혼자 모두 소모합니다.

빈 응답만 void로 셉니다. 장애는 temperror이며, 확인은 나중에 다시 시도됩니다.

SPF flattening: 도움이 될 때와 문제가 될 때

flattening은 include를 그 안에 나열된 주소로 바꿔 레코드의 조회 횟수를 줄이는 방법입니다. 거의 바뀌지 않는 범위에는 효과가 있지만, 제공업체가 서버를 추가했는데 복사해 두지 않았다면 역효과가 납니다: 그 서버의 메일은 SPF를 통과하지 못합니다.

Microsoft는 include:spf.protection.outlook.com을 flatten하지 말라고 안내하며, Google과 Microsoft의 include는 이미 각각 조회 1회입니다. 대량 발송 업체를 news.example.com 같은 서브도메인으로 옮기면 자체 레코드와 조회 10회가 생깁니다.

include 하나를 flatten한 모습mailgun.org · 2026년 10월 24일 기록

include:mailgun.org

조회: 5
가져온 레코드: 5
내 레코드의 바이트: 19
Mailgun이(가) 범위를 변경: 즉시 반영됨

이후

ip4:159.135.224.0/20 ip4:69.72.32.0/20 ip4:204.220.90.0/23 ip4:204.220.92.0/22 +18개 더

조회: 0
내 레코드의 바이트: 450
필요한 TXT 문자열: 2
Mailgun이(가) 범위를 변경: 복사본이 오래됨

오래된 복사본의 위험. 지금 범위 22개를 복사해 두었는데, Mailgun이(가) 범위를 추가하면 누군가 알아채고 레코드를 고칠 때까지 그 범위의 메일은 SPF를 통과하지 못합니다.

flatten하기 자체 서버의 주소처럼 거의 바뀌지 않는 범위만 하세요.

flatten하지 않기 Microsoft 365: Microsoft는 발송 주소가 자주 바뀐다고 하므로 include를 유지하세요.

권장 대량 발송 업체마다 서브도메인 하나: 각각 자체 레코드와 조회 10회가 생깁니다.

flattening은 조회 횟수를 줄이는 대신 관리 부담을 늘립니다: 복사본은 제공업체가 범위를 바꾸기 전까지만 맞습니다.

~all과 -all의 차이(그리고 DMARC)

마지막 항목은 등록되지 않은 모든 발신자가 어떻게 처리될지를 정합니다. -all은 fail로 가장 강한 선언이고, ~all은 softfail로 "아마 아님"이며, ?all은 neutral로 수신 서버가 SPF가 없는 것과 똑같이 취급하고, +all은 누구나 pass시키므로 절대 게시하면 안 됩니다.

~all과 -all 사이에는 틀린 답이 없습니다. Google은 Google Workspace에 ~all을, Microsoft는 Microsoft 365에 -all을 안내합니다. DMARC를 강제 정책으로 쓰면 ~all은 DKIM에 대한 판단을 DMARC에 맡깁니다: 일부 수신 서버는 DMARC가 통과한 DKIM 서명을 확인하기 전에 -all만으로 거부하므로 전달된 메일이 반송될 수 있습니다(RFC 9989 §7.1).

종료 항목 네 가지RFC 7208 §2.6 · RFC 9989 §7.1

~all

softfail"아마 허용되지 않음": 수신 서버는 이것만으로 거부해서는 안 됩니다.

안내하는 곳Google WorkspaceMailguniCloud+

-all

fail가장 강한 선언: 수신 서버는 SMTP 단계에서 메시지를 거부할 수 있습니다.

안내하는 곳Microsoft 365ZendeskGoDaddy

?all

neutral아무 선언도 하지 않음: 수신 서버는 SPF가 없는 것과 똑같이 취급합니다.

안내하는 곳FastmailIONOS 및 OVHcloud의 include도 ?all로 끝납니다: include 안에서는 pass만 일치하므로 거기서는 무해합니다.

+all

pass for everyone인터넷의 어떤 서버든 이 도메인으로 pass합니다.

절대 게시하지 마세요

DMARC p=reject와 함께 쓴 -all

SPF 결과 fail
SMTP에서 거부
DKIM은 확인하지 않음

일부 수신 서버는 SPF를 먼저 처리하므로, 유효한 DKIM 서명이 있는 전달된 메시지도 DMARC가 실행되기 전에 거부될 수 있으며, 이 손실은 DMARC 보고서에 나타나지 않습니다.

DMARC p=reject와 함께 쓴 ~all

SPF 결과 softfail
DMARC가 DKIM 확인
정렬된 DKIM: pass

DMARC가 결정합니다. 다만 DKIM 서명이 없으면 Microsoft는 ~all 실패에 대해 DMARC가 사실상 무시된다고 하며, 그래서 -all를 권장합니다.

~all과 -all은 모두 유효한 선택입니다. ?all은 아무 선언도 하지 않고, +all은 누구나 pass시킵니다.

자주 보는 SPF 오류와 해결 방법

깨진 레코드의 대부분은 세 가지 실수에서 나옵니다: 첫 번째 레코드와 합치지 않고 옆에 SPF 레코드를 하나 더 추가함, 이미 떠난 업체의 include가 남아 있음, 문서에서 복사한 값에 오타가 있음.

업체 문서에 이런 실수가 그대로 실려 있기도 합니다: Mimecast는 –all을 엔 대시로, Postmark는 include: spf.mtasv.net을 공백과 함께, Twilio SendGrid는 존재하지 않는 aaaa 메커니즘을 안내합니다. 구문 오류가 하나라도 있으면 레코드 전체가 permerror입니다. 반면 도메인 끝의 점은 유효합니다.

레코드 여덟 개, 결과 여덟 가지실제 실수를 본뜬 가상의 예시

SPF 레코드 2개permerror

v=spf1 include:_spf.google.com ~allv=spf1 include:sendgrid.net ~all

해결: 하나로 합치세요: v=spf1 하나, 모든 include는 한 번씩, 종료 항목 하나.

조회 10회 초과permerror

v=spf1 include:_netblocks.mimecast.com include:mailgun.org -all

조회 14회

해결: 더 이상 쓰지 않는 발신자를 지우거나, 대량 발송 업체에 자체 서브도메인을 주세요.

세 번째 void 조회permerror

v=spf1 a:old.example.com mx:gone.example.net exists:%{i}.spf.example.org -all

void 3회

해결: 없어진 이름의 항목을 삭제하고 exists include는 맨 뒤에 두세요.

SPF 레코드가 없는 이름의 includepermerror

v=spf1 include:spf.retired-vendor.example -all

해결: 이름을 수정하거나, 떠난 업체를 제거하세요.

–all의 엔 대시permerror

v=spf1 include:_netblocks.mimecast.com –all

Mimecast의 공식 문서에 이 형태로 실려 있음

해결: 일반 하이픈을 쓰세요: -all.

include: 뒤의 공백permerror

v=spf1 a mx include: spf.mtasv.net ~all

Postmark의 공식 문서에 이 형태로 실려 있음

해결: include:spf.mtasv.net

aaaa 메커니즘permerror

v=spf1 aaaa:example.com ~all

Twilio SendGrid의 공식 문서에 이 형태로 실려 있음

해결: a:example.com. a가 이미 IPv6 발신자의 AAAA 레코드와도 일치합니다.

끝의 점유효

v=spf1 include:spf.protection.outlook.com. -all

유효: RFC 7208 §7.3은 게시하지 말라고 하지만, 수신 서버는 받아들여야 합니다.

Zendesk의 도움말에는 “redirect: 구문을 지원합니다”라고도 되어 있지만, 수정자는 redirect=로 씁니다(RFC 7208 §6.1).

각 레코드는 가상의 예시이며, 실수는 수신 서버가 가장 자주 보는 것들입니다.

Gmail, Yahoo, Microsoft의 요건

2024년 2월부터 Gmail과 Yahoo는 모든 발신자에게 SPF 또는 DKIM 설정을 요구합니다. 대량 발송자는 둘 다, 최소 p=none의 DMARC 레코드, 그리고 둘 중 하나와 정렬된 From: 도메인이 필요합니다. Outlook.com은 대량 발송자에게 SPF와 DKIM을 모두 요구하며, 2025년 5월 5일부터 이를 갖추지 않은 메일을 거부하고 있습니다.

Gmail의 기준은 개인 계정으로 하루 5,000통 초과이고, Yahoo는 기준을 공개하지 않습니다. SPF만으로는 메일이 "정렬"되지 않습니다: MAIL FROM 도메인이 제공업체의 반송 도메인이 아니라 자기 도메인이어야 합니다.

메일함 제공업체 세 곳의 규칙각 제공업체의 공식 페이지에서 2026년 10월 24일에 확인

	Gmail	Yahoo	Outlook.com
대량 발송 기준	Gmail개인 Gmail 계정으로 하루 5,000통 초과, 기본 도메인 기준	Yahoo공개된 기준 없음: “발송량 기준을 명시하지 않습니다”	Outlook.com하루 5,000통 초과(Microsoft 블로그), 하나의 From: 도메인에서 5,000통 이상(지원 문서)
모든 발신자	GmailSPF 또는 DKIM, 그리고 정방향·역방향 DNS, TLS, 0.3% 미만의 스팸 신고율	YahooSPF 또는 DKIM, 그리고 정방향·역방향 DNS, 0.3% 미만의 스팸 신고율	Outlook.com필수 규칙 없음
대량 발송자	GmailSPF 그리고 DKIM, DMARC(p=none이면 충분), SPF 또는 DKIM과 정렬된 From:, 마케팅 메일의 원클릭 구독 취소	YahooSPF 그리고 DKIM, 최소 p=none이며 통과하는 DMARC, SPF 또는 DKIM과 정렬된 From:, 원클릭 구독 취소	Outlook.comSPF가 반드시 pass하고 DKIM도 반드시 pass, 최소 p=none의 DMARC, SPF 또는 DKIM과 정렬
시행 시기	Gmail2024년 2월 1일. 거부는 2025년 11월부터 강화	Yahoo2024년 2월	Outlook.com2025년 5월 5일(거부)
SPF 실패 표시	Gmail`4.7.275.7.27`	YahooSPF에 대해서는 안내 없음	Outlook.com`550 5.7.515`

일본: NTT docomo의 가장 엄격한 설정 「全て拒否する」은 도메인의 SPF 레코드가 허용하지 않은 IP에서 온 메일과, SPF 레코드를 아예 게시하지 않은 도메인의 메일을 거부합니다. docomo.ne.jp

출처support.google.com senders.yahooinc.com techcommunity.microsoft.com

2026년 10월 24일 기준으로 각 제공업체의 페이지에 적힌 규칙입니다.

SPF 조회와 dig, nslookup의 차이

dig와 nslookup은 리졸버가 가진 TXT 레코드를 보여 줍니다: SPF 레코드와 해당 이름에 있는 그 밖의 레코드입니다. include를 따라가거나 조회와 void를 세지 않으며, 수신 서버가 어떻게 판단할지도 알려 주지 않습니다.

이 도구 같은 SPF 조회는 레코드 전체를 따라가므로 수치가 수신 서버의 계산과 일치합니다. 이름 하나를 볼 때는 dig, 판정을 볼 때는 이 확인 도구를 사용하세요.

SPF를 보는 세 가지 방법각각이 보여 주는 것

	이 확인 도구	`dig TXT`	`nslookup -type=TXT`
TXT 레코드 표시	이 확인 도구예항목별로 나눠서	dig TXT예	nslookup -type=TXT예
긴 레코드의 문자열 이어 붙이기	이 확인 도구예수신 서버처럼	dig TXT아니요문자열을 따로 표시	nslookup -type=TXT아니요문자열을 따로 표시
모든 include 따라가기	이 확인 도구예트리 전체	dig TXT아니요쿼리당 이름 하나	nslookup -type=TXT아니요쿼리당 이름 하나
10회까지 조회 세기	이 확인 도구예include별 누적 횟수	dig TXT아니요직접	nslookup -type=TXT아니요직접
void 조회 세기	이 확인 도구예이름과 함께	dig TXT아니요	nslookup -type=TXT아니요
레코드 2개 = permerror라고 알려 줌	이 확인 도구예	dig TXT아니요둘 다 출력	nslookup -type=TXT아니요둘 다 출력
발신 IP 테스트	이 확인 도구예check_host와 일치한 항목	dig TXT아니요	nslookup -type=TXT아니요
내 리졸버에 질의	이 확인 도구아니요저희 서버에서 Google Public DNS로	dig TXT예	nslookup -type=TXT예

같은 질문을 세 가지 방식으로 한 결과입니다: dig와 nslookup은 내 리졸버가 가진 것을, 이 확인 도구는 수신 서버가 계산하는 것을 보여 줍니다.

SPF 레코드 확인: 자주 묻는 질문

SPF 레코드 확인이란 무엇인가요?

SPF 레코드 확인은 도메인의 SPF 레코드(v=spf1로 시작하는 TXT 레코드)를 읽고 수신 메일 서버처럼 따라가는 것입니다. 모든 include와 redirect를 따라가며 DNS 조회는 한도 10회, 빈 응답은 한도 2회에 대해 셉니다. 결과는 등록되지 않은 발신자가 받는 처리, 또는 permerror와 그 원인입니다.

IP 주소가 내 도메인의 메일을 보낼 수 있는지 어떻게 테스트하나요?

IP 테스트를 선택하고 도메인과 발신 서버의 주소(IPv4 또는 IPv6)를 입력하며, 원하면 MAIL FROM 주소와 HELO 이름도 입력합니다. 해당 주소로 check_host를 실행해 pass, fail, softfail, neutral, permerror 중 하나와 일치한 항목, 그 한정자, 거기에 이른 include 경로를 보여 줍니다.

"SPF too many DNS lookups"는 무슨 뜻인가요?

레코드를 확인하는 데 DNS 조회가 10회를 넘게 필요하다는 뜻이며, 10회는 RFC 7208의 한도입니다. include, a, mx, ptr, exists, redirect는 각각 1회이고 include 안에 중첩된 것도 포함됩니다. 수신 서버는 11번째에서 permerror로 멈추므로 그 뒤에 등록된 발신자는 SPF를 통과하지 못합니다. 쓰지 않는 include를 지우거나 발신자를 자체 레코드가 있는 서브도메인으로 옮기세요.

SPF permerror란 무엇인가요?

permerror는 SPF에서 "이 레코드를 평가할 수 없다"는 결과입니다. DNS 조회 10회 초과, void 조회 2회 초과, 한 이름에 SPF 레코드 2개, SPF 레코드가 없는 이름의 include, 구문 오류에서 발생합니다. fail이 아닙니다: 수신 서버가 처리 방법을 결정하지만, DMARC에서는 pass로 인정되지 않습니다.

SPF의 void 조회란 무엇인가요?

void 조회는 SPF 항목을 위해 보낸 DNS 쿼리가 빈 응답으로 돌아오는 것입니다: 이름이 존재하지 않거나(NXDOMAIN) 요청한 유형의 레코드가 없는 경우입니다. RFC 7208은 수신 서버가 두 번까지 허용해야 한다고 하며, 세 번째는 permerror입니다. 서버 장애나 시간 초과는 void 조회가 아니라 temperror이며, 수신 서버는 보통 나중에 다시 시도합니다.

SPF 레코드는 ~all과 -all 중 무엇으로 끝내야 하나요?

둘 다 유효합니다. -all(fail)은 가장 강한 선언이며 Microsoft는 Microsoft 365에 이를 안내하고, ~all(softfail)은 Google이 Google Workspace에 안내하는 방식입니다. DKIM 서명과 DMARC를 quarantine 또는 reject로 쓴다면 ~all이 더 안전한 경우가 많은데, 일부 수신 서버는 DMARC가 통과한 DKIM 서명을 받아들이기 전에 -all만으로 거부하기 때문입니다.

도메인에 SPF 레코드를 두 개 둘 수 있나요?

아니요. 한 이름에 v=spf1로 시작하는 TXT 레코드가 두 개 있으면 수신 서버는 하나를 고를 수 없어 모든 발신자에 대해 조회 전에 permerror로 끝납니다(RFC 7208 §4.5). 새 제공업체의 레코드를 기존 레코드 옆에 추가할 때 흔히 생깁니다. v=spf1 하나, 모든 include는 한 번씩, 종료 항목 하나인 레코드로 합치세요.

SPF flattening이란 무엇이며 사용해야 하나요?

flattening은 include를 그 안에 나열된 IP 범위로 바꿔 레코드에 필요한 DNS 조회를 줄이는 방법입니다. 거의 바뀌지 않는 범위에는 도움이 되지만, 제공업체가 서버를 추가하면 flatten한 복사본이 곧바로 오래된 것이 되어 그 서버의 메일이 SPF를 통과하지 못합니다. 쓰지 않는 include를 지우거나 대량 발송 업체에 자체 서브도메인을 주는 편이 좋으며, Microsoft 365의 include는 절대 flatten하지 마세요.

서브도메인에도 자체 SPF 레코드가 필요한가요?

네. SPF에는 상속이 없습니다: 레코드는 게시된 정확한 이름에만 적용되므로, mail.example.com이나 news.example.com이 MAIL FROM이나 HELO에 나온다면 자체 레코드가 필요합니다. 조직 도메인으로 대체하는 DMARC와는 다릅니다. 메일을 보내지 않는 서브도메인은 v=spf1 -all을 게시하면 됩니다.

SPF가 여기서는 pass인데 Gmail에서는 fail인 이유는 무엇인가요?

대개 Gmail이 다른 도메인이나 주소를 확인했기 때문입니다. SPF는 MAIL FROM(Return-Path) 도메인과 접속한 서버의 IP를 기준으로 평가되며, 이 도메인은 내 도메인이 아니라 제공업체의 반송 도메인일 수 있습니다. 전달도 SPF를 깨뜨리는데, 전달한 서버의 IP가 내 레코드에 없기 때문입니다. 실제 메시지의 Authentication-Results 헤더를 확인하고 그 IP와 도메인을 여기서 테스트하세요.

SPF, DKIM, DMARC는 어떻게 다른가요?

SPF는 도메인을 대신해 보낼 수 있는 서버를 나열하며 봉투 발신자를 기준으로 확인합니다. DKIM은 DNS에 게시된 키로 메시지마다 서명하므로 전달되어도 서명이 유지됩니다. DMARC는 이 둘을 받는 사람이 보는 From: 주소와 연결합니다: From:과 정렬된 도메인에서 SPF 또는 DKIM이 pass하면 DMARC를 통과하고, 그렇지 않을 때 어떻게 할지는 정책이 정합니다.

SPF 레코드를 변경하면 적용되기까지 얼마나 걸리나요?

리졸버가 이전 레코드를 보관하는 시간만큼, 즉 도메인이 정한 TTL까지입니다(확인 당시 google.com과 github.com은 300초, microsoft.com은 1시간). 수신 서버는 자기 리졸버에 질의하므로, 캐시된 사본이 각각 만료되어야 변경이 보입니다. 이 확인 도구는 도메인의 자체 네임서버가 제공하는 TTL을 보여 주니, 그 시간이 지난 뒤 다시 확인하세요.

부족한 점이 있습니까?기능 또는 새 도구 제안하기

SPF 레코드 확인 — SPF 검증 도구

SPF 레코드란?

SPF 레코드 확인 방법

결과 읽는 법: include 트리

조회 10회 한도와 "too many DNS lookups"(permerror)

void 조회란?

SPF flattening: 도움이 될 때와 문제가 될 때

~all과 -all의 차이(그리고 DMARC)

자주 보는 SPF 오류와 해결 방법

Gmail, Yahoo, Microsoft의 요건

SPF 조회와 dig, nslookup의 차이

SPF 레코드 확인: 자주 묻는 질문

SPF 레코드 확인이란 무엇인가요?

IP 주소가 내 도메인의 메일을 보낼 수 있는지 어떻게 테스트하나요?

"SPF too many DNS lookups"는 무슨 뜻인가요?

SPF permerror란 무엇인가요?

SPF의 void 조회란 무엇인가요?

SPF 레코드는 ~all과 -all 중 무엇으로 끝내야 하나요?

도메인에 SPF 레코드를 두 개 둘 수 있나요?

SPF flattening이란 무엇이며 사용해야 하나요?

서브도메인에도 자체 SPF 레코드가 필요한가요?

SPF가 여기서는 pass인데 Gmail에서는 fail인 이유는 무엇인가요?

SPF, DKIM, DMARC는 어떻게 다른가요?

SPF 레코드를 변경하면 적용되기까지 얼마나 걸리나요?

MX 조회

DMARC 레코드 확인

DKIM 확인

이메일 헤더 분석

IP 블랙리스트 확인

역방향 DNS 조회

DNS 조회

SPF 레코드 생성기

SPF 레코드란?

SPF 레코드 확인 방법

결과 읽는 법: include 트리

조회 10회 한도와 "too many DNS lookups"(permerror)

void 조회란?

SPF flattening: 도움이 될 때와 문제가 될 때

~all과 -all의 차이(그리고 DMARC)

자주 보는 SPF 오류와 해결 방법

Gmail, Yahoo, Microsoft의 요건

SPF 조회와 dig, nslookup의 차이

SPF 레코드 확인: 자주 묻는 질문

SPF 레코드 확인이란 무엇인가요?

IP 주소가 내 도메인의 메일을 보낼 수 있는지 어떻게 테스트하나요?

"SPF too many DNS lookups"는 무슨 뜻인가요?

SPF permerror란 무엇인가요?

SPF의 void 조회란 무엇인가요?

SPF 레코드는 ~all과 -all 중 무엇으로 끝내야 하나요?

도메인에 SPF 레코드를 두 개 둘 수 있나요?

SPF flattening이란 무엇이며 사용해야 하나요?

서브도메인에도 자체 SPF 레코드가 필요한가요?

SPF가 여기서는 pass인데 Gmail에서는 fail인 이유는 무엇인가요?

SPF, DKIM, DMARC는 어떻게 다른가요?

SPF 레코드를 변경하면 적용되기까지 얼마나 걸리나요?

관련 이메일·DNS 도구

MX 조회

DMARC 레코드 확인

DKIM 확인

이메일 헤더 분석

IP 블랙리스트 확인

역방향 DNS 조회

DNS 조회

SPF 레코드 생성기