SPF 레코드 (SPF Record)

정의

SPF 레코드(Sender Policy Framework 레코드)는 도메인의 공개 DNS 영역에 게시되는 DNS TXT 자원 레코드로, 해당 도메인을 대신해 이메일을 보낼 권한이 있는 IP 주소, IPv6 접두사, 메일 서버 호스트 이름을 열거합니다. 수신 메일 서버가 인바운드 메시지를 받으면, 발신자의 DNS에서 SPF 레코드를 조회해 연결 IP 주소를 정책과 비교합니다. IP가 목록에 없으면 수신 서버는 도메인 소유자가 설정한 정책 한정자에 따라 메시지를 소프트페일로 표시하거나, 즉시 거부하거나, 추가 평가를 위해 표시할 수 있습니다.

SPF는 2006년 RFC 4408에서 IETF 표준으로 처음 형식화되었고, 이후 인터넷 엔지니어링 태스크 포스(IETF)가 2014년 4월에 발표한 현재 권위 사양인 RFC 7208로 갱신되었습니다. DKIM(DomainKeys Identified Mail), DMARC(Domain-based Message Authentication, Reporting, and Conformance)와 함께 세 가지 보완적 이메일 인증 표준 중 하나입니다.

작동 방식

SPF 평가 과정은 SMTP 핸드셰이크의 MAIL FROM 단계에서 수신 메일 서버의 SMTP 엔진이 수행하는 여러 순차적 단계를 포함합니다.

도메인 소유자는 DNS에 SPF TXT 레코드를 게시합니다. 일반적인 레코드는 다음 구문을 따릅니다. v=spf1 include:_spf.google.com ip4:203.0.113.5 ~all. 구성요소는 다음과 같습니다. v=spf1(버전 식별자), 하나 이상의 메커니즘(include, ip4, ip6, a, mx, exists), 그리고 마지막 한정자(+all, -all, ~all, ?all). -all 한정자는 하드 페일을 의미합니다. 명시적으로 나열되지 않은 어떤 서버도 권한이 없습니다. ~all 한정자(소프트페일)는 메시지를 통과시키되 정책 불일치를 기록하며, 마이그레이션 기간 동안 흔히 사용됩니다.

메시지가 도착하면 수신 MTA(Mail Transfer Agent)는 envelope sender 도메인(MAIL FROM 주소, RFC5321.MailFrom 주소라고도 함)을 추출하고 _spf.<도메인> 또는 도메인 루트에서 직접 DNS TXT 조회를 수행합니다. SPF 라이브러리는 메커니즘을 순서대로 평가해 하나가 일치하거나 10번의 DNS 조회 한도(RFC 7208 4.6.4절에 정의된 “SPF PermError” 한도)에 도달할 때까지 진행합니다. 결과 — Pass, Fail, SoftFail, Neutral, TempError, PermError — 는 메시지의 Received-SPF 헤더에 삽입되고 스팸 필터와 어떤 DMARC 정책 엔진에든 전달됩니다.

SPF는 메시지 본문에 보이는 From 헤더가 아니라 envelope sender(MAIL FROM)를 인증한다는 점이 중요합니다. 이 구분 때문에 SPF만으로는 이메일 클라이언트의 표시 이름 위조를 막을 수 없으므로, 완전한 보호를 위해 SPF 또는 DKIM 결과 모두가 RFC5322.From 도메인과 일치할 것을 요구하는 DMARC 정렬이 필요합니다.

어디에서 마주치게 되나

SPF 레코드는 이메일 도달성과 발신자 평판이 중요한 모든 맥락에 등장합니다. Amazon SES, SendGrid, Mailgun, Postmark, SparkPost 같은 서비스가 운영하는 트랜잭셔널 이메일 인프라는 메시지가 인증 검사를 통과하기 전에 도메인 소유자가 공급자의 발송 인프라를 가리키는 SPF include 메커니즘을 추가하도록 요구합니다.

이메일 확인 투표를 발송하는 콘테스트 플랫폼 — Woobox, ShortStack을 포함하고 Mailchimp Transactional(Mandrill)을 사용하는 맞춤형 시스템 — 은 발송 도메인이 유효한 SPF 레코드를 가지고 있는지에 의존합니다. Google(Gmail), Microsoft(Outlook / Exchange Online Protection), Yahoo Mail 같은 메일박스 공급자는 도달성 알고리즘의 입력으로 SPF를 평가합니다. SPF 레코드가 없거나 잘못 구성되어 있으면 확인 메일이 조용히 스팸 폴더로 가거나 완전히 거부될 가능성이 크게 늘어, 표가 확인되지 않은 채 남게 됩니다.

Cloudflare, AWS Route 53, GoDaddy, Namecheap 같은 공급자의 DNS 호스팅 패널은 관리 인터페이스를 통해 SPF TXT 레코드 편집을 제공합니다. MXToolbox SPF Lookup, Google Admin Toolbox, DMARCIAN의 SPF Surveyor 같은 진단 도구로 도메인 소유자가 게시된 레코드를 살피고 검증할 수 있습니다.

실무 예시

한 콘테스트 플랫폼이 [email protected]에서 투표 확인 메일을 발송합니다. 도메인 votes.example.com은 SPF 레코드 v=spf1 include:sendgrid.net -all을 가지고 있습니다. Gmail이 확인 메시지를 받으면, 인바운드 SMTP 서버가 votes.example.com의 SPF 레코드를 DNS에 조회하고, sendgrid.net include 메커니즘을 확장한 뒤 연결 IP를 SendGrid의 권한 서버 목록과 대조합니다. IP가 일치하면 SPF 결과는 Pass이고 메시지는 인박스로 진행됩니다. 도메인에 SPF 레코드가 없었다면 Gmail 필터는 메시지를 인증되지 않은 것으로 다뤄 인박스 배치 확률을 떨어뜨렸을 것입니다.

한 지역 신문 콘테스트가 SPF 레코드를 갱신하지 않은 채 트랜잭셔널 이메일 공급자를 Mailchimp에서 Amazon SES로 변경합니다. 확인 메일이 Microsoft Outlook에서 SPF 검사에 실패해 스팸함으로 일괄 분류되기 시작하고, 유권자들이 확인 기간을 놓칩니다. 콘테스트 관리자는 MXToolbox로 문제를 진단하고 SPF 레코드에 include:amazonses.com을 추가하면, DNS 전파 기간(보통 0~48시간, TTL 설정에 따라 다름) 안에 도달성이 회복됩니다.

관련 개념

SPF는 세 가지 표준으로 구성된 이메일 인증 스택의 한 기둥입니다. 암호학적 서명 검증은 **DKIM**을, SPF와 DKIM 결과에 따라 행동하는 정책 계층은 **DMARC**를 참조하세요. 콘테스트 운영에 미치는 실무적 영향은 **Email Confirmation Vote**에서 다룹니다. 거기서는 확인 메시지의 도달성이 가장 중요한 운영적 의존성입니다. DMARC 위에 구축된 새로운 표준인 BIMI(Brand Indicators for Message Identification)는 검증된 발신자가 지원하는 메일박스 공급자에 브랜드 로고를 표시할 수 있게 합니다. 떠오르는 신뢰 신호이지만 여기서는 다루지 않습니다.