조회수: 28

DKIM 검증 실패: dkim=fail과 body hash 불일치 진단

정상적으로 서명한 메일이 DKIM에 실패하는 이유 — body hash 불일치, 셀렉터 누락, 키 폐기, DMARC 정렬 — 와 원인을 찾는 방법.

내 도메인에 이 문제가 있는지 지금 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.

Problem

메일은 서명됐습니다. DKIM-Signature 헤더도 보입니다. 그런데도 수신 측은 dkim=fail을 보고합니다. 서버를 떠나는 순간에는 서명이 유효했지만, 당신과 수신자 사이의 어딘가에서 메시지가 바뀌었거나, 수신 측이 가져온 공개키가 서명에 쓰인 키와 더 이상 일치하지 않는 것입니다.

DKIM은 메일이 “좋은” 메일인지 검사하지 않습니다. 오직 한 가지 좁은 사실만 검사합니다 — 서명된 부분이 서명된 그대로, 바이트 단위로, DNS에 게시된 키를 사용해 도착했는가. 그 중 무엇이든 틀어지면 검증은 실패합니다. 악의적인 것이 전혀 없어도 마찬가지입니다.

Symptoms

  • Authentication-Resultsdkim=fail이 보이고, 흔히 (body hash did not verify)가 함께 표시됩니다.
  • 발송 전 테스트에서는 통과하지만 리스트나 포워딩을 거치면 실패합니다.
  • 메일은 서명됐다고 믿는데 dkim=none이 나옵니다.
  • DKIM은 검증되는데 DMARC는 여전히 실패로 보고됩니다.

Top 3 Causes

  1. 서명 이후 본문이 수정됨 — 메일링 리스트, 포워딩, 회사 게이트웨이가 푸터를 덧붙이거나 링크를 다시 쓰거나 콘텐츠 인코딩을 바꿨습니다. bh= body hash가 더 이상 맞지 않아 서명이 실패합니다. 단연 가장 흔한 원인입니다.
  2. 공개키가 없거나 교체됐거나 폐기됨 — 수신 측은 서명의 s= 셀렉터를 사용해 selector._domainkey.도메인에서 키를 가져옵니다. 그 TXT 레코드가 게시된 적이 없거나, 키 교체 후 옛 키를 가리키거나, p= 값이 비어 있으면(의도적으로 폐기된 키) 검증이 실패하거나 서명이 없는 것으로 처리됩니다.
  3. DKIM은 통과하지만 DMARC 정렬에 실패 — 서명이 From 도메인이 아닌 다른 d= 도메인에 대해 검증됩니다. DMARC에서는 통과한 DKIM 서명이라도 d=가 화면의 From: 헤더와 정렬돼야 의미가 있습니다 — strict 정렬은 정확히 일치해야 하고, relaxed는 같은 조직 도메인이면 됩니다.

Diagnose with DechoNet

  • Email Header Analyzer로 실제 Authentication-Results를 읽고, 결과가 fail인지 none인지 구분하고, 어느 홉(hop)이 메시지를 수정했는지 추적합니다.
  • Email Deliverability Test로 도메인의 일반적인 셀렉터에서 DKIM 키가 감지되는지 확인합니다.
  • DNS Lookupselector._domainkey TXT 레코드가 존재하고 기대한 키를 제공하는지 검증합니다.

Resolution Checklist

  • 결과를 정확히 읽으세요: fail은 깨진 서명, none은 서명 없음입니다. 맞는 문제를 고쳐야 합니다.
  • 결과가 body hash did not verify라면 본문을 다시 쓰는 무언가를 찾으세요 — 리스트 푸터, 면책 문구 추가, 링크 재작성, 또는 변경된 Content-Transfer-Encoding.
  • DKIM-Signature의 셀렉터(s=)가 실제로 selector._domainkey.도메인에 게시된 키로 해석되는지 확인하세요.
  • 키를 교체한 뒤에는 옛 셀렉터를 폐기하기 전에 공개키가 먼저 게시됐는지 검증하세요.
  • DMARC가 중요하다면 서명 도메인(d=)이 From 도메인과 정렬되는지 확인하세요.
  • l= body-length 태그는 피하세요. RFC 6376 §8.2는 이 태그가 서명된 길이 이후에 공격자가 서명되지 않은 콘텐츠를 덧붙이고도 DKIM을 통과시킬 수 있다고 경고합니다 — 많은 검증기가 이 태그를 쓴 서명을 신뢰하지 않습니다.
  • 로컬 점검만이 아니라 실제 전달 경로로 보내 다시 테스트하세요. 수정은 보통 전송 중에 일어납니다.

When to Escalate

  • 플랫폼이 본문을 다시 쓰는 경우 메일링 리스트나 포워딩 운영자에게 이관하세요. 깔끔한 해결책은 리스트가 자체 키로 다시 서명하고 리스트 도메인에 DMARC를 게시하는 것입니다 — 발송 측에서는 고칠 수 없습니다.
  • 셀렉터 레코드가 없거나, 교체 후 갱신되지 않았거나, 게시되는 키를 통제할 수 없다면 이메일 제공업체나 DNS 관리자에게 이관하세요.

관련 도구

관련 가이드

가이드 공유

[Ad] Guide Detail Inline
← 전체 가이드 보기