Defaults.Exposed › 보고서
SPF PermError 보고서: 표면 집계가 보여주는 것보다 100배 더 많은 도메인이 10-룩업 한도를 초과한다 (2026)
게시일 2026-07-03
2026-06-29 기준 수치 · 방법론 v7, 여기에 2026-07-03에 실행한 체인 가격 산정(chain-pricing) 패스를 추가함. 261백만 개의 등급 매겨진 도메인 인구조사에서, 우리는 100회 이상 참조된 모든 SPF
include:대상을 해석(resolve)했으며 — 전체 include 참조의 95.2%를 포괄하는 10,842개의 대상 — 그 맵을 기준으로 각 도메인이 보유한 체인의 비용을 산정했다. 해석되지 않은 꼬리 대상은 0으로 계산했고 체인 내용은 해석 당일 기준을 반영하므로, 이 헤드라인 수치는 보수적이고 하한(floor)에 치우친 근사치다: 그래서 우리는 “최소”라고 말한다. 오직 집계일 뿐, 결코 개별 기업의 레코드가 아니다. 우리가 등급을 매기는 방법을 참고하라.
얼마나 많은 도메인이 SPF 10-룩업 한도를 초과하는가?
최소 797,263개 — SPF에는 표준 자체에 자기 파괴 장치가 내장되어 있고, 그 방아쇠는 소유자가 볼 수 없는 곳에 숨어 있기 때문이다. RFC 7208 §4.6.4는 SPF 검사를 DNS 룩업 10회로 제한한다; 열 번을 넘으면 수신자는 처리를 멈추고 PermError를 반환하며, PermError 상태의 레코드는 아무것도 보호하지 못한다. 대부분의 도구가 그러하듯이 — 그리고 이 보고서 전까지 우리 인구조사 자체도 그러했듯이 — 레코드 자체에 보이는 룩업만 세면, 위반 도메인은 약 8,000개(7,958개, 정확히)로 나온다. 그 레코드들이 실제로 끌어오는 include: 체인의 비용을 산정하면, 그 수는 797,263개에 이른다: 대략 100배 더 많은 규모다.
소유자는 왜 이것이 다가오는 것을 볼 수 없는가?
예산이 다른 사람들의 레코드에 의해 소모되기 때문이다. include:onetool.example.com은 당신의 DNS 패널에서 한 줄로 보인다 — 하지만 수신자는 그 레코드까지 가져와야 하고, 그것이 담고 있는 모든 룩업 메커니즘을 재귀적으로 세야 한다. include가 세 개인 레코드가 열한 번의 비용이 들 수 있다. 당신이 한도를 넘긴 날, 당신 자신의 존(zone)에서는 아무것도 바뀌지 않았다; 어느 공급자가 include를 하나 더 중첩시켰고, 당신의 SPF는 아무런 경고 없이 죽었다.
더 나쁜 것은, DMARC가 PermError를 SPF 레그의 실패로 취급한다는 점이다 — 그래서 이런 식으로 SPF가 파손된 도메인은 이제 자기 자신의 인증 절반에서 실패하고 있는 셈이다.
체인 가격 산정이 발견한 것
| 발견 항목 | 도메인 수 |
|---|---|
| 10-룩업 한도 초과, 체인 가격 산정됨 | 797,263 |
| 보이는 메커니즘만 세었을 때 한도 초과 | 7,958 |
엄격한 -all로 끝나면서도 한도 초과 | 112,215 |
| 정확히 9~10 룩업 — 벼랑 끝 | 2,119,539 |
그 표에는 두 가지 이야기가 있다 — 세 번째, 즉 벼랑 끝은 아래에서 별도의 섹션으로 다룬다:
- 표면 집계는 파손의 약 99%를 놓친다. 보이는 메커니즘 집계는 7,958개를 찾아내지만; 체인 가격을 산정하면 797,263개가 나온다. 피해의 거의 전부는 include가 담고 있는 것으로부터 상속된다.
- 파손된 레코드 중 112,215개가
-all로 끝난다. 그 소유자들은 모든 것을 제대로 했다 — 벽을 올랐고, 엄격한 끝맺음을 선택했다 — 그런데 include 하나가 너무 많아서 전부가 무효가 되었다. 엄격해 보이는데 파손된 상태는 이메일 보안에서 가장 가혹한 실패 유형이다.
2.1백만 개 도메인이 도구 하나 차이로 벼랑 끝에 있다
현재는 멀쩡한 독자들을 걱정하게 만들어야 할 수치: 2,119,539개 도메인이 정확히 9 또는 10 룩업으로 해석된다 — 오늘은 한도 아래지만, 누군가 플랫폼 하나를 더 연결하는 날 죽는다. 이는 전체 SPF 발행자의 약 66분의 1에 해당하며, 분포의 형태와도 일치한다: 99번째 백분위수 SPF 레코드는 이미 9 룩업에 자리하고 있다. 마케팅 도구 하나를 더 신청하고, 그 “이 include만 추가하세요” 문구를 붙여 넣으면, 아침 식사 때 한도 아래였던 레코드가 점심때는 무효가 된다.
누구 잘못인가? 점점 더, 스택의 잘못이다
가장 큰 공급자들은 조용히 자신들의 SPF를 *평탄화(flatten)*했다 — 구글의 _spf.google.com과 마이크로소프트의 spf.protection.outlook.com은 이제 내부 룩업 비용이 0인 평범한 IP 목록으로 확장된다(우리는 이 분석 중 둘 다 라이브 DNS로 검증했다). 파열은 다른 곳에서 온다: 세 단계로 중첩되는 호스팅 패널 체인, include 하나만으로 7~10 룩업 비용이 드는 지역 공급자, 그리고 SaaS의 정직한 누적 — 메일박스 더하기 뉴스레터 더하기 CRM 더하기 헬프데스크, 각각 “그냥 include 하나”. 열한 번째 룩업을 일부러 추가하는 사람은 거의 없다. 그것은 합리적인 결정들의 총합으로 도래한다.
당신의 것을 확인하고 고치는 방법 — 무료
- 당신의 실제 총합을 세라 — 우리의 무료 검사가 당신의 체인을 해석해 주거나, 아무 SPF 룩업 카운터를 사용하라.
- 죽은 무게를 쳐내라: 더 이상 쓰지 않는 도구, 중복 include, 그리고 폐기된
ptr메커니즘. - 당신이 통제하는 것만 평탄화하라. 깊은 include를 그 IP 블록으로 대체하는 것은 당신 자신의 인프라에는 효과가 있다; 제3자의 IP는 예고 없이 바뀐다.
- 대량 발송자에게 서브도메인을 주라.
news.yourdomain.com에서 오는 뉴스레터는 자기만의 레코드와 자기만의 10-룩업 예산을 갖는다.
자주 묻는 질문
SPF 10 DNS 룩업 한도란 무엇인가?
RFC 7208 §4.6.4는 하나의 SPF 레코드를 평가하는 데 최대 10회의 DNS 룩업을 허용한다 — 모든 include: 안의 룩업을 재귀적으로 세는 것을 포함해서. 이를 초과하면 PermError를 반환한다: 레코드는 유효하지 않은 것으로 취급되며 아무런 보호도 제공하지 않는다.
SPF PermError는 무슨 뜻인가? 영구적 평가 오류다 — 수신자가 당신의 레코드를 처리할 수 없어서(룩업이 너무 많거나, 레코드가 여러 개거나, 구문이 깨졌거나) 당신의 도메인을 쓸 수 있는 SPF가 없는 것으로 취급한다. DMARC는 이를 SPF 레그의 실패로 계산한다.
얼마나 많은 도메인이 SPF 룩업 한도를 초과하는가? 우리의 체인 가격 산정 패스에 따르면, 139백만 SPF 발행자 중 최소 797,263개다 — 체인을 해석하지 않고 보이는 7,958개의 약 100배다. 여기에 더해 2,119,539개가 9~10 룩업에 자리하고 있어, include 하나면 한도를 넘는다.
PermError가 내 이메일 전달을 멈추는가? 보통은 아니다 — 수신자는 SPF 없이 진행하며, 당신의 메일은 DKIM과 평판에 실려 간다. 멈추는 것은 보호다: 위조자가 더 이상 거부되지 않고, 당신 메일에 대한 모든 DMARC 검사가 SPF 레그를 잃는다. 값비싸질 때까지는 보이지 않는다.
내 SPF 룩업 횟수를 어떻게 줄이는가?
사용하지 않는 include와 ptr을 제거하고, 당신 자신의 인프라를 ip4:/ip6:로 평탄화하고, 대량 발송자를 서브도메인으로 옮기고, 새 도구를 추가할 때마다 다시 세라. 수정 가이드가 그 과정을 안내한다.
당신의 실제 숫자를 알아보라
당신이 볼 수 있는 메커니즘은 당신의 룩업 횟수가 아니다 — 해석된 숫자가 수신자가 계산하는 것이며, 그것은 30초짜리 검사다.
당신의 도메인을 확인하라 → · SPF 수정하기 → · SPF 성숙도 모델 → · SPF 레코드 2개 = 0개 → · ptr 함정 → · 오직 집계 데이터만. 데이터는 EU에서 저장 및 처리됨.