[ DKIM ]

보존 전달과 수정 전달 구별

전달 경로를 추적하고 정렬된 서명이 변경되지 않은 콘텐츠에도 남아 있는지 테스트합니다.

EmailAuth 연구팀 제공

[ 핵심사항 ]

  • 전달은 DKIM이 적용되는 콘텐츠를 변경하지 않고도 SPF 의 연결 증거를 변경할 수 있습니다.
  • 보존된 정렬 DKIM 적용 가능한 정책에 따라 DMARC 의 전달 경로를 제공할 수 있습니다.
  • 봉투 재작성 및 현지 승인은 손상된 원본 서명을 복구하지 않습니다.
이 페이지에서

전달이 자동으로 중단되지 않습니다. DKIM. 해당 메시지 내용을 보존하는 전달자는 원래 서명을 유효한 상태로 남겨둘 수 있습니다. 포함된 헤더나 본문 콘텐츠를 다시 쓰는 전달자는 이를 무효화할 수 있습니다. 모든 간접 전달을 하나의 실패 모드로 취급하기보다는 전달 서비스가 실제로 수행하는 작업을 진단합니다.

ID와 변환을 별도로 추적

최종 수신자에서는 SPF 평가합니다 연결 시스템 및 관련 SMTP ID. 메시지 본문을 수정하지 않은 경우에도 전달을 통해 연결 IP가 변경될 수 있습니다. 대신 DKIM 서명 도메인의 키에 대해 포함된 메시지 내용을 확인합니다. 따라서 이러한 메커니즘은 전달된 동일한 메시지에서 분기될 수 있습니다.

표시되는 발신 도메인, 각 DKIM 서명 도메인, 선택자 결과적으로 봉투 ID와 전달 홉이 생성됩니다. DMARC 작성자 도메인과 일치하는 전달 인증 경로가 필요합니다. 그대로 정렬됨 DKIM 서명 전달이 중단될 때 적용 가능한 정책에 따라 해당 경로를 제공할 수 있습니다. SPF에 지정된 대로 RFC 9989 §4.4.1. 관련되지 않은 전달 도메인 아래에 새로 추가된 서명은 자동으로 정렬되지 않습니다.

직접 샘플과 전달된 샘플 비교

제어된 메시지를 직접 테스트 받은 편지함으로 보내고 전달 경로를 통해 다른 테스트 받은 편지함으로 보냅니다. 원시 메시지와 신뢰할 수 있는 수신자 결과를 보존합니다. 대상에만 의존하지 않고 샘플을 연관시킬 수 있도록 고유한 테스트 마커를 사용하십시오. 렌더링된 본체에서 동일성을 추론하지 마세요.

h에서 선택한 본문, 제목 및 기타 필드의 변경 사항을 검사합니다. 차이점을 해석하기 전에 c와 l 태그를 확인하세요. 기준 정규화 특정 형식 변경을 허용할 수 있는 반면 실질적인 재작성은 부호 있는 표현을 변경할 수 있습니다. 추가된 전송 헤더는 새로운 발생을 다루지 않은 서명을 본질적으로 무효화하지 않습니다. 반복되는 헤더 선택 및 초과 서명은 다음에서 중요할 수 있습니다. RFC 6376 §5.4.2.

두 가지 경로를 통해 작업

예시적인 경로 A는 해당 내용을 변경하지 않고 메시지를 전달합니다. 원본 서명은 계속 유효합니다. 경로 B는 서명된 본문에 경고 배너를 추가하여 원래의 전체 본문 서명이 실패하도록 합니다. 두 경로 모두에서 연결이 동일할 수 있으므로 SPF 관찰만으로는 DKIM 차이를 설명할 수 없습니다.

전달자는 다음을 다시 작성할 수도 있습니다. 봉투 보낸 사람 자체 SPF 인증을 개선합니다. 손상된 DKIM 서명을 복원하거나 반드시 SPF 생성하지는 않습니다. 조정 원본이 From 도메인에 표시됩니다. 어떤 ID가 SPF 통과했는지, 어떤 서명이 DKIM 통과했는지, 두 경로가 일치하는지 여부라는 세 가지 질문을 별도로 유지하세요.

범위가 지정된 해결 방법을 선택하세요.

콘텐츠 보존이 서비스의 보안 의무에 부합하는 경우 불필요한 수정을 방지하는 지원 설정을 검토하세요. 수정이 필요한 경우 서비스의 문서화된 서명 및 간접 메일 처리를 평가하십시오. 증상이 사라지도록 임의 전달자에게 서명 키를 부여하거나 SPF 에서 광범위하게 권한을 부여하지 마십시오.

관리 수신자는 간접 메일에 대해 추가로 신뢰할 수 있는 증거 또는 로컬 정책을 사용할 수 있지만 이는 별도의 승인 결정입니다. 원본 서명 복원과 같은 수락을 보고하지 마십시오. 기술 결과와 함께 비즈니스 요구 사항 및 예외 소유자를 유지합니다.

경로별 증명으로 종료

변경 후 일반 텍스트, HTML 및 첨부 파일에 대해 직접 대 전달 테스트를 반복합니다. 어떤 원본 서명이 남아 있는지, 새 서명이 나타나는지 여부, 최종 DMARC 및 전달 결과를 기록합니다. 이후의 배너 또는 검색 변경으로 인해 발신자의 DNS 변경 없이 결과가 변경될 수 있으므로 회귀 테스트에서 전달 경로를 유지하십시오.

두 가지 가상 메시지 수준 결과 읽기

적용 가능한 DMARC 정책과 작성자 도메인 example.com 가정합니다.

  • 보존 경로: 전달 후 SPF 실패하지만 원래 d=example.com 서명은 계속 확인됩니다. 정확하게 정렬된 DKIM ID는 DMARC 패스를 제공합니다.
  • 수정된 경로: 원래 DKIM 서명이 실패합니다. 유일한 새로운 통과 서명과 SPF ID는 forwarder.example.net 에 속합니다. 도메인이 example.com 과 관련이 없다고 가정하면 둘 다 정렬을 제공하지 않으므로 DMARC 실패합니다. 수신자는 여전히 별도의 현지 처리 결정을 내릴 수 있습니다.

새 서명의 패스를 이전 서명의 도메인과 병합하지 마십시오. 이러한 사례는 다음의 조건을 보여줍니다. RFC 9989 §5.3.5; 수신자 결과를 캡처하거나 모든 전달 서비스에 대해 보장하지 않습니다.

[ 테이크아웃 ]

전달은 DKIM이 적용되는 콘텐츠를 변경하지 않고도 SPF 의 연결 증거를 변경할 수 있습니다. 보존된 정렬 DKIM 적용 가능한 정책에 따라 DMARC 의 전달 경로를 제공할 수 있습니다. 봉투 재작성 및 현지 승인은 손상된 원본 서명을 복구하지 않습니다.

[ 역할별 ]

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

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

IT/메일 관리자

콘텐츠와 ID를 독립적으로 비교

연결 변경과 본체 변경은 서로 다른 검사에 영향을 줍니다.

다음 단계

  1. 두 경로를 모두 캡처합니다.
  2. 각 서명 결과를 매핑합니다.

CISO/SecOps

광범위한 권한 부여 방지

알 수 없는 전달자에게 서명 권한을 부여하여 간접 전달을 해결하지 마십시오.

다음 단계

  1. 신뢰 경계를 검토합니다.
  2. 범위가 지정된 수신기 예외를 추적합니다.

창립자 / 비기술자

간접 고객 경로를 계속 표시하세요.

직접 전달 테스트를 통과한 경우에도 전달된 메시지가 중요할 수 있습니다.

다음 단계

  1. 중요한 전달 워크플로를 식별합니다.
  2. 예외 결정을 소유하십시오.

[ 자주 묻는 질문 ]

자주 묻는 질문

모든 전달자가 DKIM 중단합니까?

아니요. 보존된 적용 콘텐츠에는 유효한 원본 서명이 유지될 수 있습니다.

RFC 6376 §3.7

DKIM 통과하는데 SPF 실패할 수 있는 이유는 무엇입니까?

서명된 콘텐츠는 그대로 유지되는 동안 평가된 봉투 ID에 대해 전달 연결이 승인되지 않을 수 있습니다.

RFC 7208 §10.3 RFC 6376 §3.7

배너가 DKIM 깨뜨릴 수 있나요?

예. 완전히 포함된 서명된 본문에 실질적인 추가가 있으면 정규화된 해시가 변경됩니다.

RFC 6376 §3.4.4 RFC 6376 §3.7

전달자의 새 서명이 DMARC 보장합니까?

아니요. DMARC 충족하려면 서명 도메인이 해당 DKIM 경로에 대해 표시되는 보낸 사람 도메인과 일치해야 합니다.

RFC 9989 §4.4.1

봉투 재작성은 DKIM 복구합니까?

아니요. 메시지 내용에 대한 원래 서명이 아닌 SMTP ID를 변경합니다.

RFC 6376 §3.7

모든 전달자를 SPF 에 추가해야 합니까?

아니요. 승인된 전송 인프라를 확장하기 전에 경로 및 권한 경계를 조사하십시오.

로컬 승인이 DKIM 여전히 실패했음을 의미할 수 있습니까?

예. 수신자 처분은 서명을 수정하지 않고도 다른 증거나 정책을 반영할 수 있습니다.

RFC 9989 §5.3.6

전달 변경 후 무엇을 테스트해야 합니까?

다양한 메시지 형식에 대한 직접 및 간접 경로로 원시 메시지와 신뢰할 수 있는 인증 결과를 보존합니다.

[ 출처 ]

출처

  1. RFC 6376

    섹션 §1 · §3.4 · §3.4.4 · §3.5 · §3.7 · §5.4.2 · §6.1

  2. RFC 9989

    섹션 §4.4 · §4.4.1 · §4.4.2 · §5.3.5 · §5.3.6

  3. RFC 7208

    섹션 §2.4 · §4.1 · §10.3

  4. RFC 8601

    섹션 §1.2

[ 어휘 ]

어휘

전송
수신된 메시지를 계속해서 릴레이하여 다음 수신자가 볼 수 있는 연결 및 봉투 ID를 잠재적으로 변경합니다.

RFC 7208 §10.3

정규화
DKIM 해싱 및 검증 전에 헤더 또는 본문 준비를 정의했습니다.

RFC 6376 §3.4

DMARC 정렬
인증된 ID와 작성자 도메인 간의 필수 관계입니다.

RFC 9989 §4.4

수신자 로컬 정책
DMARC 결과 또는 요청된 처리와 다를 수 있는 추가 수신자 처리 결정.

RFC 9989 §5.3.6

기업 출처

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

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

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

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

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

기술 자료