SPF DNS 조회 제한 점검과 구성 가이드

SPF DNS 조회 제한은 문제가 생기기 전까지는 대수롭지 않아 보이는 DNS 제약이다. 발신 서비스, CRM, 헬프데스크를 계속 추가하다가 SPF 평가가 프로토콜 제한을 넘을 수 있다. 정상 메일도 필터링되거나 지연되거나 거부될 수 있지만, 모든 수신자가 똑같이 처리하는 것은 아니며 다른 인증 결과도 영향을 준다.

SPF가 전체 구성에서 어떤 역할을 하는지 알고 싶다면 비즈니스 이메일 가이드부터 읽는다. SPF는 브랜드 설정을 마쳤다는 표시가 아니라 해당 도메인에서 발송하도록 허용된 출처인지 판단하는 인증 신호다.

이 가이드는 조회 제한의 의미, 계산 대상, flattening이 유지 관리 없는 해결책이 아닌 이유와 향후 변경에도 관리 가능한 구성을 만드는 방법을 설명한다.

SPF DNS 조회 제한이란?

SPF DNS 조회 제한은 SPF 평가 중 DNS 조회를 일으키는 메커니즘과 수정자의 수를 제한한다. RFC 7208의 제한은 10이며 이를 넘으면 통과 대신 permerror가 반환된다.

즉 SPF에는 평가 예산이 있다. DNS 조회를 일으키는 항목을 10개보다 많이 평가하게 되면 수신 서버는 평가를 중단하고 영구 오류를 반환해야 한다. Gmail만의 특성이 아니라 SPF 규칙이다. 실제 네트워크 DNS 요청 패킷의 개수와 단순히 같은 뜻은 아니다.

RFC 7208에서 계산하는 항목은 include, a, mx, ptr, exists, redirect다. ip4, ip6, all은 이 평가 예산을 사용하지 않는다.

레코드 길이와 조회 비용을 구분해야 한다. 짧은 레코드도 제한을 넘을 수 있고 긴 레코드도 제한 안에 있을 수 있다. 실제 평가 경로에서 어떤 조회 항목을 실행하는지가 중요하다.

어떤 항목이 제한에 포함될까?

SPF DNS 조회 제한은 TXT 레코드의 단어 수가 아니라 관련 조회 메커니즘과 수정자를 계산한다. 평가에서 따라가는 중첩 include도 포함되므로 DNS 화면에 직접 보이는 항목보다 전체 비용이 클 수 있다.

다음 항목은 조회 예산을 사용한다.

include: 다른 도메인의 SPF를 평가하고 해당 평가가 통과하면 일치한다.
a: 호스트 주소 레코드를 연결 IP와 비교한다.
mx: MX 호스트와 해당 주소를 확인하며 별도의 추가 제한도 적용된다.
ptr: 역방향 DNS를 사용하는 방식이며 사용이 권장되지 않는다.
exists: 지정한 DNS A 레코드 조회에 결과가 있는지 확인한다.
redirect: 현재 정책의 어떤 메커니즘도 일치하지 않으면 다른 SPF 정책으로 평가를 넘긴다.

다음 항목은 SPF 평가의 DNS 조회 예산을 사용하지 않는다.

ip4
ip6
all

주의할 점은 재귀 평가다. Microsoft를 include했는데 해당 SPF가 다른 레코드를 참조한다면 실제로 따라간 하위 항목도 같은 예산에 포함된다. 공급자의 SPF 설계와 변경에도 의존하게 된다.

발신자를 6개 추가했다고 생각했지만 재귀 평가 후에는 11개나 12개의 조회 항목이 필요할 수 있다. 직접 보이는 항목은 10개 미만인데도 제한을 넘는 이유다.

성장하는 팀이 제한에 부딪히는 이유

SPF DNS 조회 제한은 메일 호스팅 변경뿐 아니라 도구 추가로 문제가 되기 쉽다. 마케팅, 지원, 채용, CRM, 트랜잭션 발신 서비스가 각각 include를 요청하면 같은 루트 도메인 레코드에 모이기 쉽다.

초기 레코드는 단순할 수 있다. 다음은 설명용 예시이며 게시 전에 공급자의 현재 값과 실제 발신자를 확인한다.

v=spf1 include:_spf.google.com ~all

도구가 늘면 다음처럼 될 수 있다.

v=spf1 include:_spf.google.com include:servers.mcsv.net include:mail.zendesk.com include:spf.hubspot.com include:amazonses.com ~all

이때는 자체 정책뿐 아니라 외부에서 변경될 수 있는 의존 관계를 함께 관리하게 된다.

그래서 운영 중 문제가 갑자기 생긴 것처럼 보일 수 있다. 오늘 자체 DNS는 그대로인데 공급자가 내부 SPF 구조를 바꾸면 어제 통과하던 경로가 오늘 permerror를 반환할 수도 있다.

문제가 SPF보다 넓다면 TrekMail의 메일이 스팸으로 분류되는 이유도 확인한다. 인증, 평판, 콘텐츠와 수신 정책이 함께 영향을 줄 수 있다.

SPF 조회 제한을 넘으면 어떻게 될까?

SPF DNS 조회 제한을 넘으면 평가 결과는 permerror다. 수신자가 모두 같은 처리를 하는 것은 아니지만 SPF 통과 경로를 잃는다.

제한에 거의 맞췄다고 부분 통과를 받는 것은 아니다. 영구 오류를 무시하지 말고 실제 평가 경로를 조사한다.

상태	수신 측 결과	운영 영향
조회 항목 10개 미만	이 평가 제한은 넘지 않음	다른 조건도 충족하면 SPF 통과 가능
조회 항목 10개 초과	Permerror	필터링, 지연, 거부 가능
SPF permerror + DKIM 실패	다른 유효한 정렬 DKIM이 없다면 정렬 인증 경로 없음	DMARC 실패 가능, 실제 처리는 수신 정책에 따름
SPF permerror + DKIM 통과	SPF 오류와 DKIM 통과가 함께 존재	유효한 정렬 DKIM으로 DMARC 통과 가능, 전달 보장은 아님

Google의 현재 지침도 적절한 인증과 정렬을 요구한다. Gmail로 대량 발송한다면 SPF와 DKIM 모두 확인하고 적용 대상 요구사항을 검토한다. Google의 이메일 발신자 지침을 참고한다.

관련된 다른 제한도 알아둔다.

빈 조회 결과. RFC 7208은 void lookup을 두 번으로 제한하도록 권고한다. NXDOMAIN이나 답변이 없는 주소 조회 등이 해당하며 include 오타나 사라진 공급자 도메인이 permerror에 기여할 수 있다.
DNS 응답 크기. 큰 응답은 잘리면서 fallback 처리가 필요할 수 있다. 네트워크나 resolver 문제가 있으면 임시 오류나 시간 초과로 이어질 수 있으나 큰 레코드만으로 실패를 단정할 수는 없다.

SPF flattening이 간단한 해결책만은 아닌 이유

SPF DNS 조회 제한 때문에 include를 IP 주소로 바꾸는 flattening을 선택하기 쉽다. 조회 예산을 줄일 수 있지만 주소의 정확성과 최신성을 유지하는 책임도 떠안는다.

수동 flattening의 예시는 다음과 같다.

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

평가 비용은 낮지만 SaaS 공급자는 IP 범위와 인프라를 바꿀 수 있다. 오래된 레코드는 정상 발신자를 허용하지 않거나 더 이상 필요 없는 IP를 허용할 수 있다. flattening을 사용한다면 신뢰할 만한 갱신과 검증 절차를 둔다.

기존 방식은 모든 공급자를 루트 SPF에 계속 넣고 복잡해질 때마다 flattening하는 것이다.

다른 방법은 기능별 발신을 적절한 하위 도메인으로 나누고 실제 봉투 발신자 도메인의 SPF를 좁게 유지하며 유효한 정렬 DKIM을 구성하는 것이다. 의존 관계를 관리하기 쉬워지고 문제가 생긴 서비스를 구분하는 데도 도움이 될 수 있다.

현재 안내상 TrekMail은 사용자 도메인, IMAP 사서함, catch-all, 마이그레이션, 사서함 전달과 요금제에 따른 자체 또는 관리형 SMTP를 제공한다. 무료 요금제의 자체 SMTP, 유료 요금제의 관리형 SMTP 여부는 최신 조건에서 확인한다. 사용자나 도메인 수가 언제나 무제한이라고 가정하지 않는다. 필수 DNS 레코드와 자체 SMTP 사용을 참고한다.

SPF 조회 제한을 고려한 장기 구성

SPF DNS 조회 제한에는 발신 분리가 장기적인 선택지가 될 수 있다. 일반 업무, 마케팅, 지원, 트랜잭션 발신을 적절히 나눈다. 실제 발신 서비스가 해당 하위 도메인을 MAIL FROM에 사용해야 한다. 표시 From이나 DNS만 바꿔서는 별도 SPF 평가가 생기지 않는다.

가능한 모델은 다음과 같다.

루트 도메인은 사람 간 업무 메일에 사용한다. 예: alice@company.com.
마케팅 하위 도메인. 예: newsletter.company.com.
지원 하위 도메인. 예: support.company.com.
트랜잭션 하위 도메인. 예: updates.company.com.

다음은 예시이며 공급자의 현재 요구사항을 확인한 뒤 조정한다.

company.com TXT "v=spf1 include:_spf.google.com ~all"
newsletter.company.com TXT "v=spf1 include:servers.mcsv.net ~all"
support.company.com TXT "v=spf1 include:mail.zendesk.com ~all"
updates.company.com TXT "v=spf1 include:sendgrid.net ~all"

별도의 SPF 평가에는 각각 10개의 조회 항목 예산이 있다. 실제 봉투 도메인을 나누고 각 중첩 정책이 제한 안에 있어야 공통 실패 지점을 줄이는 데 도움이 된다. DMARC의 relaxed 또는 strict 정렬 조건도 함께 확인한다.

발신 흐름을 구분해 추적할 수도 있지만 평판 방화벽은 아니다. 수신 공급자는 조직 도메인이나 IP 평판을 함께 평가할 수 있어 마케팅의 부적절한 목록 운영이 루트 도메인에 전혀 영향을 주지 않는다고 보장할 수 없다.

새 도메인은 TrekMail의 도메인 추가와 DNS 검증 문서를 참고한다. 공급자를 옮길 때 IMAP 마이그레이션 개요는 사서함 수동 복사를 줄이는 데 도움이 된다. DNS, 앱, 인증이나 평판을 옮기거나 무중단을 보장하지는 않는다.

SPF 조회 비용을 확인하는 방법

SPF DNS 조회 제한은 추측하지 말고 측정한다. 원본 TXT를 가져온 뒤 실제 발신자 평가에서 따라가는 include와 redirect, 중첩 경로를 추적한다.

먼저 dig를 사용한다.

dig txt example.com +short

dig txt _spf.google.com +short

dig txt spf.protection.outlook.com +short

실제 경로에서 조회를 일으키는 항목과 중첩 항목을 계산한다. 일치하면 어디서 평가가 끝나는지도 본다. 모든 단어의 합계가 완전한 평가 결과를 대신하지는 않는다.

실무 절차는 다음과 같다.

실제 봉투 발신자 도메인이나 하위 도메인의 SPF TXT를 가져온다.
모든 include, a, mx, exists, redirect를 기록하고 아직 남은 역방향 조회 방식도 확인한다.
중첩 정책을 따라가며 일치와 오류 결과를 고려해 반복 평가한다.
실제로 더 이상 발송하지 않는 도구를 확인하고 제거한다.
flattening 전에 적절한 봉투 하위 도메인으로 분리할 수 있는지 검토한다.

중복 SPF도 확인한다. 같은 호스트에 서비스별 SPF TXT를 따로 게시하지 말고 하나의 SPF 레코드로 병합한다. TXT 레코드 안에는 여러 문자열이 들어갈 수도 있다. 전체 구성은 도메인 이메일 만들기, 다중 도메인 이메일 호스팅, imapsync를 참고한다.

구성을 정리할 때 TrekMail의 역할

TrekMail도 SPF DNS 조회 제한을 없애지는 못한다. 프로토콜의 규칙이다. 플랫폼은 제한을 고려한 구성을 더 명확하게 관리하는 데 도움을 줄 수 있지만 비용과 계정 수는 요금제와 사용에 달려 있다.

이 점은 서로 다른 사용자에게 중요하다.

개인 창업자와 소규모 팀은 루트 도메인 정책을 단순하게 유지하고 적합한 자체 또는 관리형 SMTP를 선택할 수 있다. 에이전시와 MSP는 고객 발신을 나누고 제공되는 도메인 관리 기능을 활용할 수 있다. 사용자별 요금이 없는 모델도 선택지가 되지만 그 자체가 복잡한 구성을 없애지는 않는다.

기존 방식과 새로운 방식:

기존 방식: 추가 사서함이나 도메인의 비용 때문에 업무 메일, 별칭, 앱 발신자와 마케팅을 한 공급자와 SPF에 모은다.

새 방식: 적합한 다중 도메인 모델로 IMAP 사서함을 중앙 관리하고 실제 봉투 도메인을 기능별로 나누며 공급자가 바뀌어도 SPF를 제한 안에 유지한다.

현재 가격 안내에서 Starter는 월 $3.50부터다. $0 무료 제공 항목에는 10개 도메인, 5GB 공유 저장 공간과 자체 SMTP가 기재되어 있다. 유료 요금제에는 관리형 SMTP, 높은 한도와 추가 자동화가 포함될 수 있다. 최신 조건은 TrekMail 요금에서 확인한다.

결론: SPF 조회 제한을 설계 조건으로 다룬다

SPF DNS 조회 제한은 드문 예외가 아니라 고정된 프로토콜 제약이다. 서비스가 늘어난다면 평가 경로가 제한 안에 있는지 미리 확인한다.

정책이 너무 복잡하다는 것을 permerror가 알려줄 때까지 기다리지 않는다. 발신자를 파악하고 오래된 include를 없애며 적절한 실제 봉투 하위 도메인으로 나눈다. 루트 도메인은 단순하게 유지하고 변경을 테스트하며 모니터링과 롤백 계획을 둔다. 일상 업무 메일의 위험을 줄이는 방법이지 전달 보장은 아니다.

여러 도메인의 운영을 단순화하고 싶다면 TrekMail의 사용자 도메인, IMAP 사서함, 공유 저장 공간, 마이그레이션과 SMTP 기능을 최신 조건으로 평가한다. 적합성과 한도는 요금제에 달려 있다. trekmail.net에서 무료 제공 항목을 확인하거나 trekmail.net/pricing에서 비교한다.