SPF PermError와 DNS 조회 10회 초과를 찾아 줄이는 방법
SPF의 DNS 조회 한도는 최상위 레코드뿐 아니라 include와 redirect가 참조하는 하위 정책까지 실제 평가 경로에서 합산해야 합니다. 연결 도구는 입력한 레코드의 직접 조회 용어만 1차로 세므로, 중첩 경로는 권한 DNS 조회나 재귀 SPF 검사기로 별도 확인한 뒤 미사용 발송 서비스를 제거하세요.
SPF 문자열이 짧아 보여도 외부 서비스 하나가 다시 여러 도메인을 참조하면 평가는 깊어집니다. 한도를 넘긴 결과는 단순한 softfail이 아니라 영구 오류로 처리될 수 있으므로, 현재 메일 발송 주체를 확인하는 일부터 시작해야 합니다.
먼저 보는 핵심 요약
- RFC 7208은 SPF 평가 중 DNS 조회를 일으키는 용어에 총 10회의 상한을 두며 중첩 참조도 포함합니다.
- ip4, ip6처럼 주소를 직접 적는 메커니즘은 같은 방식의 DNS 조회를 만들지 않지만 관리 부담이 달라집니다.
- 레코드를 줄인 뒤 업무 메일, 마케팅, 고객지원 등 실제 발송 서비스별로 SPF 통과와 정렬 결과를 확인합니다.
10회 제한에 포함되는 메커니즘과 변경자
RFC 7208의 처리 제한은 include, a, mx, ptr, exists 메커니즘과 redirect 변경자처럼 평가 과정에서 DNS 질의를 유발하는 용어에 적용됩니다. 최상위 TXT 레코드의 개수만 세어서는 부족하며, 조건에 따라 실제로 따라간 하위 레코드의 조회도 합산됩니다. ptr은 사용을 권장하지 않는 메커니즘이기도 합니다.
include 트리를 끝까지 펼쳐야 하는 이유
한 개의 include가 공급자 정책 안에서 다른 include, a, mx를 호출할 수 있습니다. 공급자가 레코드를 바꾸면 내 DNS를 수정하지 않아도 총 조회 수가 달라질 수 있습니다. 검사 결과에는 각 분기와 최종 IP 범위를 함께 기록해 어느 서비스가 비용을 많이 사용하는지 파악하세요.
조회 수를 줄일 때 우선 제거할 항목
계약이 끝난 메일 서비스, 테스트용 발송 도메인, 같은 공급자를 가리키는 중복 include부터 정리합니다. 현재 발송 IP가 고정이라는 이유로 외부 정책을 무작정 복사해 평탄화하면 공급자 변경을 놓칠 수 있습니다. 직접 주소를 관리하려면 갱신 책임과 모니터링 절차를 먼저 정해야 합니다.
수정 후 SPF만 보면 안 되는 이유
DNS 캐시와 TTL 때문에 변경이 즉시 모든 확인자에게 보이지 않을 수 있습니다. 권한 DNS의 TXT 값과 여러 위치의 조회 결과를 확인하고, 각 발송 서비스에서 테스트 메일을 보내 Authentication-Results를 점검하세요. DMARC를 사용한다면 SPF 또는 DKIM의 식별자 정렬도 별도로 확인해야 합니다.
단계별로 확인하는 방법
- 현재 발송 주체 목록 만들기
업무 메일, 뉴스레터, 문의 시스템 등 도메인을 대신해 보내는 서비스를 빠짐없이 정리합니다.
- 직접 항목을 센 뒤 하위 정책 확인하기
연결 도구로 최상위 레코드의 직접 조회 용어를 먼저 세고, include와 redirect의 하위 정책은 권한 DNS나 재귀 검사기로 끝까지 확인합니다.
- 미사용·중복 참조 제거하기
실제 발송 목록과 대조해 사용하지 않는 include를 삭제하고 공급자별 권장 레코드를 다시 확인합니다.
- DNS와 실제 메일 재검증하기
전파 뒤 레코드를 다시 검사하고 모든 발송 경로의 Authentication-Results와 DMARC 정렬을 확인합니다.
판단 기준을 한눈에 비교하기
| 확인 항목 | 판단 기준 |
|---|---|
| include·redirect | 참조한 정책 안의 평가까지 이어지므로 중첩 조회를 함께 계산합니다. |
| a·mx·exists | 평가 중 DNS 질의를 유발할 수 있어 전체 처리 제한에 포함해 점검합니다. |
| ip4·ip6 | 주소를 정책에 직접 선언하지만 주소 변경을 운영자가 지속해서 관리해야 합니다. |
| all | 평가 결과의 기본 처리를 정하는 메커니즘이며 레코드 끝의 정책 의도를 확인합니다. |
실행 전 체크리스트
- 현재 도메인으로 메일을 보내는 모든 서비스를 확인했나요?
- 중첩 include와 redirect 안쪽까지 조회 수를 셌나요?
- 삭제한 서비스가 실제로 더 이상 발송하지 않나요?
- 변경 후 SPF 결과와 DMARC 정렬을 실제 메일에서 확인했나요?
주의할 점
연결 도구의 수치는 입력한 한 줄에 나타난 직접 용어의 1차 집계이며 중첩 include·redirect를 재귀 해석하지 않습니다. 이 값만으로 10회 이하라고 확정하지 마세요. 외부 SPF 레코드의 IP를 한 번 복사해 고정하는 평탄화도 공급자 주소 변경을 놓칠 수 있으므로 자동 갱신과 감시 없이 운영하면 안 됩니다.
함께 보면 좋은 글
자주 묻는 질문
SPF TXT 레코드의 include가 10개 이하면 안전한가요?
아닙니다. 각 include가 다시 참조하는 정책과 a, mx, exists, redirect 평가까지 합산해야 하므로 표면의 개수만으로 판단할 수 없습니다.
ip4를 많이 적으면 DNS 조회 10회에 포함되나요?
ip4 메커니즘은 include처럼 추가 DNS 조회를 유발하지 않지만 레코드 크기, 주소 변경 관리, 정확한 소유 범위를 별도로 고려해야 합니다.
PermError와 softfail은 같은 결과인가요?
아닙니다. PermError는 정책을 정상적으로 평가하지 못한 영구 오류이고 softfail은 보통 `~all` 같은 메커니즘이 표현하는 평가 결과입니다.
SPF만 통과하면 DMARC도 통과하나요?
항상 그렇지는 않습니다. DMARC는 인증 결과와 함께 보이는 From 도메인과 인증 식별자의 정렬을 검사하므로 SPF 또는 DKIM의 정렬 조건을 확인해야 합니다.
근거와 출처
- RFC 7208 Sender Policy Framework — 1차 출처, 조회일 2026-08-30
- RFC 1035 Domain Names 구현 명세 — 1차 출처, 조회일 2026-08-30
도구에서 직접 확인하기
설명한 기준을 실제 값에 적용하려면 SPF·DMARC 1차 검사기에서 작은 샘플부터 확인하세요. 원본과 결과를 나란히 비교한 뒤 실제 사용 환경에 적용하는 순서가 가장 안전합니다.
이 글은 알파카랩스 Utils의 개발 도구 도구와 함께 보는 정보성 가이드입니다. 규격과 외부 서비스 정책은 바뀔 수 있으므로 중요한 결정 전에는 연결된 공식 출처의 최신 내용을 다시 확인하세요.