SPF란? 이메일 발신 도메인 보호

도입

어느 날 고객으로부터 연락이 옵니다.
"귀사에서 이상한 이메일을 받았는데, 이거 진짜인가요?"

확인해 보니, 누군가가 우리 회사 도메인(@yourcompany.com)을 사칭하여 피싱 메일을 보내고 있습니다.
이메일 시스템은 기본적으로 "보낸 사람" 주소를 검증하는 기능이 없기 때문에, 아무나 우리 도메인을 넣어서 이메일을 보낼 수 있습니다.

이런 이메일 스푸핑(Email Spoofing)을 방지하는 첫 번째 방어선이 바로 SPF(Sender Policy Framework)입니다.

SPF란? — 한 줄 정의

SPF(Sender Policy Framework)란, 도메인 소유자가 "이 도메인으로 이메일을 보낼 수 있는 서버 목록"을 DNS에 공개하여, 수신 서버가 허용되지 않은 서버에서 온 이메일을 식별할 수 있게 하는 이메일 인증 기술입니다.

• 쉽게 말해, "방문자 명단"입니다 — 우리 도메인 대신 이메일을 보낼 수 있는 서버를 미리 등록해 둡니다

• 수신 메일 서버는 이 명단을 확인하여, 명단에 없는 서버에서 온 이메일을 의심스러운 메일로 처리합니다

• DNS TXT 레코드로 게시합니다

• DKIM, DMARC와 함께 이메일 인증의 3대 표준을 구성합니다

왜 SPF가 필요한가요?

이메일 프로토콜(SMTP)은 1980년대에 설계되었고, 발신자 인증 기능이 없습니다.
누구든 "보낸 사람" 필드에 아무 이메일 주소를 넣어서 보낼 수 있습니다.

2024년부터 Google, Yahoo, Microsoft는 대량 발송자에게 SPF, DKIM, DMARC를 모두 필수로 요구합니다. SPF가 없으면 이메일이 거부되거나 스팸으로 분류될 수 있습니다.

SPF는 어떻게 작동하나요?

1단계: 도메인 소유자가 SPF 레코드 게시

• 도메인의 DNS에 허용된 발신 서버 목록을 TXT 레코드로 게시합니다

• 예: v=spf1 ip4:192.168.1.100 include:_spf.google.com -all

2단계: 이메일 발송

• 이메일이 발송되면, 발신 서버의 IP 주소가 이메일과 함께 전달됩니다

3단계: 수신 서버가 SPF 레코드 확인

• 수신 메일 서버가 이메일의 Return-Path(반송 주소) 도메인에서 SPF 레코드를 DNS로 조회

• 발신 서버의 IP 주소가 SPF 레코드의 허용 목록에 있는지 확인

4단계: 결과 판정

• Pass: 발신 IP가 허용 목록에 있음 → 정상

• Fail: 허용 목록에 없음 → SPF 레코드의 정책에 따라 처리

• SoftFail: 허용 목록에 없지만 엄격하게 거부하지는 않음 (테스트 단계에서 주로 사용)

• Neutral: 판단 보류

SPF 레코드 구성 요소

SPF 레코드는 여러 메커니즘(Mechanism)과 한정자(Qualifier)로 구성됩니다.

주요 메커니즘

한정자 (Qualifier)

실전 팁: SPF 레코드 끝의 all 앞 한정자가 핵심입니다. -all은 "목록에 없으면 거부", ~all은 "목록에 없으면 의심하되 일단 받아줘"입니다. 최종 목표는 -all이지만, 처음에는 ~all로 시작하여 정상 이메일이 차단되지 않는지 확인하는 것이 안전합니다.

SPF 레코드 읽는 법 — 실전 예시

실제 SPF 레코드를 하나 분석해 보겠습니다.

v=spf1 ip4:203.0.113.5 include:_spf.google.com include:servers.mcsv.net ~all

SPF vs DKIM vs DMARC — 뭐가 다른가요?

세 가지가 함께 작동해야 완전한 보호가 됩니다. SPF는 "허용된 서버인가?", DKIM은 "내용이 진짜인가?", DMARC는 "실패하면 어떻게 할 것인가?"를 각각 담당합니다. 하나만 있으면 빈틈이 생깁니다.

SPF 설정하는 법

1. 이메일 발송 서비스 목록 정리

• 우리 도메인으로 이메일을 보내는 모든 서비스를 파악합니다

• 자체 메일 서버, Google Workspace, Microsoft 365, 마케팅 도구(Mailchimp, HubSpot 등), CRM, 고객 지원 도구, 트랜잭션 이메일 서비스 등

• 빠뜨리면 해당 서비스의 이메일이 SPF 실패 처리됩니다

2. SPF 레코드 작성

• v=spf1로 시작하고, 각 서비스의 IP 또는 include 도메인을 추가합니다

• 마지막에 ~all(SoftFail) 또는 -all(Fail)을 붙입니다

• 처음에는 ~all로 시작하여 테스트 후 -all로 강화하는 것을 권장합니다

3. DNS에 TXT 레코드 등록

• 도메인의 DNS 관리 콘솔에서 TXT 레코드를 추가합니다

• 호스트: @ 또는 빈칸 (도메인 루트)

• 값: 작성한 SPF 레코드 전체

4. 테스트 및 검증

• 테스트 이메일을 보내고 이메일 헤더에서 SPF 결과를 확인

• Gmail에서 "원본 보기"로 Received-SPF: pass 여부를 확인

• 온라인 SPF 검증 도구(MXToolbox 등)로 레코드 문법 확인

SPF 설정 시 주의사항

DNS Lookup 10개 제한은 가장 흔한 실수입니다. include, a, mx, redirect 등 DNS 조회가 필요한 메커니즘은 총 10개까지만 허용됩니다. 이를 초과하면 SPF 검증 자체가 실패(PermError)합니다. ip4, ip6는 DNS 조회가 아니므로 제한에 포함되지 않습니다.

SPF의 한계

SPF는 이메일 인증의 중요한 첫 단계지만, 단독으로는 완벽하지 않습니다.

• From 주소를 검증하지 않음: SPF는 Return-Path(봉투 발신 주소)를 검증하지만, 사용자가 실제로 보는 "보낸 사람(From)" 주소는 검증하지 않습니다. DMARC의 정렬(Alignment) 기능이 이 갭을 메웁니다

• 이메일 내용 변조 감지 불가: SPF는 발신 서버만 확인하고, 이메일 내용이 중간에 변조되었는지는 알 수 없습니다. 이것은 DKIM의 역할입니다

• 이메일 전달(Forwarding) 시 깨짐: 이메일이 전달되면 발신 서버 IP가 바뀌므로 SPF가 실패할 수 있습니다

• DNS Lookup 10개 제한: 많은 서드파티 서비스를 사용하면 제한에 도달하기 쉽습니다

SPF가 B2B 비즈니스에 미치는 영향

• 콜드 이메일 전달률: SPF가 없으면 아웃바운드 영업 이메일이 스팸함으로 직행할 가능성이 높습니다

• 마케팅 이메일: 뉴스레터, 프로모션 이메일의 도달률에 직접 영향

• 거래 이메일: 주문 확인, 비밀번호 재설정 등 중요한 거래 이메일이 전달되지 않을 수 있습니다

• 도메인 평판: SPF 없이 사칭당하면 도메인 블랙리스트에 올라갈 위험

• 파트너/고객 신뢰: 보안에 민감한 B2B 고객은 이메일 인증 여부를 확인합니다

핵심 요약

관련 글

• DKIM이란? 이메일 인증의 기초

• DMARC란? 이메일 보안 설정 가이드

• 콜드 이메일 가이드: 아웃바운드 영업의 시작

• SDR·BDR·AE란? 영업 조직의 핵심 역할

• Sales Enablement란? 영업 성과를 극대화하는 전략