SPF 레코드 검사기 및 생성기

SPF 레코드를 검사하는 방법

1. 위 입력란에 도메인을 입력합니다. 전체 이메일 주소를 입력해도 됩니다. 도구는 도메인 부분만 사용합니다.
2. “SPF 레코드 검사”를 클릭합니다. 검사기는 공개 DNS에서 현재 레코드를 읽습니다. 수신 서버가 읽는 것과 같은 레코드입니다.
3. 먼저 요약을 확인합니다. 레코드가 유효한지, 경고가 있는지, 오류가 있는지 알려 줍니다.
4. 문제가 있으면 문제 목록을 확인합니다. 각 항목에 무엇을 바꿔야 하는지 나와 있습니다.
5. 그 아래에는 레코드의 각 부분에 대한 설명과 각 부분이 사용하는 DNS 조회 횟수가 나옵니다. include를 열면 그 뒤에 있는 서비스가 허용하는 내용을 볼 수 있습니다.

주소창의 링크를 열면 같은 SPF 검사가 다시 실행됩니다. 이 링크를 동료나 DNS 호스팅 업체에 보낼 수 있습니다. 한계가 하나 있습니다. 수신 서버는 메일을 보낸 서버의 IP 주소를 기준으로 SPF를 확인합니다. 이 SPF 분석 도구에는 확인할 메일이 없으므로 레코드 자체를 검사합니다. 발신 서버마다 값이 바뀌는 SPF 매크로로 만든 부분은 평가할 수 없습니다.

SPF 레코드란?

SPF 레코드는 도메인의 DNS에 있는 TXT 레코드입니다. 그 도메인의 이메일을 보낼 수 있는 서버를 나열합니다. SPF는 Sender Policy Framework의 약자이며, 규칙은 RFC 7208에 정의되어 있습니다. Google Workspace를 사용하는 도메인에는 다음과 같은 레코드가 있는 경우가 많습니다.

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

v=spf1은 이 레코드가 SPF 레코드임을 나타냅니다. include:_spf.google.com은 Google 자체 목록에 있는 모든 서버를 허용합니다. ~all은 그 밖의 서버에서 온 메일을 의심스러운 메일로 처리하라고 수신 서버에 알립니다.

메일이 도착하면 수신 서버는 Return-Path라고 부르는 반송 주소에서 도메인을 가져옵니다. 그 도메인의 SPF 레코드를 읽고, 발신 서버의 IP 주소가 목록에 있는지 확인합니다. SPF는 받은편지함에 보이는 보낸 사람(From) 주소를 확인하지 않습니다. 그래서 SPF는 DKIM, DMARC와 함께 작동합니다. 세 가지의 관계는 SPF, DKIM, DMARC 설명을 참고하십시오.

2024년 2월부터 Gmail은 모든 발신자에게 SPF 또는 DKIM을 요구합니다. 대량 발신자에게는 둘 다 요구합니다. Yahoo도 같은 규칙을 적용합니다.

SPF 레코드 각 부분의 의미

SPF 레코드는 공백으로 구분한 항목의 목록입니다. 수신 서버는 왼쪽부터 오른쪽으로 읽고, 발신 서버와 처음 일치하는 항목에서 멈춥니다.

어느 부분이든 앞에 한정자를 붙여 일치할 때의 결과를 정할 수 있습니다. +는 통과(pass)를 뜻하며 기본값이라 보통 적지 않습니다. 나머지는 - 실패(fail), ~ 소프트 실패(softfail), ? 중립(neutral)입니다. 그래서 같은 all이라도 레코드 끝은 -all, ~all, ?all처럼 달라집니다.

이름은 대소문자를 구분하지 않으므로 Include:도 include:와 똑같이 작동합니다. RFC 7208은 모든 레코드를 all 또는 redirect로 끝내라고 권장합니다. 둘 다 없으면 목록에 없는 서버는 중립(neutral) 결과를 받습니다.

DNS 조회 10회 한도

include, a, mx, ptr, exists, redirect는 각각 수신 서버가 DNS 조회를 한 번 하게 만듭니다. RFC 7208이 허용하는 횟수는 모두 합쳐 10회입니다. include 안의 조회도 세기 때문에 include 하나가 조회를 여러 번 사용할 수 있습니다. ip4, ip6, all은 조회를 사용하지 않습니다. 레코드에 10회를 넘는 조회가 필요하면 수신 서버는 처리를 멈추고 permerror를 반환하며, SPF는 실패합니다.

이 한도에는 쉽게 도달합니다. 자주 쓰는 include가 사용하는 조회 횟수를 실제 DNS에서 측정한 결과, Google Workspace 1회, Microsoft 365 1회, Salesforce 2회, Mailgun 5회, Freshdesk 7회였습니다. Google Workspace를 쓰는 회사가 Mailgun과 Freshdesk를 추가하면 그것만으로 조회가 13회 필요합니다. .com, .net, .org, .se 도메인의 SPF 레코드를 조사한 2024년 연구에서는 6.5%가 10회를 넘는 조회를 필요로 했습니다. 이 사례의 83.7%는 호스팅 업체 단 두 곳의 레코드를 include한 것이 원인이었습니다.

조회 횟수는 바뀌기도 합니다. Google의 include는 2025년 12월까지 조회 4회를 사용했습니다. 그달 Google은 중첩된 include를 하나의 목록으로 바꿨습니다. 일부 SPF 가이드와 생성기는 아직도 4회라고 적고 있습니다. 위 검사기는 실행할 때마다 실제 횟수를 셉니다.

한도를 넘는다고 모든 메일이 실패하는 것은 아닙니다. Microsoft가 지적하듯이 수신 서버는 처음 일치하는 항목에서 멈춥니다. 앞쪽에 적힌 서버에서 보낸 메일은 통과할 수 있지만, 뒤쪽에 적힌 서버에서 보낸 메일은 실패합니다. 그래서 문제가 무작위로 생기는 것처럼 보입니다. 레코드 전체의 조회 횟수를 세어 보십시오.

한도가 하나 더 있습니다. 아무것도 찾지 못한 조회를 빈 조회(void lookup)라고 합니다. 예를 들어 더 이상 존재하지 않는 도메인을 include한 경우입니다. RFC 7208은 빈 조회가 2회를 넘으면 수신 서버가 처리를 멈춰야 한다고 합니다.

DNS 조회를 10회 이내로 줄이는 방법

1. 더 이상 사용하지 않는 서비스의 include를 삭제합니다.
2. 서비스가 더 이상 요구하지 않는 include를 삭제합니다. Mailchimp, Postmark, Brevo, Klaviyo는 메인 도메인에 include가 필요하지 않고, SendGrid와 Amazon SES는 include를 하위 도메인에 둡니다. 목록은 아래에 있습니다.
3. 자체 서버는 a나 mx 대신 ip4와 ip6로 적습니다. RFC 7208은 이 방식을 권장하며, IP 주소는 조회를 사용하지 않습니다.
4. 일부 메일은 news.example.com 같은 하위 도메인에서 보냅니다. 하위 도메인마다 별도의 레코드가 있고, 각각 조회 10회를 따로 사용할 수 있습니다.

일부 서비스는 include를 그 뒤에 있는 IP 주소로 바꾸는 SPF 평탄화(flattening)를 제공합니다. 조회 횟수는 줄지만, 서비스 업체가 주소를 바꿔도 평탄화한 레코드는 따라 바뀌지 않습니다. Microsoft는 IP 범위가 안정적이고 문서로 공개된 서비스만 평탄화하고, Microsoft 365 자체는 평탄화하지 말며, 적어도 분기에 한 번 결과를 확인하라고 권고합니다.

Google Workspace, Microsoft 365 등 서비스별 SPF include

각 서비스의 설정 가이드에 나온 include 값과 각 값이 사용하는 DNS 조회 횟수입니다. 횟수는 2026년 10월 12일에 실제 DNS에서 측정했습니다. 서비스를 설정할 때는 해당 서비스의 가이드에서 값을 복사하십시오. 일부 값은 지역이나 계정에 따라 다릅니다.

HubSpot은 계정마다 hubspotemail.net으로 끝나는 고유한 include를 제공합니다. HubSpot 이메일 설정에서 복사하십시오. 조회 1회를 사용합니다.

보통 include가 필요 없는 서비스

SPF는 보낸 사람(From) 주소가 아니라 반송 주소를 기준으로 확인합니다. 요즘 많은 발신 서비스는 자체 반송 주소나, 사용 중인 도메인의 하위 도메인을 사용합니다. 이런 서비스의 include를 메인 도메인에 넣으면 아무 효과 없이 조회 횟수만 소모합니다.

• Mailchimp. 현재 Mailchimp의 도메인 설정은 SPF가 아니라 DKIM과 DMARC 레코드만 요구합니다.
• Postmark. Postmark는 SPF가 더 이상 필요하지 않다고 안내합니다. Postmark 자체 반송 주소나, Postmark를 가리키도록 설정한 Return-Path 레코드로 메일을 보냅니다.
• Brevo. Brevo는 전용 IP 주소에서 보내는 경우가 아니면 SPF가 필요하지 않다고 안내합니다.
• Klaviyo. Klaviyo는 보통 SPF 레코드를 추가할 필요가 없다고 안내합니다.
• SendGrid. SendGrid의 도메인 인증은 em1234.yourdomain.com처럼 SendGrid가 만들어 주는 하위 도메인에 SPF를 설정합니다.
• Amazon SES. SES에서는 bounce.yourdomain.com 같은 사용자 지정 MAIL FROM 하위 도메인에만 SPF가 필요합니다. 기본적으로는 SES 자체 반송 주소를 사용합니다.

검사기는 레코드에서 이런 include를 찾으면 알려 줍니다.

SPF 레코드를 만드는 방법

위의 “생성” 탭에서 SPF 레코드를 만들 수 있습니다. 메일을 보내는 서비스를 선택하면 SPF 레코드 생성기가 레코드를 작성하고 조회 횟수를 셉니다. 도메인에 이미 레코드가 있으면 먼저 불러오십시오. 그러면 기존 레코드를 대체하지 않고 내용을 추가할 수 있습니다. 그 과정은 다음과 같습니다.

1. 도메인 이름으로 이메일을 보내는 서비스를 모두 적습니다. 메일함 서비스만이 아니라 뉴스레터, CRM, 헬프데스크, 청구, 웹사이트 양식까지 생각하십시오. DMARC 보고서를 보면 잊고 있던 발신자를 찾을 수 있습니다.
2. 각 서비스의 include를 설정 가이드에서 찾거나 도구에서 선택합니다. 자체 메일 서버는 IP 주소를 사용합니다.
3. 끝부분을 ~all과 -all 중에서 고릅니다. 차이는 다음 섹션에서 설명합니다.
4. 도메인 자체에 TXT 레코드 하나로 게시합니다. 대부분의 DNS 호스팅 업체에서는 이 이름을 @로 표시합니다. v=spf1으로 시작하는 레코드가 이미 있으면 두 번째 레코드를 추가하지 말고 기존 레코드를 수정합니다.
5. 몇 분 기다린 뒤 SPF 검사기로 도메인을 다시 검사합니다.

하위 도메인은 상위 도메인의 레코드를 사용하지 않으므로, 메일을 보내는 이름마다 별도의 레코드가 필요합니다. 메일을 전혀 보내지 않는 도메인이나 하위 도메인에도 v=spf1 -all 레코드를 두십시오. RFC 7208은 이를 널리 확립된 모범 사례라고 합니다. 이렇게 하면 다른 사람이 그 이름으로 SPF를 통과하는 메일을 보낼 수 없습니다. 영국 NCSC는 이런 도메인에 p=reject DMARC 레코드와 null MX 레코드도 추가하라고 권합니다.

255자를 넘는 레코드는 같은 TXT 레코드 안에서 여러 문자열로 나눠야 합니다. 수신 서버는 문자열을 공백 없이 이어 붙이므로, 공백은 문자열 사이가 아니라 문자열 안에 넣으십시오. DNS 호스팅 업체가 긴 값을 어떻게 처리하는지 확인하십시오.

~all과 -all: 어떤 끝부분을 써야 할까

대형 서비스 업체들의 의견은 서로 다르며, 각자 이유가 있습니다.

• Google은 ~all을 권장합니다.
• 대형 메일 서비스 제공업체와 발신자가 회원으로 있는 업계 단체 M3AAWG는 레코드를 ~all로 끝내야 한다고 합니다. 또한 DMARC 확인이 끝나기 전에는 SPF fail을 이유로 메일을 거부하지 말라고 수신 서버에 요청합니다.
• Microsoft는 DKIM과 DMARC도 설정되어 있다면 -all을 권장합니다.

-all의 위험은 일부 수신 서버가 DMARC를 확인하기 전, 전송 도중에 메일을 거부한다는 점입니다. 2026년 DMARC 표준인 RFC 9989는 이런 메일이 DMARC 보고서에 나타나지 않는다고 설명합니다. 그래서 문제를 찾기가 더 어려워집니다.

실제로는 메일을 보내는 도메인에는 ~all이 더 안전한 선택입니다. 아직 모든 발신자를 찾고 있는 단계라면 특히 그렇습니다. DMARC 정책이 quarantine이나 reject라면, 실패한 메일의 처리는 어차피 DMARC가 결정합니다. 메일을 전혀 보내지 않는 도메인에는 -all을 사용하십시오. 모든 서버를 통과시키는 +all은 절대 사용하지 말고, 레코드가 없는 것과 같은 ?all도 피하십시오.

SPF 검사 결과의 의미

수신 서버는 SPF 검사 결과를 자체 용어로 표시합니다. 이 용어는 spf=pass, spf=softfail처럼 메일 헤더에 나타나며, DMARC 보고서에도 나타납니다.

흔한 SPF 레코드 오류와 해결 방법

2023년에 인기 도메인 1,200만 개를 조사한 결과, 56.5%에 SPF가 있었고, SPF 레코드의 2.9%에 오류가 있었습니다. 가장 흔한 오류는 SPF 레코드가 없는 이름을 가리키는 include나 redirect였습니다. 두 번째로 흔한 오류는 조회 횟수 초과였습니다.

한 도메인에 SPF 레코드가 2개 있음

새 서비스의 설정 가이드에 “이 TXT 레코드를 추가하십시오”라고 적혀 있어, 기존 레코드 옆에 새 레코드를 추가하면 자주 생깁니다. 레코드가 2개이면 permerror가 발생합니다. 하나로 합치십시오. v=spf1을 하나만 맨 앞에 두고, 모든 include와 IP 주소를 나열한 뒤, 끝에 all을 하나만 적습니다.

아무것도 가리키지 않는 include

include가 SPF 레코드가 없는 도메인을 가리키면 레코드 전체가 permerror로 실패합니다. 오타일 수도 있고, 서비스가 종료되었거나 include를 바꾼 경우일 수도 있습니다. 삭제하거나 서비스의 현재 값으로 바꾸십시오.

끝이 +all, ?all이거나 all이 없음

+all은 인터넷의 모든 서버를 허용하므로 레코드가 아무것도 보호하지 않습니다. ?all을 쓰거나 all이 아예 없으면 중립(neutral) 결과가 나오고, 수신 서버는 이를 레코드가 없는 것처럼 취급합니다. 레코드 끝을 ~all 또는 -all로 바꾸십시오.

레코드 안의 ptr

RFC 7208은 ptr을 사용하지 말라고 합니다. 느리고, 조회를 1회 사용하며, DNS에 문제가 있을 때 다른 메커니즘보다 신뢰도가 떨어집니다. ptr이 대상으로 삼던 서버를 ip4와 ip6 항목으로 바꾸십시오.

입력 실수

콜론 뒤의 공백, 일부가 빠진 IPv4 주소, SPF에 없는 단어는 모두 permerror를 일으킵니다. 눈에 잘 띄지 않는 실수도 있습니다. 등호를 쓴 include=example.com은 알 수 없는 설정으로 읽혀 무시되므로, 그 서비스는 허용되지 않습니다. 검사기는 이런 실수를 모두 알려 줍니다.

SPF 가이드가 자주 틀리는 세 가지

• “SPF 레코드에는 대문자를 쓸 수 없다.” RFC 7208에 따르면 이름은 대소문자를 구분하지 않습니다.
• “SPF 레코드는 최대 255자다.” 255자 한도는 문자열 하나마다 적용됩니다. 더 긴 레코드는 여러 문자열로 나눕니다. RFC 7208이 요구하는 것은 DNS 응답 전체를 약 450바이트 미만으로 작게 유지하는 것뿐입니다.
• “include는 10개까지 쓸 수 있다.” 이 한도는 DNS 조회 횟수에 적용되며, include 안의 조회도 셉니다.

SPF는 발신 도메인 인증의 한 부분

SPF 통과에는 한계가 있습니다. 같은 2023년 조사에서 도메인의 34.7%가 100,000개가 넘는 IP 주소에서 오는 메일을 허용했습니다. 또한 누군가 메일을 전달하면 전달 서버가 레코드에 없으므로 SPF가 실패합니다.

DKIM은 메일 자체에 서명하므로 보통 전달된 뒤에도 유효합니다. DMARC는 SPF 또는 DKIM이 보낸 사람(From) 주소와 같은 도메인으로 통과했는지 확인하고, 둘 다 통과하지 못했을 때 어떻게 처리할지 수신 서버에 알려 줍니다. 많은 발신 서비스는 자체 반송 도메인으로 SPF를 통과하는데, 이 도메인은 보낸 사람 주소와 일치하지 않습니다. 서비스에서 사용자 지정 Return-Path를 설정하면 해결됩니다. 나머지 두 레코드는 DKIM 생성기와 DMARC 생성기로 설정하고, MX 레코드 조회로 도메인이 메일을 받는 곳을 확인하십시오.

인증은 존재하지 않는 주소에도 도움이 되지 않습니다. 그런 주소로 보낸 메일은 반송되며, 반송률이 높으면 이메일 도달률이 떨어집니다. 주소 하나는 이메일 유효성 검사로, 리스트 전체는 대량 이메일 검증으로 확인하십시오. 팀과 공유할 짧은 정의는 용어집의 SPF 레코드 항목을 참고하십시오.