SPF 레코드를 찾을 수 없음: 원인과 해결 방법

검사 도구가 "no SPF record found"라고 하거나 메시지 헤더에 spf=none이 표시됩니다. 두 보고는 같은 의미입니다. 리졸버가 특정한 이름의 TXT 레코드를 요청했는데 v=spf1로 시작하는 것이 하나도 없었다는 뜻입니다. 메일 서버에는 아무 문제가 없습니다. 문제는 응답이 왜 비어 있었느냐이고, 대개는 잘못된 이름을 확인했거나 잘못된 이름에 게시한 경우입니다.

이 글은 그 빈 응답을 진단하는 방법을 다룹니다. 레코드가 있는데 오류가 나는 경우라면 대신 DNS 조회 횟수 초과와 10회 조회 제한에 관한 글을 보세요.

"찾을 수 없음"이 실제로 뜻하는 것

SPF는 일반 TXT 레코드에 있습니다. 수신 측은 메시지에서 도메인(보통 봉투 발신자이며 반송 주소나 Return-Path 주소라고도 합니다)을 가져와 그 TXT 레코드를 요청하고, 텍스트가 v=spf1로 시작하는 것만 남깁니다. 걸러낸 목록이 비어 있으면 결과는 none입니다. 구문 오류가 아니라 정책이 없다는 뜻입니다.

이는 흔히 혼동하는 다른 두 상황과 다릅니다. 각각 결과와 해결 방법이 다릅니다.

원인 1: 레코드가 잘못된 이름에 있음

SPF는 메일에 사용된 도메인에서만 조회하며 다른 곳은 보지 않습니다. 상위 도메인에서 상속되지 않고 www에서 찾지도 않습니다. www.example.com에 게시한 레코드는 @example.com에서 보낸 메일에 아무 효과가 없고, example.com의 레코드는 @news.example.com에서 보낸 메일에 아무 효과가 없습니다.

전형적인 실수는 DNS 관리 화면에서 일어납니다. 루트 도메인(apex, 즉 하위 이름이 없는 도메인 자체)의 레코드는 호스트 필드에 보통 @를 쓰지만, 비워 두라고 하거나 전체 도메인을 쓰라고 하는 화면도 있습니다. 화면의 안내 문구를 읽은 다음, 입력 양식을 믿지 말고 직접 조회해서 확인하세요.

• www나 mail에 있는 레코드: 내용은 맞지만 호스트가 틀렸습니다. @example.com에서 발송한다면 apex로 옮기세요.
• 도메인 중복: 영역 이름을 자동으로 덧붙이는 화면에서는 example.com이 example.com.example.com이 됩니다. 그 이름을 조회하면 레코드가 거기에 있는 것을 볼 수 있습니다.
• 발신 도메인 오류: example.com을 확인했지만 봉투 발신자는 bounce.example.net이나 mail.example.com입니다. 수신 측은 내 도메인이 아니라 그 이름을 조회했습니다.

원인 2: 메일이 쓰는 도메인과 다른 도메인을 확인하고 있음

사람들이 From 헤더에서 보는 주소와, SPF가 평가하는 봉투 발신자는 다를 수 있습니다. 많은 이메일 서비스 제공업체가 사용자 지정 반송 도메인을 쓰고, 기본값으로 자사 도메인을 쓰는 곳도 있습니다. 그러면 SPF는 그 이름으로 평가되고, 내 레코드는 검사에서 전혀 참조되지 않습니다.

메시지 헤더에는 어느 도메인이 평가되었는지 나옵니다(아래 참고). 그것이 내 하위 도메인이라면 상위 도메인의 레코드가 완벽하더라도 그 하위 도메인에는 자체 레코드가 필요합니다. 발송하지 않는 하위 도메인은 v=spf1 -all을 게시할 수 있습니다.

원인 3: 텍스트가 유효한 SPF 문자열이 아님

검사기는 값의 시작 부분에 엄격합니다. 텍스트는 v=spf1로 시작해야 하며, 등호가 있고 그 안에 공백이 없어야 합니다. 다음과 같이 아슬아슬하게 틀린 경우는 모두 "찾을 수 없음"이 됩니다.

• spf1 include:_spf.example.net ~all (v=가 빠짐)
• v=spf include:_spf.example.net ~all (버전은 spf1이어야 함)
• v = spf1 ... (등호 앞뒤에 공백)
• 문서나 채팅에서 복사한 구부러진 "스마트" 따옴표가 들어간 텍스트

따옴표는 따로 짚어 둘 만합니다. 대부분의 호스팅형 DNS 관리 화면은 곧은 큰따옴표를 자동으로 붙여 주므로, 직접 입력하면 문자 그대로 저장될 수 있습니다. dig 응답에 따옴표가 두 겹으로 보이면 직접 입력한 쪽을 지우세요.

원인 4: 수정한 영역이 실제로 사용 중인 영역이 아님

경험이 많은 사람도 속는 경우입니다. DNS 관리 화면에서 완벽한 TXT 레코드를 추가했는데도 공개 DNS에는 아무것도 보이지 않을 수 있습니다. 그 화면이 인터넷이 질의하는 곳이 아니기 때문입니다. 보통의 이유는 위임입니다.

• 등록 대행사와 DNS 호스트가 다름: 도메인은 한 회사에 등록되어 있지만 네임서버는 다른 곳(CDN, 호스팅 회사, 별도의 DNS 제공업체)을 가리킵니다. 위임된 네임서버에 있는 영역만 실제로 사용됩니다. 등록 대행사 자체의 DNS 페이지나 이전 제공업체에 남아 있는 영역에 추가한 레코드는 무시됩니다.

NS 조회로 위임된 네임서버를 찾은 다음, 바로 그 제공업체에서 영역을 수정하세요. "한 시간 전에 추가했는데 아직도 안 나온다"는 상황은 전파 지연보다 이 경우로 설명되는 일이 많습니다.

원인 5: 오래된 레코드 유형, 캐시 또는 시간

초기 SPF 초안은 전용 레코드 유형(번호 99, 이름 SPF)을 사용했습니다. 이 유형은 더 이상 권장되지 않고 수신 측은 TXT 레코드를 평가하므로, SPF 유형으로만 게시한 레코드는 최신 검사에서 보이지 않습니다. DNS 제공업체가 아직 SPF 유형을 제공하더라도 TXT 레코드를 게시하세요.

시간은 마지막으로 의심할 대상이며 가능성도 가장 낮습니다. 리졸버가 그 이름에 TXT 레코드가 없다는 것을 이미 알게 되었다면, 영역의 네거티브 캐싱 설정에 따른 기간 동안 그 빈 응답을 계속 줄 수 있습니다. 권한 있는 네임서버에 직접 질의하면 의심이 풀립니다. 동작 원리는 DNS 전파에 걸리는 시간 글에서 다룹니다.

DNS가 실제로 반환하는 값 확인하기

무엇이든 바꾸기 전에, 수신 측이 한 것과 같은 질문을 DNS에 해 보세요. Linux나 macOS에서는 다음과 같습니다.

dig TXT example.com +short
# a healthy answer includes a line like:
# "v=spf1 include:_spf.example.net ~all"

nslookup -type=TXT example.com

응답이 비어 있거나 사이트 인증 토큰 같은 것만 들어 있다면 "찾을 수 없음"이 확인된 것입니다. 내 리졸버의 캐시를 우회하려면 네임서버에 직접 물어보세요. dig TXT example.com @ns1.example.net +short처럼 NS 조회에서 얻은 네임서버를 사용합니다. 이쪽에서는 레코드가 나오는데 평소 조회에서는 나오지 않는다면 캐시 문제입니다. 둘 다 나오지 않는다면 레코드가 실제 사용 중인 영역에 없는 것입니다.

이 사이트의 SPF 검사기는 입력한 도메인의 TXT 레코드를 조회해 v=spf1로 시작하는 것만 남기고, 하나도 찾지 못하면 "No SPF record"라고 보고합니다. 레코드를 찾으면 include를 따라가며 조회 횟수도 셉니다. TXT 조회는 한 이름의 모든 TXT 값을 보여 주므로, 레코드는 있지만 형식이 잘못된 경우에 원본 텍스트를 볼 수 있어 도움이 됩니다.

실패한 메시지의 헤더 읽기

배달된 메시지의 원본 소스를 열고 수신 서버가 추가한 Authentication-Results 헤더를 찾으세요. SPF 부분에는 결과와, 보통 평가된 도메인이 적혀 있습니다. 헤더의 표현은 수신 측마다 다르므로 예시는 정확한 형식이 아니라 패턴으로 보세요.

spf=none (example.com does not designate permitted sender hosts)
spf=fail smtp.mailfrom=example.com
spf=permerror smtp.mailfrom=example.com

• spf=none: 평가된 도메인에 레코드가 없습니다. 이 글이 해당됩니다.
• spf=fail 또는 softfail: 레코드는 있지만 발신 IP가 허가되지 않았습니다. 발신처를 추가하거나 정책을 고치세요.
• spf=permerror: 레코드가 잘못되었습니다. 레코드가 둘이거나 조회가 너무 많은 경우입니다.

smtp.mailfrom(또는 Return-Path)의 도메인을 확인하세요. SPF가 평가한 것은 From 주소가 아니라 바로 그것입니다. 헤더를 전체적으로 읽는 방법은 이메일의 원래 발신자를 추적하는 방법을 참고하세요.

최소한의 안전한 레코드 게시하기

봉투 발신자에 쓰이는 이름에 TXT 레코드 하나를 게시하세요. 레코드는 왼쪽에서 오른쪽으로 읽는 메커니즘의 목록이며, 마지막에는 그 외 모든 발신처에 대한 기본 처리가 옵니다.

• ip4 / ip6: 주소 또는 대역을 허용합니다. 예: ip4:203.0.113.25. DNS 조회를 소모하지 않습니다.
• include: 다른 도메인의 SPF 레코드가 허용하는 것을 허용합니다. 예: include:_spf.example.net. 조회를 1회 소모합니다.
• a: 도메인 자체의 A(또는 AAAA) 레코드에 있는 IP 주소를 허용합니다. 조회를 1회 소모합니다.
• mx: 도메인의 MX 레코드에 지정된 호스트를 허용합니다. 조회를 1회 소모하며, 수신 호스트가 발송하는 호스트가 아니라면 잘못된 설정입니다.
• ~all, -all, ?all: 기본 처리입니다. ~all은 softfail, -all은 fail, ?all은 neutral입니다.

모든 발신처가 목록에 있는지 확인하는 동안에는 ~all로 시작하고, 확신이 서면 -all을 고려하세요. ?all은 아무 주장도 하지 않으며 대부분 과도기용입니다. 수신 측은 SPF를 DKIM, DMARC와 함께 평가하므로, 끝부분보다 목록이 정확한 것이 더 중요합니다.

주요 플랫폼별 간단 안내

메뉴는 다르고 바뀌기도 하지만, 실패 패턴은 반복됩니다. 설정 유형마다 다음을 확인하세요.

• Microsoft 365와 Google Workspace: 둘 다 관리 콘솔이나 설정 가이드에서 복사할 수 있는 include를 제공합니다. 여기서 "찾을 수 없음"이 뜬다면 보통 레코드가 잘못된 DNS 제공업체나 잘못된 호스트에 들어갔다는 뜻입니다.
• GoDaddy 등 등록 대행사: 네임서버를 CDN이나 호스팅 회사로 바꿨다면 등록 대행사의 DNS 페이지는 더 이상 권한이 없습니다. NS 조회에 나온 제공업체에서 레코드를 수정하세요.
• Cloudflare: 도메인이 Cloudflare 네임서버를 사용한다면 Cloudflare의 DNS 탭에서 TXT 레코드를 추가하세요.

SPF가 없을 때 수신 측이 하는 일

SPF none이 자동 거부는 아닙니다. 표준은 판단을 수신 측의 로컬 정책에 맡기므로 결과는 다양합니다. SPF가 없고 이를 보완할 DKIM이나 DMARC도 없는 메일은 의심스럽게 보일 가능성이 더 높으며, 일부 제공업체는 대량 발신자에 대한 인증 요건을 공개하고 있습니다. 메일을 보내는 대상 제공업체의 최신 규칙을 확인하세요.

SPF는 봉투 발신자를 검사하므로 그것만으로는 눈에 보이는 From 주소를 위조하는 것을 막지 못합니다. 그것은 DMARC의 역할입니다. SPF, DKIM, DMARC 설명과 SPF 레코드 확인 방법을 참고하세요.