SPF 레코드 조회·검사
도메인의 SPF TXT 레코드를 조회하고 구문·중복을 점검합니다.
SPF(Sender Policy Framework)는 어떤 메일 서버가 내 도메인 이름으로 메일을 보낼 수 있는지를 DNS의 TXT 레코드로 선언하는 표준입니다. 이 도구는 도메인의 SPF 레코드를 실시간으로 조회해 원문을 보여 주고, include·ip4·ip6·a·mx·redirect·all 같은 메커니즘을 하나씩 분해해 어떤 발신처가 허용되는지, 그리고 마지막 all 정책이 어떻게 설정됐는지를 한눈에 보여 줍니다.
SPF가 없거나 잘못 설정되면 정상 메일이 스팸으로 분류되거나, 반대로 누군가 내 도메인을 사칭(스푸핑)하기 쉬워집니다. 특히 SPF 레코드가 두 개 이상이면 표준 위반으로 검증 자체가 실패할 수 있으므로, 이 도구는 그런 경우를 경고로 표시합니다. 도메인만 입력하면 됩니다(프로토콜·경로 불필요).
SPF 메커니즘 빠른 정리
- ip4 / ip6: 발신을 허용할 IPv4·IPv6 주소 또는 대역(CIDR)
- a / mx: 도메인의 A 레코드 또는 MX 서버를 발신처로 허용
- include: 다른 도메인의 SPF 정책을 포함(예: 메일 발송 SaaS)
- redirect: SPF 평가를 지정한 다른 도메인으로 위임
- all: 위 어디에도 해당하지 않는 나머지 발신처의 처리 정책
all 정책(끝맺음)이 핵심
SPF는 보통 all로 끝나며, 앞에 붙는 한정자(qualifier)가 정책을 결정합니다. -all(하드페일)은 허용되지 않은 발신을 거부하라는 강한 정책이고, ~all(소프트페일)은 의심스럽지만 통과시키되 표시하라는 완화 정책입니다. ?all(중립)과 +all(모두 허용)은 사실상 보호 효과가 없어 권장하지 않습니다. 운영이 안정됐다면 ~all에서 -all로 강화하는 것이 좋습니다.
주의할 점
SPF의 DNS 조회 횟수(include·a·mx·redirect 등)는 합쳐 10회를 넘으면 안 됩니다(permerror). include를 너무 많이 중첩하면 한도를 초과해 SPF가 무효가 될 수 있으니 주의하세요. 현재 조회 수가 몇 회인지는 SPF 조회 수 계산기로 확인할 수 있습니다. 또한 SPF 레코드는 도메인당 정확히 하나여야 하며, 여러 발송 서비스는 별도 레코드가 아니라 하나의 SPF 안에 include로 합쳐야 합니다. SPF는 DKIM(DKIM 레코드 조회)·DMARC(DMARC 레코드 조회·검사)와 함께 갖춰야 위조를 효과적으로 막으며, 세 가지를 한 번에 평가하려면 이메일 도달성 종합 점검를 사용하세요.
한정자(qualifier)는 all에만 붙는 게 아닙니다
위에서 본 -all·~all 같은 부호는 사실 모든 메커니즘 앞에 붙을 수 있는 한정자입니다. 부호를 생략하면 +(Pass)로 간주됩니다. 즉 include:_spf.google.com은 내부적으로 +include:_spf.google.com과 같습니다. 평가는 왼쪽에서 오른쪽으로 진행되며, 처음 일치한 메커니즘의 한정자가 그대로 결과가 됩니다.
| 한정자 | 결과 | 수신측 일반적 처리 |
|---|---|---|
+ (기본값) | Pass | 허용된 발신처로 인정, 정상 수신 |
- | Fail (하드페일) | 거부 또는 폐기 |
~ | SoftFail | 통과시키되 의심 표시(스팸함행이 흔함) |
? | Neutral | 정책 없음과 동일하게 취급 |
레코드 분해 예시
예를 들어 조회 결과가 다음과 같다고 합시다:
v=spf1 ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net ~all
이 도구는 이를 네 부분으로 분해합니다. ip4:203.0.113.10은 그 단일 IP에서 온 메일을 Pass로 허용합니다. include:_spf.google.com·include:sendgrid.net은 각각 Google Workspace와 SendGrid의 SPF를 끌어와, 그 서비스가 공개한 발송 IP 대역도 모두 허용 목록에 포함됩니다(여기서 DNS 조회가 추가로 발생). 마지막 ~all은 “위 어디에도 안 맞으면 소프트페일”이라는 끝맺음입니다. 만약 발송 IP가 203.0.113.10이면 첫 메커니즘에서 즉시 Pass로 끝나고, 무관한 IP면 끝까지 내려가 SoftFail이 됩니다. include 대상이 또 다른 include를 품고 있으면 조회 횟수가 빠르게 누적되니SPF 조회 수 계산기로 10회 한도를 함께 확인하세요.
흔한 실수 / 함정
- 발송 서비스를 추가할 때
v=spf1 include:sendgrid.net ~all처럼 두 번째 SPF TXT를 따로 만드는 것 — 이러면 레코드가 두 개가 되어 permerror로 SPF 전체가 무효가 됩니다. 반드시 기존 한 줄 안에 include를 추가하세요. a·mx·ptr을 습관처럼 넣어 두는 것 — 실제로 그 서버로 메일을 보내지 않는다면 불필요하게 DNS 조회만 소모합니다(ptr은 표준에서 사용 비권장).+all로 끝내는 것 — 모든 IP를 허용한다는 뜻이라 SPF를 사실상 무력화하므로, 조회 결과에 보이면 즉시 수정 대상입니다.
자주 묻는 질문
SPF 레코드는 어디에 등록하나요?
SPF 레코드가 두 개면 어떻게 되나요?
~all과 -all 중 무엇을 써야 하나요?
SPF만 설정하면 스푸핑이 완전히 막히나요?
입력한 도메인 정보가 외부로 전송되나요?
관련 가이드
- SPF 10회 조회 한도 초과(permerror) 해결SPF의 10회 DNS 조회 한도를 넘겨 permerror가 날 때 원인 진단과 평탄화로 해결하는 법.
- 메일이 스팸함에 빠지는 이유: SPF·DKIM·DMARC 한 번에발송 메일이 스팸 처리되는 흔한 원인과 SPF·DKIM·DMARC를 함께 맞추는 방법.
- 메일 헤더 보는 법: 발신자 추적과 피싱 판별원본 헤더를 열어 실제 발신 서버를 추적하고 SPF·DKIM·DMARC 결과로 위조 메일을 가려내는 법.
- DKIM 설정 방법: 키 생성부터 DNS 등록·검증까지DKIM 서명이 동작하는 원리와 selector 개념, 키 생성·DNS 등록·정상 동작 확인 절차.