레코드는 필터가 아니라 정책입니다
SPF 자체는 아무것도 차단하지 않습니다. 게시한 레코드는 어떤 IP 와 제공업체에 권한이 있는지 수신 서버에 알리고, 목록에 없는 곳에서 메시지가 도착했을 때의 처리는 각 수신 서버가 결정합니다.
그래서 SPF 레코드 생성기는 정상 메일이 어디에서 오는지, 권한 없는 출처를 얼마나 엄격하게 처리할지 두 가지를 묻습니다.
무료 SPF 도구
SPF 레코드 생성기
도메인의 유효한 v=spf1 TXT 레코드를 만드는 무료 SPF 레코드 생성기입니다. IP 와 제공업체를 추가하고 SPF 정책을 선택한 뒤 SPF 레코드를 복사하세요. 가입할 필요가 없으며 일반적인 SPF 사용에는 요청 한도가 없습니다.
SPF 레코드 생성
이 도메인으로 메일을 보낼 권한이 있는 IPv4 또는 IPv6 주소를 추가하세요.
Google Workspace나 SendGrid 같은 타사 발신 서비스를 추가하세요.
SPF 레코드 생성기가 만드는 것
SPF 레코드는 봉투 발신자에 도메인을 사용해 메일을 보낼 수 있는 모든 출처를 나열한 하나의 TXT 레코드입니다. 이 무료 SPF 레코드 생성기는 해당 목록을 수신 서버가 요구하는 정확한 구문으로 변환하므로, 일 년에 두 번 쓸까 말까 한 문법을 직접 작성할 필요가 없습니다.
수신 서버는 메일 수신 시 SPF 레코드를 읽고 연결 IP 와 비교한 뒤 선택한 한정자를 적용합니다. SPF 레코드 생성기는 메커니즘을 일반적인 순서로 배치하고 레코드가 DNS 조회 10 회 한도를 넘지 않게 합니다.
생성기가 출력하는 SPF 레코드 구문
생성기가 출력할 수 있는 모든 SPF 메커니즘과 SPF 레코드 안에서 각 메커니즘이 허용하는 항목입니다.
- ip4:x.x.x.x — 단일 IPv4 주소를 허용합니다
- ip4:x.x.x.x/24 — IPv4 CIDR 범위를 허용합니다
- ip6:::1 — IPv6 주소를 허용합니다
- include:domain.com — 다른 도메인의 SPF 레코드를 가져옵니다(타사 발신자에 사용)
- a — 도메인의 A 레코드 IP를 허용합니다
- mx — 도메인의 MX 레코드 IP를 허용합니다
all 한정자 선택하기
마지막 SPF 메커니즘은 SPF 레코드에 없는 모든 발신자를 어떻게 처리할지 결정합니다. 가입 없이 SPF 레코드 생성기를 사용할 수 있으므로 정책을 조정하는 동안 원하는 만큼 레코드를 다시 만들 수 있습니다.
| 한정자 | 동작 |
|---|---|
| +all | 모든 발신자가 통과합니다. 절대 사용하지 마세요. SPF를 완전히 무력화합니다. |
| ~all | Softfail — 허용되지 않은 메일은 수락하되 표시합니다. 테스트 중에 사용하세요. |
| -all | Hard fail — 허용되지 않은 메일은 거부합니다. 운영 환경에서 사용하세요. |
| ?all | Neutral — 정책이 없습니다. 거의 유용하지 않습니다. |
자주 쓰는 제공업체 include
다음 서비스를 통해 메일을 보낸다면 해당 SPF include 를 생성기에 붙여 넣으세요. 각 include 는 자체 SPF 조회를 추가합니다.
- Google Workspace: include:_spf.google.com
- Microsoft 365: include:spf.protection.outlook.com
- Mailchimp: include:servers.mcsv.net
- SendGrid: include:sendgrid.net
- Mailgun: include:mailgun.org
10 회 조회 한도
SPF 를 평가할 때 include:, a, mx, ptr, exists: 메커니즘은 각각 DNS 조회 1 회를 사용하며, RFC 7208 은 총 조회 수를 10 회로 제한합니다. 이를 초과하면 수신 서버가 permerror 를 반환하고, 많은 서버가 이를 SPF 가 전혀 없는 것처럼 처리합니다. 이 SPF 레코드 생성기는 SPF 출력을 단순하게 유지하고 레코드가 한도를 넘기 전에 경고합니다.
SPF는 DKIM, DMARC와 함께 쓸 때 가장 효과적입니다
SPF만으로는 봉투 발신자(Return-Path)를 보호하며, 표시되는 From 주소는 보호하지 않습니다. 스푸핑을 완전히 막으려면 메시지에 서명하는 DKIM과 인증 결과를 From 헤더에 맞추는 DMARC도 필요합니다. 이 세 표준이 함께 Gmail, Outlook, Yahoo Mail이 기대하는 이메일 인증 기준을 이룹니다.
SPF를 설정한 뒤에는 목록도 깨끗하게 유지하세요. 이메일 검증 은 발송 전에 유효하지 않거나 위험한 주소를 제거하여 반송률을 낮추고, 올바른 인증으로 쌓은 발신자 평판을 보호합니다. 주소는 대량 이메일 검증 으로 한꺼번에 검증하거나 이메일 검증 API로 스택에 검증을 직접 연동할 수도 있습니다.
레코드가 나타내는 내용
SPF 레코드 생성기가 실제로 만드는 것
SPF 레코드는 봉투에 도메인을 사용해 메일을 보낼 수 있는 모든 출처를 나열한 하나의 TXT 문자열입니다. 무료 SPF 레코드 생성기는 문법을 외우지 않아도 이 정책 결정을 올바른 구문으로 변환해 줍니다.
메커니즘은 허용된 발신자를 나타냅니다
ip4 와 ip6 는 직접 관리하는 특정 주소나 CIDR 범위를 허용합니다. include:는 제공업체의 SPF 레코드에 권한 관리를 위임하므로 Google, Microsoft, Mailchimp, SendGrid, Mailgun 이 인프라를 변경해도 올바른 상태가 유지됩니다.
a 와 mx 는 도메인의 A 또는 MX 레코드가 가리키는 대상을 허용합니다. SPF 레코드 생성기는 일반적인 경우 평가가 일찍 끝나도록 이를 관례적인 순서로 출력합니다.
all 한정자가 전체 정책을 결정합니다
-all 은 hard fail 로, 목록에 없는 모든 출처를 권한 없음으로 처리합니다. ~all 은 soft fail 로, 보통 거부하는 대신 의심스러운 것으로 처리합니다. ?all 은 neutral 이며 아무것도 강제하지 않습니다.
기본값으로 곧바로 -all 을 적용하는 무료 SPF 레코드 생성기는 도움이 되지 않습니다. 먼저 ~all 을 게시해 무엇이 실패하는지 살핀 뒤 정책을 강화하세요. 이 생성기는 이러한 이유로 세 가지 옵션을 모두 제공합니다.
DNS 조회 10 회는 엄격한 상한입니다
include:, a, mx, ptr, exists: 메커니즘은 각각 DNS 조회 1 회를 사용하며, SPF 사양은 평가를 10 회로 제한합니다. 한도를 넘으면 수신 서버가 permerror 를 반환하고, 많은 서버가 이를 SPF 가 전혀 없는 것처럼 처리합니다.
직접 작성한 레코드가 아무런 신호 없이 작동을 멈추는 가장 흔한 원인입니다. SPF 레코드 생성기는 출력을 단순하게 유지하고 레코드가 문제가 될 만큼 길어지기 전에 경고합니다.
레코드 읽기
생성된 SPF 레코드의 각 부분이 의미하는 것
출력은 처음부터 끝까지 읽을 만큼 짧습니다. 각 토큰의 역할을 알면 나중에 전송을 중단시키지 않고 레코드를 수정할 수 있습니다.
v=spf1 — 버전 태그
모든 SPF 레코드는 v=spf1 로 시작하며, 이 값이 없는 TXT 레코드는 SPF 레코드가 아닙니다. 도메인마다 SPF 레코드는 하나만 존재할 수 있습니다. 레코드를 두 개 게시하면 병합되지 않고 permerror 가 발생합니다.
SPF 레코드 생성기의 출력으로 기존 레코드를 교체하려면 두 레코드를 모두 게시하지 말고 메커니즘을 직접 병합하세요.
include: — 제공업체에 위임
include:_spf.google.com 은 Google 이 현재 허용하는 대상을 가져옵니다. Google 의 변경 사항을 자동으로 반영하는 동시에, 해당 DNS 조회 비용도 10 회 조회 한도에 포함됩니다.
실제로 도메인을 사용해 메일을 보내는 제공업체만 include 에 추가하세요. 사용하지 않는 include 는 아무 이득 없이 조회 한도만 소모합니다.
ip4 / ip6 — 자체 인프라
직접 운영하는 메일 서버에는 이를 사용하세요. DNS 조회를 사용하지 않으므로 발신 출처가 많을 때 한도 안에 머무는 가장 경제적인 방법입니다.
CIDR 표기법을 지원하므로 전체 범위를 주소 목록 대신 하나의 메커니즘으로 나타낼 수 있습니다.
~all 또는 -all — 나머지 출처의 처리 방식
마지막 메커니즘은 수신 서버가 가장 중요하게 적용하는 항목입니다. 모든 정상 발신 출처가 목록에 있는지 확인하는 동안에는 ~all 로 시작하고, 일주일간 보고서에 문제가 없으면 -all 로 전환하세요.
잊힌 발신자가 있는 도메인에 곧바로 -all 을 적용하는 것은 실제 메일을 잃는 가장 빠른 방법입니다.
레코드 게시
무료 SPF 레코드 생성기에서 실제 DNS 레코드까지
네 단계로 진행되며, 대부분의 사람은 세 번째 단계에서 너무 일찍 멈춥니다.
- 1
생성하기 전에 모든 발신자를 나열하세요
마케팅 플랫폼, 트랜잭션 메일 제공업체, CRM, 지원 데스크, 청구 시스템, 수년간 아무도 손대지 않은 사내 메일 서버까지 도메인을 사용해 메일을 보내는 모든 시스템을 레코드에 포함해야 합니다.
목록을 모두 완성한 뒤 무료 SPF 레코드 생성기를 실행하세요. 목록의 절반만으로 만든 레코드는 나머지 절반의 메일을 중단시킵니다.
- 2
도메인 루트에 TXT 레코드 하나를 게시하세요
호스트는 @ 또는 루트 도메인, 유형은 TXT, 값은 생성된 문자열입니다. 전파에는 보통 몇 분, 간혹 한 시간 정도 걸립니다.
SPF 유형의 레코드로 게시하지 마세요. 이 레코드 유형은 수년 전에 폐기되었으며 수신 서버가 무시합니다.
- 3
실제로 조회되는 값을 확인하세요
DNS 제공업체는 긴 TXT 값을 예상치 못한 방식으로 줄바꿈하거나 분할하고 잘라내기도 합니다. 전파가 끝나면 SPF 검사기로 게시된 레코드를 확인하세요. 무료 SPF 레코드 생성기가 만든 값과 DNS 가 실제로 제공하는 값이 항상 같지는 않습니다.
DNS 패널에서는 올바르게 보여도 실제 조회 결과가 잘못된 경우가 흔하며, 직접 조회하기 전에는 알아차릴 수 없습니다.
- 4
정책은 한 번, 신중하게 강화하세요
일주일 동안 정상 메일 실패가 없으면 ~all 을 -all 로 바꾸고 다시 게시하세요. 이때부터 SPF 가 도메인을 실질적으로 보호하기 시작합니다.
발신 제공업체를 추가하거나 제거할 때마다 DNS 패널에서 실제 문자열을 직접 편집하지 말고 SPF 레코드 생성기를 다시 실행하세요.
한계
SPF 가 하지 않는 것
SPF 는 세 가지 발신자 인증 레코드 중 하나입니다. 다른 두 가지 역할까지 기대할 때 대부분의 잘못된 설정이 시작됩니다.
SPF 는 포워딩 후 유지되지 않습니다
메시지가 포워딩되면 봉투 발신자는 그대로지만 전송 IP 는 포워더의 IP 로 바뀝니다. 따라서 완전히 정상적인 메일도 SPF 검사에 실패합니다.
이것이 바로 DKIM 이 존재하는 이유이며, DMARC 가 정렬된 상태에서 둘 중 하나만 통과해도 인정하는 이유입니다.
SPF 는 표시되는 From 주소를 검사하지 않습니다
SPF 는 수신자가 볼 수 없는 봉투 발신자를 인증합니다. 메시지는 원하는 From 주소를 표시하면서도 SPF 를 통과할 수 있습니다.
표시되는 도메인을 인증된 도메인과 연결하는 것은 DMARC 뿐입니다. SPF 만으로는 사용자가 알아차릴 만한 스푸핑을 막을 수 없습니다.
SPF 는 수신자를 검증하지 않습니다
완벽한 레코드를 게시해도 발송 대상 주소가 존재하는지는 알 수 없습니다. 발신자 인증과 수신자 검증은 서로 다른 문제입니다.
수신자 측에서는 캠페인 전에 이메일 검증기 또는 대량 검증을 사용하고, 두 작업을 같은 발송 워크플로의 별도 단계로 다루세요.
SPF 는 평판을 개선하지 않습니다
올바른 SPF 레코드는 전송 성공률을 높이기 위한 전제 조건이지 직접적인 원인은 아닙니다. 콘텐츠, 신고율, 반송률이 여전히 받은편지함 배치를 결정합니다.
먼저 레코드를 올바르게 설정한 다음 나머지를 개선하세요.
참고 자료와 다음 단계
사양과 관련 도구
SPF 는 IETF 에서 정의하며, 이 SPF 레코드 생성기와 함께 제공되는 도구는 SPF 가 수행하지 않는 검사를 담당합니다.
RFC 7208 이 구문을 정의합니다
IETF의 RFC 7208 은 SPF, 메커니즘, 한정자와 이 SPF 레코드 생성기가 지키도록 돕는 10 회 조회 평가 한도를 정의합니다.
레코드를 게시하기 위해 반드시 읽을 필요는 없지만, 한정자의 의미에 관한 모든 논쟁은 이 문서로 해결할 수 있습니다.
게시한 내용을 확인하세요
게시한 뒤에는 SPF 검사기 가 실제 레코드를 조회해 조회 횟수, 구문 오류, 적용되는 정책을 알려 줍니다.
여기서 생성하고 검사기에서 확인하세요. 이 조합은 생성기가 볼 수 없는 DNS 패널의 값 변형을 찾아냅니다.
인증 체계를 완성하세요
SPF 는 전체 인증 체계의 3 분의 1 입니다. DMARC 생성기 와 DKIM 도구는 정렬과 메시지 서명을 담당합니다.
SPF 는 있지만 DMARC 가 없는 도메인은 인증되어 있어도 From 줄에서 여전히 스푸핑될 수 있습니다.
무료 기능 살펴보기
유료 AI 기능과 함께 계정 없이 사용할 수 있는 19 가지 무료 도구를 제공합니다.
무료 도구
SPF 체커
무료 SPF 레코드 검사기로 모든 도메인의 실제 SPF 레코드를 해석하고 DNS 조회 횟수와 구문을 검증하십시오. 가입이 필요 없습니다.
도메인 또는 인프라 증거이며, 메일박스 증명은 아닙니다.
무료 도구
DKIM 생성기
무료 DKIM 레코드 생성기로 모든 제공업체용 v=DKIM1 TXT 레코드와 selector._domainkey 호스트 이름을 만드세요. 가입 없이 무료로 이용할 수 있습니다.
무료 도구
DMARC 생성기
무료 DMARC 레코드 생성기로 정책, 정렬, 보고 태그를 포함한 유효한 v=DMARC1 TXT 레코드를 몇 초 만에 만드세요. 가입 없이 무료로 이용할 수 있습니다.
무료 도구
DNS 체커
모든 도메인의 A, AAAA, MX, TXT, NS, CNAME, SOA DNS 레코드를 권한 있는 네임서버에서 실시간으로 무료 조회하십시오. 가입이 필요 없습니다.
이메일 도구
이메일 전달성 테스트
무료 이메일 전달률 테스트: 메시지 하나를 보내 인증, DNS, 스팸 필터, 블랙리스트, 헤더, 콘텐츠 점수를 확인하세요. 가입 없이 이용하는 무료 인박스 배치 테스트입니다.
발신자 또는 메시지 진단이며, 주소 탐색이 아닙니다.
이메일 검증 도구
이메일 검증기
가입 없이 무료 이메일 검증기로 이메일 주소의 유효성을 확인하세요 — 구문, MX, SMTP 메일박스, 일회용, 역할 및 catch-all 검사.
수신자 증거이며, 발신자나 DNS 설정이 아닙니다.
자주 묻는 질문
1. 무료 SPF 레코드 생성기는 정말 무료인가요?
예. 가입이나 계정이 필요 없고 만들 수 있는 SPF 레코드 수에도 제한이 없습니다. SPF 로직은 페이지 안에서만 실행되며 도메인이나 SPF 설정 정보는 저장되지 않습니다.
2. SPF 레코드 생성기가 만든 레코드는 어디에 게시하나요?
도메인 루트에 TXT 레코드로 게시하세요. 호스트는 @ 또는 루트 도메인, 유형은 TXT, 값은 생성된 문자열로 설정합니다. 더 이상 사용되지 않는 SPF 레코드 유형은 수신 서버가 무시하므로 사용하지 마세요. 전파에는 보통 몇 분이 걸립니다.
3. SPF 레코드를 두 개 둘 수 있나요?
아니요. 도메인마다 SPF 레코드는 하나만 있어야 합니다. 레코드 두 개를 게시하면 permerror 가 발생하며 수신 서버는 이를 병합하지 않습니다. 기존 레코드가 있다면 두 번째 레코드를 게시하지 말고 기존 메커니즘을 SPF 레코드 생성기의 입력에 합치세요.
4. ~all 과 -all 중 무엇을 사용해야 하나요?
~all 로 시작하세요. 권한 없는 메일을 거부하지 않고 의심스러운 것으로 표시하므로, 아무도 기억하지 못한 발신 출처를 일주일 동안 찾을 수 있습니다. 정상 메일이 모두 통과하는 것을 확인한 뒤 -all 로 전환하세요. 처음부터 -all 을 적용하는 무료 SPF 레코드 생성기는 실제 메일 손실을 초래할 수 있습니다.
5. 게시한 뒤 SPF 레코드가 작동하지 않는 원인은 무엇인가요?
주된 원인은 두 가지입니다. 제공업체 include 를 계속 추가해 DNS 조회 10 회를 넘기는 경우와 DNS 패널이 긴 TXT 값을 분할하거나 잘라내는 경우입니다. 제공업체가 바뀌면 무료 SPF 레코드 생성기를 다시 실행하고, 이후 SPF 검사기로 실제 레코드를 확인하세요.
6. SPF 레코드가 스푸핑을 막아 주나요?
SPF 만으로는 막을 수 없습니다. SPF 는 사용자가 볼 수 없는 봉투 발신자를 인증합니다. 표시되는 From 도메인을 인증된 도메인과 연결하는 것은 DMARC 뿐이므로, SPF 를 SPF, DKIM, DMARC 라는 세 단계 중 첫 단계로 보세요.