[ 신고 및 조사 ]

원시 DKIM 결과와 정렬된 DKIM 정책 결과 비교

DMARC 만족할 수 있는 정렬된 DKIM 경로와 서명 확인을 구별합니다.

EmailAuth 연구팀 제공

[ 핵심사항 ]

  • 각 서명의 도메인, 선택기 및 결과를 함께 유지하십시오.
  • 확인된 정렬 서명만 DKIM 경로를 제공합니다.
  • 집계된 서명 적용 범위와 처리에는 별도의 제한이 있습니다.
이 페이지에서

A DKIM 서명 독자가 보낸 사람에서 보는 도메인을 인증하지 않고도 공급자의 도메인을 성공적으로 확인할 수 있습니다. 집계 보고서 두 레이어를 모두 보존합니다. DKIM 관련 내용을 해석하기 전에 원시 서명 ID 및 결과를 읽어보세요. DMARC 결과.

보고된 각 서명으로 시작

참고자료: RFC 9990 §3.1.1.12, RFC 9990 §3.1.3.

auth_results/dkim에서, RFC 9990 서명 도메인을 식별하고, 선택자 그리고 검증 결과. 도메인은 DKIM-Signature 의 d에 해당하고 선택자는 s에 해당합니다. 친숙한 표시 이름이나 선택기 레이블은 서명 도메인을 대체하지 않습니다. 조정.

메시지에는 여러 서명이 포함될 수 있습니다. 콘텐츠 수정 후 하나는 실패하고 다른 하나는 확인하거나 둘 다 서로 다른 도메인에서 확인할 수 있습니다. 인터페이스에 표시되는 첫 번째 서명을 선택하기보다는 개별 결과를 검사하세요. 보고서는 포함되는 서명을 제한할 수 있으므로 집계 기록이 없다고 해서 항상 서명이 존재하지 않았다는 증거는 아닙니다.

서명 도메인을 보낸 사람과 비교

참고자료: RFC 9989 §4.4.1, RFC 9989 §3.2.10.2, RFC 9989 §4.10.2, RFC 9990 §3.1.1.9.

DMARC 표시되는 보낸 사람 필드의 작성자 도메인과 성공적으로 확인된 DKIM 서명의 도메인을 사용합니다. 엄격한 정렬에는 정확한 도메인 일치가 필요합니다. 완화된 정렬은 해당 규칙에 따라 조직-도메인 검색에 의해 정의된 관계를 사용합니다. 이 비교에서 서명의 i ID는 d를 대체하지 않습니다.

도메인이 일치하지만 암호화 확인에 실패한 서명은 통과를 제공하지 않습니다. DKIM 길. 반대로, 관련되지 않은 도메인의 유효한 서명은 정렬되지 않은 상태로 유지됩니다. policy_evaluated/dkim 필드는 단순히 서명 확인 여부가 아닌 DMARC 관련 평가를 나타냅니다.

합성 예제에서 결과 재현

참고자료: RFC 9989 §5.3.5.

적용 가능한 유효한 정책, 완료된 확인, 관련 없는 brand.example / vendor.example 조직 도메인 및 header_from= brand.example 가정합니다. 서명 1은 d=vendor.example 사용하여 확인합니다. 서명 2는 d=brand.example 사용하고 본문 해시 확인에 실패합니다. 이 예에는 성공적으로 정렬된 DKIM 경로가 없으므로 DKIM 관련 정책 실패는 서명 1의 원시 전달과 일치합니다.

이제 신원을 동일하게 유지하면서 서명 2의 결과를 통과하도록 변경하십시오. 해당 서명은 정확한 정렬을 제공하므로 DKIM 경로는 관련 없는 서명의 결과에 관계없이 DMARC 충족할 수 있습니다. 이는 실제 수신기 측정이 아닌 구성된 사례입니다. 검사 SPF 첫 번째 경우 전체 DMARC 결과를 결정하기 전에도 마찬가지입니다.

검증 및 정렬을 별도로 수리

참고자료: RFC 6376 §6.1, RFC 9989 §5.4.

확인 실패의 경우 보고된 서명의 키, 콘텐츠 범위 및 실제 메시지 처리를 조사합니다. 단순히 보낸 사람 주소를 변경하는 것만으로는 본문 해시 결함이 복구되지 않습니다. 확인되었지만 정렬되지 않은 공급자 서명의 경우 서비스가 사용자 정의 서명 도메인 또는 다른 정렬된 경로를 지원하는지 여부를 설정합니다.

추가 서명을 추가하면 이전 서명이 복구된다고 가정하지 마십시오. 독립적으로 평가되는 또 다른 경로를 생성합니다. 유용한 질문은 가능한 모든 서명이 통과하는지 여부가 아니라 지원되는 유효한 서명 중 하나 이상이 일치하는지 여부입니다.

모호한 집계 증거를 해결할 때 원시 샘플과 신뢰할 수 있는 수신자 결과를 보존합니다. 테스트된 각 경로에 대해 d 도메인, 선택기, 검증 결과, 정렬 모드 및 작성자 도메인을 기록합니다. 처리를 별도로 유지합니다. 인증 성공은 전달을 보장하지 않으며 수신자 처리 예외는 실패한 서명을 유효한 서명으로 바꾸지 않습니다.

다중 서명 비교 유지

두 개의 부분 합성 지도는 header_from= brand.example , 정책을 사용합니다. p=reject, 완화된 정렬 및 신기원 간격 1704067200-1704153600. 둘 다 관련 없는 vendor.example 에 대한 원시 SPF 패스를 갖고 있으므로 둘 다 SPF 정렬하지 않았습니다. 첫 번째에는 vendor.example /v1 DKIM 통과와 brand.example /b1 DKIM 실패가 있습니다. 정렬된 DKIM 결과와 전체 DMARC 결과가 실패합니다. 두 번째에는 vendor.example /v1 실패와 brand.example /b1 통과가 있습니다. 정렬된 DKIM 및 전체 DMARC 결과가 통과되었습니다.

제공된 로컬 ID 연습은 이러한 결과를 재현하고 선택기를 각 서명에 첨부된 상태로 유지합니다. 모델은 제공된 검증 결과를 가정합니다. 서명을 다시 계산하거나 DNS 테스트하지 않습니다. 두 지도 모두 측정된 교통 샘플이 아닌 각각 25개의 관측치를 나타냅니다. 해당 처리 필드는 계산된 배달 보장이 아닌 제공된 보고 컨텍스트로 유지됩니다. 실제 원시 메시지를 사용하여 생산 경로에 대해 이 체인을 검증합니다.

범위 내에서 운동을 유지하세요.

예는 스키마가 유효한 보고서나 측정된 트래픽이 아닌 부분적인 필드 예측입니다. 로컬 검사에서는 명시적으로 제공된 인증 결과와 조직 관계를 사용합니다. DNS 검색, SPF 평가, 암호화 확인, 보고서 수집 또는 수신자 전달 테스트를 수행하지 않습니다. 프로덕션을 변경하기 전에 원본 보고서와 신뢰할 수 있는 메시지 증거를 보존하세요.

[ 테이크아웃 ]

각 서명의 도메인, 선택기 및 결과를 함께 유지하십시오. 확인된 정렬 서명만 DKIM 경로를 제공합니다. 집계된 서명 적용 범위와 처리에는 별도의 제한이 있습니다.

[ 역할별 ]

이것이 당신에게 의미하는 바

실용적인 다음 단계를 위해 역할을 선택하세요.

IT/메일 관리자

서명을 개별적으로 평가

여러 서명으로 인해 분명히 충돌하는 보고서 필드가 설명될 수 있습니다.

다음 단계

  1. 보고된 각 서명에 대해 d와 s를 기록합니다.
  2. 검증과 정렬을 분리하세요.
  3. 원시 샘플을 사용하여 누락된 세부정보를 조사하세요.

CISO/SecOps

신뢰 결론을 좁게 유지

유효한 서명과 정렬된 ID는 메시지 안전이나 전달을 설정하지 않습니다.

다음 단계

  1. 서명 권한을 검토하세요.
  2. 실패 증거를 보존합니다.
  3. 수신기 재정의를 복구된 인증으로 처리하지 마세요.

창립자 / 비기술자

실제로 어떤 신분이 통과되었는지 물어보세요

제공업체 도메인 녹색 체크 표시는 DKIM 조정되지 않은 채 고객 대상 도메인을 떠날 수 있습니다.

다음 단계

  1. 중요한 작성자 도메인을 식별합니다.
  2. 지원되는 사용자 정의 서명을 확인하세요.
  3. 전체 DMARC 결과를 검토하세요.

[ 자주 묻는 질문 ]

자주 묻는 질문

DMARC 의 DKIM 결과가 실패하는데 DKIM 통과할 수 있나요?

예. 확인된 서명은 작성자 도메인과 관련이 없는 도메인을 사용할 수 있습니다.

RFC 9990 §3.1.1.9 RFC 9990 §3.1.1.12

정렬에 어떤 DKIM ID가 사용됩니까?

작성자 도메인과 비교하여 성공적으로 검증된 서명의 d 서명 도메인입니다.

RFC 9989 §4.4.1

DMARC d로 바꾸나요?

아니요. DKIM i ID는 DMARC 정렬에 사용되는 서명 도메인 식별자가 아닙니다.

RFC 9989 §4.4.1

모든 서명이 통과되어야 합니까?

아니요. 성공적으로 정렬된 서명은 다른 서명이 실패하더라도 DKIM 경로를 제공할 수 있습니다.

RFC 9989 §5.3.5

정렬되었지만 깨진 서명이 DMARC 전달하는 데 유용합니까?

아니요. 서명은 성공적으로 확인되고 정렬되어야 합니다.

RFC 9989 §4.4.1

종합 보고서에는 반드시 모든 서명이 나열됩니까?

아니요. 보고 제한 및 수신자 평가 동작은 표시되는 서명에 영향을 미칠 수 있습니다.

RFC 9990 §3.1.3

SPF 여전히 DMARC 충족할 수 있나요?

예. 통과 정렬된 SPF 경로는 DKIM 경로와 독립적으로 DMARC 충족할 수 있습니다.

RFC 9989 §5.3.5

두 번째 서명이 첫 번째 서명을 복구합니까?

아니요. 각 서명은 별도로 평가됩니다. 새 서명은 다른 성공 경로를 제공할 수 있습니다.

RFC 6376 §6.1 RFC 9989 §5.3.5

[ 출처 ]

출처

  1. RFC 9989

    섹션 §3.2.10.2 · §4.10.2 · §4.4.1 · §5.3.5 · §5.4

  2. RFC 9990

    섹션 §3.1.1.12 · §3.1.1.9 · §3.1.3

  3. RFC 6376

    섹션 §6.1

[ 어휘 ]

어휘

도메인 서명
서명 확인 및 DMARC 정렬에 사용되는 DKIM d 도메인. 선택기는 정렬된 ID가 아닌 키 조회를 식별합니다.

RFC 9990 §3.1.1.12 RFC 9989 §4.4.1

서명 범위 보고
보고 규칙에 포함된 서명 보고서에는 원본 메시지에 있는 모든 서명이 포함될 필요는 없습니다.

RFC 9990 §3.1.3

기업 출처

최고의 금융 기관과 정부가 필요한 이유 이메일 보안 대시보드를 폐기했습니다.

기존 이메일 인증 플랫폼은 대시보드를 판매하고 엔지니어에게 작업을 요청합니다. 위험이 높은 환경에서 수동 감독은 시행 지연, 구성 드리프트 및 모니터링되지 않는 섀도우 도메인을 의미합니다.

EmailAuth 는 에이전트 이메일 출처 플랫폼입니다. 우리 대리인은 집행합니다 p=reject, 제3자 발신자를 정렬하고 도메인을 전체로 이동하세요. RFC 9989 인간 참여형 감사 기능을 갖춘 새로운 DMARC 표준을 준수합니다.

정부 대기업 1등급 금융기관

SaaS · 전용 테넌시 · Air-Gapped 온프레미스 · BYOK 암호화

기술 자료