애플리케이션 이메일의 DKIM은 어떻게 확인하나요?

DKIM 확인을 네 가지 개별 테스트로 나누기

DNS 조회만으로는 완전한 DKIM 확인이 되지 않습니다. 첫째, 메시지에 DKIM-Signature 필드가 있는지 확인하고 테스트할 서명을 식별합니다. 둘째, 그 서명이 지정한 공개 키 레코드를 가져와 파싱합니다. 셋째, 서명된 헤더와 정규화된 본문이 암호학적 서명과 여전히 일치하는지 검증합니다. 넷째, 통과한 서명 도메인이 DMARC 기준으로 보이는 From 도메인과 정렬되는지 판단합니다. 이 계층들은 서로 다른 질문에 답합니다. 게시된 레코드가 사용되지 않을 수 있고, 메시지가 존재하지 않는 셀렉터를 참조할 수 있으며, 내용이 수정된 뒤에 서명이 실패할 수 있고, 암호학적으로 통과해도 작성자 도메인과는 정렬되지 않을 수 있습니다. 하나의 녹색 배지로 뭉뚱그리지 말고 각 결과를 기록하세요. 전송 상태와 메일함 상태도 따로 유지하세요. 제공업체의 접수, 수신 서버의 수락, 받은편지함 도달은 DKIM 검증 결과가 아닙니다.

실제 메시지의 서명에서 시작하기

일반적인 애플리케이션 경로로 도달한 통제된 수신자에게서 원본 메시지를 확보하세요. 각 DKIM-Signature 필드에서 `d=` 서명 도메인, `s=` 셀렉터, `a=` 알고리즘, `c=` 정규화 모드, `h=` 서명된 헤더 목록, `bh=` 본문 해시, `b=` 서명 데이터, 그리고 있다면 타임스탬프를 기록하세요. RFC 6376은 서명 도메인과 셀렉터 태그를 정의하고 이를 사용해 공개 키를 찾도록 합니다. 제공업체 대시보드를 보고 셀렉터를 추측하거나 셀렉터 없이 `_domainkey`를 조회하지 마세요. 하나의 메시지에는 발신자, 중간 서버, 메일링 시스템이 붙인 여러 서명이 있을 수 있으므로 서명마다 결과를 보존하세요. 프로덕션 메시지를 공개 검사 도구에 붙여 넣지 마세요. 원본 헤더와 본문에는 수신자, 메시지 식별자, 라우팅 정보, 수신 거부 토큰, 애플리케이션 콘텐츠가 노출될 수 있습니다. 전체 내용이 필요 없다면 접근이 제한된 저장소와 민감 정보를 가린 진단용 사본을 사용하세요.

정확한 셀렉터와 서명 도메인 조회하기

서명에서 `<selector>._domainkey.<signing-domain>` 형태로 DNS 이름을 만드세요. 헤더에 `s=app2026`과 `d=notify.example.test`가 있다면 `app2026._domainkey.notify.example.test`의 TXT를 조회합니다. 원래 이름, 리졸버, 응답, TTL, CNAME 체인을 기록하세요. 텍스트 조각을 검색하지 말고 결과로 나온 태그-값 레코드를 파싱하세요. 레코드에는 버전, 키 유형, 서비스 제한, 플래그, 해시 알고리즘, 공개 키 데이터가 선언될 수 있습니다. 공개 키 값이 비어 있으면 해당 키가 폐기된 것입니다. NXDOMAIN, 빈 응답, 형식이 잘못된 내용, 지원되지 않는 알고리즘, 사용할 수 없는 키, 일시적인 리졸버 실패를 구분하세요. 변경된 조회는 TTL이 만료된 뒤 독립적인 리졸버로 다시 확인하되, 모든 수신자가 즉시 갱신되었다고 가정하지 마세요. DNS 조회가 성공했다는 것은 그 시점에 레코드가 반환되었다는 것만 증명합니다. 테스트한 메시지가 검증된다는 것이나 제공업체가 현재 트래픽을 그 셀렉터로 서명한다는 것은 증명하지 않습니다.

헤더, 본문 해시, 서명 검증하기

DKIM 검증은 서명에 선언된 정규화 규칙을 따릅니다. 검증하는 쪽은 본문을 정규화하고 해시를 계산해 `bh=`와 비교합니다. 또한 `h=`에 명시된 서명된 헤더를 정규화하고, 규격에 따라 DKIM-Signature 필드를 포함시킨 뒤, 공개 키로 `b=`를 검증합니다. 이러한 변환을 문자열 연산으로 직접 재현하지 말고, 유지 관리되는 검증기 라이브러리나 수신자의 신뢰할 수 있는 인증 결과를 사용하세요. 본문 해시 불일치는 서명 이후 본문이 바뀌었음을 뜻하는 경우가 많고, 헤더 서명 실패는 서명된 헤더의 수정, 잘못된 키, 손상된 서명 데이터, 구현 오류를 나타낼 수 있습니다. 어느 단계에서 실패했는지 기록하세요. From, Subject, Date, Message-ID 같은 중요한 필드가 서명되었는지 살펴보되, 모든 경우에 적용되는 서명 헤더 정책을 임의로 만들어 내지 마세요. 정규화는 정해진 서식 변경만 허용할 뿐, 임의의 푸터 삽입, MIME 재작성, 줄 끝 손상, 전송 중 변경까지 안전하게 만들어 주지는 않습니다.

수신자 결과는 신뢰 경계 안에서 읽기

RFC 8601은 Authentication-Results 헤더와 none, pass, fail, policy, neutral, temperror, permerror를 포함한 DKIM 결과를 정의합니다. pass는 수신자가 검증 테스트를 통과한 적합한 서명을 찾았다는 뜻입니다. temperror는 일시적인 키 조회 실패처럼 바뀔 가능성이 높은 상황을 반영할 수 있고, permerror는 수정하지 않으면 나중에 다시 시도해도 성공하기 어렵습니다. 제공되는 경우 보고한 인증 서비스, 서명 도메인, 셀렉터, 알고리즘을 기록하세요. 발신자가 전송 전에 위조된 Authentication-Results 필드를 추가할 수 있으므로 수신 시스템의 문서화된 경계 안에서 삽입된 결과만 신뢰하세요. 최종 수신 환경에서 가장 위에 있는 신뢰할 수 있는 결과를 확인하고 중간 홉도 고려하세요. 수신자마다 결과가 다르다면 정확한 메시지 버전, DNS 관점, 평가 시각, 지원 알고리즘, 로컬 정책을 비교하세요. `dkim=pass`를 메일박스 제공업체가 콘텐츠를 승인했다거나 받은편지함에 넣었다는 주장으로 바꾸지 마세요.

DKIM 통과와 별개로 DMARC 정렬 확인하기

DKIM 통과는 `d=`의 서명 도메인을 인증할 뿐, 그 도메인이 보이는 RFC 5322 From 도메인과 같아야 한다는 조건은 없습니다. RFC 9989는 DKIM으로 인증된 식별자가 통과했더라도 적용되는 strict 또는 relaxed 정렬 모드에서 작성자 도메인과 정렬될 때만 DMARC에 사용합니다. 예를 들어 `billing.example.test`에서 온 메시지가 `d=provider.test`로 서명되었다면 DKIM은 통과해도 정렬되지 않을 수 있습니다. `d=example.test`의 유효한 서명은 조직 도메인 계산과 정책에 따라 relaxed 모드에서 정렬될 수 있습니다. DKIM 결과, 서명 도메인, 정렬 판정의 세 가지 필드를 보고하세요. DKIM이 실패하거나 정렬되지 않아도 정렬된 SPF로 DMARC를 통과할 수 있으므로, DMARC 통과가 특정 DKIM 서명의 통과를 증명하지는 않습니다. 현재 Gmail 발신자 가이드에는 해당 트래픽에 대한 인증과 정렬 요건이 있지만, 이를 충족해도 수신 서버의 수락이나 메일함 배치가 보장되지는 않습니다.

현재 알고리즘과 키 교체 확인하기

RFC 8301은 DKIM 암호 요건을 갱신했습니다. 서명하는 쪽은 `rsa-sha256`을 사용해야 하고, 검증하는 쪽은 이를 지원해야 하며, `rsa-sha1`은 사용해서는 안 됩니다. 또한 RSA 서명 키는 최소 1024비트여야 하며, 운영상 가능하다면 더 큰 키가 바람직한 이유도 설명합니다. 검사 도구는 알고리즘을 식별하고 폐기되었거나 사용할 수 없는 자료를 표시해야 하며, 키 길이만으로 메일 스트림이 신뢰할 수 있다고 주장해서는 안 됩니다. 제공업체마다 워크플로가 다릅니다. Amazon SES는 Easy DKIM이 기본적으로 2048비트 키를 사용한다고 문서화하고, 중간 단계 없이 서명 방식을 바꾸면 메시지가 DKIM 서명 없이 나가는 기간이 생길 수 있다고 경고합니다. 유효한 셀렉터 두 개 또는 제공업체가 문서화한 중복 메커니즘으로 교체를 계획하고, 새 메시지가 새 셀렉터를 사용하는지 확인하고, 지연된 메일이 도착할 수 있는 동안 이전 공개 키를 유지했다가 중복 기간이 끝난 뒤에만 제거하세요. 개인 서명 키는 DNS, 로그, 티켓, 프롬프트에 절대 게시하지 마세요.

메시지에서 바깥쪽으로 실패 원인 진단하기

확인에 실패하면 DNS를 바꾸기 전에 원본 메시지와 수신자 결과를 보존하세요. 예상한 애플리케이션과 제공업체가 실제로 그 메시지를 만들었는지 확인합니다. 서명이 없다면 해당 ID, 리전, 테넌트, 메시지 유형에서 서명이 활성화되어 있었는지 살펴보세요. 셀렉터 조회가 실패하면 정확한 `d=`와 `s=` 값, DNS 영역, CNAME 대상, TTL, 최근 교체 여부를 비교하세요. 키는 파싱되지만 본문 해시가 실패한다면 게이트웨이, 메일링 리스트 푸터, 추적 링크 재작성, MIME 변환, 줄 끝, 서명 이후에 콘텐츠를 수정할 수 있는 보안 제품을 점검하세요. 본문 해시는 일치하는데 암호학적 서명이 실패한다면 서명된 헤더의 변경, 키 불일치, 서명 구현을 확인하세요. DKIM은 통과하지만 DMARC가 실패한다면 같은 키를 다시 게시하지 말고 정렬을 테스트하세요. 관련 TTL이나 구성 전파 이후 통제된 수신자로 다시 테스트하고, 성공한 샘플 하나로 도메인 전체가 고쳐졌다고 선언하지 말고 메시지 유형별로 증거를 기록하세요.

감사 가능한 DKIM 확인 기록 유지하기

통제된 메시지마다 민감하지 않은 상관 식별자, 발송 시스템, 제공업체 계정 또는 워크스페이스, 보이는 From 도메인, 수신 시스템, 메시지 시각, 서명별 전체 결과를 보관하세요. `d=`, `s=`, `a=`, 정규화 방식, 서명된 헤더, DNS 조회 이름, DNS 응답 시간과 TTL, 키 레코드 상태, 본문 해시 결과, 서명 결과, 신뢰할 수 있는 Authentication-Results 값, DMARC 정렬 판정, 개선 담당자를 포함하세요. 원본 메시지는 접근 및 보존 통제가 적절한 곳에만 저장하세요. 정상적인 애플리케이션 발송, 제공업체 마이그레이션, 키 교체, 게이트웨이 경로, 전달(forwarding) 사례 같은 테스트 시나리오도 함께 기록하세요. 그러면 회귀를 서로 비교할 수 있고, 셀렉터나 메시지 처리 방식이 바뀐 뒤에도 스크린샷이 영구적인 증거로 남는 일을 막을 수 있습니다. 제공업체 설정, DNS, 서명 방식, 라우팅이 바뀌거나 새 메시지 유형이 생기면 다시 확인하세요. 운영 대시보드는 알 수 없음과 사용 불가 상태를 조용히 통과나 실패로 처리하지 말고 명시적으로 표시해야 합니다.

SendHQ가 이 확인에서 맡는 역할 이해하기

SendHQ는 검증된 From 도메인을 요구하고 전달 이벤트를 제공합니다. DKIM 확인을 위해 의도한 애플리케이션 경로로 제어된 메시지를 보내고, 수신된 서명을 검사하며, 실제 `d=` 및 `s=` 값을 조회하고 정렬을 별도로 기록하세요. 제품 문서만으로 셀렉터, 키 길이, 서명 알고리즘, 받은편지함 도달, 전달 보장을 추정하지 마세요.

자주 묻는 질문

출처

• RFC 6376: DomainKeys 식별 메일(DKIM) 서명 — RFC Editor
• RFC 8301: DomainKeys 식별 메일(DKIM)의 암호화 알고리즘 및 키 크기 업데이트 — RFC Editor
• RFC 8601: Authentication-Results 헤더 필드 — RFC Editor
• RFC 9989: 도메인 기반 메시지 인증, 보고 및 준수(DMARC) — RFC Editor
• Gmail 이메일 발신자 가이드라인 — Google
• Amazon SES의 Easy DKIM — Amazon Web Services
• SendHQ OpenAPI 명세 — SendHQ