Defaults.Exposed › 수정 › Guides

'DKIM 서명이 유효하지 않음' — 원인 및 확인 순서 (2026)

게시일 2026-07-08

2026-06-29 기준 수치 · 방법론 v7. 261백만 개의 평가된 도메인에 대한 집계 데이터. 평가 방식 보기.

“DKIM signature not valid”에는 다섯 가지 일반적인 원인이 있으며, 이 순서대로 확인하는 것이 좋습니다: 전송 중 콘텐츠 변조, 잘린 키 레코드, 서명자와 일치하지 않는 게시된 키, 잘못된 셀렉터, 취약한 정규화. Defaults.Exposed 센서스(2026-06-29)에 따르면 평가된 261,086,232개 도메인 중 10,092,481개(3.87%)만이 SPF + DKIM + 적용 중인 DMARC 트리아드를 갖추고 있습니다.

수정 순서가 중요한 이유는 가장 일반적인 원인이 DNS에 전혀 없기 때문입니다. 먼저 전송 중 메시지를 변경한 것을 확인하고, 그 다음 내부로: 키 레코드의 무결성, 메일 서버가 실제로 서명에 사용하는 것과 일치하는지, 셀렉터, 마지막으로 서명 설정. 대부분의 유효하지 않은 서명은 1단계 또는 2단계에서 수정됩니다.

”DKIM signature not valid”는 실제로 무슨 의미인가요?

모든 DKIM 서명된 메시지에는 도메인(d=), 셀렉터(s=), 메시지 본문 해시(bh=), 본문 해시와 선택된 헤더에 대한 암호화 서명(b=)을 지정하는 DKIM-Signature 헤더가 있습니다. 수신자는 <selector>._domainkey.<domain>에서 DNS의 공개 키를 가져오고, 두 해시를 재계산하고, 서명을 확인합니다(RFC 6376). “Signature not valid”는 확인 도구와 헤더 용어로: 검증이 실행되었는데 실패했다는 의미 — 키는 찾았지만 수학이 맞지 않았습니다.

마지막 절이 진단의 핵심입니다. 키를 찾지 못한 검증자는 다른 것을 말합니다 — 일반적으로 dkim=fail (no key for signature) 같은 헤더 — 이건 셀렉터 문제로, DKIM “no key for signature” — 셀렉터 및 교체 수정에서 다룹니다. 다른 본문 해시를 재계산하는 검증자는 보통 명시적으로 그렇게 말합니다: body hash did not verify — Microsoft는 dkim=fail (body hash did not verify)로, Gmail은 종종 같은 진단을 dkim=neutral (body hash did not verify)로 표시합니다. 어느 쪽이든 콘텐츠 변조를 가리키며, “body hash did not verify” — 메시지를 변경한 것에서 다룹니다. 무언가 건드리기 전에 Authentication-Results 헤더의 정확한 문구를 읽으세요: 다섯 가지 원인 중 어느 것을 가지고 있는지 알려줍니다.

이를 제대로 하는 것은 드뭅니다: Defaults.Exposed 센서스에 따르면 평가된 도메인 중 51.84%만이 DNS에서 검색 가능한 DKIM 키를 게시하며, 261백만 개의 평가된 도메인 중 3.87%만이 SPF, DKIM, 적용 중인 DMARC 정책을 결합합니다 — 대용량 발신자 규칙이 이제 가정하는 설정. 단계별 그림은 SPF 채택 성숙도 모델에 있습니다.

다섯 가지 원인은 무엇인가요, 순서대로?

원인 1이 굵게 표시된 이유는 완벽하게 서명된 메시지의 서명을 깨뜨리기 때문입니다. 보안 게이트웨이가 고지문을 추가하거나, 규정 준수 footer가 서명 후 추가되거나, 메일링 리스트가 제목에 [listname]을 추가하면 — 본문 또는 서명된 헤더가 변경되어 해시가 더 이상 일치하지 않고 여러분의 DNS 잘못 없이 서명이 유효하지 않게 됩니다. 실패가 게이트웨이, 리스트, 아카이빙 홉을 통과한 메일과 상관관계가 있다면 그곳에서 시작하세요.

”DKIM signature not valid”를 어떻게 수정하나요?

1. DNS를 건드리기 전에 defaults.exposed에서 무료 스캔을 실행하세요. 게시된 키 레코드가 존재하고 올바른 형식이며 완전한지 보여줍니다 — 한 번에 “DNS가 깨짐”(원인 2–4)과 “DNS는 괜찮은데 메시지가 변경되고 있음”(원인 1)을 분리합니다.
2. 실패하는 메시지의 Authentication-Results 헤더를 읽으세요. body hash did not verify → 원인 1, 본문 해시 가이드로 이동 — 일반적인 원인은 게이트웨이 footer와 고지문이며 수정은 변경 후 서명입니다. no key for signature → 원인 4, 셀렉터 가이드로 이동. 일반 서명 실패 → 계속.
3. 게시된 키의 잘림을 확인하세요. <selector>._domainkey.<yourdomain>을 TXT로 조회하세요(dig TXT selector._domainkey.example.com). 2048비트 RSA 공개 키는 단일 TXT 문자열의 255자 제한보다 길기 때문에 수신자가 연결하는 여러 인용 문자열로 게시되어야 합니다 — DNS 공급자 웹 UI는 붙여넣기를 자동으로 잘라내거나, 분할을 손상시키거나, p= 값에 공백과 따옴표를 삽입하는 것으로 악명높습니다. 서명자가 생성한 키와 문자 하나하나 비교하세요; DKIM 설정 안내에서 공급자별 특이사항을 다룹니다.
4. 게시된 키가 서명자와 일치하는지 확인하세요. 키 교체, 공급자 마이그레이션, ESP 재연결 후에는 서명자가 새 개인 키를 가지고 있는 동안 DNS가 여전히 이전 공개 키를 서비스하는 것이 흔합니다 — 모든 서명이 잘못된 키에 대해 검증하여 실패합니다. 공급자 관리 콘솔에서 현재 레코드를 다시 복사하세요. 더 좋게는: 공급자가 CNAME 위임을 제공하면 사용하세요 — 공급자가 자체적으로 키를 교체하고 이 전체 오류 유형이 사라집니다. 그리고 이전 셀렉터의 트래픽이 소진될 때까지 이전 셀렉터를 절대 삭제하지 마세요.
5. 레코드만이 아닌 서명 설정도 수정하세요. 정규화를 c=relaxed/relaxed로 설정하세요, 이는 중간 서버가 합법적으로 하는 공백 재래핑과 헤더 재폴딩을 허용합니다; simple 정규화는 사람이 볼 수도 없는 변경에서 실패합니다. 그리고 l= 본문 길이 태그를 사용하지 마세요: footer를 통과시키기 위한 것이었지만 서명을 깨뜨리지 않고 누구든 서명된 메시지에 콘텐츠를 추가할 수 있게 합니다 — 실제 공격 벡터 — 이고 대부분의 게이트웨이 변조에서 여전히 살아남지 못합니다. l= 없는 것이 더 안전하고 더 신뢰할 수 있는 선택입니다.
6. 재스캔 후 정렬 확인. 유효한 서명은 d= 도메인이 From 도메인과 정렬될 때만 DMARC에 도움이 됩니다 — d=yourcompany.gappssmtp.com으로 검증되는 서명은 DKIM을 통과하지만 여전히 DMARC에 실패합니다. 이 경우라면 기본 서명 함정을 참조하고, DKIM 수정 페이지에서 스캔이 표시한 다른 항목도 처리하세요.

자주 묻는 질문

“DKIM signature not valid”와 “body hash did not verify”는 같은 건가요? 본문 해시 메시지는 하나의 특정 하위 사례입니다: 서명 후 본문이 변경됨(footer, 고지문, 리스트 재작성). “Signature not valid”는 잘못된 키와 헤더 변경을 포함한 모든 검증 실패에 대한 포괄적 판정입니다 — 따라서 위의 2단계에서 헤더를 읽는 것이고, 본문 해시 사례가 자체 가이드를 갖는 이유입니다.

유효하지 않은 DKIM 서명은 메일이 거부된다는 의미인가요? 그 자체만으로는 아닙니다 — 수신자는 깨진 서명을 없는 것처럼 처리합니다. 피해는 DMARC를 통해 발생합니다: SPF도 정렬과 함께 통과하지 않으면 메시지가 DMARC에 실패하고 게시된 정책이 적용됩니다. 2026-06-29 센서스 기준으로 평가된 261,086,232개 도메인 중 3.87%만이 SPF, DKIM, 적용 중인 DMARC 정책을 함께 갖추고 있습니다 — 하지만 Gmail과 Microsoft는 이제 발신자에게 정확히 그것을 기대하므로, 깨진 DKIM 요소는 거부 이전에도 배달성에 비용이 됩니다.

DKIM 키는 1024비트와 2048비트 중 어느 것을 사용해야 하나요? 2048비트 — 1024비트 키는 현재 암호화 권고사항 이하이며 일부 수신자는 점수를 낮춥니다. 단점은 순전히 운영 측면입니다: 2048비트 키는 하나의 255자 TXT 문자열에 맞지 않으므로 올바르게 분할되어야 합니다(위의 원인 2). 공급자에 대한 CNAME 위임은 분할 문제를 완전히 피합니다.

DKIM 검사기에서는 통과하는데 DMARC가 여전히 실패합니다 — 왜 그런가요? 거의 확실히 정렬 문제입니다: 서명이 검증되지만 d= 도메인(예: yourcompany.gappssmtp.com 또는 yourtenant.onmicrosoft.com)이 From 도메인과 일치하지 않아 DMARC가 사용할 수 없습니다. 공급자의 사용자 정의 도메인 서명을 활성화하세요 — 전체 안내는 기본 서명 함정 가이드에 있습니다.

계속 실패하면 그냥 DKIM을 꺼도 되나요? 아닙니다 — 2024년 대용량 발신자 의무사항 이후 Gmail과 Yahoo는 대용량 발신자에게 DKIM을 요구하며, 적용 중인 DMARC 정책은 현실적으로 DKIM이 필요합니다. SPF 단독으로는 전달(forwarding) 시 깨지기 때문입니다. 서명을 수정하세요; 위의 원인들은 모두 오후 한 번에 수정 가능합니다.

소유자에게 보고서 전달

클라이언트나 고용주를 위해 수정하는 경우 증거로 마무리하세요. 변경 후 무료 스캔을 다시 실행하고 등급 보고서를 비즈니스 소유자에게 전달하세요: 날짜 기록, 알기 쉬운 언어, DKIM 녹색 표시. 사이버 보험 갱신과 다음 공급업체 보안 설문지에 필요한 증거물입니다 — “DNS 항목을 수정했습니다”와 도메인이 메일을 인증한다는 것을 보여주는 전후 기록의 차이.

도메인 확인하기 → · “Body hash did not verify” 가이드 → · DKIM 수정 → · 평가 방식 → · 집계 데이터만 사용합니다. 데이터는 EU에서 저장 및 처리됩니다.