DKIM 도메인이 암호화 서명을 통해 메시지에 대한 책임을 지도록 합니다. 특정 이메일에 대한 의미를 이해하려면 DNS 검사기 대신 수신된 원본으로 시작하십시오. 유용한 증거 체인은 메시지 서명, 서명 도메인 및 선택자, 공개 키, 수신자 확인 결과, 임의 DMARC 조정 결정.
서명된 신원을 읽어보세요.
각각의 위치를 찾아보세요 DKIM-Signature 원본 메시지의 헤더. d= 값은 서명 도메인을 식별하고 s=는 해당 선택기를 식별합니다. DNS 기반 키 검색의 경우 이를 선택기로 결합합니다. _domainkey.signing-domain. 서명 도메인은 작성자의 조직, 릴레이 또는 이를 대신하는 서비스에 속할 수 있습니다. DKIM 의도적으로 서명 책임을 명백한 작성자로부터 분리합니다. RFC 6376 §1, RFC 6376 §3.5, RFC 6376 §3.6.2.
예시: 보낸 사람은 accounts@example.com 이고 서명에는 d=example.com; s=mail2026. 검증자는 mail2026._domainkey.example.com 조회합니다. 해당 DNS 레코드는 공개 확인 자료를 제공합니다. 개인 서명 키는 승인된 서명자와 함께 유지되며 공개되어서는 안 됩니다. 이 예에서는 조회를 설명합니다. 이는 실제 서명이나 테스트된 메시지가 아닙니다.
성공적인 확인과 존재 여부를 분리하세요.
DKIM-Signature 헤더가 존재하고 유효하지 않을 수 있습니다. 애플리케이션이 서명을 전혀 보내지 않는 동안에도 DNS 키가 존재할 수 있습니다. 검증은 서명 구조, 키, 선택한 헤더 및 본문 표현을 확인합니다. 서명 후 변경하면 변경된 내용과 내용에 따라 문제가 발생할 수 있습니다. 정규화 사용된. 다이제스트처럼 보이는 문자열은 이러한 검사가 통과되었다는 증거가 아닙니다. RFC 6376 §3.4, RFC 6376 §3.5, RFC 6376 §3.7, RFC 6376 §6.
수신 시스템의 신뢰도를 검사하세요. Authentication-Results 또는 이에 상응하는 로그. 해당 결과를 추가한 인증 서비스와 신뢰할 수 없는 인바운드 결과 헤더가 제거되거나 무시되는 위치를 이해합니다. 발신자는 그럴듯해 보이는 패스 텍스트를 메시지에 삽입할 수 있으므로 임의의 Authentication-Results 콘텐츠는 증거가 아닙니다. RFC 8601 §1.2, RFC 8601 §7.1.
결과를 보이는 작성자에게 연결
DMARC 의 경우 성공적으로 확인된 d= 도메인을 From의 작성자 도메인과 비교합니다. 엄격한 DKIM 정렬에는 다음과 같은 정확한 일치가 필요합니다. RFC 9989 §3.2.10; 완화된 정렬은 조직 영역 발견을 사용합니다. RFC 9989 §4.10.2. 선택기와 선택적 i= 값은 이 DMARC 비교에 사용되는 도메인이 아닙니다. 여러 개의 DKIM 서명이 있는 경우 정렬된 하나의 전달 서명이 DMARC 패스에 대한 DKIM 경로를 제공할 수 있습니다. RFC 9989 §4.4.1.
예에서 d=example.com 보낸 사람 도메인과 일치합니다. 대신 d=service.example.net 확인하는 경우 원시 DKIM 통과하지만 관련 없는 도메인은 example.com 과의 정렬을 설정하지 않습니다. 수신된 헤더를 편집하여 이 문제를 "수정"하지 마십시오. 지원되는 적절한 ID를 사용하도록 합법적인 서명자를 구성하십시오.
유용한 조사 기록을 구축하세요
메시지 시간, 경로, 보낸 도메인, 각 d/s 쌍, 신뢰할 수 있는 DKIM 결과 및 이유, DNS 관찰 시간 및 정렬 결과를 기록합니다. 개인정보나 기밀정보가 포함될 수 있으므로 원본 메시지를 보호하세요. 사본을 수정하면 서명이 무효화될 수 있습니다. 재검증이 필요할 때 접근이 통제된 원본을 보관하세요.
확인에 실패하면 서명이 활성화되었는지, 올바른 키를 사용할 수 있는지, 알고리즘이 지원되는지, 메시지가 전송 중에 변경되었는지 조사하세요. 현재 암호화 지침은 더 이상 사용되지 않는 기본값을 대체합니다. RFC 8301 §3.1 서명 및 확인을 위해 rsa-sha1을 금지합니다. RFC 8301 §3.2 RSA 주요 지침을 업데이트합니다. 단지 구문이 여전히 유효해 보인다는 이유만으로 이전 튜토리얼의 암호화 선택을 사용하지 마십시오. DNS 에 키가 포함되어 있다는 증거뿐만 아니라 수신된 결과에 대한 증거로 마무리합니다.
구별을 적용하십시오
가상 메시지의 경우 각 서명(d, s, 조회 소유자, 신뢰할 수 있는 확인 결과 및 정렬)에 대해 하나의 행을 작성합니다. 관련 없는 service.example.net 서명이 통과하는 동안 example.com 서명이 실패하는 경우 첫 번째 도메인을 두 번째 결과와 결합하지 마십시오. 실패한 서명을 조사하고 평가합니다. SPF DMARC 할당하기 전에 별도로 이 기사에 대한 메시지 확인이 실행되지 않았습니다.