이메일을 서명하고 검증하는 표준인 DKIM의 후속 규격 DKIM2가 다음 공개 단계에 도달했습니다. DKIM을 새로 작성 중인 IETF 워킹그룹은 2026년 5월 17일 최신 규격 초안을 공개했으며, 앞으로 12~18개월 안에 정식 승인 절차로 진행할 예정입니다. 이 글에서는 DKIM2가 이메일 서명 방식에서 무엇을 바꾸는지, IETF가 왜 지금 표준을 새로 만드는지, 그리고 현재 DMARC를 운영하는 도메인 소유자에게 어떤 요구가 있는지(있다면) 정리합니다.
DKIM(DomainKeys Identified Mail)은 자기 도메인에서 보냈다고 주장하는 메시지가 전송 중에 변조되었거나 위조되었는지를 수신 측 메일박스 제공자에게 알려주는 역할을 합니다. DMARC가 의존하는 두 가지 암호학적 검증 가운데 하나입니다(다른 하나는 SPF). DKIM은 2007년부터 이메일 업계의 서명 표준으로 사용되어 왔습니다. IETF는 단순한 패치보다 더 큰 작업을 공개적으로 진행하고 있습니다. DKIM이 자체적으로는 해결하지 못한 세 가지 문제를 정면으로 다루는 전면 재설계입니다.
DKIM(DomainKeys Identified Mail, RFC 6376에 정의됨)은 모든 발신 이메일에 암호학적 서명을 붙이는 방식으로 동작합니다. 발신 도메인은 DNS에 공개키를 게시하고, 수신 서버는 이 공개키로 서명을 검증합니다. 서명이 일치하면 수신자는 두 가지를 신뢰할 수 있습니다. 해당 도메인의 개인키 접근 권한을 가진 누군가가 메시지를 보냈다는 점, 그리고 본문과 선택된 헤더가 전송 중 수정되지 않았다는 점입니다.
이 메커니즘에는 알려진 약점이 세 가지 있으며, IETF DKIM 워킹그룹은 DKIM2 동기 초안(draft-ietf-dkim-dkim2-motivation)에 이 세 가지를 모두 정리해 두었습니다.
이러한 약점은 실제 인증 데이터에서도 확인됩니다. DMARCeye Q1 2026 산업 보고서에서, 대형 메일박스 제공자와 기업 메일 시스템의 DKIM 실패율은 높게 나타납니다. Microsoft 19.6%, Google 11.1%, Proofpoint 26.3%, Mailgun 22.9%입니다. 같은 데이터셋에서 최상위 트랜잭션 발신자(Bird, Amazon SES, SendGrid)는 DKIM 실패율이 1% 미만으로 측정됩니다. 두 그룹 사이의 이 격차가 바로 DKIM2가 해결하려는 운영 현실입니다.
Q1 보고서 자체에서도 지적하듯, 주요 메일박스 제공자에서 나타나는 높은 실패율은 거의 항상 제공자의 결함이 아니라 고객 측 설정 문제입니다. Microsoft 365나 Google Workspace 테넌트를 거치는 발신 메일은 포워더, 메일링 리스트, 서드파티 릴레이, 오래된 온프레미스 게이트웨이를 통과합니다. 이 가운데 하나만 잘못되어도 고객이 알아채지 못한 사이 DKIM 서명이 깨질 수 있습니다.
합리적인 가설은 이렇습니다. 전용 트랜잭션 발신자의 수치가 가장 깨끗한 이유는 사업 전체가 단일 서명 파이프라인을 통해 한 가지 유형의 메일만 발송하기 때문입니다. 반면 범용 메일박스 제공자는 원래의 DKIM 규격이 보존하도록 설계된 적이 없는 훨씬 다양한 메일 흐름을 처리합니다. ESP별 컴플라이언스 비율을 더 자세히 분석한 글에서 같은 패턴을 발신 측 관점으로 살펴볼 수 있습니다.
DKIM2는 기본 발상은 그대로 유지합니다. 모든 발신 이메일에 서명을 붙여 수신자가 자기 도메인에서 보냈음을 검증할 수 있게 한다는 것입니다. 다만 서명이 동작하는 방식 자체를 다시 설계했습니다. 현재 규격 초안(draft-ietf-dkim-dkim2-spec-02, 2026년 5월 17일 표준 트랙으로 공개됨)은 네 가지 실질적 변화를 도입합니다.
전달 경로상의 모든 서버가 메시지에 서명합니다. 오늘날 이메일을 보내면 발신 서버만 서명합니다. 전달 경로 중간에서 무엇이든 메시지를 건드리면(기업 자동 포워더, 제목에 접두어를 붙이는 메일링 리스트, 헤더를 수정하는 이메일 보안 게이트웨이 등) 원래 서명이 깨지고, 수신 측에서는 무엇이 어떻게 바뀌었는지, 누가 바꿨는지 알 길이 없습니다. DKIM2는 이를 바꿉니다. 메시지를 처리하는 모든 메일 서버가 자신만의 서명을 추가하므로, 수신자는 어떤 도메인이 어떤 순서로 메시지를 거쳤는지 검증 가능한 사슬을 받게 됩니다. 이 보관 사슬(chain-of-custody) 개념은 Authenticated Received Chain 프로토콜(ARC, RFC 8617에 정의됨)에서 먼저 시도된 바 있으며, 이는 실험적 부가 규격으로서 이제 DKIM2로 대체되어 폐기될 예정입니다.
서명은 메시지의 실제 수신자와 묶입니다. 오늘날 DKIM은 이메일의 내용(본문과 선택된 헤더 일부)에는 서명하지만, 이메일을 받는 사람이 누구인지는 포함하지 않습니다. 서명된 메시지 한 통을 확보한 스팸 발송자가 그것을 수백만 명에게 다시 보내도 모든 사본이 서명 검증을 통과하는 이유가 여기에 있습니다. DKIM2는 라우팅 엔벨로프까지 서명해 이 문제를 해결합니다. MAIL FROM 주소(발신자)와 메시지가 발송된 RCPT TO 주소(수신자) 모두에 서명합니다. 다른 수신자 목록으로 재전송된 DKIM2 서명 메시지는 즉시 검증에 실패합니다. 엔벨로프상의 수신자 주소가 원래 서명자가 서명한 내용과 더는 일치하지 않기 때문입니다.
전송 중에 메시지를 수정하는 서버는 자신이 무엇을 바꿨는지 기록으로 남깁니다. 오늘날 메일링 리스트가 제목줄에 "[리스트 이름]" 접두어를 붙이거나 본문에 풋터를 덧붙이면, 원래 DKIM 서명은 조용히 깨지고 수신 측에서는 그 변경이 무해한 편집이었는지 적대적 조작이었는지 알 수 없습니다. DKIM2에서는 수정하는 서버가 자신이 바꾼 내용을 묘사한 작은 기계가독 메모를 첨부할 수 있습니다. 수신 측 소프트웨어는 기록된 변경 사항을 하나씩 되돌려 원본 메시지를 복원한 뒤, 복원본에 대해 원래 서명을 검증합니다. 변경 메모의 형식은 별도의 동반 초안에서 규정합니다.
반송 메시지도 서명되므로 위조될 수 없습니다. 보내지도 않은 이메일에 대한 반송 알림을 받아 본 적이 있다면, "백스캐터(backscatter)"를 경험한 것입니다. 스팸 발송자가 당신의 발신자 주소를 위조했고, 수신 서버는 메시지 배달을 시도했다가 실패하면서 그 반송을 스팸 발송자가 아니라 당신에게 되돌려 보낸 결과입니다. DKIM2는 반송 메시지 자체를 수신 서버가 암호학적으로 서명하도록 요구해 이 문제를 막습니다. 반송은 원래 메시지를 받은 도메인에서만 발송될 수 있고, 원래 메시지를 보낸 도메인에만 도달할 수 있습니다.
DKIM 워킹그룹은 그 이유를 솔직하게 밝힙니다. DKIM 위에 보관 사슬 처리 기능을 덧붙이려던 이전 시도가 신뢰할 수 있는 수준의 배포에 도달하지 못했다는 것입니다. 2019년 RFC 8617로 공개된 ARC는 메일링 리스트와 포워더 문제에 대한 IETF의 첫 답이었습니다. ARC는 중간 처리자가 메시지를 다룬 시점의 인증 상태를 증언할 수 있게 했고, 이론적으로는 DKIM 자체가 도중에 깨지더라도 하류 수신자가 그 사슬을 신뢰할 수 있게 해주는 구조였습니다.
실제로는 ARC가 실험적 규격에 머물렀고 채택률도 고르지 못했습니다. DKIM2 동기 초안은 새로운 표준이 "ARC 실험을 구현하면서 배운 교훈을 바탕으로" 만들어지고 있다고 명시합니다. ARC는 별도의 IETF 초안을 통해 Historic 등급으로 재분류될 예정입니다. DKIM2는 같은 보관 사슬 개념을 통합해 정식 제품 수준으로 다시 설계한 버전이며, 선택적 부가물이 아니라 DKIM의 핵심 후속 규격으로 배포될 수 있도록 만들어집니다.
DKIM 워킹그룹이 하고 있는 작업은 DMARC 워킹그룹이 DMARC 자체의 후속 규격인 DMARCbis로 진행 중인 세대 교체 작업과 같은 성격입니다. 두 표준 모두 2007년부터 2015년 사이의 이메일 인증 시대에서 비롯되었고, 모두 10년 넘는 운영 경험을 통해 원래 규격의 한계가 드러난 상태이며, 그 경험을 바탕으로 지금 다시 작성되고 있습니다.
DKIM2가 출시될 때 어떤 모습이든, 오늘 게시하는 DKIM 레코드는 여전히 올바르게 설정되어 있어야 합니다. 잘못 설정된 DKIM 레코드는 정당한 발신자의 메일이 인증 실패로 처리되는 가장 흔한 원인이며, 위의 Q1 2026 데이터가 보여주듯 주요 메일박스 제공자에서의 실패율은 대부분의 도메인 소유자가 짐작하는 것보다 높습니다.
아래에 도메인을 입력해 현재 게시된 DKIM 레코드가 어떻게 구성되어 있으며 제대로 설정되어 있는지 확인해 보세요.
DKIM2가 당신에게 얼마나 중요한지는 이메일 생태계에서 당신이 맡은 역할에 따라 달라집니다.
단일 도메인을 운영하거나 소규모 사업을 운영하는 경우: 오늘 당장 바뀌는 것은 없습니다. 기존 DKIM 레코드는 계속 동작합니다. 메일박스 제공자들은 DKIM2가 공개된 뒤로도 수년간 DKIM1 서명을 계속 검증할 것이며, 주요 제공자가 DKIM2 레코드를 확인하기 시작한다고 신호를 보내기 전까지는 도메인에 DKIM2 레코드 게시가 요구되지 않습니다. 지금 해야 할 일은 현재 DKIM을 제대로 갖추는 것입니다. 발신 출처별로 키 하나, 일정에 따른 키 교체, DMARC 정책과의 정렬이 핵심입니다.
이커머스 스토어를 운영하며 트랜잭션 이메일이 받은편지함에 도달하는 것에 의존한다면, 위에 정리한 Q1 2026 실패율이 더 시급한 문제입니다. DKIM은 고객이 사용하는 메일박스 제공자에서 가장 자주 실패하는 인증 방식이며, 실패는 DKIM2 표준과는 아무 관련이 없는 운영상의 세부 요인(포워더, 메일링 리스트, 키 교체 공백)에서 비롯됩니다. DKIM 모니터링이 아직 마련되어 있지 않다면, DMARCeye의 무료 플랜이 도메인 하나에 대해 보고서 전체 파싱을 제공하므로 DKIM이 안정적으로 서명되고 있는지 확인하기에 충분합니다.
고객사 도메인을 관리하는 에이전시나 MSP라면: DKIM2는 결국 포트폴리오 전반에 걸쳐 조율이 필요한 멀티테넌트 전환입니다. DMARCeye는 각 고객 계정을 독립적으로 분리해 관리하며, 인증 상태를 프로그램 방식으로 조회할 수 있게 해주는 Model Context Protocol 연동도 동일한 분리를 따릅니다. 팀은 단일 콘솔에서 여러 고객 도메인의 DKIM 상태를 모니터링할 수 있고, 각 고객은 자신의 데이터만 볼 수 있습니다. 지금 갖춰 둔 가시성 인프라가 전환 시점에 그대로 활용됩니다.
기업 메일 인프라를 운영한다면: 배포 프로파일 초안(draft-moccia-dkim2-deployment-profile, 2026년 4월 공개)을 주시하세요. 배포 프로파일 초안은 DKIM2가 대부분의 Mail Transfer Agent가 이미 지원하는 기존 milter 인터페이스를 통해 MTA 코어를 수정하지 않고도 구현될 수 있는 방식을 설명합니다. 의미는 분명합니다. DKIM2는 전면 재작성이 아니라 기존 메일 스택에 끼워 넣을 수 있도록 설계되고 있습니다. 지금 키 인벤토리를 작성하고, 어떤 발신 경로부터 먼저 마이그레이션할지 식별해 두세요.
DKIM2는 아직 공개된 RFC가 아니며, 그 단계에 가까이 있지도 않습니다. 본 규격은 2026년 5월 17일 기준 revision 02 상태입니다. IETF 인터넷 드래프트는 6개월 후 만료되므로, 현재 revision은 2026년 11월 전에 다음 단계로 진행되거나 다시 게시되어야 합니다. 여러 부속 초안(동기, DNS 규격, 모범 운영 사례, 배포 프로파일)이 병행해 진행되고 있습니다.
가장 공격적인 일정으로 잡아도 안정적인 규격 초안에서 RFC 공개까지는 보통 12~18개월이 걸립니다. 그 뒤 메일박스 제공자의 채택에는 다시 수년이 필요합니다. DMARC 자체가 2015년 RFC 7489로 공개되었지만 지금도 보편적으로 강제되고 있지는 않습니다. 현실적으로 DKIM2가 발신 메일의 기본값이 되는 시점은 일러야 2020년대 후반입니다.
2026년에 해 둘 만한 일은 자신이 신경 쓰는 모든 도메인에서 DKIM1이 올바르게 설정되어 있는지 확인하는 것입니다. 새로운 규격이 이 점을 바꾸지는 않습니다.
DKIM2는 IETF가 20년 가까운 표준 운영 기간 동안 기록해 온 재전송 공격, 책임 추적, 중간 단계 수정의 세 가지 공백을 정직하게 다시 만들어 해결하려는 작업입니다. ARC에서 효과가 있었던 부분은 이어받고, 그렇지 않은 부분은 버렸으며, 기존 메일 스택 안에 배포할 수 있도록 설계되고 있습니다. 오늘 도메인 소유자에게 요구하는 것은 아무것도 없지만, 지금 마련해 두는 가시성 인프라가 향후 전환을 이끌어 줄 토대가 됩니다.
이미 DMARC 모니터링을 운영하고 있다면, 오늘 할 수 있는 일은 DKIM 서명이 안정적으로 통과하고 있는지, 그리고 레코드가 올바르게 구성되어 있는지 확인하는 것입니다. DMARCeye는 도메인이 수신하는 DMARC 보고서를 파싱해, 원시 XML을 읽지 않고도 DKIM이 어디에서 통과하는지, 어디에서 실패하는지, 무엇이 실패를 일으키는지 평이한 언어로 보여 줍니다.