가장 믿을 수 있는 곳을 찾을 수 있는 곳 DKIM 선택기 은 DKIM-Signature 조사 중인 메시지의 헤더. s= 값을 읽고 이를 동일한 서명의 d= 서명 도메인과 쌍으로 연결합니다.
선택기는 검증 자료가 게시된 위치를 식별합니다. 눈에 보이는 보낸 사람을 식별하거나 서명이 통과되었음을 증명하지 않습니다. 이 가이드에서는 수신된 메시지의 증거를 따라 올바른 DNS 이름을 찾은 다음 조회를 통해 설정할 수 있는 것과 설정할 수 없는 것을 설명합니다.
수신된 원본 메시지 가져오기
실제 서비스를 통해 별도의 수신자에게 전송되는 제어된 메시지를 사용합니다. 거기에서 수신된 원본 메시지를 보존합니다. 전달된 스크린샷이나 다시 저장, 편집된 메시지의 경우 증거가 누락되거나 변경될 수 있습니다.
모든 DKIM-Signature 헤더를 찾으세요. 메시지에는 둘 이상의 메시지가 포함될 수 있습니다. 각 서명에 대해 서명 도메인과 선택기를 별도로 기록한 다음 신뢰할 수 있는 수신자의 확인 결과를 연관시킵니다.
- d: 서명 도메인.
- s: 선택자.
- a: 서명/해시 알고리즘.
- h: 선택된 서명된 헤더 목록.
- bh와 b: 본문 해시 DNS 공개 키 레코드가 아닌 서명 값.
이러한 필드는 다음에 의해 정의됩니다. RFC 6376 §3.5.
표시되는 보낸 사람 도메인을 대체하지 마세요. d= 키 조회를 구축할 때. 조정 통과하는 서명 ID와 표시되는 From ID를 나중에 비교한 것입니다.
인증 이름 구성 및 쿼리
아래에 RFC 6376 §3.6.2.1, 확인 이름은 동일한 서명의 두 값을 결합합니다.
<선택자>. _domainkey .<서명-도메인>
이 합성 예에서 서명은 다음을 식별합니다.
합성 서명에는 d=example.com 및 s=mail2026.
해당 조회는 다음과 같습니다.
TXT mail2026._domainkey.example.com +noall +답변을 살펴보세요.
공급자가 키 관리를 위임하는 경우 CNAME, 해당 체인도 검사하십시오.
CNAME mail2026._domainkey.example.com +noall +답변 발굴
이는 캡처된 실제 메시지를 확인하는 것이 아니라 예시적인 DNS 확인입니다. 실제 서명 값을 사용하십시오. 아래에 RFC 1034 §3.6.2, 게시된 별칭의 경우 의도한 대상을 따르고 확인 데이터가 체인을 통해 사용 가능하도록 설정합니다.
퍼블릭 DNS 에는 확인 키 자료 또는 이를 연결하는 위임이 포함되어 있습니다. 개인 서명 키는 인증된 서명 시스템에 속하지만 TXT 레코드.
확인 결과와 함께 조회 해석
공개 키 답변은 확인자가 해당 시점에 특정 확인 자료를 검색할 수 있음을 보여줍니다. 메시지에 서명이 포함되어 있는지, 해당 개인 키가 올바르게 사용되었는지, 서명된 콘텐츠가 그대로 유지되었는지 여부는 증명되지 않습니다.
키는 존재하지만 서명이 실패하는 경우 전체 검증 결과를 조사합니다. 콘텐츠 변경, 잘못되었거나 호환되지 않는 키 데이터, 서명 적용 범위, 시간 관련 조건 및 DNS 관찰에는 다른 해결 방법이 필요할 수 있습니다.
키가 발견되지 않으면 정확한 내용을 확인하세요. d= 그리고 s=, 권한 있는 영역, CNAME 대상, 키 폐기 기록 및 확인자 오류. 단순히 체커를 녹색으로 바꾸기 위해 추측된 선택기를 게시하지 마세요.
원본에 관련 DKIM 서명이 없으면 선택기 검색으로 서명을 생성할 수 없습니다. 실제 발신자가 서명하도록 구성되었는지, 서비스가 필수 ID를 지원하는지, 이후 경로에서 증거가 변경되었는지 여부를 확인하세요.
여러 서명 및 키 순환 처리
각 서명과 신뢰할 수 있는 결과에 대해 별도의 행을 만듭니다. 서비스 자체 전달 서명은 정렬되지 않은 반면 고객 도메인 서명은 정렬을 전달합니다. 또 다른 메시지에는 실패한 고객 도메인 서명이 있고 관련되지 않은 서명만 있을 수 있습니다.
순환의 경우 DNS 에서 사용할 수 있는 두 레코드가 무엇인지 확인하는 것이 아니라 실제 메시지가 사용된 선택기를 확인하세요. 구성 상태, 서명 컷오버 및 이미 전송 중인 메시지 간의 관계를 유지합니다. 이전 선택기의 사용 중지는 저장되거나 지연된 메시지의 이후 확인에 영향을 미칠 수 있습니다.
Microsoft 365 의 경우 테넌트별 설정 가이드. 작업공간의 경우 선택된 도메인 설정 가이드. 두 공급자의 공통 선택기 패턴은 실제 증거를 읽는 것을 대체해서는 안 됩니다.
실제 서비스에서 서명 확인
공급업체가 귀하의 도메인에 DKIM 구성된 경우 관련 워크플로에서 보낸 메시지와 실제로 서명한 도메인을 표시하도록 요청합니다. 공개적으로 표시되는 키는 실시간 서명 증명이 아닌 하나의 구성 종속성입니다.
이는 여러 도구가 동일한 가시적 브랜드를 사용하는 경우 중요합니다. 직원 메일, 지원 티켓 및 영수증에는 선택기, 서명 도메인 및 소유자가 다를 수 있습니다. 한 가지에 대한 성공적인 확인이 나머지 부분을 대신할 수는 없습니다.
소유권 및 위임 서명을 추적하세요.
서비스, 도메인, 키 관리 모델 및 비즈니스 소유자와 연결된 선택기 인벤토리를 유지합니다. 키에 대한 직접 제어와 공급자에 대한 위임을 구별합니다. 서비스가 오프보드될 때 위임을 검토합니다.
개인 키 액세스를 제한하고 의심되는 손상에 대한 대응을 정의합니다. 유효한 공개 기록은 열쇠 보관이 건전하다는 증거가 아닙니다. 마찬가지로, 유효한 서명은 해당 콘텐츠에 대한 도메인 수준 어설션을 설정합니다. 결제 요청을 승인하거나 계정 손상을 배제하지 않습니다.
유용한 증거 체인은 메시지, 서명 ID, 키 조회, 신뢰할 수 있는 확인 및 정렬입니다. 다음 검토자가 진단을 재현할 수 있도록 이러한 관찰 내용을 함께 보관하십시오.
실용적인 테이크아웃
원본 메시지, 서명 ID, DNS 관찰 및 신뢰할 수 있는 수신자 결과를 함께 보관하세요. 이러한 증거는 누락된 키와 서명되지 않은 메시지, 실패한 서명 또는 통과했지만 정렬되지 않은 서명을 구별합니다.
구별을 적용하십시오
두 개의 가상 서명 d=example.com/s=mail2026 및 d=service.example.net/s=outbound, 사용하여 mail2026._domainkey.example.com 및 outbound._domainkey.service.example.net 을 별도로 쿼리합니다. mail2026을 두 번째 d와 결합하지 마십시오. 각 조회 시간과 신뢰할 수 있는 결과를 해당 쌍과 함께 보관하세요. 나중에 누락된 키는 이전에 신뢰할 수 있는 수신자 관찰을 삭제하지 않습니다.