도메인에 유효한 SPF TXT 레코드를 만드세요. IP 주소, 메일 서버, 타사 발신자를 추가하면 게시할 정확한 DNS 값을 얻을 수 있습니다.
이 도메인으로 메일을 보낼 권한이 있는 IPv4 또는 IPv6 주소를 추가하세요.
Google Workspace나 SendGrid 같은 타사 발신 서비스를 추가하세요.
SPF(Sender Policy Framework) 레코드는 도메인을 대신해 이메일을 보낼 권한이 있는 메일 서버를 지정하는 DNS TXT 레코드입니다. 수신 서버가 귀하의 도메인에서 온 것으로 주장하는 메시지를 받으면 SPF 레코드를 조회하여 발신 IP가 목록에 있는지 확인합니다. IP가 허용되지 않은 경우 메시지가 거부되거나 스팸으로 표시될 수 있습니다.
SPF는 DKIM, DMARC와 함께 이메일 인증의 세 가지 기반 표준 중 하나입니다. SPF가 없으면 누구나 봉투 발신자 필드에 귀하의 도메인을 위조할 수 있어 피싱과 스푸핑 공격의 대상이 됩니다. 대부분의 최신 메일함 제공업체와 기업 메일 게이트웨이는 메일을 수락하기 전에 SPF를 확인합니다.
모든 SPF 레코드는 버전을 선언하는 v=spf1로 시작합니다. 그다음 허용된 발신자를 나열하는 메커니즘을 추가합니다. 레코드는 all 메커니즘이라고 하는 한정자로 끝납니다.
SPF 레코드 끝의 한정자는 허용되지 않은 발신자의 메일을 수신 서버가 어떻게 처리할지 결정합니다.
| 한정자 | 동작 |
|---|---|
| +all | 모든 발신자가 통과합니다. 절대 사용하지 마세요. SPF를 완전히 무력화합니다. |
| ~all | Softfail — 허용되지 않은 메일은 수락하되 표시합니다. 테스트 중에 사용하세요. |
| -all | Hard fail — 허용되지 않은 메일은 거부합니다. 운영 환경에서 사용하세요. |
| ?all | Neutral — 정책이 없습니다. 거의 유용하지 않습니다. |
타사 이메일 서비스를 사용하는 경우 include: 지시문으로 해당 서비스의 허용된 발신 도메인을 추가해야 합니다. 가장 많이 쓰이는 항목은 다음과 같습니다.
SPF는 평가 중 DNS 조회를 10회로 엄격히 제한합니다. include:, a, mx 메커니즘은 각각 조회로 계산됩니다. 많은 타사 SPF 레코드는 내부적으로 추가 조회를 유발합니다. 총 조회가 10회를 초과하면 SPF 평가는 PermError를 반환하며 이는 실패로 처리됩니다. 한도를 지키려면 가능한 한 직접 IP 주소를 사용하고 중첩된 include 체인을 피하세요.
SPF만으로는 봉투 발신자(Return-Path)를 보호하며, 표시되는 From 주소는 보호하지 않습니다. 스푸핑을 완전히 막으려면 메시지에 서명하는 DKIM과 인증 결과를 From 헤더에 맞추는 DMARC도 필요합니다. 이 세 표준이 함께 Gmail, Outlook, Yahoo Mail이 기대하는 이메일 인증 기준을 이룹니다.
SPF를 설정한 뒤에는 목록도 깨끗하게 유지하세요. 이메일 검증 은 발송 전에 유효하지 않거나 위험한 주소를 제거하여 반송률을 낮추고, 올바른 인증으로 쌓은 발신자 평판을 보호합니다. 주소는 대량 이메일 검증 으로 한꺼번에 검증하거나 이메일 검증 API로 스택에 검증을 직접 연동할 수도 있습니다.
실제 발신자부터 구성
SPF 레코드는 봉투 발신자 도메인의 권한 목록입니다. 생성기는 그 목록을 형식화할 수 있지만, 목록은 도메인으로 메일을 보내는 모든 시스템의 정확한 목록에서 시작해야 합니다.
워크스페이스 제공업체, 트랜잭션 메일 서비스, 마케팅 플랫폼, 지원 데스크, CRM, 그리고 MAIL FROM 또는 HELO에 이 도메인을 사용하는 모든 서버를 나열하세요. 출처가 빠지면 잘못된 SPF 실패가 생기고, 더 이상 쓰지 않는 출처를 남기면 권한이 필요 이상으로 넓어집니다.
해당 제공업체가 실제로 귀하를 대신해 발송할 때만 제공업체가 지정한 include 도메인을 사용하세요. 다른 회사의 SPF 레코드를 복사하거나, 익숙해 보인다는 이유로 메커니즘을 추가하지 마세요.
생성된 값은 v=spf1로 시작하며 DNS TXT 레코드 하나에 넣습니다. 같은 이름에 v=spf1 레코드가 두 개이면 영구 평가 오류가 발생합니다. 허용된 모든 출처를 하나의 정책으로 합치세요.
SPF는 봉투 발신자 도메인에서 평가되며, 이는 표시되는 From 도메인이 아니라 return-path 서브도메인일 수 있습니다. 루트에 게시하기 전에 제공업체가 사용하는 도메인을 확인하세요.
메커니즘과 한정자
각 메커니즘은 메일이 어디서 출발할 수 있는지를 답합니다. 마지막 한정자는 어느 메커니즘에도 맞지 않는 발신자를 수신측이 어떻게 분류해야 하는지를 나타냅니다.
ip4와 ip6는 추가 DNS 조회 없이 지정된 주소나 네트워크를 허용합니다. include는 수신측이 다른 도메인의 SPF 정책을 평가하도록 하여 제공업체가 자체 인프라를 유지할 수 있게 하지만, 재귀 DNS 작업을 더합니다.
a와 mx 메커니즘은 DNS에서 해석된 주소를 허용합니다. 편리할 수 있지만, 메일을 보내도록 의도되지 않은 시스템에 쓰이는 레코드까지 정책을 넓힐 수 있습니다.
~all은 일치하지 않는 출처를 softfail로, -all은 fail로 표시합니다. 어느 쪽도 모든 수신측이 메시지를 전달하거나 거부하도록 강제하지 않습니다. 수신측은 SPF를 DKIM, DMARC, 평판, 콘텐츠, 로컬 정책과 함께 봅니다.
+all을 게시하지 마세요. 인터넷의 모든 출처를 허용하여 SPF 레코드가 제공하려던 보호를 없앱니다.
안전하게 게시
생성은 초안 단계로 보세요. 검증과 관찰이 변경을 완성합니다.
필요한 각 IP 주소와 제공업체 include를 추가하고, 중복을 제거한 뒤, 도입 단계용으로 신중한 한정자를 선택하고, 스마트 따옴표나 줄 바꿈 없이 전체 TXT 값을 복사하세요.
봉투 발신자 도메인에 TXT 레코드를 만들거나 교체하세요. DNS 제어판은 호스트 이름을 다르게 표시하므로, 제공업체가 @, 루트 도메인, 또는 서브도메인 레이블만 기대하는지 확인하세요.
공개 DNS가 파싱 가능한 정책을 하나만 반환하는지 SPF 검사기로 확인하세요. 그런 다음 모든 정상 플랫폼으로 발송하고 한정자를 강화하기 전에 Authentication-Results를 검사하세요.
SPF는 한 번 설정하고 잊어버리는 배지가 아니라 운영 설정입니다. 벤더, return path, IP 범위, 메일 아키텍처가 바뀌면 레코드를 업데이트하고, 더 이상 필요 없는 권한은 제거하세요.
생성기가 증명할 수 없는 것
구문이 깨끗한 레코드를 완전한 이메일 인증으로 오해하지 않도록 이 경계를 분명히 하세요.
이 도구는 모든 출처가 공개되었는지, 중첩 include가 유효한지, 실제 메일이 사용하는 신원에 레코드가 게시되었는지를 알 수 없습니다. 공개 DNS와 메시지 헤더 테스트는 여전히 필요합니다.
include, a, mx, exists, redirect와 그 재귀 종속성은 DNS 조회를 소모할 수 있습니다. 짧아 보이는 정책도 중첩된 제공업체 레코드를 평가한 뒤 한도를 초과하여 permerror를 반환할 수 있습니다.
완벽한 SPF 결과는 수신자 메일함이 존재하는지를 말해 주지 않습니다. 발신자 인증과 수신자 검증을 분리하려면 발송 전에 이메일 검증기를 사용하세요.
권위 있는 참고 자료
생성기는 SPF 표준의 용어를 따르며, 관련 검사는 별도 도구로 유지합니다.
IETF의 RFC 7208은 TXT 게시, 메커니즘, 수정자, 한정자, 재귀 평가, 처리 한도를 정의합니다. 제공업체 안내가 일반적인 설정 조언과 충돌할 때 표준을 사용하세요.
실제 정책을 SPF 레코드 검사기로 확인하고, 서명 키는 DKIM 레코드 생성기로 게시하며, 정렬과 보고는 DMARC 레코드 생성기로 추가하세요.
다음 도구를 증거 유형으로 고르십시오. 수신자, 주소 탐색, DNS와 인프라, 또는 발신자 워크플로입니다.
무료 도구
모든 도메인의 SPF 레코드를 확인하고 검증합니다. 전체 SPF 레코드, 메커니즘 분석, 올바른 구성 여부를 확인하십시오. 무료, 가입 불필요.
도메인 또는 인프라 증거이며, 메일박스 증명은 아닙니다.
무료 도구
도메인과 셀렉터에 맞는 DKIM DNS 레코드 형식을 만듭니다. 이메일 인증용 TXT 호스트와 값을 준비하는 무료 도구입니다.
도메인 또는 인프라 증거이며, 메일박스 증명은 아닙니다.
무료 도구
정책, 정렬, 보고 옵션으로 DMARC DNS TXT 레코드를 만듭니다. 도메인 이메일 인증용 무료 생성기입니다.
도메인 또는 인프라 증거이며, 메일박스 증명은 아닙니다.
무료 도구
모든 도메인의 A, AAAA, MX, TXT, NS, CNAME 레코드를 확인하십시오. 실시간 DNS 조회로 즉시 결과를 확인합니다. 무료이며 가입이 필요 없습니다.
도메인 또는 인프라 증거이며, 메일박스 증명은 아닙니다.
이메일 도구
실제 메시지 샘플로 이메일 전달성 테스트를 실행하세요. SPF, DKIM, DMARC, DNS, 블랙리스트, 스팸 필터, 헤더, 콘텐츠 증거를 검토합니다.
발신자 또는 메시지 진단이며, 주소 탐색이 아닙니다.
이메일 검증 도구
구문, MX, SMTP 메일박스, 일회용, 역할, Catch-All 검사를 실행하는 무료 이메일 검증기로 이메일 주소가 유효한지 확인하세요.
수신자 증거이며, 발신자나 DNS 설정이 아닙니다.
SPF는 Sender Policy Framework의 약자입니다. 도메인 소유자가 자신을 대신해 이메일을 보낼 수 있는 메일 서버를 지정할 수 있게 하는 DNS 기반 이메일 인증 방식입니다. SPF가 없으면 어떤 서버든 귀하의 도메인에서 메일을 보낸다고 주장할 수 있어 피싱이 매우 쉬워집니다. ISP와 스팸 필터는 이메일 전달 여부를 결정할 때 SPF 결과를 주요 신뢰 신호로 사용합니다.
이 도구로 SPF 레코드를 생성한 다음 DNS 제공업체에 로그인해 도메인 루트(보통 @ 또는 루트 도메인)에 생성된 값으로 TXT 레코드를 추가하세요. 변경 사항은 보통 30분 이내에 전파되지만, 전 세계적으로는 최대 48시간이 걸릴 수 있습니다.
~all(softfail)은 목록에 없는 IP의 이메일이 의심스럽지만 수락해야 한다고 수신 서버에 알립니다. -all(hardfail)은 목록에 없는 발신자를 거부하거나 강하게 감점하라고 지시합니다. SPF를 처음 설정할 때는 ~all을 사용하고, 모든 발신 서비스가 목록에 있다고 확신하면 -all로 전환하세요.
아니요. 도메인에는 SPF 레코드가 정확히 하나여야 합니다. 같은 도메인에 v=spf1로 시작하는 TXT 레코드가 두 개 있으면 SPF 평가는 영구 오류가 되어 모든 메일이 SPF 검사에 실패합니다. 모든 메커니즘을 하나의 레코드로 합치세요.
SPF는 DNS를 조회하는 메커니즘(include, a, mx, ptr, exists)의 총합을 평가당 10회로 제한합니다. 이 한도를 초과하면 permerror가 발생합니다. include를 신중히 세세요. 많은 제공업체가 한도에 각각 포함되는 중첩 include를 연쇄적으로 사용합니다.
SPF는 봉투 발신(MAIL FROM) 주소만 인증하며, 수신자에게 보이는 From 헤더는 인증하지 않습니다. SPF가 통과해도 공격자는 From 헤더를 스푸핑할 수 있습니다. 수신함에 보이는 도메인 스푸핑을 완전히 막으려면 SPF와 DKIM 모두에 정렬된 DMARC 정책이 필요합니다.
