[ DKIM ]

아웃바운드 보안 또는 서명 서비스 후에 DKIM 올바르게 배치하세요.

승인된 아웃바운드 콘텐츠 처리 후 최종 서명 경계를 설계하고 테스트합니다.

EmailAuth 연구팀 제공

[ 핵심사항 ]

  • 최종 서명자를 선택하기 전에 콘텐츠 변경 사항을 매핑하세요.
  • 전달되는 각 ID와 해당 DMARC 정렬을 검사합니다.
  • 필수 검사를 유지하고 실제 사업 경로를 테스트합니다.
이 페이지에서

아웃바운드 보안 게이트웨이 또는 기업 서명 서비스는 애플리케이션이 이미 메일에 서명한 후에 메일을 검사하고 수정할 수 있습니다. 마구간 DKIM 설계는 필요한 콘텐츠 변경 후 최종 승인된 서명 단계를 배치하고 전체 경로를 확인합니다. 중요한 질문은 어떤 제품이 활성화된 DKIM 설정을 먼저 표시하는지가 아니라 어떤 구성 요소가 최종 메시지를 표시하는지입니다.

실제 처리 순서를 그려라

지도 제출, 콘텐츠 검사, 고지 사항 또는 서명 삽입, MIME 직렬화, DKIM 서명 및 외부 전달. 애플리케이션 및 긴급 장애 조치에 사용되는 대체 경로를 포함합니다. 직원 사서함 메일과 응용 프로그램 메일이 동일한 경로를 사용한다고 가정하지 마십시오.

각 구성 요소에 대해 본문, 선택한 헤더, 봉투 ID 또는 라우팅 메타데이터만 변경하는지 여부를 기록합니다. 회사 이메일 서명 블록은 본문 콘텐츠입니다. 암호화폐와는 관련이 없습니다 DKIM-Signature 공유 단어 "서명"에도 불구하고 헤더. URL 재작성, 첨부 파일 처리 및 HTML 재구축도 해당 콘텐츠에 영향을 줄 수 있습니다.

RFC 6376 §5.3 그리고 RFC 6376 §5.5 서명자가 의도한 전송 표현에 대해 작업을 수행하고 재서명자가 재서명하기 전에 변경하도록 수정하도록 요구합니다. 디자인은 해당 시퀀스를 눈에 보이고 테스트 가능하게 만들어야 합니다.

도메인 및 키 소유자 선택

게이트웨이는 자체 도메인 아래에 유효한 서명을 추가할 수 있습니다. 이는 자동으로 DKIM 충족하지 않습니다. 조정 귀하의 작성자 도메인에 대해 RFC 9989 §4.4.1. 필요한 설계에서 사용자 정의 도메인 서명을 사용하는 경우 제품의 문서화된 기능, 생성된 DNS 값 및 개인 키의 관리권을 확인하십시오. 발명하지 마세요 선택자 다른 테넌트의 구성 이름을 지정하거나 복사합니다.

서명 구성을 변경하고, 키를 순환하고, 최종 콘텐츠 파이프라인을 변경할 수 있는 사람을 결정하세요. 개인 키를 사건 기록이나 테스트 번들로 내보내지 못하도록 보호하세요. 공개 키 게시는 설정의 한 부분일 뿐입니다. 실제 발신 메시지에는 최종 처리 후에 생성된 일치하는 서명이 있어야 합니다.

두 개의 컨트롤을 사용하여 파이프라인 테스트

예시 디자인 A가 먼저 서명한 다음 회사 연락처 블록을 추가합니다. 원본 전신 서명이 실패할 수 있습니다. 디자인 B는 블록을 삽입하고 MIME 직렬화를 완료한 다음 승인된 정렬 도메인으로 서명합니다. 나중에 처리하여 해당 데이터가 그대로 유지되는 경우 의도한 서명은 그대로 유지될 수 있습니다. 이는 테스트 기대치이며 지정된 공급업체에 대한 주장이 아닙니다.

원하는 경로를 통해 일반 텍스트, HTML, 비ASCII 콘텐츠 및 첨부 파일을 보냅니다. 해당되는 경우 애플리케이션에서 생성된 메시지와 지원되는 장애 조치 경로를 포함합니다. 마지막 프로세서 다음과 신뢰할 수 있는 외부 수신기에서 메시지를 캡처합니다. 미분화된 합격 라벨을 받아들이는 대신 각 결과를 d 및 s와 연관시킵니다.

설계에 보안 제어 유지

나중에 서명을 이동하면 보호된 작업 흐름 외부로 검사를 자동으로 이동하거나 필수 검색을 우회해서는 안 됩니다. 필수 재작성 서비스 이후 최종 서명자를 실행할 수 없는 경우 지원되는 통합 또는 다른 승인된 서명 경계를 평가하십시오. 단지 통과 횟수를 생성하기 위해 이후 콘텐츠를 제외하기 위해 l을 사용하지 마세요. RFC 6376 §8.2 서명되지 않은 콘텐츠의 위험을 설명합니다.

다운스트림 새 서명은 이전에 실패한 서명과 공존할 수 있습니다. 어떤 서명이 의도한 정렬을 제공하는지와 수신 서비스가 이를 보고하는 방법을 확인합니다. 테스트 기록에서 이전 실패의 증거를 삭제하지 마십시오.

변경 제어 서비스로 경계를 운영합니다.

경로 다이어그램, 책임 소유자, 키 보존 계획 및 형식 테스트 모음을 유지합니다. 게이트웨이 업그레이드, 브랜딩 템플릿 변경, 라우팅 변경 및 장애 조치 활성화 후 다시 테스트하십시오. 성공하려면 의도된 콘텐츠, 유효하게 정렬된 인증 경로 및 올바른 전달이 필요하며, 사람의 승인은 여전히 ​​기술 결과와 별개입니다.

다음 결정을 기록하세요

가상 메시지의 경우 프로세서 순서, 예상되는 콘텐츠 변경 사항, 각 d/s 쌍, 수신기 판정 및 정렬을 기록합니다. 게이트웨이가 관련되지 않은 공급업체 도메인으로만 서명하는 경우 서명이 통과되더라도 정렬된 DKIM 확인되지 않은 것으로 표시합니다. 서명자를 이동하면 검사를 우회할 수 있는 경우 해당 설계 변경을 중지하고 지원되는 통합을 찾으십시오. 이는 실행된 경로 테스트가 아닌 계획 기준입니다.

[ 테이크아웃 ]

최종 서명자를 선택하기 전에 콘텐츠 변경 사항을 매핑하세요. 전달되는 각 ID와 해당 DMARC 정렬을 검사합니다. 필수 검사를 유지하고 실제 사업 경로를 테스트합니다.

[ 역할별 ]

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

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

IT/메일 관리자

방출된 표현에 서명

콘텐츠 처리 후 최종 서명을 하고 실제 수신자 결과를 확인합니다.

다음 단계

  1. d와 s를 확인합니다.
  2. 형식 회귀 제품군을 유지합니다.

CISO/SecOps

마지막 수정자에서의 제어 권한

최종 서명자와 콘텐츠 프로세서는 중요한 신뢰 경계를 정의합니다.

다음 단계

  1. 열쇠 양육권을 검토하세요.
  2. 필수 검사를 유지합니다.

창립자 / 비기술자

전체 비즈니스 경로를 소유하세요

DKIM 토글은 모든 애플리케이션이 올바른 파이프라인을 따른다는 것을 증명하지 않습니다.

다음 단계

  1. 애플리케이션 메일 소유자의 이름을 지정합니다.
  2. 장애 조치 테스트를 승인합니다.

[ 자주 묻는 질문 ]

자주 묻는 질문

회사 서명 블록은 DKIM 서명입니까?

아니요. 회사 블록은 메시지 콘텐츠입니다. DKIM-Signature 은 암호화 인증 헤더입니다.

RFC 6376 §3.5

최종 서명은 어디에서 이루어져야 합니까?

필요한 콘텐츠 변경 및 최종 직렬화 후, 해당 표현을 보존하는 전송 전.

RFC 6376 §5.3 RFC 6376 §5.5

공급업체 도메인 서명이 DMARC 충족합니까?

서명 도메인이 최종 표시되는 보낸 사람 도메인과 일치하는 경우에만 해당됩니다. 관련이 없는 공급업체 도메인은 자동으로 정렬되지 않습니다.

RFC 9989 §4.4.1

다른 테넌트의 선택기 값을 재사용할 수 있나요?

아니요. 서비스의 문서화된 테넌트별 생성 값을 사용하고 실제 발신 서명을 확인하세요.

DKIM 보존하기 위해 검사를 우회해야 합니까?

자동 수리로 만들지 마십시오. 필수 검사 및 최종 서명을 유지하는 지원되는 디자인을 선택하세요.

지원서 메일을 별도로 테스트하는 이유는 무엇입니까?

직원 메일 경로를 우회하거나 다른 게이트웨이, ID 또는 서명자를 사용할 수 있습니다.

이전 서명과 새 서명이 공존할 수 있습니까?

예. 이전 서명이 복구되었다고 가정하기보다는 각각을 독립적으로 평가하고 통과 정렬 경로를 식별합니다.

RFC 6376 §4.2 RFC 9989 §4.4.1

어떤 변경 사항이 재테스트를 유발합니까?

게이트웨이 업그레이드, 콘텐츠 템플릿, 직렬화, 라우팅, 키 및 장애 조치 변경 사항은 모두 최종 경계에 영향을 미칠 수 있습니다.

[ 출처 ]

출처

  1. RFC 6376

    섹션 §1 · §3.1 · §3.5 · §4.2 · §5.3 · §5.5 · §8.2 · §8.3

  2. RFC 9989

    섹션 §4.4 · §4.4.1

  3. RFC 8601

    섹션 §1.2 · §7.1

[ 어휘 ]

어휘

DKIM
공개 키 데이터를 사용하여 확인된 선택한 메시지 콘텐츠에 대한 도메인 관련 서명입니다.

RFC 6376 §1

선택자
확인 데이터를 찾기 위해 d 서명 도메인과 함께 사용되는 s 값입니다.

RFC 6376 §3.1 RFC 6376 §3.5

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

RFC 9989 §4.4

기업 출처

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

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

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

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

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

기술 자료