Defaults.Exposed › 수정 › Guides
"SPF 레코드를 찾을 수 없음" — 레코드가 있는데도? 5가지 진짜 원인 (2026)
게시일 2026-07-08
데이터 기준: 2026-06-29 · 방법론 v7. 261백만 개 등급 도메인의 집계 센서스 데이터입니다. 등급 방법론 보기.
검사 도구가 “SPF 레코드를 찾을 수 없음”이라고 표시하는데 레코드를 발행했다고 확신한다면, 해당 레코드는 대개 없는 것이 아니라 보이지 않는 상태입니다. 1,013,416개 도메인 — SPF를 시도하는 도메인 중 약 138개 중 하나 — 이 두 개 이상의 SPF 레코드를 발행하고 있으며, 이는 PermError(RFC 7208 §3.2)로서 많은 검사 도구가 not-found로 보고합니다. Defaults.Exposed의 261백만 도메인 센서스에 따른 결과입니다.
진짜 원인은 5가지이며, 한 번의 작업으로 모두 수정할 수 있습니다: 잘못된 호스트, 중복 레코드, 잘못된 DNS 유형이나 왜곡된 따옴표, 일관성 없는 네임서버, 또는 길이/CNAME 충돌입니다. 아래에서 각각에 대한 60초 테스트를 확인 순서대로 설명하고, 수정 단계를 안내합니다.
레코드가 실제로 존재하는지 확실한가요?
가장 흔한 가능성부터 시작하세요. Defaults.Exposed 센서스에서 등급을 받은 261,086,232개 도메인 중 121,145,609개 — 46.4% — 는 SPF 레코드가 전혀 없습니다. “설정했는데”라고 하는 많은 경우가 더 이상 권한이 없는 스테이징 영역이나 이전 DNS 제공업체에 추가된 레코드로 판명됩니다. 네임서버가 실제로 가리키는 DNS 제공업체(종종 도메인 등록 기관이 아님)에서 v=spf1로 시작하는 TXT 레코드를 확인하세요. 레코드가 정말 없다면 탐정 작업을 건너뛰고 바로 SPF 레코드 수정으로 이동하세요.
SPF 레코드를 올바르게 확인하는 방법은 무엇인가요?
웹 검사 도구는 자체 캐싱 리졸버를 통해 DNS를 쿼리합니다. 실제 상태를 확인하려면 도메인의 권한 있는 네임서버에 직접 요청하세요:
# 권한 있는 네임서버 찾기
dig NS yourdomain.com +short
# 해당 네임서버에 직접 TXT 레코드 요청
dig TXT yourdomain.com @ns1.yourdnshost.com +short
Windows의 경우: nslookup -type=TXT yourdomain.com ns1.yourdnshost.com.
해석의 두 가지 규칙: 첫째, v=spf1로 시작하는 줄의 수를 세세요 — 내용만큼 수가 중요합니다. 둘째, 올바른 이름을 쿼리했는지 확인하세요. 수신자는 Return-Path(RFC5321.MailFrom, “봉투 발신자”) — 수신자가 보는 From 주소가 아님 — 의 도메인을 기준으로 SPF를 평가합니다. 뉴스레터 도구가 bounce.yourdomain.com을 통해 메일을 반송한다면, 최상위 도메인의 완벽한 레코드는 수신자가 조회하는 레코드가 아닙니다.
5가지 진짜 원인은 무엇인가요?
| # | 원인 | 60초 테스트 | 수정 방법 |
|---|---|---|---|
| 1 | 잘못된 호스트(서브도메인 대 최상위 도메인)의 레코드 | Return-Path의 정확한 도메인에 dig TXT 실행 | 실제로 발신하는 이름에 발행 |
| 2 | 두 개 이상의 v=spf1 레코드 = PermError | dig TXT가 2개 이상의 v=spf1 줄 반환 | 정확히 하나의 레코드로 병합 |
| 3 | 유형 99로 발행되거나 따옴표 왜곡 | 레코드 유형과 불필요한 따옴표 확인 | 하나의 깔끔한 TXT 레코드로 재발행 |
| 4 | 오래된 캐시 / 일관성 없는 네임서버 | 각 NS에 직접 쿼리하여 답변 비교 | 지연된 네임서버 수정 후 이전 TTL 만료 대기 |
| 5 | 255자 초과 분할 또는 CNAME 충돌 | 깨진 문자열 조각이나 같은 이름의 CNAME 확인 | 제공업체가 문자열을 올바르게 분할하도록 하고 CNAME이 있는 이름에서 레코드 이동 |
데이터 기준: 2026-06-29.
1. 잘못된 호스트에 레코드가 있나요?
가장 흔한 경우: 메일이 yourdomain.com에서 오는 것처럼 보이는데 SPF가 mail.yourdomain.com에 추가된 경우, 또는 그 반대. SPF는 하위 도메인으로 상속되지 않습니다 — 최상위 도메인의 레코드는 서브도메인에 대해 아무것도 말하지 않으며, 반대도 마찬가지입니다. Return-Path의 정확한 이름에 발행하세요. 자체 반송 서브도메인에서 발송하는 공급업체는 해당 서브도메인에 레코드가 필요합니다 — 일반적으로 공급업체가 제공하는 CNAME이나 TXT입니다(GoDaddy SPF 설정 가이드에서 이 필드의 위치를 확인하세요).
2. SPF 레코드가 두 개 있나요?
이메일 인증에서 가장 오해를 불러일으키는 오류 메시지입니다. RFC 7208 §3.2는 명확합니다: 도메인에는 정확히 하나의 SPF 레코드가 있어야 합니다. 두 개 이상은 PermError — 수신자는 SPF를 무효로 취급합니다. 일부 검사 도구는 이 상태를 정확하게 보고하고(“여러 레코드 발견”), 다른 도구는 결과를 보고합니다: 유효한 SPF 레코드 없음. 패널에서 레코드를 보고 검사 도구가 고장났다고 결론 내립니다. 아닙니다 — 레코드가 하나 더 많은 것입니다.
센서스에서 두 개 이상의 SPF 레코드를 가진 1,013,416개 도메인이 발견되었습니다 — SPF를 시도하는 도메인 중 약 138개 중 하나 — 모두 SPF가 사실상 비활성화된 상태입니다. 이는 대개 제공업체 변경 중에 발생합니다: 새 제공업체의 마법사가 이전 레코드를 편집하는 대신 새 레코드를 추가합니다. 수정 방법은 두 번째 레코드를 추가하는 것이 아니라 병합입니다: 모든 내용을 단일 v=spf1 … ~all 줄에 합치고 나머지를 삭제하세요. 데이터 보고서 두 SPF 레코드는 없는 것과 같다에서 백만 개 도메인이 어떻게 이 상황에 이르렀는지 설명합니다. 마이그레이션 후에 시작된 경우 제공업체 전환 후 SPF가 작동하지 않을 때를 참조하세요. 병합할 때 모든 include:를 무작정 연결하지 마세요 — 각각은 SPF의 하드 제한인 10개에 대해 DNS 조회 비용을 사용하여 not-found를 PermError: DNS 조회 초과로 바꿉니다.
3. 잘못된 레코드 유형을 발행했거나 UI가 왜곡시켰나요?
초기 SPF에는 자체 DNS 레코드 유형(유형 99, 문자 그대로 “SPF”라고 명명)이 있었습니다. 이는 더 이상 사용되지 않습니다: RFC 7208은 TXT를 요구하며, 수신자는 유형 99를 쿼리하지 않습니다. 일부 DNS 패널은 여전히 레코드 유형 드롭다운에 “SPF”를 제공합니다. 선택하면 레코드는 실제이고 올바르게 형성되었지만 보이지 않습니다. 유형 열을 확인하고 TXT로 재발행하세요.
더 교묘한 문제는 따옴표입니다. 이미 따옴표로 묶인 값을 자체 따옴표를 추가하는 필드에 붙여넣으면 ""v=spf1 …"" 가 생성됩니다 — 더 이상 v=spf1로 시작하지 않으므로 검증자에게는 존재하지 않는 것과 같습니다. dig 출력이 실제 상태를 보여줍니다; DNS 패널은 종종 표면적으로 숨깁니다.
4. 정말 “아직 전파 중”인가요?
“전파에 24~48시간이 걸립니다”는 DNS에서 가장 과도하게 처방되는 조언입니다. 전파는 단지 캐시 만료입니다: 레코드의 TTL이 경과하면(일반적으로 1시간, 드물게 24시간 이상), 모든 리졸버가 새 답변을 볼 수 있습니다. 24시간 후에도 찾을 수 없다면 전파가 원인이 아닙니다.
실제 두 가지 원인: 부정적 캐싱 — 레코드를 추가하기 전에 조회한 리졸버가 부정적 TTL이 만료될 때까지 “해당 레코드 없음” 답변을 캐싱 — 그리고 마이그레이션 후 일관성 없는 네임서버, 도메인이 여전히 이전 제공업체의 네임서버를 새 것과 함께 나열하고 세계의 절반이 더 이상 편집하지 않는 영역을 읽는 경우입니다. 나열된 각 네임서버에 직접 쿼리하세요. 답변이 다르면 원인을 찾은 것입니다. 등록 기관의 NS 위임을 수정하여 실제로 편집하는 제공업체만 권한이 있도록 하세요.
5. 레코드가 너무 길거나 CNAME에 의해 차단되어 있나요?
TXT 레코드의 단일 문자열은 최대 255자입니다. 더 긴 SPF 레코드는 합법적이지만 하나의 레코드 내에서 여러 개의 인용된 문자열로 분할해야 합니다 — DNS 제공업체 인터페이스는 값을 잘라내거나 파싱이 불가능하게 중간에서 끊어 버리는 경우가 많습니다. 레코드가 길면 dig 출력에서 갑자기 끝나는 값을 확인하세요.
별도로, DNS는 이미 CNAME이 있는 이름에 TXT 레코드를 금지합니다. mail.yourdomain.com이 제공업체의 CNAME이라면, 거기에 SPF를 넣을 수 없습니다 — 일부 패널은 이를 수락하고 CNAME만 제공합니다. CNAME이 가리키는 곳에 레코드를 넣거나(제어할 수 있는 경우), 발신 이름이 CNAME되지 않도록 재구성하세요. 깔끔한 TXT 처리를 가진 제공업체는 두 가지를 모두 더 쉽게 만듭니다 — Cloudflare SPF 설정 가이드를 참조하세요.
단계별로 어떻게 수정하나요?
- defaults.exposed에서 무료 스캔을 실행하세요 — 라이브 DNS를 읽고 아무것도 건드리기 전에 5가지 상태 중 어디에 있는지 알려줍니다.
- 권한 있는 네임서버(
dig NS)를 확인하고 모두 동의하는지 확인하세요. - 정확한 Return-Path 도메인에 대해 권한 있는 네임서버에서 TXT를 쿼리하세요.
v=spf1줄 수를 세세요: 0이면 하나 발행, 두 개 이상이면 하나로 병합하세요.- 유형이 TXT이고 값이 정확히
v=spf1으로 시작하며 불필요한 따옴표나 잘림이 없는지 확인하세요. - TTL 하나가 만료되도록 기다린 후 재스캔하여 전 세계에서 올바르게 확인되는지 확인하세요.
자주 묻는 질문
DNS 패널에서 레코드를 볼 수 있는데 검사 도구가 “찾을 수 없음”이라고 하는 이유는 무엇인가요?
대개 원인 2 또는 4입니다: 두 번째 v=spf1 레코드가 두 레코드를 모두 무효화합니다 — 2026-06-29 기준으로 1,013,416개 도메인이 이 상태에 있는 PermError로서 일부 도구는 not-found로 보고합니다 — 또는 패널이 실제로 권한 있는 DNS가 아닙니다.
수정 후 검사 도구가 언제 변경 사항을 볼 수 있나요? TTL 하나 — 일반적으로 한 시간, 최대 24시간. 그 이후에는 “전파”가 설명이 아닙니다. 5가지 원인을 다시 확인하고 네임서버 일관성부터 시작하세요.
DNS 패널이 제공하는 “SPF” 레코드 유형을 사용해야 하나요? 아니요. 유형 99는 더 이상 사용되지 않으며 RFC 7208은 TXT만 요구합니다. 유형 99 레코드는 최신 수신자에게 보이지 않습니다.
레코드가 이제 찾아지는데 메일이 여전히 SPF에 실패하는 이유는 무엇인가요? SPF는 From 헤더가 아닌 Return-Path 도메인을 기준으로 확인하며, 레코드가 실제로 발신 서버를 나열해야 합니다. 찾아지는 것은 첫 번째 단계입니다. SPF 레코드 수정 가이드에서 통과하는 방법을 설명합니다.
SPF 레코드가 없는 것이 정말 그렇게 흔한 일인가요? 네 — Defaults.Exposed 센서스에서 등급을 받은 261,086,232개 도메인(2026-06-29 기준)의 46.4%인 121,145,609개 도메인이 SPF를 전혀 발행하지 않습니다. 찾을 수 없음이 인터넷의 기본 상태입니다.
소유자에게 보고서 보내기
레코드가 올바르게 확인되면 스캔을 다시 실행하고 등급이 매겨진 보고서를 도메인 소유자 또는 클라이언트에게 전달하세요. 무엇이 잘못되었는지, 무엇을 수정했는지, 도메인이 현재 어떤 상태인지를 평문으로 보여줍니다 — 사이버 보험 갱신 및 공급업체 보안 설문지에서 요청받을 정확한 증거입니다. 보고서가 작업의 영수증입니다.
SPF 레코드 무료 확인
도메인이 5가지 not-found 상태 중 어디에 있는지 확인하세요 — 비공개로, 소유자만.
도메인 확인 → · SPF 수정 → · 제공업체 전환 후 SPF 중단 → · 등급 방법론 → · 집계 데이터만. 데이터는 EU에서 저장 및 처리됩니다.