DKIM 실패는 단순한 경고가 아니라 서명 검증 문제입니다. 수신 서버가 DKIM 서명을 검증하지 못했다는 뜻이며, 메시지 전체를 신뢰할 수 없다는 판정이나 받은편지함 도착 여부를 직접 의미하지는 않습니다. 다만 필터링과 수신 처리에 영향을 줄 수 있습니다. 전체 환경을 정비하려면 비즈니스 이메일 가이드에서 SPF, DKIM, DMARC, 라우팅과 사서함 설정을 함께 점검하세요.
발신 측에서는 정상으로 보이는데 Gmail, Microsoft 또는 Yahoo에서 dkim=fail이 나타날 수 있습니다. 다른 인증 결과와 수신 정책에 따라 스팸 분류, 일시 제한 또는 거부로 이어질 수 있습니다. 그 결과 응답이 줄고 지원 문의가 발생할 수 있습니다. 원인은 DNS, 발신 시스템 또는 전송 중 메시지를 수정하는 장비에 있을 수 있습니다.
추측보다 근거를 따라 진단하세요. 인증 결과를 읽고 오류 유형을 분류한 뒤 선택자, 키와 서명 이후의 수정 여부를 확인합니다. 그런 다음 확인된 원인을 해결하세요.
dkim fail의 정확한 의미
DKIM 실패는 수신 서버가 메시지에 붙은 암호학적 서명을 검증하지 못했다는 뜻입니다. 서명된 내용의 변경이나 잘못된 키가 원인일 수 있습니다. DNS 공개키 누락이나 조회 오류는 영구 오류 또는 일시 오류로 보고될 수 있으므로 검증 실패와 구분해야 합니다.
RFC 6376에서 DKIM은 bh=의 본문 해시와 b=의 헤더 서명을 사용합니다. 불일치가 있으면 검증이 실패할 수 있습니다. 이것만으로 발신자 위조를 단정할 수는 없습니다. 너무 이른 서명, 잘못된 키 게시나 후속 시스템의 메시지 변경도 원인입니다.
DKIM은 포장의 봉인에 비유할 수 있습니다. 봉인 검사 실패는 검증이 되지 않았다는 뜻이지, 누가 변경했는지 또는 내용 전체가 위험한지까지 설명하지는 않습니다.
문제 메시지의 Authentication-Results 헤더부터 확인하세요. 아래 예시는 결과의 표기 형식을 보여 주지만, 같은 From 도메인에 정렬된 SPF가 통과했다면 일반적으로 DKIM 실패와 무관하게 DMARC도 통과해야 합니다. 이 조합을 정상적인 예상 결과로 해석하지 마세요.
Authentication-Results: mx.google.com;
dkim=fail (body hash did not verify) header.i=@example.com header.s=tm1;
spf=pass smtp.mailfrom=example.com;
dmarc=fail header.from=example.com발신 설정을 바꾸기 전에 도메인 레코드를 확인하려면 TrekMail의 필수 DNS 레코드와 비교하세요.
자주 발생하는 DKIM 문제 유형
진단에 유용한 분류는 본문 해시 불일치, 선택자 또는 키 불일치, 잘못되거나 잘린 DNS 키와 전달 또는 중계 과정의 변경입니다. 먼저 유형을 확인하면 원인이 아닌 키를 불필요하게 교체하는 일을 줄일 수 있습니다.
| 인증 결과 | 가능한 의미 | 먼저 확인할 위치 |
|---|---|---|
dkim=fail (body hash did not verify) | 정규화한 서명 대상 본문이 일치하지 않음 | 발신 중계, 안내문, 링크 변경, 정규화 |
dkim=fail (signature did not verify) | 키 불일치, 서명된 헤더 변경 또는 다른 검증 오류 | 선택자 레코드, 키 교체, 발신 플랫폼, 헤더 |
dkim=permerror (no key for signature) | 사용할 수 있는 공개키를 찾지 못함 | 선택자 호스트 이름, DNS 응답, 레코드 형식 |
dkim=temperror | 일시적인 DNS 조회 또는 처리 문제 | 권한 DNS, TTL, 네임서버 응답 상태 |
이 표는 초기 분류용입니다. 실제 원인은 추가 검사로 확인해야 합니다.
오류 유형 1: 본문 해시 불일치
본문 해시 불일치는 수신된 서명 대상 본문을 정규화한 결과가 서명 시 계산한 값과 다르다는 뜻입니다. 메시지 전체를 바이트 단위로 비교하는 것이 아니며, 이 결과만으로 DNS가 정상이라고 판단할 수도 없습니다.
RFC 6376에 따르면 다시 계산한 본문 해시가 bh=와 다르면 영구 검증 실패가 됩니다. 서명된 부분의 변경뿐 아니라 발신 및 수신 측의 계산과 처리도 확인하세요.
가능한 원인은 다음과 같습니다.
- Microsoft 365, Exchange 또는 보안 게이트웨이가 서명 이후 법적 안내문을 추가합니다.
- Mimecast, Barracuda, Proofpoint 등의 필터가 링크를 다시 작성합니다.
- 중계 서버가 선택한 정규화 규칙으로 흡수되지 않는 공백이나 줄바꿈 변경을 합니다.
- 앱이 먼저 서명한 뒤 게이트웨이가 MIME 경계를 변경하거나
[External]같은 배너를 추가합니다.
서명의 c=를 확인하세요. c=simple/simple은 일부 형식 변경에 더 민감합니다. RFC 6376의 relaxed 본문 정규화는 줄 끝 공백을 무시하고 줄 안의 반복 공백을 줄이는 등의 처리를 합니다. 하지만 텍스트 추가나 링크 수정 같은 실질적인 변경을 복구하지는 않습니다.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=tm1; h=from:to:subject:date:mime-version;
bh=...; b=...관리할 수 있는 바닥글, 링크, 라우팅과 규정 관련 변경이 끝난 뒤 서명하는 구성이 적절합니다. 마지막으로 통제하는 발신 단계가 보통 좋은 위치입니다. 이후 외부 시스템의 변경까지 막아 주는 것은 아닙니다.
전달을 사용한다면 이메일 전달과 도메인 이메일을 Gmail로 전달하기를 읽어 보세요. 직접 발송 테스트와 실제 전달 경로의 인증 결과가 달라질 수 있습니다.
오류 유형 2: 선택자 또는 키 불일치
메시지가 선택자 X로 서명되었는데 해당 DNS 위치에 사용할 키가 없거나 개인키에 대응하지 않는 공개키가 있다면 문제가 생깁니다. 키 누락은 영구 오류로, 잘못된 키는 검증 실패로 나타날 수 있습니다.
서명 헤더에서 선택자와 도메인을 찾으세요.
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...해당 선택자를 정확히 조회합니다.
dig txt k1._domainkey.example.com +short빈 응답은 레코드 누락이나 잘못된 위치뿐 아니라 캐시 또는 다른 조회 문제일 수도 있습니다. 전체 응답을 확인하세요. 레코드가 있으면 현재 발신 시스템이 요구하는 키와 비교합니다. 마이그레이션이나 여러 발신 플랫폼을 사용하는 환경에서는 일부 시스템만 새 키로 전환하고 나머지는 이전 개인키를 사용할 수 있습니다.
앱 메일은 SES, 지원 메일은 Microsoft 365, 캠페인은 다른 ESP를 사용하는 경우가 예입니다. DNS를 바꾸면 특정 경로만 실패할 수 있습니다. 필요한 경우 발신 시스템마다 선택자를 분리하세요.
TrekMail 관리형 발신 경로에서는 관리형 TrekMail SMTP를 참고해 서명 위치를 확인하세요. Nano 또는 외부 발신 시스템에서는 자체 SMTP (BYO)를 확인하세요. 이 구성의 TrekMail은 클라이언트이며, 실제 발신 시스템에 DKIM 서명이 설정되어 있어야 합니다.
오류 유형 3: 긴 공개키의 DNS 게시 문제
2048비트 키를 입력할 때 DNS 관리 화면이 TXT 값을 잘못 처리할 수 있습니다. 이 경우 permerror, 잘못된 형식 또는 불완전한 키가 나타날 수 있습니다.
RFC 8301은 RSA 키를 최소 1024비트로 요구하며 2048비트 이상을 권장합니다. 동시에 DNS 관리 화면이 긴 TXT 값을 정확히 저장하는지도 확인하세요.
개인키가 정상이어도 공개키가 잘리거나 따옴표가 잘못 처리되면 오류가 발생할 수 있습니다. 아래는 형식 예시이며 실제 전체 키를 같은 TXT 레코드 안의 문자열로 나눠 사용해야 합니다.
; Good DKIM TXT record pattern
k1._domainkey.example.com IN TXT (
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE..."
"restOfThePublicKeyContinuesHere..."
)실제 조회에서 첫 부분만 보지 말고 전체 응답을 확인하세요.
dig txt k1._domainkey.example.com +shortDNS 제공업체 변경, 영역 이동 또는 수동 복사 후 특히 점검해야 합니다. 애플리케이션은 같은 레코드의 문자열을 추가 공백 없이 연결합니다.
오류 유형 4: 전달, 중계와 정렬 문제
전달 중간 시스템이 서명된 데이터를 바꾸면 DKIM이 실패할 수 있습니다. 동시에 원래 발신자에 대한 SPF도 실패할 수 있습니다. 다른 정렬된 인증이 통과하지 않는 경우에만 DMARC 실패로 이어지며, 거부 여부는 수신 정책에 달려 있습니다.
example.com에서 대학 사용자에게 보낸 메일이 Gmail로 전달되는 경우를 생각해 보세요. 전달 서버는 원래 발신 서버가 아니므로 SPF가 실패할 수 있습니다. 서명된 내용이 검증에 영향을 받지 않는 한 DKIM은 유지될 수 있습니다. 바닥글 추가, 링크 변경이나 서명된 제목 수정은 DKIM을 깨뜨릴 수 있습니다. 다른 정렬된 인증이 없다면 DMARC도 실패할 수 있습니다.
Google은 개인 Gmail 계정으로 보내는 일반 발신자에게 SPF 또는 DKIM을 요구하며, 대량 발신자에게는 SPF와 DKIM 모두, DMARC와 해당 정렬 조건을 요구합니다. 전달이나 메일링 리스트에는 해당되는 경우 ARC도 권장합니다. 수신자가 ARC를 신뢰하고 활용할지는 수신 측이 결정합니다. 따라서 전달 경로의 DKIM 실패만으로 기본 설정이 틀렸다고 단정할 수 없습니다.
SRS와 적절한 라우팅도 전달에 도움이 될 수 있습니다. TrekMail 구성에서 사용할 수 있는 SRS 기능을 확인하세요. SRS는 봉투 발신자를 바꿔 새 발신자에 대한 SPF 통과를 도울 수 있지만 원래 From 도메인과 자동으로 정렬되지는 않습니다. DKIM을 대신하는 기능도 아닙니다.
별칭이 많은 환경에서는 이메일 별칭 전달과 자체 도메인 이메일 만들기도 참고하세요. 별칭 설정만 볼 것이 아니라 실제 전달 경로를 조사해야 합니다.
dkim fail이 발생했을 때 확인할 위치
인증 결과, 선택자 조회, 서명 경로와 정렬 순서로 확인하세요. 실제 원인이 서명 이후의 수정인데 불필요하게 DNS를 바꾸는 일을 줄일 수 있습니다.
- 원본 메시지에서
Authentication-Results를 찾아 정확한 DKIM 결과를 기록합니다. d=,s=와c=를DKIM-Signature헤더에서 찾습니다.dig로 선택자를 조회하고 호스트 이름이selector._domainkey.example.com인지 확인합니다.- 어떤 플랫폼이 실제로 서명하는지 확인합니다. 여러 플랫폼은 간헐적 오류의 원인이 될 수 있습니다.
- 게이트웨이, 필터나 전달 서버가 서명 이후 본문 또는 서명된 헤더를 수정하는지 확인합니다.
d=도메인과 표시되는From:도메인의 정렬을 확인해 DKIM이 DMARC 조건에 기여하는지 점검합니다.
외부 검사기에 일부 내용만 붙여 넣으면 불완전한 메시지 때문에 잘못된 본문 해시 오류가 발생할 수 있습니다. 전체 원본 또는 내보낸 .eml 파일을 검사하세요.
TrekMail을 활용한 통합 진단 방식
여러 업체의 DNS, 중계와 바닥글을 따로 수정하면 실제 서명 위치를 놓치기 쉽습니다. 마지막으로 통제할 수 있는 메시지 변경 이후에 서명하고 DNS를 검증하며 관리형 발신과 자체 SMTP를 명확히 구분하세요.
| 분산된 방식 | 통합된 방식 |
|---|---|
| 내부 단계가 서명 이후 메시지를 변경 | 마지막으로 관리하는 변경 이후 서명 |
| 여러 도구에서 수동 키 교체 | 지원되는 절차에 따른 관리형 SMTP 키 관리 |
| 중복 SPF나 잘못된 DKIM 이름을 만드는 수동 편집 | 정해진 절차로 레코드마다 검증 |
| SRS나 ARC를 고려하지 않은 전달 | 적절한 표준을 사용하고 가능한 인증 유지 |
여기서 설명하는 구성에서는 무료 Nano가 자체 SMTP를 사용합니다. 유료 요금제는 월 $3.50부터이며 관리형 SMTP를 포함합니다. 현재 가격과 기능은 확인하세요. TrekMail이 서명하도록 하려면 지원되는 관리형 경로를 사용합니다. SES, SendGrid 또는 Mailgun이 서명한다면 해당 발신 시스템에서 DKIM을 조사하세요. 유료 요금제에는 신용카드가 필요한 14일 무료 체험이 적용될 수 있습니다. 자세한 조건은 TrekMail 요금에서 확인하세요.
이 구분은 조사 범위를 정하는 데 중요합니다. 자체 SMTP에서는 외부 발신 경로의 선택자, 키와 서명 이후 변경을 확인해야 합니다. 근거 없이 TrekMail 사서함을 원인으로 단정하지 마세요.
DKIM 사고 대응 최종 점검
DKIM 실패를 막연한 수신 문제보다 구체적인 검증 오류로 다루세요. 결과를 읽고 선택자를 조회하며 서명 경로를 검사한 뒤 설정을 변경하면 더 정확하게 대응할 수 있습니다.
운영 환경을 바꾸기 전에 다음을 확인하세요.
- 반송 요약만 보지 말고 전체 인증 헤더를 읽습니다.
- 본문 해시 오류, 서명 검증 오류, permerror와 temperror를 구분합니다.
- 정확한 선택자를 DNS에서 조회합니다.
- 전체 키가 올바른 따옴표 처리와 함께 게시되었는지 확인합니다.
- 필요하면 마지막으로 통제하는 메시지 변경 이후로 서명을 이동합니다.
- 환경에서 지원한다면
c=relaxed/relaxed를 검토하되 실질적인 변경까지 허용하지는 않음을 기억합니다. d=와 표시되는From:도메인의 DMARC 정렬을 확인합니다.
dkim fail이 반복되면 기다리기만 하지 말고 근거를 모으세요. 서명 위치, 선택자, 키와 이후 수정 과정을 조사해 확인된 원인을 해결해야 합니다.
