SPF(Sender Policy Framework)란?

정의

Sender Policy Framework는 DKIM, DMARC와 함께 3대 핵심 이메일 인증 표준 중 하나예요. 이메일의 기본적인 약점을 다루는데요, 원래의 메일 프로토콜에는 실제 발신자를 증명하는 방법이 없어서 기본적으로 누구나 어떤 도메인에서 온 것처럼 메시지를 보낼 수 있어요. SPF는 도메인 소유자가 어떤 서버가 도메인을 대신해 메일을 보낼 수 있는지 기계가 읽을 수 있는 형태로 공개 선언하게 해서 그 틈의 일부를 메워요.

이 선언은 도메인 이름을 네트워크 주소로 바꿔주는 전 세계 디렉터리인 Domain Name System에 있어요. 도메인 소유자는 승인된 발신자를 명시한 특수 DNS 레코드를 게시해요. 메시지가 도착하면 수신 메일 서버는 그 레코드를 조회해 실제로 메시지를 전달한 서버와 비교해요. 발신 서버가 목록에 있으면 SPF를 통과하고, 없으면 SPF에 실패하는데, 이는 메일이 위조되었을 수 있다는 강한 단서예요. SPF는 아무것도 암호화하지 않고 메시지 내용도 확인하지 않아요. 이 메시지가 도메인 소유자가 승인한 서버에서 발송되었는가, 이 한 가지 질문에만 답해요.

작동 방식

SPF 정책은 도메인에 하나의 DNS TXT 레코드로 게시돼요. 레코드는 항상 버전 태그 v=spf1로 시작하고, 승인된 발신자를 나타내는 여러 메커니즘이 이어지며, 보통 기본 결과를 정하는 all 메커니즘으로 끝나요. 간단한 레코드는 v=spf1 include:_spf.google.com -all처럼 생겼는데, Google Workspace 메일 서버를 승인하고 나머지는 모두 거부한다는 뜻이에요.

메커니즘은 SPF 레코드의 구성 요소예요. ip4와 ip6 메커니즘은 특정 주소나 주소 범위를 직접 승인해요. a 메커니즘은 도메인의 주소 레코드에 있는 서버를, mx는 도메인의 메일 교환 서버로 등록된 서버를 승인해요. 실무에서 가장 많이 쓰는 것은 include 메커니즘으로, 다른 제공업체의 SPF 정책을 가져와요. 도메인이 Google, Microsoft, 이메일 플랫폼 같은 서비스에 발송을 위임하는 방식이 바로 이거예요. 각 메커니즘에는 일치할 때의 결과를 정하는 한정자를 붙일 수 있어요. 기본값인 더하기 기호는 통과, 빼기 기호는 실패, 물결표는 약한 경고인 softfail, 물음표는 중립을 뜻해요. 마지막의 all 메커니즘은 일치하지 않은 모든 서버를 잡아내므로, -all은 목록에 없는 것을 강하게 거부하고 ~all은 더 약한 신호를 보내요.

수신 서버는 SPF를 평가할 때 SMTP 교환 중에 선언된 Return-Path, 즉 envelope-from 주소를 확인하고, Return-Path가 비어 있는 반송 메시지라면 대신 HELO 식별자를 확인해요. 표준에는 중요한 제약이 있어요. 레코드 하나를 평가할 때 DNS 조회는 10번을 넘을 수 없고, include, a, mx, exists 같은 메커니즘은 각각 한 번씩 조회를 사용해요. 10번을 넘으면 PermError가 발생하고 수신 서버는 이를 실패로 처리할 수 있으므로, SPF 레코드는 간결하게 유지해야 해요. SPF에는 구조적인 한계도 있어요. 전달 서버가 원래 도메인의 목록에 없기 때문에 메일이 포워딩되면 깨지고, 무엇보다 수신자가 실제로 보는 From 주소가 아니라 envelope-from 주소만 검증해요.

이메일 도달률에 중요한 이유

이제 SPF는 선택 사항이 아니라 기본 요건이에요. 메일함 제공업체는 SPF 통과를 긍정적인 신뢰 신호로, 레코드가 없거나 실패하면 의심할 이유로 보며, 이는 메일이 받은편지함에 갈지 스팸함에 갈지에 직접 영향을 줘요. Google과 Yahoo가 2024년 발신자 요건을 도입한 이후 대량 발신자는 SPF 인증이 필수이고, 유효한 SPF 레코드가 없는 도메인은 메일 발송이 제한되거나 아예 거부될 수 있어요.

SPF가 중요한 또 다른 이유는 인증을 화면에 보이는 From 주소와 연결하는 정책 계층인 DMARC의 전제 조건이기 때문이에요. DMARC는 SPF나 DKIM이 통과했는지, 그리고 그 결과가 From 도메인과 일치하는지를 확인해요. SPF 레코드가 올바르게 설정되지 않으면 도메인은 SPF를 통한 DMARC 정렬을 달성할 수 없어 전체 보호 수준이 약해져요. 동시에 SPF가 할 수 없는 일도 현실적으로 봐야 해요. 화면에 보이는 From 헤더를 무시하고 포워딩 시 깨지기 때문에, SPF만으로는 작정한 사칭자를 막을 수 없어요. SPF는 3중 방어의 필수 계층 중 하나이고, DKIM과 DMARC가 함께 있을 때 제 가치를 온전히 발휘해요.

VeriMails의 처리 방식

SPF와 이메일 검증은 같은 도달률 문제의 서로 다른 절반을 해결해요. SPF는 보내는 메일을 인증해 수신 서버가 그 메일이 정말 나에게서 왔다고 믿게 해줘요. 이메일 검증은 보내는 대상 리스트를 정리해 실제로 도달 가능한 주소에만 메일을 보내게 해줘요. 받은편지함 도달률을 높이려면 둘 다 함께 작동해야 하고, 어느 하나가 다른 하나를 대신할 수는 없어요.

VeriMails는 수신자 쪽에 집중해요. 제출한 모든 주소는 구문 검사, MX 및 DNS 조회, 실시간 SMTP 핸드셰이크, 캐치올 감지, 일회용 주소 감지, 역할 기반 감지를 거치므로, 유효하지 않은 주소가 반송되어 SPF, DKIM, DMARC 레코드가 지키려는 평판을 떨어뜨리기 전에 제거돼요. 인증 쪽도 돕기 위해 VeriMails는 무료 SPF 생성기를 제공해요. 도메인과 발송 서비스에 맞춰 구문상 올바른 레코드를 만들고 10회 조회 한도도 지켜줘요. 리스트 검증은 REST API나 대량 CSV 업로드로 할 수 있고, 캠페인 결정에 바로 쓸 수 있는 명확한 도달 가능성 분류를 제공해요. 검증은 이메일당 $0.0019부터, 10,000 크레딧에 $19이며 연간 플랜은 연 결제 시 월 $12.50부터예요. 모든 계정은 신용카드 없이 만료되지 않는 무료 크레딧 100개로 시작해요.

자주 묻는 질문