Defaults.Exposed › 수정 › Guides

SPF PermError: 이메일을 깨뜨리지 않고 "DNS 조회 너무 많음" 수정 방법 (2026)

게시일 2026-07-08

2026-06-29 기준 수치 · 방법론 v7. 261백만 개의 평가된 도메인에 대한 집계 데이터. 평가 방식 보기.

Defaults.Exposed의 261,086,232개 도메인 센서스에 따르면 139백만 개의 SPF 게시자 중 최소 797,263개 도메인이 SPF의 10회 DNS 조회 제한을 초과합니다. 10회를 초과하면 수신자가 멈추고 PermError를 반환합니다: SPF가 무효이며, DMARC는 PermError를 실패로 집계합니다.

수정에는 엄격한 순서가 있으며, 대부분의 가이드가 이를 거꾸로 알려줍니다. 실제 해석된 조회를 계산하고; 오래된 미사용 include를 삭제하세요 — 그것만으로 대부분의 레코드가 수정됩니다; 대용량 발신자를 자체 SPF 예산이 있는 하위 도메인으로 이동하세요; 마지막 수단으로만, 그것도 자동화된 재플래트닝으로만 플래트닝하세요. 수동 플래트닝은 낡아서 조용히 배달을 깨뜨립니다.

”SPF PermError: too many DNS lookups”는 무슨 의미인가요?

RFC 7208 §4.6.4는 모든 SPF 확인을 10회 DNS 조회로 제한합니다. 10회를 초과하면 수신자가 멈추고 PermError를 반환합니다 — 예산을 초과한 부분만이 아닌 전체 레코드가 깨진 것으로 처리됩니다. 같은 섹션에서 덜 알려진 두 번째 제한도 추가합니다: 최대 2회의 “void 조회”(응답 없거나 NXDOMAIN을 반환하는 쿼리), 따라서 취소된 서비스에 대한 죽은 include: 항목 두 개로도 SPF가 무효화될 수 있습니다.

결과는 “SPF 없음”보다 더 나쁩니다: DMARC는 PermError를 SPF 실패로 처리하므로, 자체 SPF를 깨뜨리는 도메인은 모든 DMARC 평가의 SPF 레그에서 인증되지 않습니다. DKIM이 설정되지 않거나 전송 중 깨지면 그 메일은 이제 DMARC에 완전히 실패합니다.

하나의 센서스 숫자가 이 실패 모드가 얼마나 잔인한지 보여줍니다: 112,215개 도메인이 조회 초과로 무효인 엄격한 -all 레코드를 게시합니다 — -all을 게시하는 54,655,923개 도메인 중. 소유자들이 어려운 부분을 했습니다 — 엄격한 끝부분을 선택 — 그리고 include 하나가 너무 많아 전체 레코드가 꺼졌습니다. 엄격해 보이지만 깨져 있습니다. 전체 데이터 그림은 SPF PermError 보고서를 참조하세요.

아무것도 변경하지 않았는데 SPF가 왜 깨졌나요?

예산의 대부분이 다른 사람의 레코드에 의해 소비되기 때문입니다. 모든 include:는 재귀적으로 평가되며, 그 안의 모든 조회 메커니즘은 10회 중에 집계됩니다. DNS 패널의 한 줄이 해석하면 4~5회 조회가 될 수 있습니다. 공급자가 한 개 더 include를 중첩하면 여러분의 영역에서 단 하나의 변경 없이 SPF가 죽습니다.

대형 플랫폼은 문제가 아닙니다: Google과 Microsoft 모두 자체 SPF를 플래트닝했습니다 — _spf.google.com과 spf.protection.outlook.com은 내부 조회 0회가 드는 일반 IP 목록으로 확장됩니다(2026년 7월 실제 DNS 기준 확인). 실제 폭발은 여러 레이어 깊이 중첩된 호스팅 패널 include 체인과 정직한 SaaS 쌓기에서 옵니다 — 사서함 plus 뉴스레터 plus CRM plus 헬프데스크, 각각 “include 하나만”. 아무도 의도적으로 열한 번째 조회를 추가하지 않습니다; 합리적인 결정들의 합으로 도착합니다. 그것이 절벽 가장자리가 붐비는 이유입니다: 2,119,539개 도메인이 정확히 9~10회 해석된 조회에 앉아 있습니다 — 모든 SPF 게시자의 약 66개 중 1개로, 오늘은 괜찮고, 누군가 include 하나를 더 붙여넣는 날에 무효가 됩니다. 99번째 백분위수 SPF 레코드는 이미 9회 조회로 해석됩니다. SaaS가 많은 스택이라면 SaaS 도구의 SPF 실패 가이드에서 벤더별 버전을 다룹니다.

SPF 레코드의 어떤 부분이 DNS 조회로 계산되나요?

보이는 줄이 아닌 해석된 총계를 계산하세요. 네 개의 include가 4회 또는 14회 조회가 될 수 있습니다.

이메일을 깨뜨리지 않고 “too many DNS lookups”를 어떻게 수정하나요?

1. DNS를 건드리기 전에 무료 스캔을 실행하세요. 전체 include 체인을 해석하고 실제 조회 수를 보여줍니다. 패널에 나타나는 레코드가 아닌 실제 문제를 수정하도록 합니다. (SPF가 전혀 없다고 하면 다른 오류입니다 — “SPF 레코드를 찾을 수 없음”을 참조하세요.)
2. 오래된 미사용 include를 먼저 삭제하세요. 2023년에 그만둔 도구, 마이그레이션에서 살아남은 이전 호스트의 include, 중복, ptr 메커니즘. 죽은 include는 이중으로 독성입니다: 조회 예산을 소비하고 void 조회의 일반적인 원인입니다. 대부분의 초과 레코드는 이 단계만으로 10회 이하로 돌아옵니다. 이전 공급자의 메커니즘이 여전히 있다면 마이그레이션 정리 가이드를 따르세요.
3. 남은 include가 실제로 작동하는지 확인하세요. 수신자는 SPF를 From 헤더가 아닌 Return-Path(RFC5321.MailFrom) 도메인에 대해 평가합니다 — 많은 SaaS 도구가 Return-Path에 자체 반송 도메인을 넣으므로, 레코드의 include가 예산만 소비하고 아무것도 안 합니다. Return-Path로 도메인을 사용하는 서비스에만 include를 유지하세요; 나머지는 대신 벤더의 사용자 정의 도메인 DKIM을 활성화하세요.
4. 대용량 발신자를 하위 도메인으로 이동하세요. news.yourdomain.com에서 뉴스레터, mail.yourdomain.com에서 트랜잭션 메일. 각 하위 도메인은 새 10회 조회 예산이 있는 자체 SPF 레코드를 얻으며, 한 스트림의 문제가 다른 스트림으로 번지지 않습니다.
5. 그런 다음에만 플래트닝을 고려하세요 — 그것도 자동화된 플래트닝만. 아래를 참조하세요.
6. 재스캔으로 확인하세요 편안하게 10회 이하인지 — 정확히 10을 목표로 하지 말고 여유를 목표로 하세요. 아니면 절벽 가장자리의 2.1백만 개 도메인에 다시 합류한 것입니다. 그런 다음 SPF 수정 페이지에서 스캔이 표시한 다른 항목을 처리하세요.

SPF 레코드를 플래트닝해야 하나요?

플래트닝은 include를 기본 ip4:/ip6: 블록으로 교체하여 조회 비용을 0으로 만듭니다. 작동합니다 — 그리고 수동으로 하면 지연된 배달 중단입니다.

공급자는 발송 IP를 정기적으로 교체하고 아무에게도 알리지 않습니다. 정적 IP 목록은 붙여넣는 날에는 올바르고 몇 달 안에 조용히 잘못됩니다 — 그리고 다른 사람들이 메일을 받지 못한다는 것으로 실패가 나타나기 때문에 늦게 알게 됩니다. 정리와 하위 도메인으로 제한 이하로 줄어들면 거기서 멈추세요; 절대 제3자의 IP 블록을 영구 수정으로 레코드에 수동으로 복사하지 마세요.

자주 묻는 질문

SPF PermError는 이메일 배달이 중단된다는 의미인가요? 즉시는 아닙니다 — 그것이 위험한 이유입니다. DMARC는 PermError를 SPF 실패로 집계하므로 배달이 전적으로 DKIM에 의존합니다; DKIM이 없거나 전송 중 깨지면 DMARC에 실패합니다. 센서스(2026-06-29 기준)의 139백만 개 SPF 게시자 중 최소 797,263개가 이 상태입니다 — 대부분 알지 못한 채로.

레코드에 include가 4개뿐인데 어떻게 10회를 초과할 수 있나요? include는 재귀적으로 계산됩니다: 각 include 안의 모든 것(그리고 그 include 안의 것들)이 예산에 청구되므로, 보이는 줄 4개가 14회 조회로 해석될 수 있습니다. 눈으로 세지 말고 해석 도구로 계산하세요 — 체인을 해석하는 것이 표면 계산보다 PermError 보고서가 ~100배 더 많은 깨진 도메인을 발견한 방법입니다.

레코드가 -all로 끝납니다 — 보호받고 있지 않나요? 레코드가 평가되어야만 합니다. 센서스(2026-06-29 기준)에서 조회 초과로 인해 엄격한 -all 레코드가 무효인 112,215개 도메인을 발견했습니다. PermError 레코드의 엄격한 한정자는 아무것도 보호하지 않습니다.

제한은 include당 10회인가요, 전체 레코드당 10회인가요? 전체 평가: RFC 7208 §4.6.4는 완전한 확인을 10회로, 추가로 최대 2회의 void 조회로 제한합니다. 각 하위 도메인에는 자체 레코드와 예산이 있습니다 — 4단계가 작동하는 이유입니다.

ip4와 ip6 항목이 제한에 계산되나요? 아닙니다 — IP 메커니즘은 비용이 없으며, 그것이 바로 플래트닝이 계산을 줄이는 이유입니다.

소유자에게 보고서 전달

클라이언트나 고용주를 위해 수정하는 경우 증거로 작업을 마무리하세요. 변경 후 무료 스캔을 다시 실행하고 등급 보고서를 비즈니스 소유자에게 전달하세요: 알기 쉬운 언어, 날짜 기록, PermError 사라짐. 사이버 보험 갱신과 다음 고객 보안 설문지를 위한 증거물입니다 — “DNS 레코드를 변경했습니다”와 문서화된 전후 기록의 차이.

도메인 무료 확인

실제 해석된 조회 수 — 그리고 SPF, DKIM, DMARC의 모든 것 — 을 비공개로, 소유자만 확인하세요.

도메인 확인하기 → · SPF 수정 → · SaaS 도구의 SPF 실패 → · GoDaddy에서 SPF 설정 → · 평가 방식 → · 집계 데이터만 사용합니다. 데이터는 EU에서 저장 및 처리됩니다.