정확한 GoodData 제품 및 경로를 확인하세요
이 가이드를 지원하는 자사 절차에는 GoodData Legacy Growth, Configure라는 라벨이 붙어 있습니다. DKIM 발신 이메일용. 이는 화이트 라벨이 붙은 발신 메일과 관련이 있으며 고객 측과 GoodData 측 모두의 작업이 필요합니다. 현재 GoodData Cloud, 다른 요금제, 다른 알림 서비스에 자동으로 적용하지 마세요.
계정 소유자에게 제품, 화이트 라벨 도메인, 보낸 사람 주소 및 실제 메시지 워크플로를 확인하는 것부터 시작하세요. 화이트 라벨 구성을 처리하는 DNS 관리자와 GoodData 지원 소유자를 식별합니다. 사용자 정의 애플리케이션 URL 또는 브랜딩 테마는 발신 이메일이 동일한 도메인으로 서명되었다는 증거가 아닙니다.
독자의 작업은 지원되는 서명 배열을 설정한 다음 의도한 메일을 테스트하는 것입니다. 카탈로그의 광범위한 공급자 라벨은 모든 GoodData 제품이 동일한 기능을 지원한다고 주장하는 것을 정당화하지 않습니다. 선택자, 릴레이 또는 키 관리 프로세스. 문서화된 레거시 범위가 테넌트와 일치하지 않는 경우 DNS 변경하기 전에 일치하는 자사 절차를 얻으세요.
지원되는 키 배열 선택
레거시 성장 문서에서는 대안으로 GoodData에서 생성된 고유 키와 함께 특정 개인 키를 사용하거나 GoodData 공유 키를 사용하는 방법을 설명합니다. 공유 키 경로에서 지원팀은 공개 키가 포함된 DNS 레코드를 제공합니다. 특정 키 경로에서 당사자는 서명 구성에 따라 선택기와 도메인을 조정합니다. 고객이 이 가이드에서 복사할 수 있는 범용 선택기 또는 공개 키 값은 제공되지 않습니다.
조직의 서명 키 소유권 정책에 적합하고 불필요한 노출을 최소화하는 배열을 선호합니다. 키를 생성하는 사람, 키를 사용할 수 있는 사람, 순환 조정 방법, 서비스가 중단될 때 공급자의 서명 권한이 제거되는 방법을 명확히 합니다. 공용 DNS 레코드는 널리 표시될 수 있습니다. 개인 키는 같은 방식으로 취급될 수 없습니다.
공급자 문서에서는 고객이 제공한 개인 키를 사용할 때 암호화된 전송에 대해 설명합니다. 채팅, 일반 지원 댓글, 공개 문서 또는 DNS 에 개인 키를 붙여넣지 마세요. 승인된 보안 소유자가 의도한 수신자와 보안 전송 프로세스를 확인하도록 하십시오. 공급자가 생성한 대안을 요청하거나 수락하려면 여전히 개인 서명 자료를 보유하고 통제하는 사람이 누구인지 이해해야 합니다.
공개 검증 자료만 게시
지원되는 설정에서 정확한 레코드 유형, 전체 소유자, 선택자 및 공개 값을 가져옵니다. 승인된 서명 도메인과 비교하세요. 상대 이름 필드가 영역을 자동으로 추가할 수 있으므로 필요한 DNS 편집기 레이블을 별도로 기록합니다. 변경하기 전에 기존 선택기가 이미 다른 메일 서비스에 속해 있는지 확인하세요.
A DKIM 서명 d=example.com 및 s=analytics1 사용하면 analytics1._domainkey.example.com 에서 해당 키를 찾습니다. 이는 GoodData 기본값이 아닌 합성 이름 구성의 예입니다. 다른 선택기 또는 도메인에서 올바르게 게시된 키는 해당 서명을 확인하지 않습니다. 편집자가 긴 내용을 표현할 때 완전한 공개 가치와 기록 경계를 보존합니다. TXT 레코드 여러 문자열로.
게시 후 정확한 소유자에 대해 권한 있는 DNS 쿼리하세요. 답변을 유지하고 활성 위임이 귀하가 편집한 기록을 제공하고 있는지 확인하십시오. 그런 다음 지원 소유자에게 GoodData 측 구성을 완료하도록 하세요. 서명 활성화 없이 DNS 게시하는 것은 작업의 절반에 불과합니다.
선택적 SPF 정렬과 다르게 유지
레거시 성장 페이지 목록에는 include:relays.gooddata.com 이 선택 사항으로 SPF 또한 메일 릴레이를 승인합니다. 이용하기 전에 해당 경로인지 확인하세요. 조직에 관련 없는 GoodData 워크플로가 존재한다는 이유만으로 추가하지 말고, 동일한 소유자에게 두 번째 SPF 정책을 생성하지 마세요.
필요한 SPF 업데이트를 전체적으로 검토합니다. 승인된 기존 발신자를 보존하고, 정책의 DNS 조회 종속성을 확인하고, 터미널 동작을 확인합니다. 명시적인 유지 관리 계획 없이 릴레이 IP 주소를 정적 허용 목록에 복사하지 마세요. 공급자 관리 인증 대상과 오늘의 답변 고정 목록은 운영상의 결과가 다릅니다.
SPF 성공 자체는 입증되지 않습니다. DMARC 조정. 평가된 신원은 봉투 보낸 사람 도메인. 메시지가 보낸 사람에 도메인을 표시하는 동안 공급자 소유 봉투를 사용하는 경우 해당 공급자 도메인의 SPF 패스가 도메인과 일치하지 않습니다. 표시되는 보낸 사람과 정렬된 전달 DKIM 서명은 필수 경로를 제공할 수 있습니다.
실제 화이트 라벨 메시지 테스트
각 자료 범위 내 워크플로를 통제되고 승인된 테스트 사서함으로 트리거합니다. 수신된 원시 메시지를 보관하고 작업 흐름, 발신자 구성 및 테스트 시간을 기록해 둡니다. 표시되는 보낸 사람, 봉투 ID, 모든 DKIM 서명 도메인 및 선택기, 신뢰할 수 있는 수신자 인증 결과를 기록합니다. 화이트 라벨 URL이나 서명된 디스플레이만으로 이러한 값을 추론하지 마십시오.
종합 승인 예: From is reports@example.com , 메시지의 DKIM 서명이 d=example.com 으로 확인되고 수신자는 정렬된 경로에서 DMARC 성공적으로 평가합니다. SPF 관련되지 않은 봉투 도메인에 대해서만 통과하더라도 정확하게 정렬된 DKIM DMARC 경로를 제공할 수 있습니다. 서명이 관련되지 않은 다른 도메인을 대신 사용하는 경우 DKIM 패스만으로는 이러한 승인 결론을 뒷받침하기에 충분하지 않습니다.
키 순환 또는 메일 전송 변경 후 샘플을 반복합니다. 예상되는 서명이 없는 경우 레코드를 더 추가하기 전에 GoodData 측 활성화 및 실제 작업 흐름을 확인하세요. 서명이 있지만 유효하지 않은 경우 선택기, 도메인, 공개 키 및 메시지 수정 사항을 비교하십시오. 인증은 통과했지만 전송 상태가 좋지 않은 경우 다른 수신자와 평판 요소를 별도로 조사하세요.
계획 순환, 폐기 및 복구
변경 전 기록 세트와 서명 계약의 각 부분에 대해 문서화된 소유자를 보관하십시오. 공급자가 새로운 선택기로 서명을 시작하는 시간과 공개 키를 사용할 수 있게 되는 시간을 조정합니다. 단일 레코드 삭제로 모든 기능이 취소되거나 이미 전송된 메일이 아직 전달 중이므로 이전 키를 즉시 삭제하는 것이 안전하다고 가정하지 마십시오.
통합을 중단할 때 선택기 또는 SPF 권한을 제거하기 전에 아직 통합이 필요한 워크플로가 없는지 확인하세요. 조직의 보안 프로세스에 따라 개인 키 보존 및 공급자 측 서명 액세스를 조정합니다. 키가 노출되었을 수 있는 경우 문제를 일반적인 DNS 캐시 지연으로 처리하기보다는 사고 및 순환 프로세스를 사용하십시오.
이것은 특별히 라벨이 붙은 레거시 제품에 대한 다큐멘터리 가이드입니다. 예시는 합성입니다. 개인 키, 테넌트 구성, DNS 변경, 지원 교환 또는 전달된 GoodData 메시지가 액세스되거나 테스트되지 않았습니다. 생산 검증 및 더 광범위한 제품 범위 결정은 계정 및 보안 소유자에게 있습니다.
경로 완료를 호출하기 전에 활성화 원장을 사용하십시오.
서면 사례 GD-01에서는 테넌트가 Legacy Growth로 확인되었고 승인된 보낸 사람은 reports@example.com 이고 합의된 예시 선택자는 Analytics1이라고 가정합니다. DNS 소유자는 analytics1._domainkey.example.com 에 규정된 공개 키를 가지고 있지만 공급자 측 서명 활성화는 확인되지 않은 상태로 유지됩니다. DNS 만으로는 작업을 종료할 수 없습니다. 화이트 라벨 소유자에게 지원되는 서명 구성을 확인한 다음 무해한 인증 알림을 검사하도록 요청하세요. d=example.com, s=analytics1 사용한 이후의 가상의 신뢰할 수 있는 DKIM 패스는 정확한 정렬을 제공하지만 해당 증거가 존재할 때까지 메시지 결과는 알 수 없는 상태로 유지됩니다. 여기서는 개인 키, 지원 요청, DNS 조회 또는 테넌트 작업이 사용되지 않았습니다.
시행 경계 유지
RFC 9989 섹션 7.4에서는 도메인 게시를 위해 SPF 단독이 아닌 유효한 DKIM 필요합니다. p=reject, 간접 메일과 메일링 목록 상호 운용성에 대해 경고합니다. 단일 성공적인 직접 메시지 테스트가 모든 합법적인 경로가 더 강력한 정책을 수용할 준비가 되어 있다는 증거는 아닙니다. 실제 격차를 진단하는 동안 기존에 승인된 보호를 유지합니다. 모든 정책 변경에는 자체 결정이 필요합니다.