SPF 레코드란 무엇인가요?
SPF 레코드(Sender Policy Framework, RFC 7208)는 도메인 이름으로 이메일을 보낼 수 있는 서버 목록을 담은 TXT 레코드입니다. 메시지가 도착하면 수신 서버는 봉투 발신자 도메인(눈에 보이는 From 주소가 아니라 Return-Path)의 SPF 레코드를 조회해 발송 IP가 목록에 있는지 확인합니다.
한 도메인에는 SPF 레코드가 하나만 있어야 합니다. v=spf1로 시작하는 레코드가 두 개 있으면 모든 SPF 검사가 PermError로 실패하므로, 새 서비스를 추가할 때는 레코드를 하나 더 만들지 말고 기존 레코드를 수정하세요. 2024년 2월부터 Gmail과 Yahoo는 모든 발신자에게 SPF 또는 DKIM을, 대량 발신자에게는 SPF, DKIM, DMARC를 모두 요구합니다.
SPF 레코드 생성 방법
메일함 제공업체, 뉴스레터와 트랜잭션 메일 서비스, 헬프데스크, CRM, 그리고 도메인으로 메일을 보내는 모든 서버와 웹사이트를 적어 보세요. 하나를 빠뜨리는 것이 SPF 실패의 가장 흔한 원인입니다.
위에서 각 제공업체를 선택하고, 다른 include 도메인을 추가한 뒤, 자체 서버를 IPv4 또는 IPv6 주소로 입력하세요. mx는 수신 메일 서버가 발송도 할 때만 사용하세요.
보통은 ~all(소프트 실패)로 시작합니다. 목록이 완전하다고 확신하면 -all(실패)로 바꾸세요. 조회 카운터를 계속 확인하세요: 반드시 10 이하로 유지되어야 합니다.
호스트 @(또는 메일을 보내는 하위 도메인)에 TXT 레코드로 추가하고, 기존 v=spf1 레코드가 있으면 교체하세요. 그런 다음 SPF 검사기로 확인하세요.
Advertisement
SPF 레코드 구문 설명
SPF 레코드는 왼쪽에서 오른쪽으로 읽는 항목 목록입니다. 발송 IP와 처음으로 일치하는 항목이 결과를 결정합니다.
버전 태그입니다. 반드시 첫 번째 항목이어야 하며, 수신 서버는 이 태그를 보고 TXT 레코드를 SPF로 인식합니다.
include:_spf.google.com처럼 다른 도메인의 SPF 레코드에 있는 모든 것을 승인합니다. 그 레코드 안의 조회도 모두 내 제한에 포함됩니다.
ip4:203.0.113.10이나 ip6:2001:db8::/48처럼 주소 하나 또는 CIDR 범위를 승인합니다. DNS 조회가 들지 않습니다.
도메인의 A/AAAA 레코드 IP 또는 MX 호스트의 IP를 승인합니다. 편리하지만 각각 조회 1회가 들고, mx는 내부적으로 최대 10번의 쿼리가 더 필요할 수 있습니다.
나머지 모든 서버를 어떻게 처리할지 정합니다: 소프트 실패, 실패, 중립. 누구나 내 도메인으로 메일을 보낼 수 있게 하는 +all은 절대 게시하지 마세요.
redirect=는 검사 전체를 다른 도메인의 레코드에 넘깁니다. exists:는 일부 대량 발신자가 매크로와 함께 사용합니다. ptr는 느리며, RFC 7208은 게시하지 말라고 권고합니다.
~all vs -all: 소프트 실패와 실패 중 무엇을 쓸까?
-all은 목록에 없는 서버에서 온 메일이 SPF에 실패했다고 수신 서버에 알리며, 많은 서버가 이런 메일을 거부합니다. ~all은 소프트 실패로 표시합니다: 이것만으로 거부해서는 안 되지만 의심스러운 메일로 다룰 수는 있습니다. ?all은 중립이며 아무런 보호도 제공하지 않습니다.
Google의 Workspace 안내는 ~all을, Microsoft의 Microsoft 365 예시는 -all을 사용합니다. 둘 다 작동합니다. DMARC를 게시하면 실패한 메일의 처리는 DMARC 정책(p=quarantine 또는 p=reject)이 결정하므로, 많은 도메인이 정상적인 전달(forwarding) 메일을 거부하지 않도록 ~all을 유지하고 차단은 DMARC에 맡깁니다. 도메인에서 이메일을 전혀 보내지 않는다면 v=spf1 -all을 게시하세요.
Advertisement
SPF 레코드 예시
내 환경과 가장 비슷한 예시를 복사하거나 위 생성기로 직접 만드세요. 각 예시는 도메인에 게시하는 TXT 레코드 하나입니다.
v=spf1 include:_spf.google.com ~allv=spf1 include:spf.protection.outlook.com -allv=spf1 ip4:203.0.113.10 include:_spf.google.com include:mailgun.org ~allv=spf1 include:zohomail.com ~allv=spf1 mx ip4:198.51.100.0/24 ip6:2001:db8::/48 -allv=spf1 -allDNS 조회 10회 제한
RFC 7208은 SPF 검사 한 번에 DNS 조회를 10회로 제한합니다. include, a, mx, ptr, exists, redirect는 각각 1회로 계산되고, include한 레코드 안에 있는 이런 항목도 모두 계산됩니다. ip4, ip6, all은 조회가 들지 않습니다. 11번째 조회가 필요한 검사는 PermError로 중단되며, DMARC에서는 이를 SPF 실패로 간주합니다. 또한 수신 서버는 Void 조회를 2회(존재하지 않거나 레코드를 반환하지 않는 이름)까지만 허용해야 합니다.
제공업체마다 드는 조회 수가 다릅니다. 2026년 10월 5일에 중첩 조회를 포함해 각 include를 직접 계산한 결과입니다:
_spf.google.com과 spf.protection.outlook.com은 IP 범위를 직접 나열합니다. Amazon SES, Brevo, Mailjet, Zendesk, Fastmail도 1회입니다.
각각 자체 레코드를 하나 더 가리킵니다.
호스팅 메일함은 여러 include를 연쇄적으로 연결하는 경우가 많습니다.
이 중 하나에 다른 서비스 몇 개만 더해도 한도를 모두 쓸 수 있습니다.
Advertisement
조회가 너무 많은 SPF 레코드 수정 방법
더 이상 쓰지 않는 서비스를 제거하세요. 예전 뉴스레터 도구와 체험 계정이 주범인 경우가 많습니다.
자체 서버의 주소가 고정되어 있다면 `a`와 `mx`를 `ip4`/`ip6`로 바꾸세요.
대량 메일은 하위 도메인으로 옮기세요. news.example.com처럼 자체 SPF 레코드와 별도의 10회 조회 한도를 갖는 하위 도메인을 사용합니다.
서비스에 include가 정말 필요한지 확인하세요. 많은 발송 서비스가 자체 반송(bounce) 도메인을 사용하므로 SPF는 그쪽 도메인에서 통과하고, DMARC 정렬은 DKIM으로 맞춰집니다.
SPF 평탄화(flattening)는 신중하게 사용하세요. include를 복사한 IP 목록으로 바꾸면 당장은 작동하지만, 제공업체가 IP를 바꾸는 순간 아무 경고 없이 메일이 실패하기 시작합니다.
흔한 SPF 실수
같은 도메인에 SPF 레코드가 두 개(예: 제공업체마다 하나씩) 있는 경우. 하나로 합치세요.
인터넷 전체를 승인하는
+all사용.잘못된 이름에 레코드 게시. SPF는 봉투 발신자 도메인에서 검사되며, 하위 도메인은 이를 상속받지 않습니다.
all뒤에 메커니즘 추가. 수신 서버는 이를 평가하지 않으므로 해당 발신자는 승인되지 않습니다.문의 양식 메일을 보내는 웹 서버처럼 발신자 하나를 빠뜨리는 경우.
예전 SPF 레코드 유형(유형 99) 사용. RFC 7208에서 폐지되었으므로 TXT로만 게시하세요.
Advertisement
SPF, DKIM, DMARC는 함께 작동합니다
SPF만으로는 수신자가 보는 From 주소의 위조를 막을 수 없습니다. DKIM은 각 메시지에 서명하고, DMARC는 두 결과를 눈에 보이는 From 도메인과 연결해 실패했을 때 수신 서버가 어떻게 처리할지 알려 줍니다. 세 가지를 모두 설정하세요: