무료 SPF 레코드 생성기를 찾아 Google Workspace, Mailchimp, CRM 등 모든 항목을 선택한 뒤 결과를 DNS에 바로 붙여 넣었습니다. 이 주 후 Gmail이 청구서를 550 5.7.26으로 거부하고 Outlook은 550 5.7.515를 반환합니다. 지원 요청이 쌓입니다.
SPF 레코드 생성기가 구문상 유효한 결과를 제공했지만 실제로 작동하는 레코드를 제공한 것은 아닙니다. 바로 이 간극에서 전달 가능성 문제가 생깁니다. 전체 DNS 구성을 아직 갖추는 중이라면 도메인에 이메일을 설정하는 방법부터 확인하세요. SPF는 MX, DKIM, DMARC를 아우르는 더 큰 구성의 일부입니다.
이 가이드에서는 자동 생성기가 실제 운영 환경에서 실패하는 이유, 이미 갖춘 도구로 결과를 오 분 안에 검사하는 방법, 운영에 적합한 SPF 레코드의 형태를 설명합니다.
SPF 레코드 생성기가 실제로 하는 일
SPF 레코드 생성기는 선택한 항목에 따라 제공업체별 include: 메커니즘을 이어 붙여 TXT DNS 레코드를 만드는 웹 도구입니다. 발신자를 선택하면 문자열을 얻습니다. 하지만 실제 DNS를 조회하거나 재귀 조회를 세지 않으며 도메인에 이미 SPF 레코드가 몇 개 있는지도 알지 못합니다.
대부분의 무료 SPF 레코드 생성기는 문자열 조합 도구에 가깝습니다. 실제 DNS 환경에서 작동하는지 확인하지 않고 올바르게 보이는 결과를 만듭니다. 구문이 정확하다는 것과 운영상 정확하다는 것은 다릅니다.
모든 SPF 레코드 생성기가 놓치는 3가지 실패 유형
운영 환경에서 발생하는 주요 SPF 실패는 세 가지 문제 중 하나로 이어집니다. 일반적인 생성기는 실제 DNS 데이터나 수신자가 평가에 사용하는 조회 계산 방식에 접근하지 못하므로 이 문제를 볼 수 없습니다.
1. 중복 레코드로 인한 PermError
도메인에는 SPF 레코드가 정확히 하나 있어야 합니다. RFC 7208에 따르면 수신 서버가 v=spf1로 시작하는 TXT 레코드 두 개를 찾으면 영구 실패인 PermError를 반환합니다. Gmail과 Yahoo는 PermError를 SPF가 없는 경우와 비슷하게 처리할 수 있습니다. 메일이 반송되거나 조용히 스팸으로 분류됩니다.
생성기는 기존 레코드를 확인하지 않습니다. 도메인을 몇 달 이상 사용했다면 등록기관, 이전 호스팅 업체 또는 삼 년 전에 Google Workspace를 설정한 사람이 만든 레코드가 이미 있을 가능성이 큽니다. 확인 없이 생성 결과를 게시하면 중복이 생기며, 잘 작동하던 설정을 망가뜨릴 수 있습니다.
2. 재귀 조회 한도
RFC 7208은 SPF 평가를 정확히 DNS 조회 10회로 제한합니다. 모든 include:, a, mx, exists, redirect와 각 include가 유발하는 중첩 조회가 포함됩니다. SPF 레코드 생성기는 선택한 메커니즘은 세지만 그 내부 항목까지 계산하지는 않습니다.
| 선택한 제공업체 | 생성기 계산 | 실제 조회 |
|---|---|---|
| Google Workspace | 1 | 4 (중첩된 _netblocks.google.com 등) |
| Zendesk | 1 | 2-3 |
| Mailchimp | 1 | 2 |
| Salesforce | 1 | 2-3 |
| 합계 | 4 | 10-12 → PermError |
생성기에는 조회 4회로 표시되지만 수신 서버는 #11에서 중단합니다. 도메인의 모든 메시지가 SPF에 실패합니다. 화면에 경고가 없고 반송 이메일도 없을 수 있습니다. 화가 난 고객의 연락으로 알게 됩니다.
3. 빈 조회 한도 (RFC 7208 §11.1)
결과가 비어 있는 DNS 조회(NXDOMAIN)는 2회를 넘을 수 없다는 추가 제한도 있습니다. include:의 오타 하나가 빈 조회를 만듭니다. 이런 오류가 두 개면 생성기의 구문 검사를 통과했더라도 SPF 레코드 전체가 실패합니다.
예:
include:spf.trekmaill.net(추가 'l'). 구문상 유효하므로 SPF 레코드 생성기는 올바르다고 표시합니다. 수신 서버가 조회했지만 아무것도 찾지 못합니다 - 빈 조회 #1입니다. 잘못된 include가 두 번째로 나오면 레코드 전체가 실패합니다.
배포 전 SPF 레코드 생성기 결과 검사 방법
생성 결과를 게시하기 전에 실제 DNS에 다음 세 가지 검사를 수행하세요. 오 분이면 생성기가 놓친 중복 레코드, 과도한 조회 깊이, 잘못된 구문을 확인할 수 있습니다. macOS, Linux, Windows 명령 프롬프트에서 사용할 수 있습니다.
1단계: 기존 레코드 확인
DNS를 변경하기 전에 다음 명령을 실행하세요.
nslookup -type=txt yourdomain.comv=spf1로 시작하는 줄이 두 개라면 중복입니다. 새 내용을 게시하기 전에 수동으로 하나의 레코드에 통합하세요.
# Broken - two records, PermError guaranteed:
"v=spf1 include:_spf.google.com -all"
"v=spf1 include:spf.trekmail.net -all"
# Fixed - merged into one:
v=spf1 include:_spf.google.com include:spf.trekmail.net -all2단계: 재귀 조회 계산
레코드의 각 include:에 대해 내용을 조회하세요.
dig +short txt _spf.google.com결과:
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"include:_spf.google.com 하나가 실제 조회 4회를 유발합니다. 모든 제공업체에 대해 반복하고 합산하세요. 합계가 10을 넘으면 구조를 바꿔야 합니다. 일반적으로 거래 이메일을 더 짧은 자체 레코드가 있는 하위 도메인(send.yourdomain.com)으로 옮깁니다.
3단계: 메커니즘 검사
SPF 레코드 생성기가 만든 문자열을 다음 표와 비교하세요.
| 메커니즘 | 상태 | 조치 |
|---|---|---|
ptr | 더 이상 권장되지 않음 | 삭제 - RFC 7208은 사용을 명시적으로 권장하지 않습니다. 느리고 신뢰하기 어렵습니다. |
+all | 안전하지 않음 | 삭제 - 인터넷의 모든 발신자에게 도메인으로 보낼 권한을 줍니다. |
ip4: 1.2.3.4 | 잘못된 구문 | 공백을 삭제하세요. ip4:1.2.3.4여야 합니다. |
?all | 취약함 | 피하기 - 중립 정책은 스푸핑 방지 기능을 제공하지 않습니다. |
~all | 허용 가능 | SoftFail - 마이그레이션 중에만 사용하고 영구 설정으로 두지 마세요. |
-all | 올바름 | HardFail - 허용되지 않은 발신자를 거부합니다. 운영 환경에서 사용하세요. |
SPF 구문 점검 목록
첫 초안에 SPF 레코드 생성기를 사용했든 문자열을 직접 작성했든 DNS를 변경하기 전에 이 목록을 확인하세요. 중복 레코드, 재귀 조회 한도, 안전하지 않은 정책 표시처럼 생성기가 찾지 못하는 모든 실패 유형을 다룹니다.
- 도메인마다 레코드 하나. 중복이 있으면 통합하고 두 개를 게시하지 마세요.
v=spf1로 시작. 변형 없이 정확한 문자열을 사용하세요.-all또는~all로 끝남.+all또는?all은 사용하지 마세요.- IP를 include 앞에 배치.
ip4:와ip6:메커니즘은 DNS 조회를 전혀 사용하지 않습니다 - 빠른 평가를 위해 앞에 두세요. - 자기 참조 금지.
include:yourdomain.com은 무한 반복을 만듭니다. 삭제하세요. - 수동 IP 평면화 금지. 자동화로 최신 상태를 유지하는 경우만 예외입니다. Google이 IP를 변경할 때 업데이트하지 않으면 메일이 조용히 실패합니다.
- 전체 조회 ≤ 10. 중첩 include를 포함해 모두 계산하세요.
운영에 적합한 레코드:
v=spf1 ip4:192.0.2.1 include:spf.trekmail.net include:_spf.google.com -allIP를 먼저 배치하고(조회 비용 없음), include를 그다음에 두며 끝에는 hard fail을 둡니다. 이것이면 충분합니다.
대행사와 중소기업이 SPF 레코드 생성기를 벗어나는 이유
SPF 레코드 생성기는 발신자 한두 개를 사용하는 단일 도메인에는 적합합니다. 수십 고객을 관리하는 대행사나 전체 SaaS 도구를 사용하는 중소기업처럼 규모를 늘리는 순간, 전체 도메인의 조회 횟수와 중복 레코드를 중앙에서 파악할 수 없어 반복적인 운영 위험이 됩니다.
기존 방식에서는 고객마다 다른 생성 세션으로 고유한 SPF 레코드를 만들고 검사 기록은 남지 않습니다. 한 도메인이 조회 한도에 도달해도 누군가 알아차리기까지 사흘이 흐릅니다. 고객의 전달 평판이 피해를 입습니다.
기업 수준에서 이메일 인프라를 보호하는 전체 방법은 기업 이메일 보안 가이드를 참조하세요. SPF를 넘어 필요한 기본 구성을 다룹니다.
TrekMail이 SPF 생성기 문제를 줄이는 방법
SPF의 복잡성은 여러 외부 발신자를 관리하면서 조회 한도 10회 이내를 유지하는 데서 생깁니다. TrekMail은 기본 메일 인프라에서 두 문제를 줄여 핵심 발신 도메인에 SPF 레코드 생성기를 실행하거나 중첩 조회를 계산하고 메커니즘을 검사할 필요를 없앱니다.
중소기업용: Include 하나, 유지보수 없음
TrekMail Starter 요금제(월 $3.50)에서는 발신 이메일을 TrekMail 관리형 SMTP로 전달합니다. SPF 레코드는 한 줄이 됩니다.
v=spf1 include:spf.trekmail.net -allTrekMail은 이 include 뒤에서 IP 교체와 발신자 평판을 관리합니다. TrekMail 자체를 위해 레코드를 다시 수정할 필요는 대체로 없습니다. 생성기 세션이 필요 없고 육 개월 뒤 새 SaaS 도구를 추가할 때 조회 검사도 줄어듭니다.
대행사용: 모든 고객에 템플릿 하나
기존 방식은 고객 100명, 서로 다른 생성기 실행 100회에서 나온 SPF 레코드 100개이며 각각 재귀 조회 위험이 있습니다. 어느 레코드든 경고 없이 실패할 수 있습니다.
TrekMail 방식은 모든 고객 도메인에 템플릿 하나를 사용합니다.
v=spf1 include:spf.trekmail.net -allAgency 요금제(월 $23.25)에서는 하나의 대시보드에서 도메인 1,000+개를 관리합니다. 기업 메일에 TrekMail을 표준화하면 핵심 통신 채널의 재귀 조회 문제를 없앨 수 있습니다. 다중 도메인 구성을 확장한다면 다중 도메인 이메일 호스팅이 관리 방식을 어떻게 바꾸는지 확인하세요.
SPF와 함께 TrekMail에 필요한 전체 DNS 설정 - MX, DKIM, DMARC - 은 필수 DNS 레코드 문서에서 네 가지 모두 확인할 수 있습니다.
SPF 레코드 생성기 FAQ
첫 SPF 레코드 생성기 세션이 작동하지 않는 레코드를 만든 뒤 자주 나오는 질문입니다. 모두 생성기가 확인하는 구문 검증과 실제 DNS 검사가 필요한 운영 검증 사이의 차이에서 비롯됩니다.
두 생성기로 결과를 교차 확인할 수 있나요?
가능하지만 두 번째 SPF 레코드 생성기도 핵심 문제를 해결하지는 않습니다. 서로 다른 도구가 서로 다른 문자열을 줄 수 있으며, 실제 DNS의 중복 레코드를 찾거나 재귀 조회를 정확히 계산하지 못할 수 있습니다. 위의 CLI 절차가 더 신뢰할 수 있는 검사입니다.
생성기는 레코드가 유효하다고 합니다. 메일이 반송되는 이유는?
SPF 레코드 생성기에서 "유효"하다는 것은 구문이 정확하다는 뜻이지 환경에서 작동한다는 뜻은 아닙니다. 이런 차이의 가장 흔한 두 원인은 PermError를 일으키는 중복 레코드와 10회를 넘는 재귀 조회입니다. 둘 다 화면상의 검증이 아니라 실제 DNS 검사가 필요합니다.
-all과 ~all은 언제 사용하나요?
운영 환경에서는 -all(HardFail)을 사용해 허용되지 않은 발신자를 즉시 거부하세요. 모든 발신자를 등록했는지 확실하지 않은 마이그레이션 기간에만 ~all(SoftFail)을 사용하세요. 임시 상태이지 최종 설정이 아닙니다. ?all 또는 +all을 기본값으로 쓰는 생성기는 실제 전달 가능성보다 "작동해 보이는" 결과에 초점을 둔 것입니다.
간단한 요약
무료 SPF 레코드 생성기는 문자열 초안을 만드는 합리적인 시작점이지만 운영 환경의 최종 단계로는 부족합니다. 생성기가 놓치는 중복 레코드, 재귀 조회 초과, 빈 조회 오류라는 세 가지 실패 유형은 조용한 반송과 PermError를 일으켜 진단에 몇 시간이 걸릴 수 있습니다.
해결책은 더 나은 생성기가 아니라 오 분짜리 CLI 검사입니다. 중복 레코드를 확인하고 중첩 조회를 계산하며 메커니즘을 점검한 뒤 게시하세요.
생성 과정을 완전히 건너뛰고 싶다면 TrekMail은 발신 이메일을 include: 하나로 통합합니다. DNS 한 줄이면 되며 조회 계산이나 PermError 진단이 필요 없습니다.
14일 무료 평가판을 시작하세요 - 신용카드가 필요하며 언제든 취소할 수 있습니다.
