SPF 플래트닝: DNS 조회 10회 제한 해결

조회 10회 제한이란

수신 메일 서버가 SPF 레코드를 해석하기 위해 DNS 조회를 10회보다 많이 수행해야 하면 SPF(Sender Policy Framework)는 permerror로 실패합니다. 이는 중첩된 include 구문 때문에 발생합니다. 레코드가 제공업체를 include하고, 그 제공업체가 또 다른 서비스를 include하면 각 단계가 제한에 포함됩니다. 이를 해결하려면 이런 재귀적 조회를 고정된 IP 주소 목록으로 바꾸는 SPF 플래트닝을 사용해야 합니다.

전달성을 관리하는 엔지니어로서, 저는 이 문제가 "벤더 난립" 상황에서 가장 자주 나타나는 것을 보았습니다. 회사가 트랜잭션 제공업체 하나로 시작해서 마케팅 도구를 더하고 CRM을 더하면, 어느새 SPF 레코드는 모래 위에 지은 집이 됩니다. 11번째 조회가 발생하면 수신 서버는 검색을 멈추고 영구 오류를 반환합니다. 즉 이메일이 스팸으로 표시되는 데 그치지 않고, 인증 검사가 근본적으로 실패했기 때문에 아예 거부될 수 있습니다.

조회 제한이 작동하는 방식

RFC 7208에 따르면 이 제한은 DNS 인프라에 대한 서비스 거부(DoS) 공격을 막기 위해 존재합니다. 제한이 없다면 악의적인 행위자가 순환 참조나 거대한 include 체인을 만들어, 수신 서버가 이메일 한 통을 처리하려고 수백 번의 쿼리를 수행하게 만들 수 있습니다.

무엇이 조회로 계산되나요?

SPF 레코드의 모든 메커니즘이 무료인 것은 아닙니다. 다음은 DNS 쿼리를 일으킵니다.

• include: 가장 흔한 원인입니다. 서버가 다른 도메인의 SPF 레코드를 찾아보게 합니다.
• a: 도메인의 A 레코드를 조회합니다.
• mx: 도메인의 MX 레코드를 조회합니다.
• ptr: 역방향 DNS를 조회합니다(다만 더 이상 권장되지 않으므로 피해야 합니다).
• exists: 특정 도메인이 존재하는지 조회합니다.

ip4와 ip6 같은 메커니즘은 IP 주소가 레코드에 명시적으로 나열되어 있으므로 무료입니다.

조회 체인의 구조

다음과 같은 가상의 SPF 레코드를 생각해 봅시다.

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendhq.cc ~all

겉으로 보면 3회 조회입니다. 하지만 _spf.google.com에 include 구문이 세 개 더 있고 spf.protection.outlook.com에 네 개가 있다면 이미 10회 조회입니다. SendHQ의 레코드에도 include가 있다면 제한에 도달한 것입니다. 이것이 "include 체인"입니다.

permerror 식별하기

제한에 도달했는지 확실하지 않다면 SendHQ 이메일 DNS 확인 도구로 레코드를 검증할 수 있습니다. 원본 로그나 헤더 분석 도구에서는 다음과 같은 결과가 표시됩니다.

spf=permerror (too many DNS lookups)

이는 softfail(~all)이나 fail(-all)과는 다릅니다. permerror는 SPF 검사를 완료할 수 없었다는 뜻입니다. 이 경우 수신 측은 발신자가 승인되었는지 확인할 수 없으며, 이메일이 버려지거나 공격적인 필터에 걸리는 경우가 많습니다.

SPF 플래트닝이란?

SPF 플래트닝은 모든 include, a, mx 메커니즘을 ip4와 ip6 주소의 평면 목록으로 해석하는 과정입니다.

예시: 적용 전과 후

적용 전(재귀):

v=spf1 include:_spf.example.com include:_spf.vendor.com ~all

(_spf.example.com은 1.2.3.4로, _spf.vendor.com은 5.6.7.8로 해석된다고 가정합니다)

적용 후(플래트닝):

v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 ~all

레코드를 IP 목록으로 바꾸면 조회 횟수가 2회(또는 그 이상)에서 0회로 줄어듭니다. 수신 서버는 IP를 즉시 확인하고 추가 DNS 쿼리 없이 발신자를 검증합니다.

플래트닝의 트레이드오프

플래트닝은 강력한 해결책이지만 상당한 유지 관리 부담이 따릅니다.

1. 오래된 IP 문제

include 구문을 사용하면 IP 주소 관리를 제공업체에 위임하는 것입니다. Amazon SES나 SendGrid가 인프라에 새 IP 대역을 추가하면 그들이 자신의 SPF 레코드를 업데이트하므로 이메일은 계속 전달됩니다.

이런 레코드를 플래트닝해서 자신의 DNS에 넣으면 그 IP는 사용자가 책임지게 됩니다. 제공업체가 IP를 바꿨는데 플래트닝한 목록을 업데이트하지 않으면 이메일이 SPF 인증에 실패합니다. 이것이 대량 트랜잭션 메일에서 수동 플래트닝이 위험한 주된 이유입니다.

2. 레코드 길이 제한

DNS 레코드에는 최대 길이가 있습니다. TXT 레코드의 단일 문자열은 255자로 제한됩니다. 여러 문자열을 이어 붙일 수 있지만 일부 오래된 DNS 파서는 매우 긴 레코드를 처리하지 못합니다. 너무 많은 제공업체를 플래트닝하면 SPF 레코드가 너무 커져 올바르게 처리되지 않을 수 있습니다.

include 체인 해결 방법

조회 10회 제한에 걸린다면 가장 안전한 방법부터 가장 공격적인 방법 순으로 다음 해결 단계를 따르세요.

1단계: 점검하고 정리하기

레코드에서 오래된 제공업체를 확인하세요. 많은 팀이 3년 전에 사용을 중단한 서비스의 include 구문을 여전히 유지하고 있습니다. 더 이상 사용자를 대신해 메일을 보내지 않는 제공업체는 모두 제거하세요.

2단계: 트래픽 유형별로 서브도메인 사용하기

가장 전문적인 아키텍처 해결책입니다. 모든 서비스를 루트 도메인에 두는 대신 기능별로 나누세요.

• 루트 도메인(example.com): 사내 이메일(Google Workspace/Outlook).
• 트랜잭션 서브도메인(mail.example.com): SendHQ 또는 Amazon SES.
• 마케팅 서브도메인(news.example.com): Mailchimp 또는 Klaviyo.

각 서브도메인은 자체 SPF 레코드와 자체 조회 10회 제한을 가집니다. 이렇게 하면 위험이 격리되고, 마케팅 도구의 복잡한 SPF 체인이 중요한 트랜잭션 이메일을 망가뜨리는 일을 막을 수 있습니다.

3단계: 동적 SPF 플래트닝

동적 플래트닝은 제공업체의 include 체인을 실시간으로 모니터링하고 현재 IP 주소로 DNS 레코드를 자동 업데이트하는 서비스입니다. API로 업데이트 과정을 자동화하므로 "오래된 IP" 문제를 해결합니다.

최신 전달 환경에서의 SPF

SPF는 인증이라는 퍼즐의 일부일 뿐이라는 점을 이해하는 것이 중요합니다. 메일이 수신 서버에서 수락되도록 하려면 SPF를 DKIM, DMARC와 함께 조율해야 합니다. 이들의 관계에 대한 자세한 설명은 SendHQ의 DKIM, SPF, DMARC 가이드에서 볼 수 있습니다.

접수 vs 전달 vs 도달

엔지니어로서 저는 이 세 단계를 구분합니다.

1. 접수: 수신 서버가 연결과 메시지를 수락합니다. SPF permerror는 서버가 SMTP 수준에서 메시지를 거부하게 만들 수 있으며, 이 경우 메시지는 접수되지 않습니다.
2. 전달: 메시지가 수락되어 사용자의 메일함(또는 폴더)으로 이동합니다.
3. 받은편지함 도달: 메시지가 스팸함이 아닌 기본 받은편지함에 도착합니다.

SPF 플래트닝은 접수 문제를 해결합니다. 받은편지함 도달을 보장하지는 않습니다. 도달 여부는 발신자 평판, 콘텐츠, 참여 지표가 좌우합니다.

AI 에이전트를 위한 특별 고려 사항

AI 에이전트가 API로 이메일을 보내는 일이 늘면서, 에이전트가 여러 도메인에 걸쳐 대량의 이메일을 발생시킬 수 있기 때문에 SPF 문제의 위험도 커집니다. 에이전트 워크플로를 구축할 때는 이메일 발송을 외부 부수 효과로 취급하세요.

멱등성과 승인

에이전트는 안전 장치 없이 루프 안에서 이메일을 보내서는 안 됩니다. 에이전트의 재시도 로직이 같은 트랜잭션 이메일을 고객에게 열 번 보내지 않도록 멱등성 키를 사용하세요. 또한 중요도가 높은 이메일에는 API 호출 전에 사람이 개입하는 승인 단계를 구현하세요.

발송 제공업체 비용 분석

SPF 레코드에 포함할 제공업체를 고를 때는 발송량에 따른 비용을 고려하세요. 2026년 9월 요금 기준입니다.

• Amazon SES: 종량제는 이메일 1,000통당 0.10 USD입니다(Amazon SES 요금). 50,000통은 약 5 USD입니다. 2026년 7월 21일에 도입된 새 요금제로는 Essentials(1,000통당 0.16 USD), Pro(1,000통당 0.22 USD + 리전당 월 105 USD), Enterprise(1,000통당 0.23 USD + 월 500 USD)가 있습니다.
• Postmark: 월 15 USD에 10,000통이며 초과분은 1,000통당 1.80~1.20 USD입니다(Postmark 요금). Postmark 요금제에서 50,000통은 대략 66 USD입니다.
• Resend: 무료 요금제는 월 3,000통(일 100통 제한)입니다. Pro는 월 20 USD에 50,000통이며 초과분은 1,000통당 0.90 USD입니다(Resend 요금).
• Mailgun: 월 15 USD에 10,000통이며 초과분은 1,000통당 1.80~1.10 USD입니다(Mailgun 요금).
• SendGrid: 무료 요금제는 이제 60일 체험판이며 Essentials는 월 19.95 USD부터 시작합니다(SendGrid 요금).

SPF 문제 해결 체크리스트

조회 제한 문제가 의심된다면 다음 체크리스트를 확인하세요.

• 루트 도메인과 모든 발송 하위 도메인에서 DNS 검사를 실행하세요.
• include, a, mx, exists 메커니즘의 총수를 세세요.
• 각 제공업체의 include 체인을 추적해 중첩 조회가 있는지 확인하세요.
• 사용하지 않는 제공업체를 식별하고 제거하세요.
• 트래픽을 전용 하위 도메인(예: notifications.example.com)으로 옮길 수 있는지 평가하세요.
• 제한을 계속 초과한다면 동적 SPF 플래트닝을 구현하세요.
• 최종 레코드가 문자열당 255자 제한을 넘지 않는지 확인하세요.

요약표: SPF 메커니즘

메커니즘 | DNS 조회 | 위험 | 권장 사항

ip4 / ip6 | 아니요 | 낮음 | 고정 IP에 사용

include | 예 | 높음 | 아껴서 사용하고 체인을 모니터링

a | 예 | 중간 | 가능하면 피하고 ip4 사용

mx | 예 | 중간 | 가능하면 피함

ptr | 예 | 높음 | 사용하지 않음(더 이상 권장되지 않음)

SPF 레코드를 선제적으로 관리하면 이메일이 스팸 필터에 도달하기도 전에 전달성을 무너뜨리는 permerror를 피할 수 있습니다. 단순한 API를 쓰든 복잡한 에이전트 시스템을 쓰든, DNS를 간결하게 유지하는 것이 트랜잭션 메일이 수락되도록 하는 가장 좋은 방법입니다.

도메인 인증을 관리하는 전체 도구 모음은 https://sendhq.cc 에서 확인하세요.