개요편집이의 제기
전송자 정책 프레임워크(Sender Policy Framework, SPF)는 발신 메일 서버가 특정 도메인의 이름으로 이메일을 발송할 권한이 있는지 확인하는 이메일 인증 기술이다. 이메일 스푸핑을 탐지하기 위해 설계된 단순한 검증 시스템으로, 초기 SMTP 연결 시 '봉투 발신자(envelope from)' 필드에 기록된 발신자 주소에만 적용된다. 수신자가 '보낸 사람(From:)' 헤더에서 실제로 보는 주소를 인증하려면 DMARC와 같은 별도 기술이 필요하다. 도메인 관리자는 자 도메인을 대신해 메일을 보낼 수 있는 호스트와 IP 주소 목록을 DNS 레코드에 공개하며, 수신 측은 이 정보를 조회해 권한 없는 발신자를 차단하거나 표시한다. 현재 표준은 2014년 4월 제정된 RFC 7208로 '제안된 표준(Proposed Standard)' 지위를 가진다.[1][2][3]
역사편집이의 제기
개념의 태동과 초기 제안
SPF의 기본 개념은 2000년에 처음 공개적으로 언급되었으나 당시에는 주목받지 못했다. 2002년 IETF 'namedroppers' 메일링 리스트에서 Dana Valerie Reese가 SPF와 유사한 사양을 처음 게시했고, 바로 다음 날 Paul Vixie가 독자적인 사양을 올렸다. 두 제안은 큰 관심을 끌어 IETF 반스팸 연구 그룹(ASRG) 결성으로 이어졌으며, 이곳에서 Hadmut Danisch의 'Reverse MX(RMX)', Gordon Fecyk의 '지정 메일러 프로토콜(DMP)' 등 여러 제안이 논의되었다.[3]
병합과 이름 변경
2003년 6월 Meng Weng Wong이 RMX와 DMP를 병합하고 커뮤니티 의견을 수렴하기 시작했다. 이후 6개월 동안 수많은 수정과 함께 대규모 커뮤니티가 형성되었다. 초창기에는 'Sender Permitted From'의 약자로 'SMTP+SPF'라고도 불렸으나, 2004년 2월 'Sender Policy Framework'로 명칭이 확정되었다.[3]
MARID 워킹 그룹과 Sender ID 분기
2004년 초 IETF는 MARID 워킹 그룹을 만들어 SPF와 마이크로소프트의 Caller ID 제안을 기반으로 Sender ID를 표준화하려 했으나, 기술적·라이선스 갈등으로 무산되었다. 커뮤니티는 다시 원래의 '클래식' SPF로 돌아왔다.[3]
실험 표준에서 제안 표준으로
2005년 7월 IESG가 클래식 SPF 사양을 IETF 실험(Experimental) 표준으로 승인해 RFC 4408로 2006년 4월 28일 공개했다. 2년간의 관찰 기간을 거쳐 2014년 4월 25일 RFC 7208이 '제안된 표준'으로 발표되면서 RFC 4408을 폐기(obsolete)시켰다. 2026년 5월 현재까지 RFC 7208은 폐기되지 않은 상태다.[3]
평가편집이의 제기
스팸·피싱 억제 효과
도메인이 SPF 레코드를 게시하면 스패머·피싱범이 해당 도메인을 위조해 메일을 보내도 SPF를 검사하는 스팸 필터에 걸릴 확률이 높아진다. 결과적으로 해당 도메인은 스푸핑 표적으로서 매력이 떨어져 스팸 필터의 차단 목록(denylist)에 오를 가능성이 줄어들고, 정상 메일의 전달률이 올라간다.[3]
스패머의 우회와 추적성
스패머가 SPF 정책을 가진 도메인의 계정을 얻거나 해당 도메인 내 시스템을 해킹하면 SPF PASS 결과를 얻을 수 있다. 그러나 이 경우 발신자가 더 쉽게 추적되므로 공격자 입장에서 리스크가 커진다.[3]
백스캐터(Backscatter) 감소
위조된 Return-Path 주소 소유자는 대량의 원치 않는 오류 메시지·자동 회신(백스캐터)을 받는다. 정당한 발신 IP를 SPF로 지정하고 그 외를 FAIL로 두면, 수신 측 SPF 검사로 위조 메일을 거부해 백스캐터를 줄이거나 없앨 수 있다.[3]
허용 목록과의 결합
발신자가 SPF 정보를 제공하면 수신 측은 SPF PASS 결과와 허용 목록을 조합해 신뢰할 수 있는 발신자를 식별할 수 있다. 다만 해킹된 시스템이나 공용 발송 메일러가 개입하면 이 방식의 신뢰도는 제한된다.[3]
헤더 위조 한계와 DMARC 보완
SPF가 봉투 발신자 위조를 막자 공격자는 수신자에게 실제 보이는 From 헤더 주소만 위조하는 쪽으로 이동했다. SPF나 DKIM만으로는 From 헤더를 검증할 수 없으나, DMARC와 함께 쓰면 '식별자 정렬(identifier alignment)'을 통해 From 헤더도 검증할 수 있다. 표시 이름(display name) 스푸핑은 독자적인 독점 구현이 필요하며 SPF로는 방어할 수 없다.[3]
SPF 레코드 타입 폐지의 교훈
전용 레코드 타입 99가 할당되었음에도 마이그레이션이 진전되지 않아 상호운용성 문제가 지속되자, SPFbis 워킹 그룹은 2014년 SPF 레코드 타입 지원을 중단하고 TXT 레코드 단일화로 정리했다. 이는 표준화 과정에서 배포 현실을 고려해야 함을 보여준 사례다.[3]
라이선스·특허 이슈편집이의 제기
MARID 워킹 그룹에서 Sender ID 표준화 시 마이크로소프트의 Caller ID 제안과 관련한 라이선스 갈등이 발생해 표준화 시도가 붕괴된 바 있다. 클래식 SPF로 복귀한 뒤에는 이러한 라이선스 문제 없이 공개 표준으로 유지되고 있다.[3]
이 문서는 GGWiki AI가 공개 자료(아래 출처)를 조사해 새로 쓴 초안입니다. 틀린 내용은 편집하거나 이의 제기로 알려 주세요.
