5,798개의 .co.kr 도메인의 SPF 레코드를 분석했다. 이 중 85.6%가 -all 대신 ~all을 사용하고 있었다. 이는 전 세계 평균인 53.6%보다 훨씬 높은 수치다.
SPF 레코드란 무엇인가?
SPF 레코드는 DNS의 단일 TXT 레코드다. 이메일 수신 서버가 메일을 받을 때, 발신 서버의 IP 주소가 해당 도메인을 대리하여 이메일을 보낼 권한이 있는지 확인하는 데 사용하는 값이다.
구글이 나를 대신해 이메일을 보낼 수 있도록 승인하는 SPF 레코드 예시:
v=spf1 include:_spf.google.com ~all
include:_spf.google.com은 _spf.google.com의 A 또는 AAAA 레코드 조회 결과에 포함되는 모든 IP 주소에 권한을 위임한다.
마지막 항인 ~all에서 all은 그 외의 모든 IP 주소를 포함한다.
한국에서 가장 흔하게 발견된 도메인은 다음과 같다.
_spf.daum.net(465개 레코드)email.ncloud.com(463개)_spf.google.com(378개)spf.protection.outlook.com(296개)spf.cafe24.com(279개)
SPF는 SMTP MAIL FROM 명령에 명시된 주소를 검증한다. 이는 수신자의 메일 클라이언트에 표시되는 주소와 다르다. 수신자가 보는 From: 줄에는 완전히 다른 도메인이 들어갈 수 있다. DMARC가 중요한 이유가 바로 여기에 있다. DMARC는 From: 주소가 MAIL FROM 주소와 일치하도록 강제한다.
RFC 9989 §3.2.4: "DMARC는 오직 MAIL FROM 신원에 대한 SPF 검증에만 의존한다."
한국의 DMARC 적용 현황은 이전 글에서 측정했다.
한국 대상 실증 조사
Tranco 스냅샷에서 추출한 10,135개의 한국 등록 가능 도메인을 조사했으며, 이 중 10,123개가 .co.kr 도메인이었다. 조회가 실패한 201개를 제외하고 9,934개의 도메인이 남았다. 도메인이 v=spf1로 시작하는 레코드로 TXT 질의에 응답하면 "SPF를 게시했다"고 판단한다.
9,934개 중 5,798개 도메인이 SPF 레코드를 게시하고 있었다. 비율로는 58.4%로, 전 세계 평균인 56.0%와 비슷한 수준이다.
MX 레코드를 게시한 도메인(기본적으로 이메일을 발송할 가능성이 있음을 의미) 66.1% 중 83.1%가 SPF도 함께 게시하고 있었다.
- 아이뉴스24가 보도한 KISA 자료: 2017년 6월 기준, 메일 서버를 운영하는 46만 개 한국 도메인 중 66%(약 30만 개)가 SPF를 게시함.
- Lazy Gatekeepers: 2023년에 스캔한 1,280만 개 Tranco 도메인을 대상으로 한 2025년 연구에 따르면, 전체 도메인의 SPF 도입률은 56.5%였음. 논문의 주요 분석 대상인 상위 100만 개 도메인으로 한정하면 "도메인당 SPF 사용률은 전체 스캔 도메인의 60.2%, MX 레코드가 있는 도메인의 79.3%로 증가했다"고 보고함.
9년 전 한국은 66%, 3년 전 전 세계 상위 100만 개 메일 발송 도메인은 79.3%, 그리고 현재 한국은 83.1%다. 특히 이번 조사 대상 9,934개 도메인 중 8,248개는 상위 100만 위 밖에 위치하므로, 훨씬 낮은 순위의 도메인들까지 포함했음에도 높은 기준을 충족하고 있다. 따라서 한국의 문제는 SPF 도입률 자체에 있지 않다.
다른 지역과 마찬가지로 한국에서도 기업 규모에 비례하는 경향을 보인다. 전 세계 상위 10만 개 이내 도메인 128개 중 82.8%가 SPF를 게시하고 있으며, 10만~100만 위 사이 도메인 1,558개 중에서는 70.7%, 100만 위 밖 도메인 8,248개 중에서는 55.6%가 SPF를 게시하고 있다. 다만 최상위 구간은 128개 도메인에 불과하므로 참고 수준으로 보는 것이 좋다.
하지만 정작 차단을 요청하는 레코드는 거의 없다
이제 마지막 항을 살펴보자. 5,798개 레코드 중:
- 4,964개 (85.6%)가
~all(softfail)을 사용함 - 772개 (13.3%)가
-all(fail)을 사용함 - 35개 도메인은
all항목이 없음 - 25개 도메인은
redirect=를 사용함 - 2개 도메인은
?all을 사용함 +all을 사용하는 도메인은 없음
RFC 7208은 두 지시자가 의미하는 바를 명확히 정의하고 있다.
RFC 7208 §8.5: "'softfail' 결과는 'fail'과 'neutral'/'none' 사이의 어딘가로 처리되어야 한다. 관리 도메인(ADMD)은 해당 호스트가 권한이 없다고 판단하지만, 단호한 정책을 표명할 의사는 없다. 수신 소프트웨어는 이 결과만을 이유로 메시지를 거부해서는 안 되며(SHOULD NOT), 일반적인 경우보다 메시지를 더 면밀히 검사할 수 있다(MAY)."
RFC 7208 §8.4: "'fail' 결과는 클라이언트가 지정된 신원으로 해당 도메인을 사용할 권한이 없음을 명시적으로 선언하는 것이다. SPF fail 메시지의 처리 방식은 수신 측의 자체 정책에 따른다."
~all 레코드도 나름의 역할을 하긴 한다. 수신 측에서 점수를 부여하거나, 임시 거부(greylist)하거나, 스팸함으로 분류할 수 있다. 다만 도메인 소유자가 단호한 선언을 보류했을 뿐이다. 반면 -all은 단호한 선언을 남기며, 단독으로도 작동한다. 즉, DMARC 레코드가 전혀 없는 상황에서도 수신 측의 자체 정책에 따라 fail 처리를 실행할 수 있다.
~all이 과반수를 차지하는 것 자체는 일반적인 현상이다. DMARCguard의 2026년 스캔 결과에 따르면 전 세계 SPF 게시 도메인의 53.6%가 ~all로, 40.2%가 -all로 끝났다.
이상한 점은 한국의 -all 비율이 다른 국가들에 비해 지나치게 낮다는 사실이다.
실제로 13.3%라는 -all 비율은 2017년 당시 전 세계 평균이었던 약 27.4%(Hu and Wang)보다도 낮다.
또 다른 기이한 점은 ~all을 사용하는 4,964개 도메인 중 3,901개는 유효한 DMARC 정책조차 설정되어 있지 않다는 것이다.
가설
도메인 소유자들이 주요 메일 서비스 제공업체의 SPF 설정 가이드를 그대로 복사해서 붙여넣고 있기 때문이라고 추정된다.
예를 들어 Google Workspace 관리자 가이드에는 다음과 같이 적혀 있다.
Google Workspace 관리자 도움말, "SPF 설정": "
~all태그는 SPF 레코드에 나열되지 않은 서버에서 발송된 메시지를 스팸으로 표시하도록 수신 서버에 알린다. Google은 SPF 레코드에~all을 사용할 것을 권장한다."
또한 Cafe24 웹메일 가이드에서는 관리자에게 다음 설정을 사용하도록 안내한다.
v=spf1 ip4:183.110.224.0/24 ip4:175.126.146.0/24 ip4:112.175.12.0/24 ip4:118.219.233.0/24 ~all
Cafe24의 가이드는 이번 조사 결과 중 두 가지를 명확히 설명해 준다. 첫째는 ~all로 끝난다는 점이고, 둘째는 발신 서버를 개별 CIDR 블록으로 지정하고 있다는 점이다. 실제로 한국 도메인의 42.5%(2,463개)가 이와 정확히 동일한 방식으로 설정되어 있었다.
스티비(Stibee): v=spf1 include:mail.stibee.com ~all.
반면 마이크로소프트(Microsoft)는 예외적인 행보를 보인다.
Microsoft Learn, "Microsoft 365 도메인의 유효한 이메일 소스를 식별하도록 SPF 설정": "Microsoft 365 도메인의 경우 DKIM 및 DMARC 적용도 함께 권장하므로
-all(hard fail)을 사용할 것을 권장한다."
인용한 4개 서비스 중 ~all을 권장하는 3개 서비스가 이번 조사에서 총 795개 레코드를 차지했다(Google 378개, Cafe24 279개, 스티비 138개). 반면 -all을 권장하는 Microsoft를 가리키는 레코드는 296개였다.
내 도메인 확인 방법
다음 명령어를 실행하여 도메인의 SPF 레코드를 확인할 수 있다.
dig +short yourcompany.co.kr TXT
SPF 레코드는 v=spf1로 시작한다.
문득 궁금해진다. 도메인 메일을 설정할 때 다들 호스팅 업체의 예시를 그대로 복사해서 쓰고 있었던 걸까?
참고 자료
- IETF — RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 (2014년 4월)
- IETF — RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (2026년 5월)
- 아이뉴스24 — KISA, 포털 등에 이메일 발신서버 진위 확인기술(SPF) 적용 권고 (2017년 7월 6일)
- Stefan Czybik, Micha Horlboge, Konrad Rieck — Lazy Gatekeepers: A Large-Scale Study on SPF Configuration in the Wild (arXiv:2502.08240, 2025년; 2023년 1월~5월 스캔한 12,823,598개 도메인)
- Hang Hu, Gang Wang — Revisiting Email Spoofing Attacks (arXiv:1801.00853, 2018년; 2017년 10월 수집 데이터)
- DMARCguard — SPF Supply Chain 2026 (벤더 연구 보고서; 2026년 3월 15일 스캔한 5,499,028개 Tranco 도메인)
- Google Workspace 관리자 도움말 — SPF 설정
- Cafe24 — 웹메일 스팸 설정 및 관리 가이드
- 스티비 (Stibee) 도움말 — SPF, DKIM 설정 이해하기
- Microsoft Learn — Microsoft 365 도메인의 유효한 이메일 소스를 식별하도록 SPF 설정
Instagram