SPF 10-lookup 제한은 이메일이 더 작고, 더 단순하고, 덜 외주화되었을 때 말이 되던 설계 결정이다.
지금 그렇게 성가신 이유가 바로 그거다.
RFC 7208은 SPF 평가가 DNS 쿼리를 유발하는 항목을 10개로 제한해야 한다고 말한다. 초과하면 결과는 PermError. “거의 다 됐어”가 아니다. “경고와 함께 재시도”가 아니다. 프로토콜이 DNS 작업이 너무 많으면 의심스럽다고 판단해서 SPF 정책이 에러 상태로 무너진다.
프로토콜이 완전히 틀린 건 아니다. DNS 증폭과 재귀 남용은 2003년에 실제 우려였다. 하지만 그 제한을 준 인터넷은 지금 하나의 도메인이 기업 메일, 마케팅 자동화, 헬프데스크 소프트웨어, CRM 시스템, HR 플랫폼, 빌링 시스템, 트랜잭션 제공자를 통해 동시에 메일을 보내라고 요구하는 인터넷이 아니다.
제한은 얼어붙었다. 이메일은 안 얼었다.
10개에 포함되는 것
모든 SPF 메커니즘이 DNS 쿼리를 유발하는 건 아니다. ip4:와 ip6:는 리터럴 값 — 조회 불필요. 하지만 이 메커니즘과 수정자는 각각 최소 하나를 소비한다:
include:— 가장 큰 놈. 각 include가 다른 도메인의 SPF 레코드를 당기고, 그 안에 또 include가 있을 수 있다.a— 도메인의 A 레코드 조회mx— MX 레코드 조회, 그다음 각 MX 호스트의 A 레코드ptr— 역방향 DNS 조회 (RFC에서 비권장, 아직도 보임)exists— 도메인 존재 확인redirect— 다른 SPF 레코드로 이동
함정은 include가 재귀적이라는 것. include:spf.provider.com 자체가 include 3개를 포함하면, 레코드에서 한 줄로 보이는 것이 4개 조회다. include:_spf.google.com 하나가 이미 Google의 현재 설정에 따라 2-3개 조회를 소비한다.
실제 조직이 제한에 걸리는 방법
2026년의 전형적인 기업 이메일 셋업:
- Google Workspace 또는 Microsoft 365: 2-3 조회
- 마케팅 플랫폼 (Mailchimp, HubSpot, Sendgrid): 1-2 조회
- CRM (Salesforce): 1-2 조회
- 고객 지원 (Zendesk, Freshdesk): 1 조회
- HR/온보딩 시스템: 1 조회
- 트랜잭션 이메일 (빌링, 알림): 1 조회
정상적 발신자를 다 추가하기도 전에 7-10개. 재무팀이 include가 필요한 인보이스 플랫폼에 가입한다. 인수합병으로 자체 이메일 인프라를 가진 자회사가 추가된다. 아무도 문서화하지 않은 SaaS 트라이얼이 도메인으로 비밀번호 재설정 이메일을 보내고 있다.
12개가 됐다. SPF가 조용히 깨진다. DMARC 정렬이 실패한다. 이메일이 스팸에 들어가거나 거부되기 시작한다 — 수신 서버의 에러 메시지에는 SPF 조회에 대한 언급이 없다. 몇 주 후 누군가 전달률이 떨어진 걸 발견한다.
조용한 실패
진짜 미치게 하는 부분. 조회 제한 초과가 에러 이메일을 보내지 않는다. 도메인 관리자에게 경고를 보내지 않는다. SPF 레코드가 그냥 작동을 멈춘다. 수신 서버는 PermError를 보고 설정에 따라 하드 페일로 처리하거나 SPF를 완전히 무시한다.
대부분의 SPF 검증 도구가 제한 초과를 알려준다 — 확인하려고 생각한다면. 하지만 SaaS 온보딩할 때마다, 마케팅 도구 트라이얼마다, 벤더 연동마다 SPF 레코드를 감사하는 관리자가 몇 명이나 될까?
레코드가 조용히 커진다. 조용히 깨진다. 피해가 조용히 쌓인다.
우회 방법은 전부 핵
SPF 플래트닝. 모든 include: 체인을 리터럴 ip4:/ip6: 항목으로 해석한다. 전부 하드코딩이니 조회가 필요 없다. 문제: IP 주소가 바뀐다. 클라우드 제공자가 IP를 로테이션한다. 플래트닝된 레코드는 정기적으로 재해석하지 않으면 오래된다 — 즉, DNS를 모니터하고 업데이트하는 자동화 도구가 필요하다. 프로토콜 문제를 유지보수 문제로 바꾼 것이다.
서브도메인 위임. 마케팅 이메일은 mail.example.com에서, 지원 이메일은 support.example.com에서. 각 서브도메인이 자체 10-lookup 예산을 갖는다. 작동하지만 이메일 정체성이 파편화되고 DMARC 정렬이 복잡해진다.
SPF 매크로. exists: 메커니즘과 매크로를 써서 평가를 단축하는 동적 조회를 구성한다. 영리하지만 깨지기 쉽고, 디버깅이 어렵고, 모든 수신 서버가 매크로를 제대로 처리하는 건 아니다.
모든 우회 방법이 복잡성과 유지보수 비용을 추가한다. 근본 문제를 해결하는 건 하나도 없다.
왜 아무도 표준을 안 고치나
10-lookup 제한이 RFC에 박혀 있다. 바꾸려면 새 스펙이 필요하고, IETF 프로세스는 느리다. 제한을 올리면 DNS 부하가 늘어난다는 진지한 주장도 있다 — 하지만 반론은 SPF 플래트닝이 더 높은 제한보다 더 많은 DNS 트래픽을 생성한다는 것이다. 자동화 플래트닝 도구가 레코드를 최신 유지하려고 DNS를 끊임없이 폴링하니까.
아이러니: DNS 남용을 방지하려고 설계된 제한이 이제 방지하려던 남용보다 더 많은 운영 피해를 준다.
20년. 이메일 생태계가 완전히 변했다. 제한은 움직이지 않았다.
할 수 있는 것
SPF 레코드를 확인해라. 지금. 조회 수를 세라. 8개 이상이면 벤더 연동 하나가 조용한 실패와의 거리다.
이미 초과했으면: 플래트닝하거나 서브도메인을 분리해라. SPF 검증 실패 모니터링을 설정해라. 그리고 벤더에게 SPF include를 통합하라고 요구해라 — 많은 SaaS 제공자가 불필요하게 방대한 include 체인을 써서 조회 예산을 낭비한다.
제한은 사라지지 않는다. 더 단순한 인터넷을 위해 쓰여진 20년 된 제약 주변을 관리하는 게 최선이다.