DKIM이란? 이메일 인증 표준 완벽 가이드

DKIM(DomainKeys Identified Mail)은 이메일 인증을 위한 암호화 프로토콜입니다. DKIM이란 무엇인지 실무 관점에서 설명하면: 메일 서버가 전송하는 모든 발신 메시지에 RSA 서명을 첨부하는 시스템입니다. 수신 MTA는 DNS에서 공개 키를 가져와 서명을 검증하고 결과를 dkim=pass 또는 dkim=fail로 보고합니다. 이 결과는 도메인의 평판 모델에 반영되며 DMARC 정렬이 유지되는지 여부를 결정합니다. 유효한 서명이 없으면 수신 MTA는 메시지가 귀하의 인프라에서 전송되었다는 암호화 확인을 받지 못합니다.

DKIM은 서명 프로토콜이지 필터가 아닙니다

이 이름은 흔한 오해를 불러일으킵니다. DKIM은 이메일을 차단하지 않습니다. 메시지를 격리하거나 자체적으로 정책을 적용하지도 않습니다. DKIM이 하는 것은 모든 발신 메시지에 검증 가능한 주장을 스탬프하는 것입니다: 이 메시지는 d= 필드의 도메인이 s= 선택자에 해당하는 개인 키를 사용하여 서명했습니다.

수신 MTA는 그 주장을 가져와 <선택자>._domainkey.<도메인>에 DNS 쿼리를 구성하고, 공개 키가 포함된 TXT 레코드를 가져와 암호화 검증을 실행합니다. 검증이 성공하면 인증 결과 헤더에 dkim=pass가 표시됩니다. 실패하면 dkim=fail 또는 dkim=temperror가 표시됩니다.

두 결과 중 어느 것도 그 자체로 거부를 유발하지 않습니다. 이 신호는 수신 서버의 평판 모델과, 결정적으로 DMARC 평가에 반영됩니다. DKIM의 역할은 검증 가능한 결과를 생성하는 것이지, 그에 따라 행동하는 것이 아닙니다.

DKIM이 서명하는 것과 서명이 다루는 범위

DKIM은 두 가지를 서명합니다: 선택된 메시지 헤더와 메시지 본문입니다. 서명 알고리즘은 둘 다 해시하고 결과를 DKIM-Signature 헤더 필드에 저장합니다.

헤더 목록은 서명의 h= 태그로 제어됩니다. 일반적인 프로덕션 설정에는 from:subject:date:message-id:content-type이 포함됩니다. DMARC 정렬에 중요한 헤더는 from 헤더입니다. 본문 해시는 simple 또는 relaxed 정규화를 통해 정규화된 전체 메시지 본문을 포함합니다.

relaxed 정규화는 대부분의 프로덕션 스택이 사용하는 방식입니다. 해싱 전에 공백을 정규화하므로 릴레이 MTA에 의한 소소한 재포맷팅에서도 서명이 살아남을 수 있습니다. simple은 더 엄격합니다: 단 하나의 후행 공백 변경만으로도 서명이 깨집니다. 잘 구성된 거의 모든 ESP의 DKIM-Signature 필드에는 c=relaxed/relaxed가 표시됩니다.

DKIM이 서명하지 않는 것: SMTP 봉투 발신자, Received와 같은 라우팅 헤더, h= 목록 외의 모든 헤더. 이것은 의도적인 설계입니다. 봉투에 서명하면 전달 시나리오가 깨지는데, 이것이 SPF에 대한 DKIM의 장점이 되는 부분입니다.

선택자: 레이블로 취급되는 액세스 제어 메커니즘

선택자는 대부분의 팀이 압박 속에서 키 교체가 필요해질 때까지 과소평가하는 DKIM의 부분입니다.

DKIM-Signature의 s= 필드는 DNS의 특정 공개 키를 가리킵니다. 조회 형식은 <선택자>._domainkey.<귀하의도메인.com>입니다. 선택자가 mail2026이고 도메인이 example.com이라면, 리졸버는 mail2026._domainkey.example.com에서 TXT 레코드를 찾습니다.

하나의 도메인이 여러 활성 선택자를 동시에 가질 수 있습니다. 각 발송 서비스, 각 ESP, 각 내부 MTA는 자체 선택자를 사용해야 합니다. 이를 통해 세 가지 구체적인 운영 능력을 갖게 됩니다:

• 다른 발송자에 영향을 미치지 않고 서비스별 독립적인 키 교체.

• 인증 로그에서 추적 가능한 귀속: 선택자는 특정 메시지에 어떤 서명 키가 사용되었는지 알려줍니다.

• 깔끔한 오프보딩: 선택자의 DNS 레코드를 삭제하면 해당 ESP가 귀하의 도메인으로 서명할 수 없게 됩니다.

추적 로그에서 관찰되는 것: 모든 발송 서비스에 공유 선택자를 구성한 팀은 다른 모든 팀을 방해하지 않고 단일 발송자의 액세스를 취소할 수 없습니다. 선택자는 장식이 아닙니다. 액세스 제어 메커니즘입니다.

DKIM과 DMARC 정렬: 시행 레이어가 실제로 작동하는 방식

DKIM 통과는 DKIM 정렬이라고 하는 특정 유형의 DMARC 통과를 위한 전제 조건입니다.

DMARC는 두 가지 정렬 조건 중 하나 이상을 요구합니다: SPF 정렬 또는 DKIM 정렬. DKIM 정렬은 From: 헤더의 도메인이 DKIM 서명의 d= 값과 일치하고 서명이 검증됨을 의미합니다. 두 조건이 모두 충족되면 DMARC는 메시지를 인증된 것으로 간주합니다.

DKIM이 더 내구성 있는 인증 신호인 이유입니다. SPF 정렬은 전달 시 깨집니다: 메시지가 전달될 때 SMTP 봉투 발신자가 변경되고 SPF 평가는 새로운 발송 IP에 대해 실패합니다. DKIM 정렬은 전달을 견뎌냅니다. 서명과 From: 헤더가 메시지 본문과 함께 이동하고, 전송 중 본문이 수정되지 않는 한 릴레이 MTA에 의해 다시 작성되지 않기 때문입니다.

DMARC 정책이 p=reject인 도메인의 경우, SPF와 DKIM 정렬 모두에 실패한 메시지는 수신 MTA에 의해 거부됩니다. 이것이 귀하의 도메인에서 스푸핑된 이메일이 대규모로 받은 편지함에 도달하는 것을 막는 메커니즘입니다. DKIM은 여기서 최후의 방어선이 아닙니다. 하지만 전달이 경로에 있을 때 유지되는 방어선입니다.

2024년 이후 Google, Yahoo, Microsoft는 하루 5,000개 이상의 메시지를 MX로 보내는 대량 발송자에게 DKIM을 요구합니다. 서명되지 않은 도메인의 메시지는 기본적으로 스팸으로 라우팅되거나 거부됩니다.

이것은 마케팅 기능이 아닙니다. 인프라 제약입니다.

키 길이와 교체: 2026년의 실용적인 결정

대부분의 DKIM 구현은 RSA-SHA256을 사용합니다. 핵심 질문은 키 길이입니다.

1024비트 RSA 키는 여전히 레거시 구성에서 나타납니다. NIST는 2015년에 대부분의 사용 사례에서 1024비트 RSA를 폐기했습니다. 2048비트 키는 훨씬 강력한 마진을 제공하며 모든 주요 MTA 및 수신 공급자가 지원합니다. 오늘 새 키를 생성한다면 2048비트를 사용하세요.

일부 팀은 활성 서명 키를 2048비트로 마이그레이션했지만 인벤토리를 감사한 사람이 없어 이전 1024비트 선택자를 DNS에 게시된 채로 남겨뒀습니다. 시스템 동작을 변경하는 세 가지 신호: 이전 선택자에서 k=rsa와 1024비트 키가 보이면, 현재 서명 인프라가 이미 전환되었더라도 해당 선택자는 취약점입니다. 유효하지만 더 이상 사용되지 않는 선택자는 악용 가능합니다.

키 교체 일정: 대부분의 인프라 팀은 연간으로 교체하고, 더 민감한 도메인의 경우 일부는 분기별로 교체합니다. 순서가 중요합니다:

• 새 키 쌍을 생성합니다.

• DNS의 새 선택자 이름 아래에 새 공개 키를 게시합니다.

• TTL 전파를 기다립니다. 일반적으로 낮은 TTL을 가진 레코드의 경우 24~48시간이 걸립니다.

• MTA 구성의 서명 키를 새 선택자로 전환합니다.

• 이메일 테스트 도구를 통해 또는 테스트 메시지의 인증 결과 헤더를 검사하여 발신 메시지에서 DKIM 통과를 확인합니다.

• 새 키가 라이브 상태이고 올바르게 서명하는 것을 확인한 후 이전 DNS 레코드를 삭제합니다.

순서를 따르면 교체는 중단 없이 이루어집니다: 먼저 DNS, 그 다음 서명 전환, 마지막으로 이전 레코드 삭제. 4단계와 6단계를 바꾸면 dkim=fail 창이 발생합니다.

DKIM 설정 후 추적해야 할 운영 신호

DKIM은 일회성 구성 작업이 아닙니다. 다음 신호는 무언가 변경되거나 중단되었음을 나타냅니다.

수신 헤더에 dkim=temperror. 일시적인 실패는 일반적으로 수신 측의 DNS 조회 문제 또는 키 교체 중 TTL 불일치를 나타냅니다. 키 교체 직후 발신 메시지에서 이것이 보이면 키 자체가 잘못 구성되었다고 결론짓기 전에 전체 전파를 기다리세요.

보낸 메시지에 dkim=fail. 중간 릴레이에 의한 본문 수정이 가장 일반적인 원인입니다. 배달 경로에 전달 홉, 메일링 리스트 프로세서, 또는 푸터를 삽입하는 릴레이가 있는지 확인하세요. 단일 흐름에서 일관되게 실패하면 릴레이 체인을 홉별로 매핑하세요.

DKIM-Signature 헤더가 완전히 누락됨. MTA의 서명 데몬이 실행되지 않거나, 서명 키 경로가 잘못되었거나, MTA 구성에서 도메인 선택자 매핑이 잘못 구성되었습니다. 이는 영향받는 메시지 흐름에 대한 완전한 DKIM 중단입니다.

선택자 TXT 레코드가 DNS에 없음. DKIM 선택자 레코드를 보존하지 않고 DNS 영역이 편집 또는 마이그레이션되었습니다. 외부 리졸버에서 dig TXT <선택자>._domainkey.<도메인>으로 확인하세요.

다중 지역 발송 설정에서 노드 전체에 걸쳐 불일치하는 DKIM 결과는 종종 다른 노드가 다른 선택자 구성을 사용하기 때문에 발생합니다. 교체를 배포하기 전에 모든 발송 노드에서 서명 키 구성이 동기화되었는지 확인하세요.

DKIM이 보호하지 않는 것

DKIM은 스팸 필터가 아닙니다. 발송자는 새 도메인을 등록하고 유효한 DKIM을 구성하여 완전히 인증된 스팸을 보낼 수 있습니다. 서명은 깨끗하게 검증됩니다. 인증은 출처를 확인하지, 의도나 콘텐츠 품질을 확인하지 않습니다.

DKIM은 또한 표시 이름 스푸핑도 다루지 않습니다. From: 헤더에 "급여팀"과 같은 신뢰할 수 있는 이름이 표시되고 공격자가 제어하는 도메인과 연결되는 경우입니다. 암호화 검증은 도메인에서 작동하며, MUA의 시각적 표현에서는 작동하지 않습니다. MUA 수준에서의 피싱 대부분은 정확한 도메인 스푸핑이 아닌 표시 이름 기만에 의존합니다.

DKIM이 보호하는 것: 귀하의 개인 키 없이 귀하의 도메인으로 보내려는 공격자의 정확한 도메인 스푸핑. DKIM 정렬을 적용하는 p=reject DMARC 정책과 결합하면, DMARC를 적용하는 수신 공급자에서 스푸핑된 메시지 클래스가 받은 편지함에 도달하는 것을 방지합니다.

실용적인 참고 사항: DKIM만으로는 충분하지 않습니다. 보호 모델은 수신 MTA에서의 DMARC 정책 적용이 필요합니다. DKIM은 DMARC를 의미 있게 만드는 인증 레이어입니다. SPF는 다른 인증 레이어로, 봉투 발신자 확인을 처리합니다. 세 가지 모두 함께 작동합니다. 이 중 하나라도 없으면 시행 체인에 gap이 남습니다.

DKIM과 SPF를 이미 구성했지만 DMARC 레코드를 아직 게시하지 않은 경우, 서명은 존재하지만 활성 시행 정책이 없습니다. 모니터링 모드(rua 보고가 있는 p=none)는 합리적인 첫 번째 단계입니다: p=quarantine 또는 p=reject에 커밋하기 전에 발송 도메인 전체의 인증 통과율을 보여주는 집계 보고서를 받습니다.