Defaults.Exposed › 수정 › Guides
DKIM '본문 해시가 검증되지 않음' — 메시지를 변경한 것과 수정 방법 (2026)
게시일 2026-07-08
2026-06-29 기준 수치 · 방법론 v7. 261백만 개의 평가된 도메인에 대한 집계 데이터. 평가 방식 보기.
“Body hash did not verify”는 메시지가 발송될 때 DKIM 서명이 유효했지만 이후 누군가 메시지 본문을 재작성했다는 의미입니다. 서명이 깨진 것이 아니라 전송 중에 메시지가 변조되었습니다. Defaults.Exposed의 261,086,232개 도메인 센서스(2026-06-29) 기준으로 3.87% — 10,092,481개 도메인 — 만이 전체 SPF-DKIM-DMARC 트리아드를 완성합니다.
수정은 추적 후 결정입니다. 메일을 수정하는 홉을 찾으세요 — 고지문을 추가하는 게이트웨이, 링크를 재작성하는 어플라이언스, footer를 추가하는 메일링 리스트. 그런 다음 그 홉 이후에 서명하거나, 수정을 중단하거나, 서명이 허용하도록 만드세요 — 이 순서대로.
”body hash did not verify”는 실제로 무슨 의미인가요?
DKIM 서명(RFC 6376)은 두 개의 해시를 가집니다: bh=, 서명된 메시지 본문의 해시, 그리고 b=, 헤더와 그 본문 해시를 서명합니다. 검증자는 수신한 메시지에서 본문 해시를 재계산합니다; bh=와 일치하지 않으면 검증이 멈추고 모든 사람이 검색창에 붙여넣는 문자열이 나타납니다 — 수신자 헤더:
Authentication-Results: …; dkim=fail (body hash did not verify)
이것은 Microsoft의 문서화된 이유 문자열입니다; Gmail은 종종 같은 진단을 dkim=neutral (body hash did not verify)로 표시합니다. 어느 쪽이든 판정이 문제를 크게 좁힙니다. DNS 키, 셀렉터, 서명 설정이 모두 괜찮습니다. 암호화가 제 역할을 했습니다: 서명과 검증 사이에 본문이 변경되었습니다 — 추가된 줄 하나, 재작성된 URL 하나, 재인코딩된 문자 하나로 충분합니다. (다른 메시지 — signature did not verify, no key for signature — 는 다른 오류를 의미합니다; “DKIM 서명이 유효하지 않음”부터 시작하세요.) 그리고 실패한 서명은 DMARC에 정렬된 통과를 줄 수 없기 때문에 긴급합니다: 같은 메시지에서 SPF가 정렬과 함께 통과하지 않으면 메일이 DMARC에 완전히 실패합니다.
메시지를 변경한 것은 무엇인가요? 일반적인 원인
배달 경로에서 무언가가 서명자가 봉인한 후에 본문을 편집했습니다. 실제로는 네 가지 중 하나입니다:
| 수정한 것 | 변경 내용 | 일반적인 징후 |
|---|---|---|
| 아웃바운드 게이트웨이 / 스마트 호스트 (Exchange 전송 규칙, Mimecast, Proofpoint, Barracuda…) | 메일 서버가 이미 서명한 후 법적 고지문, 마케팅 footer, 또는 “EXTERNAL:” 배너 추가 | 해당 경로의 모든 메시지 실패; 게이트웨이를 우회하는 직접 발송은 통과 |
| 보안 어플라이언스 / 링크 보호 | URL을 스캔 리다이렉트로 재작성, 추적 래퍼 추가 | 링크가 포함된 메시지만 실패 |
| 메일링 리스트 (Google Groups, Mailman…) | 제목 태그와 리스트 footer 추가, 때로는 본문 재편성 | 리스트를 통해 보낸 메일만 실패 |
| 포워더 / 릴레이 MIME 재인코딩 | 문자 집합 변환, 줄 재래핑 — 사람에게는 보이지 않지만 해시에는 치명적 | 하나의 수신자나 전달 주소에서 실패 집중 |
굵게 표시된 행을 먼저 확인하세요 — 메일 서버가 서명하고, 엣지 장치가 편집하며, 모든 메시지가 30밀리초 동안만 사실이었던 서명과 함께 떠납니다.
메일을 수정하는 홉을 어떻게 찾나요?
차별 진단 — 작동하는 경로와 실패하는 경로를 비교합니다:
- 아웃바운드 체인을 최대한 우회하여 주요 수신자(Gmail이 잘 작동합니다)에서 제어하는 사서함으로 직접 테스트 메시지를 보내세요.
- 실패하는 경로 — 게이트웨이를 통해, 리스트를 통해, 영향받는 수신자 도메인으로 — 두 번째 메시지를 보내세요.
- 전체 헤더에서 두
Authentication-Results줄을 비교하세요. 직접 발송dkim=pass, 실패 경로dkim=fail(또는dkim=neutral)body hash did not verify가 포함: 수정자가 두 경로 사이에 있습니다. - 수신된 본문을 보세요: 입력하지 않은 고지문, 배너, footer? 스캔 도메인으로 재작성된 링크? 그것이 홉이며 —
Received:체인이 실패 경로에만 나타나는 릴레이를 보여줍니다.
DMARC 집계 보고서도 대규모로 같은 이야기를 합니다: SPF 통과와 함께 일관되게 DKIM 실패를 보고하는 소스는 보통 공격자가 아닌 자체 경로에서의 전송 중 변조입니다.
어떻게 수정하나요?
- 무언가 건드리기 전에 defaults.exposed에서 무료 스캔을 실행하세요. 게시된 DKIM 키와 DMARC 정책이 올바른지 확인하여 DNS의 유령이 아닌 진짜 문제 — 변조 — 를 디버깅하도록 합니다. DKIM 수정 페이지에서 레코드 측 확인을 다룹니다.
- 수정하는 홉 이후에 서명하세요. 구조적으로 올바른 수정: 메시지를 마지막으로 처리하는 장치로 DKIM 서명을 이동하세요. Exchange-plus-gateway 환경은 게이트웨이에서 서명하고(Mimecast, Proofpoint 등은 모두 지원합니다) 업스트림에서는 서명을 비활성화해야 합니다. Google Workspace 또는 Microsoft 365가 마지막 홉이라면 거기서 서명하고 그 이후에 아무것도 메일을 편집하지 않도록 하세요 — Google Workspace에서 DKIM 설정 또는 Microsoft 365 참조.
- 또는 수정을 중단하세요. 전송 경로에서 편집을 제거하세요: 전송 규칙 대신 클라이언트 서명이나 템플릿에 고지문; 인바운드 메일에만 범위를 제한한 “EXTERNAL:” 배너(자체 아웃바운드 메일을 외부로 태그하는 것은 두 번의 잘못된 설정); 링크 재작성에서 제외된 인증된 아웃바운드 메일.
- relaxed/relaxed 정규화(
c=relaxed/relaxed)를 사용하세요.simple본문 정규화는 한 줄 재래핑에서 실패합니다;relaxed는 공백과 줄 끝 변경을 허용합니다. 한계에 대해 솔직하게: relaxed는 서식 지정을 용서하지, 절대 콘텐츠를 용서하지 않습니다 — 추가된 footer는 여전히 실패하며, 그래야 맞습니다. - 두 경로를 재테스트한 후 재스캔하세요. 두 경로 모두 이제
d=에 도메인이 있는dkim=pass를 표시해야 하며, 스캔 보고서가 깨끗해야 합니다.
추가된 콘텐츠를 DKIM이 무시하게 하려면 l= 태그를 사용해야 하나요?
아닙니다 — 그것을 제안하는 가이드를 의심하세요. l= 태그는 본문의 처음 N바이트만 해싱하므로 추가된 footer가 더 이상 서명을 깨뜨리지 않습니다. 메시지 끝을 서명되지 않은 채로 두어 “작동”합니다: 합법적으로 서명된 메시지를 가진 사람은 임의의 콘텐츠를 추가할 수 있고 여전히 결과에 대해 유효한 서명이 검증됩니다. 이것은 수정처럼 보이는 사칭 구멍입니다 — 실제 악용이 입증되었으며 일부 수신자는 바로 이 이유로 l=을 불이익을 주거나 무시합니다. 변조를 해결하세요; 메일의 일부를 서명 없이 두지 마세요.
메일링 리스트는 어떤가요 — 수정할 수 있나요?
대부분 아닙니다 — 그리고 그것을 아는 것이 몇 주를 절약합니다. 제목 태그나 footer를 추가하는 리스트는 의도적으로 본문 해시를 깨뜨리며, 여러분은 리스트를 제어하지 않습니다. 두 가지가 도움이 됩니다:
- 이 잔재는 정확히 DMARC 전환이 단계적으로 이루어지는 이유입니다. 집계 보고서를 읽으면서
pct=증가와 함께p=none에서p=quarantine으로 이동하면 리스트에서 손상된 메시지가 영향을 평가하는 동안 파괴되지 않고 격리됩니다 — 합법적인 이메일을 잃지 않고 p=none에서 p=reject로의 주제. - ARC는 여러분이 아닌 수신자의 메커니즘입니다. Authenticated Received Chain은 리스트가 도착 시 인증이 어떻게 보였는지를 증명하고 수신자가 신뢰 여부를 결정하게 합니다. 발신자인 여러분이 설정할 것은 없습니다. 잘 운영되는 리스트는 From 헤더를 재작성하여 완화합니다; 잘못 운영되는 것은 그냥 메일을 깨뜨립니다.
전달(forwarding)은 인접한 경우입니다 — SPF는 신뢰할 수 없이 깨뜨리지만 DKIM은 본문이 살아남을 때만 가끔 깨뜨립니다. 따라서 본문이 살아남으면 정렬된 DKIM이 전달 증거 레그입니다: 전달된 이메일이 SPF에 실패하는 이유 — 수정할 수 없는 이유 참조.
전체 스택을 갖춘 도메인이 적은데 DKIM이 왜 이렇게 자주 깨지나요?
DKIM이 트리아드의 취약한 중간 자식이기 때문입니다: SPF는 정적 DNS 레코드, DMARC는 정책 선언이지만, DKIM은 여정을 살아남아야 합니다. Defaults.Exposed 센서스에 따르면 평가된 도메인 중 51.84%만이 DNS에서 검색 가능한 DKIM 키를 게시하며, 10,092,481개 도메인 — 평가된 261,086,232개의 3.87% — 만이 SPF, DKIM, 적용 중인 DMARC 정책을 함께 갖추고 있습니다(SPF 채택 성숙도 모델이 사다리를 분류합니다). 이 수정을 제대로 하는 것이 그 3.87%에 합류하는 가장 어려운 부분입니다.
자주 묻는 질문
“body hash did not verify”는 누군가 내 도메인을 사칭하고 있다는 징후인가요?
보통 아닙니다 — 사칭자는 일반적으로 DKIM 서명을 전혀 만들 수 없으므로, 그들의 메일에는 서명이 없거나 no key가 표시됩니다. 실패한 본문 해시는 인프라에서 진정으로 서명된 메시지가 이후에 편집되었다는 의미입니다. 공격자를 가정하기 전에 자체 게이트웨이를 확인하세요.
이 메시지에서 SPF가 통과합니다 — 괜찮은 건가요? 지금은 아마도: DMARC는 정렬된 통과 하나만 필요합니다. 하지만 SPF의 통과는 누군가 메시지를 전달하는 순간 사라지며, From 도메인과 정렬되지 않으면 DMARC에 전혀 의미가 없었던 것입니다. 전체 트리아드를 갖춘 도메인이 3.87%에 불과하고(261,086,232개 도메인의 2026-06-29 센서스), “한 레그가 절뚝거리는” 것이 정상적인 상태입니다 — 그리고 수정 가능한 상태.
relaxed/relaxed 정규화로 전환하면 고지문 문제가 수정되나요? 아닙니다. Relaxed는 공백과 줄 래핑 변경만 허용합니다. 추가된 고지문은 콘텐츠 변경이며, 해시가 실패해야 합니다 — DKIM이 올바르게 작동하는 것입니다. 서명 위치를 이동하거나 고지문을 이동하세요.
오류가 한 고객 도메인에서만 발생합니다. 왜 그런가요? 그쪽에서 거의 확실히 인바운드 메일을 수정합니다 — 검증자가 실행되기 전에 링크를 재작성하거나 배너를 찍는 보안 어플라이언스, 또는 본문을 재인코딩하는 내부 전달. 이 페이지의 진단 섹션을 그들에게 보내세요; 수정은 DNS가 아닌 그들의 게이트웨이에 있습니다.
소유자에게 보고서 전달
클라이언트나 고용주를 위해 수정하는 경우 증거로 마무리하세요. 수정하는 홉이 수정되면 무료 스캔을 다시 실행하고 등급 보고서를 비즈니스 소유자에게 전달하세요: 날짜 기록, 알기 쉬운 언어, DKIM과 DMARC가 한 페이지에 표시. 사이버 보험 갱신과 다음 공급업체 설문지를 위한 증거물입니다 — 회사에서 나가는 메일이 이제 도착하는 메일임을 증명합니다.
도메인 확인하기 → · “DKIM 서명이 유효하지 않음” 가이드 → · DKIM 수정 → · 평가 방식 → · 집계 데이터만 사용합니다. 데이터는 EU에서 저장 및 처리됩니다.