도메인 별칭은 서비스 내에서 주소를 사용하거나 수신하는 방법을 변경합니다. 그 자체로는 아웃바운드에 배치된 도메인을 정의하지 않습니다. DKIM 서명. 고객 메일에 별칭을 사용하기 전에 의도한 경로를 통해 전송된 메시지를 검사하고 서비스가 서명하는 ID를 확인하세요.
별칭은 또한 과부하된 제품 용어이기도 합니다. 대체 사서함 주소, 테넌트에 연결된 도메인 또는 애플리케이션 수준 보낸 사람 ID를 설명할 수 있습니다. 이 워크플로는 결과 메시지 및 DNS 증거에 적용됩니다. 전송 또는 사용자 정의 도메인을 지원한다고 가정하기 전에 특정 별칭 기능에 대한 최신 설명서를 참조하세요. DKIM.
발신 ID와 수신 구성을 분리하세요.
먼저 별칭이 수행할 작업을 설정합니다. 기존 사서함으로 메시지를 받는 주소는 아웃바운드 사용이 승인되지 않을 수 있습니다. 전송이 지원되는 경우 서비스가 보낸 사람의 별칭을 유지하는지, 기본 주소에 다시 쓰는지, 다른 보낸 사람을 통해 라우팅하는지 확인합니다.
작성창에서 선택한 주소뿐만 아니라 배송 후 보이는 보낸사람 주소도 기록해 주세요. 또한 보낸 사람 필드와 봉투 ID를 모두 기록하되 DKIM 의 sd 도메인과 혼동하지 마세요. RFC 6376 §3.5 메시지 작성자의 주소와는 다른 d 서명 도메인을 정의합니다. RFC 9989 §4.4 작성자 도메인 및 인증된 식별자를 사용합니다. 조정.
통제된 메시지의 모든 서명을 읽으세요
프로덕션과 동일한 클라이언트, API 또는 위임된 사서함 경로를 사용하여 별칭에서 테스트를 보냅니다. 받은 메시지를 편집하지 않고 내보냅니다. 각 DKIM-Signature , 해당 d 및 s 값, 신뢰할 수 있는 수신자의 결과를 식별합니다. 서비스는 공급자 서명과 고객 도메인 서명을 모두 추가할 수 있습니다. 도구에 의해 표시되는 첫 번째 항목은 관련 항목이 아닐 수 있습니다. DMARC.
통과하는 각 서명에 대해 수신된 보낸 사람 도메인과의 정렬을 평가합니다. 엄격 모드에서는 다음과 같은 정확한 도메인 일치가 필요합니다. RFC 9989 §3.2.10. 편안한 모드는 동일한 것을 허용합니다 조직 도메인 아래에 RFC 9989 §4.10.2. 서로 다른 두 개의 등록된 도메인은 관리 포털에서 하나가 다른 도메인의 별칭이라는 이유만으로 정렬되지 않습니다.
작은 ID 워크시트를 사용하세요.
별개의 조직 도메인과 적용 가능한 DMARC 정책을 가정하는 예시 사례: 기본 주소는 person@company.example 이고 발신 별칭은 person@newbrand.example 입니다. 수신자는 newbrand.example 에서 From을 확인하고 d=company.example. 해당 서명은 newbrand.example 과 일치하지 않습니다. 다른 전달 서명이 d=newbrand.example, 사용하는 경우 해당 두 번째 서명은 정렬된 DKIM 경로를 제공합니다.
전체 메시지를 서명되지 않은 상태로 호출하거나 DKIM 손상되었다고 말하는 대신 두 가지 결과를 모두 기록하세요. 기본 도메인 아래의 유효한 서명은 여전히 유효한 DKIM 입니다. 누락된 속성은 별칭에 대한 정렬입니다. 평가하다 SPF 전체 DMARC 결과를 할당하기 전에 별도로 이 워크시트는 서비스의 별칭 동작에 대한 증거가 아닌 종합적인 예입니다.
지원되는 구제책 요청
공급자가 별칭 도메인으로 별칭 메일에 서명할 수 있는지 여부와 도메인을 고유한 발신 ID로 추가해야 하는지 여부를 물어보세요. 현재 DNS 레코드 이름, 레코드 유형 및 값을 가져옵니다. DNS 영역을 제어하는 사람이 누구인지, 제안된 변경 사항이 기존 영역과 충돌하는지 확인하십시오. 선택자.
기본 도메인 공개 키를 수동으로 복사하지 말고 서비스가 새 d 값을 사용하여 시작한다고 가정하지 마십시오. DNS 게시는 임의의 서명자에게 ID를 변경하도록 지시할 수 없습니다. 전송 구성과 게시된 검증 자료가 일치해야 합니다.
수명주기 검토에서 별칭 유지
해당 경로가 사용되는 경우 응답, 모바일 클라이언트 및 애플리케이션 생성 메시지에 대한 테스트를 반복합니다. 별칭의 사업주와 날짜가 적힌 샘플이 포함된 선택자-공급자 지도를 보관하세요. 마이그레이션 또는 은퇴 시 위임된 기록을 제거하기 전에 다른 ID가 여전히 동일한 공급자에 의존하는지 확인하세요.
클로저 문에는 어떤 별칭과 경로가 테스트되었는지, 어떤 도메인이 통과했는지, 정렬 여부가 명시되어야 합니다. 제품이 필수 ID를 제공할 수 없는 경우 별칭을 자격 없이 인증된 것으로 보고하는 대신 해당 제한 사항을 문서화하고 지원되는 전송 디자인을 선택하십시오.
다음 결정을 기록하세요
실제 경로당 하나의 행(요청된 별칭, 수신된 보낸 사람, 각 d/s 쌍, 신뢰할 수 있는 결과, 정렬 모드 및 남은 간격)을 사용합니다. 관련 없는 별칭 From이 있는 기본 도메인 패스는 유효한 DKIM 이지만 정렬된 DKIM 아닙니다. SPF 및 해당 정책이 평가될 때까지 전체 메시지를 DMARC 실패라고 부르지 마십시오. 여기서는 공급자별 별칭 기능이나 실시간 결과가 주장되지 않습니다.