Defaults.Exposed › 보고서

SPF가 실패하는 이유는? 영국·EU 발신자를 위한 SaaS 10-조회 문제 (2026)

게시일 2026-07-09

2026-06-29 기준 데이터 · 방법론 v7. 261백만 개의 등급이 매겨진 도메인을 대상으로 한 집계 센서스 데이터입니다. 평가 방법을 확인하세요.

영국 또는 EU에서 SaaS 도구를 사용하는 기업에서 SPF가 실패할 때, 가장 가능성이 높은 원인은 지금껏 생각해 본 적 없는 RFC의 단 하나의 규칙입니다: DNS 조회가 10회를 초과하면, SPF는 “fail”을 반환하는 것이 아니라 PermError를 반환합니다. 이는 레코드가 존재하지 않는 것으로 처리된다는 의미입니다. 이미 797,263개 이상의 도메인이 그 선을 넘었습니다. 또한 2,119,539개의 도메인이 정확히 9~10회 조회 위치에 있어, 도구 하나만 추가하면 동일한 절벽에서 떨어질 상황입니다.

SaaS 도구를 추가하면 왜 SPF가 중단되나요?

SPF는 도메인을 대신해 메일을 발송할 권한이 있는 메일 서버를 나열하는 방식으로 작동합니다. 현대 기업들은 자체 메일 서버를 운영하지 않습니다 — 내부 이메일에는 Google Workspace, 캠페인에는 Mailchimp, 영업 시퀀스에는 HubSpot, CRM 아웃리치에는 Pipedrive를 사용합니다. 각 플랫폼은 DNS에 붙여넣을 include: 행을 제공합니다.

문제는 모든 include:가 그 자체로 DNS 조회라는 점입니다. 그리고 해당 include 내부의 모든 레코드가 재귀적으로 추가 조회를 유발할 수 있습니다. RFC 7208 §4.6.4는 10회라는 엄격한 상한을 설정합니다. 10회를 초과하면 수신 메일 서버는 평가를 중단하고 PermError를 반환합니다 — PermError는 스팸함으로 가는 소프트 실패가 아닙니다. SPF 레코드가 없는 것으로 처리된다는 의미입니다. 이메일 인증이 SPF 단계에서 실패합니다.

DNS 패널에서는 이를 확인할 수 없습니다. 카운터는 실시간 평가 중에만 작동합니다. 가시적인 레코드에 include: 행이 세 개만 있어도, 각 공급업체의 SPF 레코드가 자체 서브-include를 끌어들이기 때문에 실제로는 12개의 조회 깊이에 있을 수 있습니다.

이미 한도를 초과한 도메인은 얼마나 되나요?

797,263개 이상입니다. 이 수치는 100회 이상 참조된 모든 SPF include: 대상(10,842개의 개별 대상, 전체 include 참조의 95.2% 커버)을 해석하고 각 도메인의 전체 체인을 평가한 결과입니다. 표면적 수치(레코드의 가시적 행만 계산한 경우)는 약 7,958개를 찾습니다. 체인 평가 수치는 100배 더 크며, 이는 거의 모든 피해가 include 대상 내부에 보이지 않게 숨어 있기 때문입니다.

유럽 기업에 가장 많은 영향을 미칠 가능성이 높은 상황:

유럽 호스팅 제공업체와 취약한 SPF 기본값

처음 선택한 호스팅 제공업체가 중요합니다 — 일부는 단일 SaaS 도구도 연결하기 전에 이미 10회 조회 중 일부를 소비하는 SPF 기본값을 설정하기 때문입니다.

센서스의 유럽 도메인에서 사용하는 주요 호스팅 제공업체 중:

IONOS가 두드러집니다: IONOS 호스팅 도메인의 1.0%만이 DMARC를 적용하고 있어, 압도적 다수가 실질적인 발신자 인증이 전혀 없습니다. OVH 도메인은 SPF 엄격 설정(43.7%)에서는 더 나은 성과를 보이지만, DMARC 적용에서는 2.2%로 떨어집니다 — DMARC 없이 SPF만으로는 수신자가 보는 From: 헤더가 아닌 봉투만 보호합니다.

Microsoft 365는 좋은 의미에서 예외입니다: Microsoft 호스팅 도메인의 85.0%가 엄격한 SPF를 사용하며, 이는 주로 Microsoft의 메일 흐름 마법사가 기본적으로 -all을 설정하기 때문입니다. Google Workspace는 기본적으로 ~all(softfail)을 설정하여, 해당 도메인의 92%가 엄격한 보호 없이 남아 있습니다.

60초 이내에 SPF 실패를 진단하는 방법

가장 빠른 확인 방법은 가시적인 레코드만이 아닌 전체 조회 체인을 평가하는 무료 도구를 사용하는 것입니다. 명령줄에서 nslookup -type=TXT yourdomain.com을 실행하고 보이는 모든 include:를 세어 보세요. 그런 다음 각 레코드를 조회하여 그 레코드의 수를 세어 보세요. include가 끝나기 전에 손가락이 부족해진다면 위험 지대에 있는 것입니다.

더 신뢰할 수 있는 방법: 여기서 도메인을 확인하세요 — 스캐너가 완전히 해석된 체인을 평가하고 PermError에 플래그를 표시하며 어떤 메커니즘이 조회 예산을 사용하고 있는지 보여줍니다.

세 가지 진단 결과:

• PermError — 이미 10회를 초과했습니다. 발송하는 모든 이메일이 수신자의 SPF 검사에서 실패합니다.
• 9~10회 조회 — 절벽 끝에 있습니다. 다음 SaaS 통합 하나로 넘어집니다.
• hardfail (-all) 대신 Softfail (~all) — 한도 이하이지만 레코드 설정이 너무 허용적이어서 실질적인 보호를 제공하지 못합니다. -all 대 ~all에 대한 전체 그림은 SPF 잘못된 구성 보고서를 참조하세요.

여러 SaaS 도구를 사용할 때 SPF 수정 방법

영속성 순으로 세 가지 접근법이 있습니다:

1. 감사 및 정리. 현재 레코드의 모든 include:를 나열하는 것부터 시작하세요. 더 이상 사용하지 않는 플랫폼을 제거하세요 — 오래된 ESP, 이전 계약의 CRM 도구, 테스트하다 포기한 플랫폼. 이는 무료이며 종종 여러 조회를 회수할 수 있습니다. 제거된 각 include:는 1~3개의 서브-조회를 제거할 수 있습니다.

2. SPF 레코드 플래트닝. SPF 플래트닝은 모든 include: 대상을 기반 IP 범위로 해석하고 ip4: 및 ip6: 메커니즘으로 레코드에 직접 작성합니다. IP 메커니즘은 조회를 유발하지 않으므로, 플래트닝된 레코드는 수십 개의 발송 소스를 나열하면서도 조회 수를 0으로 유지할 수 있습니다. 단점: 공급업체가 발송 IP를 업데이트할 때마다 재-플래트닝이 필요하며, 이는 예고 없이 발생합니다. 대부분의 기업은 유료 SPF 플래트닝 서비스(PowerDMARC, EasyDMARC, Dmarcian 등이 제공)를 사용하거나 모니터링 워크플로우를 구축합니다.

3. SPF 매크로 사용. RFC 7208 매크로를 사용하면 include 체인 대신 검사마다 단일 DNS 조회를 수행하고 동적으로 응답하는 레코드를 구축할 수 있습니다. 매크로는 DNS 호스팅 지원과 구현 노력이 필요하지만, 많은 SaaS 발신자를 보유한 조직에 대한 아키텍처적으로 깔끔한 솔루션입니다.

SPF를 수정한 후에는 DMARC 적용과 함께 사용하세요 — DMARC 없는 SPF는 수신자가 보는 헤더 From: 주소가 아닌 봉투 발신자만 인증합니다.

자주 묻는 질문

SPF 레코드가 DNS 도구를 통과하는데 왜 이메일 헤더에서는 실패하나요? 대부분의 DNS 조회 도구는 자체 레코드에서 볼 수 있는 메커니즘만 계산하며, 해당 메커니즘이 유발하는 서브-조회는 계산하지 않습니다. include: 행이 두 개만 있어도 각 공급업체의 레코드에 몇 개가 더 포함되어 있으면 한도를 초과할 수 있습니다. 체인 평가 도구(또는 수신 메일 서버)만이 전체 깊이를 계산합니다. 실제 체인 수를 확인하려면 도메인을 확인하세요.

SPF가 실패하면 이메일이 스팸함으로 가나요? PermError(조회 횟수 초과)는 인증의 SPF 단계가 결과 없음을 반환한다는 의미입니다 — 사실상 부재입니다. DMARC는 SPF와 DKIM 모두를 평가합니다; DKIM이 통과하면 SPF PermError에도 불구하고 DMARC가 통과할 수 있습니다. 둘 다 통과하지 못하면 DMARC가 실패하며, 결과는 DMARC 정책에 따라 달라집니다. p=none에서는 이메일이 여전히 배달되지만 실패가 기록됩니다. p=quarantine 또는 p=reject에서는 이메일이 필터링되거나 반송됩니다. DKIM에만 의존하지 않도록 SPF를 수정하세요.

일반적인 SaaS 스택은 몇 번의 조회를 사용하나요? 센서스의 p99 SPF 레코드는 이미 9회 조회에 있습니다 — 아무것도 추가하기 전부터 한도에 가까이 있습니다. Google Workspace 레코드는 34회 조회를 추가하고, Mailchimp는 12회, HubSpot은 현재 구성에 따라 1~3회를 추가합니다. 주류 도구 세 개와 호스팅 제공업체의 기본값만으로도 10회를 초과하기에 충분한 경우가 많습니다.

SPF 플래트닝은 안전한가요? 최신 상태를 유지하면 안전합니다. 플래트닝은 include: 체인을 정적 IP 범위로 변환합니다 — 공급업체가 발송 IP를 교체하고 재-플래트닝하지 않으면 해당 공급업체의 메일을 거부하기 시작합니다. 대부분의 조직은 수동으로 관리하는 대신 IP 변경을 모니터링하는 관리형 플래트닝 서비스를 사용합니다.

SPF가 몇 년째 이 상태인데 왜 갑자기 실패하나요? 공급업체가 자신의 SPF 레코드를 업데이트했기 때문입니다 — 귀하의 것이 아닙니다. SaaS 플랫폼이 새로운 발송 IP 범위를 추가하거나 다른 include를 중첩할 때마다, 귀하 측의 변경 없이 체인 비용이 상승합니다. 10-조회 한도는 메시지 수신 시 실시간으로 평가되므로, 화요일 아침의 공급업체 변경이 화요일 오후에 SPF를 망가뜨릴 수 있습니다.

SPF를 수정하면 이메일 배달률이 향상되나요? 인증 실패 원인을 제거하면 일관된 배달의 전제 조건이 갖춰집니다 — 특히 Google과 Yahoo가 대량 발신자에 대해 DMARC 정렬을 적용하기 시작한 지금은 더욱 중요합니다. SPF만으로는 전체 그림이 되지 않습니다: 완전한 이메일 인증을 위해 DKIM 및 DMARC와 함께 사용하세요.

무료 SPF 확인

SPF 레코드가 조회 한도를 초과했는지, 또는 도메인 보호에 너무 약하게 설정되어 있는지 확실하지 않다면 무료 검사를 실행하세요. 완전히 해석된 체인을 평가하고 예산이 어디에 사용되고 있는지 정확히 보여줍니다.

도메인 확인 → · SPF 수정 → · SPF PermError 보고서 → · SPF 잘못된 구성 보고서 → · SPF 도입 성숙도 모델 → · DMARC 수정 → · 집계 데이터만 사용. 데이터는 EU 내에서 저장 및 처리됩니다.