테넌트는 여러 브랜드, 획득한 도메인 및 직원 주소를 모두 동일한 방식으로 서명하지 않고도 포함할 수 있습니다. DKIM 관리 포털의 테넌트 레이블이 아닌 각 메시지에 포함된 서명 도메인과 함께 작동합니다. 서비스가 지원하는 ID를 설정한 다음 중요한 모든 도메인에 대한 결과를 증명하세요.
이 가이드에서는 공급자 중립적인 확인 워크플로를 설명합니다. 특정 제품이나 구독이 사용자 지정 도메인 서명을 지원한다고 주장하지 않습니다. 기록을 게시하거나 구성을 변경하기 전에 실제 서비스 및 경로에 대한 최신 지침을 얻으십시오.
도메인 구축 및 인벤토리 라우팅
표시되는 보낸 사람 도메인, 비즈니스 소유자, 테넌트, 전송 애플리케이션, 예상 DKIM d 도메인, 선택자, DNS 소유자 및 서명 상태. 웹메일, 인증된 SMTP , 애플리케이션 API, 위임된 계정 및 실제로 사용된 게이트웨이 경로를 포함합니다. 성공적인 직원 메일 테스트에서는 송장 신청서 서명 방법이 확립되지 않습니다.
아웃바운드 서명을 위해 구성된 도메인에서 테넌트의 확인된 도메인을 분리합니다. 또한 해당 개인 키를 사용하여 적극적으로 발신자로부터 존재하는 DNS 레코드를 분리합니다. 이는 별개의 상태이며 소유권 확인이나 게시된 키 중 어느 것도 수신된 메시지에 유효한 서명이 있음을 증명하지 못합니다.
받은 메일의 신원 매핑
각 경로에 대해 검사할 수 있는 외부 사서함에 제어된 메시지를 보냅니다. 원시 형식을 유지하고 수신자의 신뢰를 얻습니다. Authentication-Results. 각각에서 d와 s를 읽습니다. DKIM-Signature. RFC 6376 조회 이름을 서명 도메인의 _domainkey 아래 선택기로 정의합니다. 따라서 d=brand.example 및 s=tenant1 서명은 tenant1._domainkey.brand.example 을 가리킵니다.
서명 확인을 평가하고 DMARC 조정 갈라져. d의 도메인은 DMARC 에 대한 관련 DKIM ID입니다. 엄격한 정렬에는 정확한 도메인 일치가 필요합니다. 완화된 정렬은 해당 검색 규칙에 따라 조직 도메인을 비교합니다. 동일한 상업용 테넌트에 두 도메인이 모두 있어도 관련되지 않은 도메인이 정렬되지는 않습니다. RFC 9989 섹션 3.2.10 및 4.4에서는 이러한 차이점을 설명합니다.
두 가지 브랜드 사례를 통해 작업
예시적인 인벤토리: 테넌트는 d=brand.example 사용하여 brand.example 에서 직원 메일을 보내고 d=provider.example. 사용하여 second.example 에서 캠페인 메일을 보냅니다. 두 서명이 모두 통과되었다고 가정합니다. 첫 번째는 정확한 DKIM 정렬 일치입니다. 두 번째는 동일한 테넌트가 두 워크플로를 모두 소유하기 때문에 second.example 에 대해 정렬된 DKIM 제공하지 않습니다.
다음에 대한 별도의 결과를 추가하세요. SPF 두 번째 메시지를 확인하지 않고 DMARC 실패로 선언하는 대신. 적용 가능한 정책이 있고 해결되지 않은 평가 오류가 없으면 통과하고 정렬된 SPF ID가 메시지에 대한 DMARC 계속 충족할 수 있습니다. 그러나 RFC 9989 섹션 7.4 및 8에서는 도메인 게시가 필요합니다. p=reject DMARC 패스를 위해 SPF 에만 의존하지 않고 유효한 DKIM 서명을 적용합니다. 누락된 정렬 DKIM 경로를 완전한 거부 정책 설계가 아닌 해당 정책에 대한 배포 공백으로 간주합니다. 이 예에서는 완전한 수신자 판정이 아니라 누락된 DKIM 경로를 보여줍니다. 이는 실제 공급자에 대한 테스트가 아닌 합성 ID 및 가정된 결과입니다.
지원되는 서명 ID만 구성
각 도메인을 활성화하는 방법, 별칭이 기본 도메인의 구성을 따르는지 여부, SMTP 와 API 경로가 다르게 작동하는지 공급자에게 문의하세요. 정확한 TXT 따르거나 CNAME 지침. CNAME 모델을 사용하면 공급자 관리 검증 데이터에 대한 위임을 따릅니다. 추측된 공개 키를 대체하거나 다른 테넌트의 대상을 복사하지 마십시오.
서비스에 필요한 경우 별도의 선택기를 사용하고 소유권 기록을 유지관리하세요. 여러 도메인에서 선택기 레이블을 재사용하는 것은 전체 DNS 이름이 다르기 때문에 본질적으로 충돌이 아닙니다. RFC 6376 섹션 3.6.2.2 에는 키가 필요합니다. TXT 레코드 선택기 이름에 대해 고유해야 합니다. 해당 조회 이름의 여러 TXT 레코드에 정의되지 않은 결과가 있습니다. 거기에 경쟁 키를 게시하지 마십시오.
증거로 재고를 마감하세요
날짜가 지정된 수신 메시지 샘플, 예상 신원, 관찰된 서명 결과 및 정렬 평가가 있는 경우에만 확인된 각 행을 표시하십시오. 지원되지 않는 경로를 테넌트의 활성화 상태 뒤에 숨기지 말고 소유자 및 대안에 대한 제한 사항으로 기록하십시오.
도메인 추가, 라우팅 규칙 변경, 브랜드 마이그레이션 후 다시 테스트하세요. 서명 권한 및 공급자 종속성이 해당 목적보다 오래 지속되지 않도록 오프보딩에 위임된 기록을 포함합니다. 유용한 결과는 전역 전환의 스크린샷이 아니라 설명 가능한 도메인-서명 맵입니다.
경로당 하나의 증거 행을 완료하세요.
- 예상: 비즈니스 소유자, 보낸 도메인, 애플리케이션 경로, 서명 도메인 및 선택기.
- 게시됨: 정확한 선택기 DNS 이름, 레코드 유형 및 위임된 대상(사용된 경우).
- 관찰됨: 수신된 메시지 날짜, 각 d=/s= 쌍 및 신뢰할 수 있는 확인 결과.
- 정렬됨: 해당 정책에 따라 DKIM 및 SPF ID 전달과 From을 비교합니다.
- 결정: 소유자 및 다음 테스트를 통해 확인, 지원되지 않음 또는 해결되지 않음.
- 폐기: 경로 서명이 중지되는 시점, 대기 중인 메일 허용 및 사용되지 않는 위임을 제거하는 사람을 기록합니다.