인증과 DNS

SPF 레코드

SPF 레코드는 도메인에 두는 텍스트 한 줄로, 그 도메인의 메일을 보낼 수 있는 서버를 나열합니다. 받는 쪽 서버는 이 레코드를 확인해, 내 도메인에서 왔다고 주장하는 메일이 실제로 내 서버에서 보내졌는지 확인합니다.

최종 업데이트 2026년 11월 4일

SPF 레코드란?

SPF 레코드는 도메인에 두는 텍스트 한 줄로, 그 도메인의 메일을 보낼 수 있는 서버를 나열합니다. SPF는 Sender Policy Framework의 약자입니다. RFC 7208에 정의되어 있습니다.

먼저 몇 가지 용어를 설명합니다. 도메인이란 이메일 주소에서 @ 뒤에 오는 이름으로, example.com 같은 것입니다. 서버란 메일을 보내거나 받는 컴퓨터입니다. DNS는 도메인이 자신의 설정을 공개하는 공개 디렉터리입니다. 각 설정을 레코드라고 합니다. SPF 레코드는 DNS TXT 레코드, 즉 일반 텍스트를 담는 DNS 레코드입니다.

간단한 SPF 레코드는 다음과 같은 형태입니다.

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

각 부분에는 뜻이 있습니다.

v=spf1: 이것이 SPF 레코드라는 뜻입니다.
include:_spf.google.com: Google이 나열한 모든 서버가 이 도메인의 메일을 보낼 수 있다는 뜻입니다.
-all: 다른 모든 서버에서 온 메일을 거부하라는 뜻입니다.
~all: 더 느슨한 끝맺음입니다. 다른 서버에서 온 메일을 의심스러운 메일로 다루되 거부하지는 말라는 뜻입니다.

간단한 예

SPF 레코드 하나가 작은 가게를 어떻게 보호하는지 보겠습니다.

빵집이 Google Workspace를 씁니다. Rosa's Bakery는 Google Workspace로 rosa@bakery.example에서 메일을 보냅니다.
SPF 레코드를 게시합니다. 레코드는 v=spf1 include:_spf.google.com -all입니다. bakery.example의 메일은 Google의 서버만 보낼 수 있다는 뜻입니다.
로사가 고객에게 메일을 보냅니다. 메일은 Google의 서버 중 하나에서 나갑니다.
고객의 서버가 확인합니다. bakery.example의 SPF 레코드를 조회합니다. Google의 서버는 허용되어 있으므로 결과는 pass(통과)입니다.
누군가 가짜 메일을 보냅니다. 사기범이 bakery.example에서 왔다고 주장하는 메일을 보냅니다. 이 메일은 레코드에 없는 서버에서 나갑니다.
확인에 실패합니다. 레코드가 -all로 끝나므로, 고객의 서버는 가짜 메일을 거부할 수 있습니다.

받는 쪽 서버가 확인하는 방법

메일이 도착하면 받는 쪽 서버는 Return-Path의 도메인을 읽습니다. Return-Path란 반송 메시지가 가는 주소입니다. 반송 메시지란 메일이 전달되지 않았다고 발신자에게 알려 주는 자동 메시지입니다.

서버는 그 도메인의 SPF 레코드를 가져옵니다. 그런 다음 메일을 전달한 IP 주소가 레코드에 있는지 확인합니다. IP 주소란 인터넷에서 서버를 식별하는 번호입니다. 흔한 결과는 세 가지입니다.

Pass(통과). IP 주소가 레코드에 있습니다. 메일은 허용된 서버에서 왔습니다.
Fail(실패). IP 주소가 레코드에 없고, 레코드가 -all로 끝납니다. 서버는 메일을 거부할 수 있습니다.
Softfail(소프트페일). IP 주소가 레코드에 없고, 레코드가 ~all로 끝납니다. 서버는 메일을 받아들이지만 의심스러운 메일로 표시합니다.

Microsoft Exchange Online은 확인에 실패한 메일을 5.7.23 The message was rejected because of Sender Policy Framework violation 메시지와 함께 거부합니다. Gmail은 인증이 전혀 없는 메일에 550 5.7.26을 돌려줍니다. 두 코드 모두 5로 시작합니다. 주소에는 문제가 없는데도 발송 도구는 이것을 하드 바운스로 기록합니다.

SPF 레코드가 필요한 발신자

대량 메일을 보내는 모든 발신자에게 필요합니다. Google의 발신자 가이드라인은 Gmail로 하루 5,000통 이상 보내는 발신자에게 SPF와 DKIM을 요구합니다. DMARC도 요구합니다. Microsoft도 Outlook.com, Hotmail, Live로 하루 5,000통 넘게 보내는 도메인에 같은 레코드 3개를 요구합니다. Microsoft는 2025년 5월 5일부터 이 규칙을 적용하기 시작했습니다.

그보다 적게 보내더라도 이 레코드는 중요합니다. 레코드가 없으면 메일이 스팸함으로 갈 가능성이 높아집니다.

DNS 조회 10회 제한

RFC 7208은 SPF 확인 한 번에 DNS 조회를 10회까지로 제한합니다. 조회란 받는 쪽 서버가 DNS에 하는 질문 하나입니다. 레코드 안의 include:, a, mx, redirect는 각각 조회 1회로 셉니다. 포함한 레코드 안의 조회도 셉니다. 합계가 10회를 넘으면 확인 결과는 영구 오류(permanent error)가 됩니다. 대부분의 받는 쪽 서버는 이 오류를 fail(실패)로 처리합니다.

이것이 SPF 레코드가 작동하지 않게 되는 가장 흔한 원인입니다. 회사가 이메일 도구를 하나씩 레코드에 추가합니다. 11번째 조회가 추가되는 순간 레코드 전체가 작동하지 않습니다. SPF 레코드 검사기는 각 include 안에 있는 조회까지 포함해 레코드의 조회 수를 셉니다.

예: 한 회사의 SPF 레코드에는 사내 메일, 뉴스레터 도구, 헬프데스크 도구, 청구서 도구가 include되어 있습니다. 그중 일부는 안에 또 다른 레코드를 포함하고 있습니다. 모두 합치면 조회가 11회 필요합니다. 그날부터 회사 사무실에서 보낸 메일까지 포함해, 회사의 메일은 SPF 확인에 실패합니다.

SPF는 레코드 3개 중 하나

SPF는 어느 서버가 메일을 보냈는지 확인합니다.
DKIM은 메일이 보낸 뒤에 바뀌지 않았는지 확인합니다.
DMARC는 두 확인을 From 주소, 즉 읽는 사람에게 보이는 주소와 연결합니다. 확인에 실패했을 때 어떻게 처리할지도 받는 쪽 서버에 알려 줍니다.

도메인에는 세 가지가 모두 필요합니다. 하드 바운스와 소프트 바운스의 차이 가이드에서 실패 코드가 반송 보고서에 어떻게 나타나는지 보여 줍니다.

SPF 레코드와 이메일 검증

SPF 레코드는 어느 서버가 내 도메인의 메일을 보낼 수 있는지 증명합니다. 받는 사람의 주소가 존재한다는 것은 증명하지 않습니다. 인증을 올바르게 통과한 메일도 쓰이지 않는 주소로 보내면 반송됩니다. 이메일 유효성 검사 도구는 보내기 전에 메일함이 존재하는지 받는 쪽 서버에 묻습니다. 대량 이메일 검증 도구는 리스트 전체에 같은 일을 합니다. 올바른 SPF 레코드는 5.7.23 같은 인증 관련 반송을 막는 데 도움이 되고, 이메일 검증은 5.1.1 같은 코드로 반송될 주소를 찾아냅니다.

이메일 주소 검사하기