SPF 조회 수 계산기

SPF 조회 수 계산기는 도메인의 SPF 레코드(v=spf1)를 가져온 뒤 include·redirect·a·mx·ptr·exists 메커니즘을 재귀적으로 따라가며 DNS 조회 횟수를 합산합니다. RFC 7208은 한 번의 메일 평가에서 발생하는 DNS 조회를 10회로 제한하며, 이를 넘으면 수신 서버가 permerror로 처리해 SPF 검증이 통째로 실패할 수 있습니다.

메일이 자꾸 스팸으로 분류되거나 SPF가 통과되지 않는다면, 흔한 원인이 바로 이 10회 한도 초과입니다. 도메인만 입력하면 include 체인을 펼쳐 현재 몇 회를 소비하는지, 어디서 늘어나는지 한눈에 보여줍니다. 기록을 확인했다면 SPF 평탄화(flattening)로 조회 수를 줄이는 것을 검토하세요. SPF 레코드 원문과 메커니즘 해석은 SPF 레코드 조회·검사에서, 도메인 전체 인증 상태는 이메일 도달성 종합 점검에서 함께 확인할 수 있습니다.

SPF 10회 조회 한도란

SPF 평가 중 DNS 조회를 유발하는 메커니즘은 include, a, mx, ptr, exists 와 modifier redirect 입니다. 이들의 합이 10회를 넘으면 RFC 7208 기준으로 permerror가 발생합니다. 반면 ip4, ip6, all, exp 는 DNS 조회를 일으키지 않으므로 한도에 포함되지 않습니다.

• include: 다른 도메인의 SPF를 불러옴 — 그 자체로 1회, 내부 조회는 별도 합산
• a / mx: 호스트의 A/MX 조회 — 각 1회(다중 MX여도 메커니즘당 1로 계산)
• ptr: 사용 비권장 메커니즘 — 1회
• exists: 매크로 확장 후 A 조회 — 1회
• redirect= 다른 도메인 SPF로 위임 — 1회

한도를 줄이는 방법 (SPF flattening)

가장 흔한 해법은 SPF 평탄화입니다. include 체인이 가리키는 최종 IP 대역을 직접 조회해 ip4/ip6 항목으로 치환하면 중첩 조회가 사라집니다. 다만 공급자의 IP가 바뀌면 SPF를 다시 갱신해야 하므로, 자동 갱신 서비스를 쓰거나 정기 점검이 필요합니다. 더는 쓰지 않는 메일 공급자의 include는 과감히 제거하고, 필요하면 도메인을 분리해 서비스별로 SPF를 나누는 것도 방법입니다.

메커니즘별 10회 한도 포함 여부

어떤 메커니즘이 DNS 조회를 일으키고(=한도에 합산), 어떤 것이 일으키지 않는지(=공짜)를 정확히 구분하는 것이 핵심입니다. 아래 표를 기준으로 자신의 SPF 레코드를 한 항목씩 세어 보세요.

실전 예시: permerror가 나는 SPF 풀어 보기

어느 도메인의 SPF 레코드가 다음과 같다고 합시다.

v=spf1 include:_spf.google.com include:sendgrid.net include:mail.example.net -all

최상위에 include가 3개이므로 일단 3회를 씁니다. 그런데 첫 번째 _spf.google.com 자체가 내부적으로 include 4개를 더 가지고 있다고 합시다(예: _netblocks 계열 3개 + 1개). 이 경우 조회 수를 다음과 같이 합산합니다.

• 최상위 include 3개 → 3
• _spf.google.com 내부 include 4개 → 4
• 그 내부 include들이 각각 mx/a 1개씩 더 가졌다면 → +4
• 합계 → 3 + 4 + 4 = 11 회

합계 11회는 한도 10회를 1회 초과하므로 수신 서버는 permerror를 반환하고, 그 결과 SPF는 통과하지 못합니다. 증상 → 원인 → 조치는 다음과 같습니다.

• 증상: 일부 수신처에서 SPF=permerror, 메일이 스팸 처리되거나 거부됨
• 원인: include 체인을 펼친 총 DNS 조회가 11회로 10회 한도 초과
• 조치: 더 안 쓰는 include:mail.example.net를 제거(11→10 이하)하거나, 안정적인 대역은 SPF 평탄화로 ip4:/ip6:로 치환해 조회 수를 근본적으로 줄임