이메일 스푸핑: 한국 도메인 10,000개 이상 조사 결과

사람들은 이메일 설정의 "기본" 상태가 얼마나 보안에 취약한지 과소평가하곤 한다. 이메일은 아주 오래전에 개발되었으며, 보안을 심각하게 고려하지 않던 시절에 만들어졌다. 기본 설정 상태에서는 누구나 어떤 이메일 도메인이든 사칭할 수 있고, 수신자는 이를 확인할 방법이 전혀 없다. 이를 방지하는 유일한 방법은 적절한 DMARC, SPF, DKIM을 유지하는 것이다. 이번 글에서는 DMARC에 집중해 본다.

DMARC를 어떻게 설정하지 말아야 하는지 보여주기 위해, 한국 도메인 10,135개를 테스트했다. 그 결과 85.4%의 도메인이 DMARC를 설정하지 않았거나 쓸모없는 정책을 적용하고 있는 것으로 나타났다.

"From" 필드를 보호하는 방법

앞서 언급했듯이 이메일 보안을 올바르게 구현하려면 SPF, DMARC, DKIM을 모두 설정해야 한다.

SPF는 SMTP(Simple Message Transfer Protocol) 대화 중에 발신 서버를 검증한다. DKIM은 이메일 헤더에 지정된 도메인과 관련된 암호화 서명을 검증한다.

하지만 수신자의 이메일 클라이언트에 표시되는 From 주소는 제3의 도메인을 사용할 수 있으며, SPF나 DKIM 모두 이 주소와 일치해야 할 의무는 없다.

DMARC는 이러한 메커니즘을 하나로 묶어준다. 수신자에게 보이는 도메인이 SPF 또는 DKIM 인증을 성공적으로 통과한 도메인과 일치(align)하도록 요구한다. 또한 두 메커니즘 중 어느 것도 일치하지 않을 때 수신 서버가 해당 메시지를 어떻게 처리해야 하는지 도메인 소유자가 지정할 수 있게 해준다.

소유자가 무엇을 원하는지 알아내기 위해 수신자는 정책을 조회해야 한다. 2026년 5월에 발표되었으며 IETF 표준 트랙의 첫 번째 DMARC 버전인 RFC 9989는 이 조회를 _dmarc.<domain>에서 시작하여 라벨 단위로 이름의 상위 수준을 향해 올라가는 DNS 트리 탐색(tree walk)으로 정의한다.

표준에서는 아무것도 찾지 못한 트리 탐색에 대해 명확히 기술하고 있다:

RFC 9989 §4.10.1: "DNS 트리 탐색으로 생성된 세트에 DMARC 정책 레코드가 포함되어 있지 않은 경우(즉, 일시적인 DNS 오류가 아니라 해당 레코드가 없음을 나타내는 표시가 있는 경우), 메일 수신자는 해당 메시지에 DMARC 메커니즘을 적용해서는 안 된다(MUST NOT)."

.co.kr 도메인의 경우 탐색은 _dmarc.co.kr로, 그 다음에는 _dmarc.kr로 올라간다. 두 경로 모두 쿼리를 시도했지만 결과는 비어 있었다. 즉, .co.kr 도메인을 테스트하는 것은 해당 도메인 자체만 테스트하는 것만큼 간단하다: _dmarc.example.co.kr.

레코드가 없다는 것은 수신자에게 검사를 건너뛰라(SKIP)고 알리는 것이다. DMARC 정책이 없을 때 수신 서버가 할 수 있는 다른 유일한 조치는 일반적인 스팸 필터링을 적용하는 것뿐인데, 이는 특히 AI 시대에 매우 신뢰하기 어렵다.

실험 대상

실험의 모집단은 Tranco 스냅샷이다. 14,274개의 한국 호스트네임을 등록 가능한 10,135개 도메인으로 압축했으며, 그중 10,123개가 .co.kr이다. 순위는 1,653위부터 약 7,000,649위까지 분포하므로, 이는 일반적인 상업용 도메인의 롱테일 집합이다.

KRNIC에 따르면 2026년 7월 기준 등록된 co.kr 도메인은 635,934개다. 즉, 샘플은 전체의 약 1.6%다. 하지만 그 목록의 "상위(head)" — 가장 방문자가 많은 웹사이트들 — 를 선택했으므로, 여기에 포함된 웹사이트들은 다른 대다수 웹사이트보다 리소스가 풍부한 편이다.

한국은 이전에도 다른 규모로 조사된 적이 있다. CIO Korea가 보도한 Proofpoint 조사(2024년 11월 28일)에 따르면, 코스피 200(상장 대형주 200개)을 분석한 결과 DMARC 레코드가 없는 곳이 62.7%, p=none이 35.8%, p=quarantine이 1%, p=reject가 0.5%로 나타났다. 이번 전수 조사는 약 10,000개의 일반 상업용 도메인을 대상으로 하며, 측정 방법을 공개하고 2026년 5월 RFC 7489를 대체한 RFC 9989를 기준으로 측정되었다.

실험 방법

각 도메인에 대해 세 가지 DNS 쿼리를 실행했다:

1. _dmarc.{domain} TXT
2. {domain} MX
3. {domain} TXT (SPF 용)

201건의 조회(2.0%)가 SERVFAIL 또는 타임아웃으로 반환되었다. 조회가 실패했다고 해서 해당 기업이 아무것도 게시하지 않았다는 증거는 될 수 없으므로, 이 도메인들은 이하 모든 비율 계산에서 제외되었다. 분모는 9,934개다.

실험 결과

8,484개 도메인(85.4%)은 사용할 수 있는 DMARC 정책이 없었다.

순위가 낮아질수록 이 비율은 상승한다:

• 10,000위 ~ 100,000위 사이: 57.3%
• 100,000위 ~ 100만 위 사이: 73.5%
• 100만 위 초과: 88.1%

메일을 수신하는 도메인 중 5개 중 4개가 이 집계에 포함된다. MX 레코드를 게시한 6,568개 도메인 중 80.0%는 사용할 수 있는 정책이 없었다. MX 레코드가 없는 3,364개 도메인 중에서는 95.9%가 정책이 없었으며, 전체 모집단 중 단 11개 도메인만이 널(null) MX를 게시했다. 2건의 MX 조회가 실패하여, 이 분류는 9,934개 중 9,932개를 다룬다.

5,798개(58.4%)가 SPF를 게시했으며, 4,412개는 SPF는 게시했으나 DMARC는 게시하지 않았다.

DMARC 레코드를 게시하는 것이 끝이 아니다

1,450개 도메인이 정책을 게시했지만, 그중 1,131개는 p=none으로 설정했다.

RFC 9989 §4.7에서는 이 값을 다음과 같이 정의한다: "none: 도메인 소유자가 선호하는 처리 방식을 표명하지 않음."

131개 도메인은 p=quarantine을, 188개 도메인은 p=reject를 설정했다. 수신자에게 어떤 조치라도 취해달라고 요청하는 도메인은 319개, 즉 전체 모집단의 3.2%에 불과하다.

일부 도메인 소유자는 Google의 발신자 가이드라인을 손쉽게 충족하기 위한 편법으로 p=none을 설정한다. 2024년 2월 1일부터 적용된 이 가이드라인은 개인 Gmail 계정으로 하루 5,000건 이상의 메시지를 보낼 경우 DMARC가 "존재"하도록 요구한다. 해당 가이드라인에는 "DMARC 적용 정책을 none으로 설정할 수 있습니다"라고 명시되어 있다.

또한 DMARC는 모니터링 기능도 제공한다. 이는 rua 주소를 통해 수행된다.

정책을 게시한 1,450개 도메인 중 666개가 rua 주소를 설정했다.

실제로는 DMARC를 도입한 도메인 중 절반 미만이 사칭 여부를 알려주는 리포트를 수신하고 있다는 의미다. 다른 134개 레코드는 2026년 5월 RFC 9989에서 제거된 태그인 pct=를 여전히 포함하고 있었다.

메일을 보내지 않는 경우

도메인에서 메일을 전혀 보내지 않는다면, 가장 좋은 방법은 다른 사람이 해당 도메인을 사칭하지 못하도록 막는 것이다.

RFC 7505 §4.2: "메일을 보내지 않는 도메인의 운영자는 Sender Policy Framework (SPF) '-all' 정책[RFC7208]을 게시하여 해당 도메인이 메일을 보내지 않음을 명시적으로 선언할 수 있다."

작업을 완료하려면 이를 널(null) MX 레코드 및 DMARC TXT 레코드의 p=reject와 조합하면 된다.

DMARC 설정 시 언제나 그렇듯 작게 시작하라:

1. 첫날에는 rua 주소와 함께 p=none을 게시한다.
2. 일주일이나 2주일 동안 리포트를 읽어본다. 급여 시스템, CRM, 티켓팅, 3년 전에 누군가 가입한 마케팅 앱 등 자체 도메인을 사용하는 도구 중 어떤 것의 SPF 또는 DKIM 설정 수정이 필요한지 알려준다.
3. 그런 다음 p=quarantine으로, 이어서 p=reject로 이동한다. 리포트에서 본인의 메일이 일치(align)하는 것으로 확인되면 각 단계 이동은 안전하다.

내 도메인 확인 방법

DMARC 레코드를 확인하려면 아래 명령어를 실행하라(dig가 설치되어 있는 경우):

dig +short TXT _dmarc.yourcompany.co.kr

분석 방법은 다음과 같다:

• 출력 결과 없음. DMARC 정책이 설정되어 있지 않다.
• v=DMARC1; p=none으로 시작하는 문자열. 같은 문자열에 rua=가 있는지 확인하라. 이게 없다면 아무런 보고도 받지 못하게 된다.
• p=quarantine 또는 p=reject가 포함된 문자열. 좋은 신호다.
• v=spf1로 시작하는 문자열. 이것은 잘못된 설정이다(이 문자열은 DMARC가 아닌 SPF 정책의 일부여야 한다).

---

귀사의 도메인을 사용하여 이메일을 보내는 별도의 서비스가 몇 개나 되는지 알고 있는가?

참고 자료

1. IETF — RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (2026년 5월; RFC 7489 및 RFC 9091 대체)
2. IETF — RFC 7505: A "Null MX" No Service Resource Record for Domains That Accept No Mail
3. Gmail 고객센터 — 이메일 발신자 가이드라인
4. CIO Korea — Proofpoint의 코스피 200 대상 DMARC 분석 (2024년 11월 28일)