SPF 조회 제한: DNS 조회 10회 문제 해결하기

SPF 조회 제한의 핵심은 간단합니다. SPF 정책을 평가할 때 DNS 조회를 일으키는 항목이 10개를 넘으면 수신 서버는 처리를 중단하고 영구 오류를 반환할 수 있습니다. DNS 관리 화면에서는 정상으로 보이는 메일 설정도 실제 인증에서는 실패할 수 있다는 뜻입니다. 도메인 이메일을 정리하고 있다면 먼저 소규모 기업용 업무 이메일을 살펴본 다음, 나중에 문제가 생기기 쉬운 이 부분을 점검하세요.

많은 팀이 이런 상황을 겪습니다. Google Workspace에 이어 Microsoft 365, Mailchimp, CRM, 헬프데스크를 추가합니다. 업체마다 “include만 추가하면 됩니다”라고 안내합니다. 몇 달 뒤 SPF 레코드는 문법상 유효하지만 실제 평가에서는 제대로 작동하지 않을 수 있습니다. 메일이 스팸함에 들어가거나 일부 메시지가 반송됩니다. 겉보기에는 레코드가 정상이어서 원인을 찾기 어렵습니다.

다행히 해결 방법은 대개 복잡하지 않습니다. 사용하지 않는 항목을 제거하고, 꼭 필요한 경우가 아니면 `mx`를 쓰지 마세요. 마케팅 메일은 하위 도메인으로 분리하고 기본 도메인의 정책은 간결하게 유지하세요.

SPF 조회 제한이란?

SPF 조회 제한은 SPF 평가 중 DNS 조회를 일으키는 항목 수에 대해 RFC가 정한 상한입니다. 수신 서버는 중첩된 `include` 체인을 포함해 실제 평가 경로 전체에서 이런 항목을 10개 넘게 처리해서는 안 됩니다. 정책이 이 한도를 넘으면 SPF가 `permerror`를 반환할 수 있으며, 메시지는 중요한 인증 신호 하나를 잃게 됩니다.

이 규칙은 RFC 7208에 정의되어 있습니다. SPF가 과도한 DNS 트래픽을 유발하지 않도록 둔 제한입니다. 선택 사항이나 권장 설정이 아니라 프로토콜의 한도입니다.

놓치기 쉬운 점은 SPF 조회 제한이 누적된다는 것입니다. 기본 레코드에서 10개를 쓰고 각 include 안에서 다시 10개를 쓸 수 있는 것이 아닙니다. 평가 경로 전체가 하나의 한도를 공유합니다.

정상처럼 보이는 레코드가 SPF 조회 제한에 걸리는 이유

SPF 조회 제한은 깔끔해 보이는 레코드에도 영향을 줍니다. SPF에서 중요한 것은 기본 TXT 레코드의 모양이 아니라, include, redirect, `a`, `mx` 항목을 따라가며 수신 서버가 실제로 평가하는 DNS 조회 유발 항목의 수입니다.

예를 들어 보겠습니다.

`v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net -all`을 게시하고 조회를 세 번만 쓴다고 생각할 수 있습니다. 하지만 Google과 Microsoft의 레코드에는 추가 조회 항목이 중첩되어 있습니다. 눈에 보이는 레코드는 짧아도 전체 평가 경로는 짧지 않습니다.

그래서 SPF 조회 제한 문제는 첫날이 아니라 나중에 나타나곤 합니다. 업체가 자체 SPF 구성을 바꾸면 사용자가 DNS를 수정하지 않아도 항목 수가 늘어날 수 있습니다.

또 다른 함정은 빈 조회(void lookup)입니다. RFC 7208은 구현체에서 이를 두 번으로 제한하도록 권고합니다. 빈 조회란 응답 데이터가 없거나 `NXDOMAIN`이 반환되는 DNS 질의입니다. include의 오타 하나는 바로 문제가 되지 않을 수도 있지만, 잘못된 참조 두 개는 오류를 유발할 수 있습니다. 따라서 10개 미만이어도 SPF 조회 제한을 점검하다 `permerror` 문제를 발견할 수 있습니다.

Google의 발신자 지침도 인증의 중요성을 보여 줍니다. 대량 발신자의 인증이 없거나 잘못되어 있으면 스팸함 분류 또는 거부로 이어질 수 있습니다. Google은 대량 발신자에게 SPF, DKIM, DMARC 구성을 요구하며, 요건을 충족하지 않는 메시지는 거부되거나 스팸으로 분류될 수 있다고 설명합니다. Google 발신자 요건 FAQ를 참고하세요.

SPF 조회 한도 사용량 계산하기

SPF 조회 제한 사용량을 계산하려면 기본 SPF 레코드에서 시작해 재귀적으로 참조되는 구성을 확인하고, 평가 경로에서 DNS 조회를 일으키는 메커니즘을 세세요. 자신의 항목뿐 아니라 업체가 내부적으로 참조하는 항목도 포함됩니다. 평가되는 총항목이 10개를 넘으면 한도를 준수한 평가를 완료할 수 없습니다.

먼저 기본 레코드를 확인합니다.

dig +short txt example.com

출력 예시:

"v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"

그다음 참조된 각 도메인을 확인합니다.

dig +short txt _spf.google.com

dig +short txt spf.protection.outlook.com

`ip4`, `ip6` 또는 정책을 끝내는 항목만 남을 때까지 참조를 따라가세요.

계산할 때는 다음 원칙을 따릅니다.

1. 평가 경로의 include, a, mx, ptr, exists, redirect를 각각 셉니다.
2. include로 불러온 레코드 안의 중첩 항목도 셉니다.
3. ip4, ip6, all은 세지 않습니다.
4. 데이터를 반환하지 않는 include 대상은 따로 표시합니다. 빈 조회 문제가 될 수 있습니다.

TrekMail에서 도메인을 설정하며 DNS를 간단히 점검하려면 DNS 상태 확인과 필수 DNS 레코드 문서부터 읽어 보세요.

SPF 조회 제한과 관련된 흔한 실수

대부분의 SPF 조회 제한 문제는 비슷한 실수에서 비롯됩니다. 여러 업체를 기본 도메인 하나에 추가하고, 이전 제공업체를 남겨 두고, 간편하다는 이유로 `mx`를 쓰고, 유지 관리 절차 없이 수동 평탄화를 적용하는 것입니다. 특이한 문제라기보다 규모가 커지면서 DNS 관리가 소홀해진 결과입니다.

주요 원인은 다음과 같습니다.

이 지점에서 겉으로 보이는 복잡성과 실제 복잡성을 혼동하기 쉽습니다. 업체의 include 하나가 내부적으로 여러 조회 항목을 사용할 수 있습니다. SPF 조회 제한을 고려하면 “발신자 하나만 더 추가하자”는 접근은 위험할 수 있습니다.

특정 업무에 전달, 별칭, 실제 사서함 중 무엇을 사용할지 고민하고 있다면 이 선택도 발신 설정과 연결됩니다. 관련 글인 도메인 이메일 별칭과 사서함의 차이, 이메일 별칭 전달도 참고하세요.

메일에 미치는 위험을 줄이며 SPF 조회 제한 해결하기

SPF 조회 제한을 해결하려면 임시방편을 더하는 대신 SPF 구성을 단순화하는 것이 좋습니다. 먼저 사용하지 않는 발신자를 제거하고, 다음으로 트래픽이 많은 시스템을 하위 도메인으로 옮기세요. 평탄화는 자동으로 최신 상태를 유지할 수 있을 때만 고려하세요.

1. 불필요한 항목을 제거하세요.

사용하지 않는 업체와 `ptr`를 삭제하세요. `mx`는 실제 발신자에게 필요한 권한 설정으로 바꾸세요. 정리만으로 SPF 조회 제한 아래로 돌아오는 정책도 많습니다.

2. 하위 도메인별로 트래픽을 분리하세요.

규모가 커지는 팀에 흔히 적합한 방법입니다.

; Primary company mail
example.com.              TXT  "v=spf1 include:spf.trekmail.net -all"

; Marketing mail
marketing.example.com.    TXT  "v=spf1 include:servers.mcsv.net include:hubspotemail.net -all"

; Transactional app mail
notify.example.com.       TXT  "v=spf1 include:amazonses.com -all"

각 하위 도메인은 자체 SPF 한도를 사용합니다. 기본 도메인의 복잡성을 줄이고 SPF 조회 제한을 관리하는 데 도움이 됩니다.

3. 평탄화는 마지막 수단으로 쓰세요.

평탄화는 include를 명시적인 IP 대역으로 바꿉니다.

; Before
v=spf1 include:vendor-a.example include:vendor-b.example -all

; After
v=spf1 ip4:192.0.2.10 ip4:192.0.2.11 ip4:198.51.100.0/24 -all

조회 사용량을 거의 없앨 수 있지만 유지 관리 부담도 생깁니다. 업체가 IP를 변경하면 레코드가 오래된 상태가 되어 인증에 실패할 수 있습니다. 평탄화한다면 업데이트를 자동화하세요.

기존 방식과 개선된 방식: TrekMail로 SPF 조회 제한 관리하기

SPF 조회 제한을 관리하는 기존 방식은 여러 사서함 제공업체, 마케팅 플랫폼, 릴레이를 기본 도메인 하나에 계속 추가하는 것입니다. 결국 DNS의 변경 이력을 파헤쳐야 합니다. 개선된 방식은 관리할 요소를 줄이고 처음부터 발신 역할을 분리하는 것입니다.

기존 방식: 복잡한 기본 도메인 SPF 레코드에 예전 업체가 남아 있고, 마케팅 트래픽과 실제 사서함 트래픽이 섞이며, 발신 권한의 관리 책임도 불분명합니다.

개선된 방식: 사서함 호스팅은 단순하게 유지하고, 대량 발신자는 하위 도메인으로 분리하며, 기본 도메인의 SPF 정책은 여유 있는 짧은 구성으로 만듭니다.

TrekMail을 활용할 수 있는 부분입니다. 유료 요금제의 TrekMail 관리형 발신을 사용하는 경우 SPF 레코드에 `include:spf.trekmail.net`을 추가하도록 안내됩니다. 이 include 자체는 조회 항목 하나로 계산되며, 중첩된 참조도 확인해야 합니다. 안내된 시작 가격은 월 $3.50이고, 자체 도메인, IMAP 사서함, catch-all, 사서함 전달, 내장 마이그레이션 도구, API 접근이 기능으로 소개되어 있습니다. 유료 요금제에는 신용카드가 필요한 14일 무료 체험이 안내되어 있습니다. Nano는 체험 기간이 없는 무료 요금제로 안내되며 BYO SMTP를 사용합니다. 최신 가격과 조건을 확인하세요.

Nano에서는 TrekMail을 사서함 계층으로 쓰면서 SES, Mailgun 또는 다른 릴레이로 발신할 수 있습니다. 기본 정책이 SPF 조회 제한에 걸리지 않도록 하위 도메인을 체계적으로 구성하세요. 사용자 지정 SMTP(BYO), TrekMail 관리형 SMTP, 대시보드에서 마이그레이션 시작 문서에 운영 방법이 설명되어 있습니다.

도메인을 통합한다면 여러 도메인의 이메일 호스팅과 내 도메인에 이메일 설정하기도 참고할 수 있습니다.

정리: SPF 조회 제한 아래로 유지하는 방법

SPF 조회 제한을 지키려면 SPF를 단순하게 유지하세요. 기본 도메인의 발신자는 최소화하고, 대량 메일과 앱 메일은 하위 도메인으로 옮기세요. 새 도구를 추가할 때마다 업체의 include를 다시 점검하세요. 정책이 10개에 가까우면 경고 신호로 받아들이세요.

핵심은 이것입니다. SPF 조회 제한은 RFC의 이론적인 예외 상황이 아니라 시스템을 계속 추가할 때 실제 운영에 영향을 주는 명확한 제약입니다. 레코드를 짧게 유지하고 DNS 관리 책임을 분명히 하세요. 다섯 업체가 한정된 인증 경로를 공유하도록 방치하면 새벽 2시에 메일 헤더를 분석하게 될 수도 있습니다.

더 단순한 구성을 원한다면 TrekMail의 정액형 다중 도메인 이메일 호스팅을 살펴보세요. 사용자별 요금 대신 공유 저장 공간, 내장 IMAP 마이그레이션, BYO SMTP 또는 TrekMail 관리형 SMTP 선택이 안내되어 있으며 제공 범위와 조건은 요금제에 따라 달라질 수 있습니다. TrekMail 요금을 확인하거나 TrekMail로 이동하세요.