DKIM 키 교체, 표준은 왜 강제하지 않았나

몇 년 전에 설정한 DKIM 키로도 여전히 이메일을 검증할 수 있으며, 프로토콜은 이에 대해 아무런 문제도 제기하지 않는다. 이는 의도된 설계다. DKIM 작성자들은 운영자가 정기적으로 키를 교체할 것으로 예상했지만, 교체 시점은 전적으로 운영자의 재량에 맡겼다.

아래에서는 초기 RFC 명세부터 시작하여 DKIM 키 교체를 표준이 어떻게 다루는지 짚어보고, 오늘날 실제 메일 도메인들의 현황을 조사한다.

default._domainkey라는 이름의 DNS TXT 레코드 카드. v=DKIM1, k=rsa, s=email, t=s 태그와 잘린 p= 공개키 값이 있고, 그 아래 'NO EXPIRY FIELD'라는 영문 문구가 있다. 카드 아래 연표는 2015년에서 2026년 너머까지 이어지며, 2026년 지점에 'still valid'라고 표시되어 있다

DKIM 키 교체는 허용되지만 의무는 아니다

2007년 5월에 발표된 RFC 4871은 최초의 DKIM 명세를 도입했다. 이후 2011년 9월에 RFC 6376이 이를 대체했다.

두 표준 모두 서명 키를 표준 DNS TXT 레코드로 다루므로, 키 업데이트는 전적으로 도메인 운영자의 몫으로 남겨둔다.

실제로 RFC 6376(§3.3.3)에서는 키 교체를 이유로 적절한 크기의 키 사용을 정당화한다.

RFC 6376 (§3.3.3): "키는 정기적으로 교체할 수 있으므로 수명이 상대적으로 짧을 수 있다."

설계자들은 운영자가 키를 교체할 것이라고 가정했지만, 이를 강제하지는 않았다.

표준은 v, h, k, n, p, s, t라는 7가지 키 레코드 태그(§3.6.1)만을 정의할 뿐이다.

`x=` 태그

DKIM의 만료 태그인 x=를 지적하는 이도 있을 것이다. 하지만 이 태그는 게시된 키가 아니라 개별 메시지에 적용된다.

RFC 4871(§3.5)은 발신 이메일에 첨부되는 DKIM-Signature 헤더 내부의 x=를 "서명 만료(Signature Expiration)"로 정의한다. 이는 해당 특정 메시지의 서명만 만료시킨다.

DKIM 키 교체 주기

RFC 외적으로는 "N개월마다 키를 교체하라"는 권장 사항이 존재한다.

RFC 8301(2018년 1월)은 최소 키 크기를 상향 조정했다. 최소 1024비트 RSA 키를 요구하며 2048비트를 권장한다.

그럼에도 불구하고 교체 주기에 대해서는 아무런 언급이 없다. 흔히 쓰이는 6개월 키 교체 주기는 M3AAWG DKIM Key Rotation Best Common Practices(2019)에서 유래한 것으로 보인다.

키 관리에 대한 지침 부재는 2008년에 생성된 키가 2026년 현재에도 여전히 기업 이메일에 서명할 수 있는 이유를 설명해 준다. 예를 들어, 유출된 일부 데비안(Debian) OpenSSL 키는 오늘날에도 여전히 이메일에 서명하고 있다.

도메인 레코드 방치 현황

보안 연구자 하노 벡(Hanno Böck)은 2024년에 그 결과를 다음과 같이 요약했다.

하노 벡: "DKIM에는 키를 교체해야 한다는 요구 사항이 없다. 상당수의 기업이 2007년에 DKIM TXT 레코드를 설정한 후 한 번도 변경하지 않은 것으로 보인다."

우리의 2026년 감사에서도 이러한 패턴이 확인되었다. 자주 사용되는 11개 셀렉터(selector)를 기준으로 111,010개의 한국 메일 도메인을 스캔한 결과, 8,559개 도메인이 DKIM 키를 게시하고 있었으며, 대다수가 google, default, selector1과 같이 예측 가능한 셀렉터를 사용하고 있었다.

이 8,559개 도메인 중:

53%가 구형 1024비트 키로 서명한다.
45%가 2048비트 키를 사용한다.
17개 도메인은 검증에 완전히 실패하는 손상된 레코드를 게시하고 있다.

DNS 레코드에는 생성 타임스탬프가 없지만, 기본 셀렉터에 설정된 1024비트 키는 '설정 후 방치(set-and-forget)'된 상태, 즉 초기 설정 시 생성된 뒤 방치된 키임을 보여준다. 더 심각한 것은 손상된 17개 레코드 중 16개가 p=none 정책 또는 정책 미설정 상태의 DMARC 아래에서 작동하여, 손상된 키가 운영자에게 알림을 주지도 않은 채 조용히 실패하고 있었다는 점이다.

'8,559 DOMAINS PUBLISHING A DKIM KEY (KOREA)'라는 영문 문구 아래 세 줄의 눈금 그래프. 1024비트 53%, 2048비트 45%, 그리고 마지막 17개가 붉게 표시된 짧은 줄에 'corrupt'라고 적혀 있다

자체 키 교체 주기 수립하기

DKIM 키를 교체하는 방법은 간단하다.

새로운 셀렉터 아래에 새 키를 생성한다.
메일 서명기(mail signer)가 새 셀렉터를 가리키도록 설정한다.
전송 중인 메시지가 모두 처리되면 이전 DNS 레코드를 제거한다.

6개월마다 키를 교체하는 등 명확한 내부 정책을 수립하라.

또한 1024비트 키를 교체하게 된다면 이 기회에 2048비트 이상으로 업그레이드하라.

조직에서 마지막으로 새 DKIM 셀렉터를 게시한 것은 언제인가? 오래된 레코드가 여전히 DNS에서 활성화되어 있지는 않은가?

참고 문헌

RFC Editor — RFC 4871: DomainKeys Identified Mail (DKIM) Signatures (2007년 5월)
RFC Editor — RFC 6376: DomainKeys Identified Mail (DKIM) Signatures (2011년 9월)
RFC Editor — RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM (2018년 1월)
M3AAWG — DKIM Key Rotation Best Common Practices (2019년 3월)
Hanno Böck — 16 years of CVE-2008-0166 - Debian OpenSSL Bug - Breaking DKIM and BIMI in 2024 (최초 게시: 2024년 5월 12일)
Panke — 2008년 발생한 Debian 버그가 여전히 기업 이메일에 서명하고 있다 (2026년 9월 15일)
Panke — 한국 메일 도메인 111,010개 대상 DKIM 스캔 (자체 측정, 2026년 9월)