정의
DKIM(DomainKeys Identified Mail)은 공개 키 암호화를 사용해 발신 메시지에 서명하는 이메일 인증 사양으로, 수신 메일 서버가 이메일이 주장된 도메인에서 왔는지, 그리고 메시지 본문과 선택된 헤더가 전송 중에 수정되지 않았는지 확인할 수 있게 합니다. 서명 도메인은 자신의 공개 키를 DNS에 게시하고, 수신 서버는 이 키를 가져와 DKIM-Signature 이메일 헤더에 임베드된 서명을 검증합니다.
DKIM은 두 개의 초기 제안 — Yahoo의 DomainKeys와 Cisco의 Identified Internet Mail — 에서 발전했으며, 2007년 IETF RFC 4871로 처음 발표되었습니다. 현재의 권위 있는 사양은 2011년 9월에 발표된 RFC 6376이며, 더 강력한 암호화 알고리즘을 의무화한 RFC 8301(2018)과 RFC 8463(2018)로 갱신되었습니다. DKIM은 이메일 생태계 전반에 광범위하게 배포되어 있고, 의미 있는 보호를 제공하는 DMARC 정책에 필수 구성요소입니다.
작동 방식
조직의 메일 서버가 메시지를 발신할 때, DKIM 서명 모듈(Postfix, Exim, Microsoft Exchange 같은 MTA에 내장되어 있거나 SendGrid, Mailgun, Amazon SES, Postmark 같은 트랜잭셔널 공급자가 서비스로 제공)이 다음 작업을 수행합니다.
서명자는 서명에 포함할 헤더의 부분 집합을 선택합니다. 보통 From, To, Subject, Date, Content-Type이며, 두 가지 정의된 알고리즘 중 하나로 정규화합니다. simple(최소한의 공백 정규화) 또는 relaxed(전송 중 사소한 헤더 재작성을 허용하는, 더 관대한 방식)입니다. 메시지 본문도 마찬가지로 정규화되고 SHA-256(RFC 8301이 SHA-1을 더 이상 권장하지 않게 된 이후로 의무화된 알고리즘)으로 해싱됩니다. 서명자는 헤더 해시와 서명 메타데이터의 구조화된 문자열 위에 RSA 또는 Ed25519 디지털 서명을 계산하고, 메시지 맨 위에 DKIM-Signature 헤더를 삽입합니다.
DKIM-Signature 헤더에는 다음이 포함됩니다. v=1(버전), a=rsa-sha256(알고리즘), d=example.com(서명 도메인, d= 태그라 부름), s=selector1(셀렉터, 특정 공개 키 조회용), h=from:to:subject(서명된 헤더), bh=<본문 해시>, b=<base64 서명>.
도메인 소유자는 해당 공개 키를 <셀렉터>._domainkey.<도메인>에 DNS TXT 레코드로 게시합니다. Gmail, Outlook, Yahoo Mail 또는 RFC 6376 호환 MTA가 메시지를 수신하면, DNS에서 해당 레코드를 조회해 공개 키를 가져온 뒤 암호학적 서명을 검증합니다. 유효한 서명은 DKIM 결과 pass를 만듭니다. 서명이 없거나 유효하지 않은 경우, 또는 서명된 헤더나 본문이 전송 중에 수정된 경우 fail 또는 neutral 결과가 나오고 이 결과는 DMARC 평가 엔진에 전달됩니다.
셀렉터(s= 태그)는 도메인이 여러 DKIM 키를 동시에 게시할 수 있게 합니다. 서비스 중단 없이 키를 교체할 때, 또는 발송 시스템 별로 키를 분리할 때(예: marketing._domainkey.example.com vs transactional._domainkey.example.com) 유용합니다.
어디에서 마주치게 되나
DKIM은 이메일 의존 서비스라면 어디서나 기본이 되는 도달성 요건입니다. Amazon SES, SendGrid(Twilio 산하), Mailgun(Sinch 산하), Postmark, SparkPost 같은 트랜잭셔널 이메일 공급자는 도메인 검증 단계의 필수 설정으로 DKIM 서명을 포함합니다. 공급자는 RSA-2048 또는 Ed25519 키 쌍을 생성하고, 공개 키를 DNS TXT 레코드 형태로 보여주며, 도메인 소유자가 이를 게시한 뒤에야 해당 도메인에서의 발송을 활성화합니다.
이메일 확인 투표를 발송하는 콘테스트 플랫폼에서 DKIM 서명은 특히 중요합니다. 확인 메일이 주요 메일박스 공급자 — Google Workspace / Gmail, Microsoft Outlook과 Exchange Online Protection, Yahoo Mail, Apple iCloud Mail, ProtonMail — 의 인증 검사를 통과해야 하기 때문입니다. 서명되지 않은 메시지나 서명이 실패한 메시지는 스팸함으로 가거나 완전히 차단될 가능성이 훨씬 높아, 유권자가 자신의 제출을 확인하지 못하게 됩니다.
Mail-Tester, GlockApps, MXToolbox DKIM Lookup 같은 이메일 테스트 도구를 사용하면 발송 전에 DKIM 설정을 점검하고 검증할 수 있습니다. Google Postmaster Tools와 Microsoft SNDS는 DKIM 통과율을 시간 순으로 반영하는 집계 수준의 도달성 데이터를 제공합니다.
실무 예시
한 콘테스트 플랫폼이 도메인 votes.example.com에 DKIM 셀렉터 s=contest를 설정하고, 공개 키를 contest._domainkey.votes.example.com에 게시합니다. 모든 발신 확인 메일에는 해당 비공개 키로 서명된 DKIM-Signature 헤더가 포함됩니다. 유권자의 Gmail 계정이 메시지를 받으면, Gmail의 인바운드 필터가 DNS를 조회해 서명을 검증하고 통과를 기록한 뒤 결과를 스팸 분류기로 전달합니다. 확인된 DKIM 통과는 SPF 정렬과 함께 DMARC 준수 조건을 충족시킵니다.
콘테스트 관리자가 RFC 8301을 읽은 뒤, 더 이상 암호학적으로 충분하지 않은 1024비트 RSA 키에서 2048비트 RSA 키로 교체합니다. 전송 중인 메시지를 다루기 위해 7일간은 이전 셀렉터를 유지한 다음 DNS에서 제거합니다. 모든 새 메시지는 갱신된 셀렉터와 키를 사용합니다.
관련 개념
DKIM은 발신 서버의 IP 주소를 인증하는 SPF Record, 그리고 SPF와 DKIM 결과에 기반해 정책 조치와 보고 메커니즘을 정의하는 **DMARC**와 함께 작동합니다. 두 신호는 함께 이해되어야 합니다. d= 도메인이 RFC5322.From 도메인과 정렬되지 않으면 DKIM만 통과해도 메시지가 DMARC를 준수하는 것은 아닙니다. 콘테스트 운영 맥락에서 DKIM 실패의 실질적 결과는 **Email Confirmation Vote**에서 설명됩니다. 거기서는 확인 메시지의 인박스 도달이 던진 표가 집계되는지를 직접 결정합니다.
