공급자는 유효한 것을 내보낼 수 있습니다. DKIM 조직의 서명 도메인을 지원하지 않는 서명. 서비스의 서명이 고객이 보낸 사람에서 볼 수 있는 도메인과 일치하지 않는 경우 이러한 제한이 중요합니다. DNS 변경하거나 서비스를 교체하기 전에 정확한 제한을 설정하십시오.
공급자가 실제로 지원하는 것이 무엇인지 확인
계정 계층, 전송 인터페이스 및 사용하는 도메인 유형을 다루는 최신 문서를 요청하세요. 확인된 발신자 주소, 사용자 정의 추적 도메인 또는 브랜드 반송 경로는 사용자 정의 DKIM 지원을 증명하지 않습니다. 실제 경로에서 수신된 원시 메시지를 얻고 모든 서명의 d 및 s 값과 신뢰할 수 있는 수신자의 확인 결과를 기록합니다.
RFC 6376 d를 서명 도메인으로 정의하고 해당 도메인과 함께 s를 사용하여 확인 데이터를 찾습니다. 자신의 도메인에 키를 게시하면 공급자가 생성한 서명의 d가 변경될 수 없습니다. 에이 CNAME 마찬가지로 공급자가 지원하는 서명 구성이 필요합니다. DNS 별칭만으로는 서비스에 서명을 지시하지 않습니다.
다른 정렬된 경로가 있는지 확인하세요.
적용 가능한 정책이 있고 해결되지 않은 평가 오류가 없는 경우 DMARC 통과 정렬된 통과 중 하나를 통과할 수 있습니다. SPF 또는 DKIM 결과. 서비스의 실제 평가 메일 보낸 사람 도메인과 SPF 결과는 별도로 표시됩니다. 지원되는 사용자 지정 반환 경로는 사용자 지정 DKIM 사용할 수 없는 경우에도 정렬된 SPF 제공할 수 있습니다. 확인 조정 모드와 도메인 관계; 공급자 소유 반환 경로는 단순히 계정 비용을 지불한다고 해서 정렬되지 않습니다.
예시 사례: 메일은 notices@brand.example 을 사용하고 d=vendor.example. 로 DKIM 전달합니다. MAIL FROM 도메인은 bounce.brand.example 이고 SPF 통과합니다. 조직-도메인 관계가 적합하다고 가정하면 완화된 SPF 정렬이 DMARC 충족할 수 있습니다. 엄격한 SPF 정렬을 사용하면 하위 도메인이 정확히 일치하지 않습니다. 이는 벤더에 대한 주장이 아닌 종합적인 결정의 예입니다.
RFC 9989 섹션 7.4 및 8에는 도메인 게시가 필요합니다. p=reject DMARC 패스를 위해 SPF 에만 의존하지 않고 유효한 DKIM 서명을 적용합니다. 따라서 직접 전달 SPF 패스는 완전한 p=reject 배포 설계가 아닙니다. 해당 서비스를 이 정책에 대해 준비된 것으로 처리하기 전에 누락된 정렬 DKIM 경로를 해결하세요.
SPF 정렬된 DKIM 의 동일한 대체물로 설명하지 마십시오. 전달은 연결 IP를 변경하고 SPF 방해할 수 있지만 그대로 정렬됩니다. DKIM 서명 살아남을 수도 있습니다. 하나의 직접 전달 테스트에 의존하기보다는 사용자에게 중요한 경로를 평가하세요.
지원되는 대안 비교
실용적인 선택은 도메인의 정책 및 허용된 제한 사항과 호환되는 문서화된 정렬 SPF 경로로 서비스를 유지하거나, 필요한 DKIM ID를 지원하는 서비스로 전송을 이동하거나, 최종 메시지에 서명하는 지원되는 승인된 릴레이를 사용하는 것입니다. 각각에는 테스트와 소유자가 필요합니다. 릴레이는 필요한 애플리케이션 동작을 보존해야 하며 내용 변경 처리 후에 서명해야 합니다. 단순히 관련되지 않은 서명을 추가하는 것만으로는 정렬이 해결되지 않습니다.
표시되는 보낸 사람 도메인을 변경하는 것은 숨겨진 기술 수정이 아니라 또 다른 제품 결정입니다. 이는 인식 및 회신에 영향을 미치며 대체 도메인에는 여전히 유효한 인증이 필요합니다. 문서화되지 않은 전송 경로 하나를 숨기기 위해 전체 조직의 DMARC 정책을 약화시키지 마십시오.
허용된 제한 사항을 기록합니다.
공급자의 기능 설명, 수신된 메시지 증거, 선택한 정렬 경로, 비즈니스 소유자 및 검토 트리거를 유지합니다. 서비스와 관련된 트랜잭션 메시지 및 전달 시나리오를 테스트합니다. 제한 사항이 남아 있는 경우 노출 및 마이그레이션 결정을 명시적으로 명시하세요. 완료란 녹색 DNS 스크린샷이 아닌 확인된 지원 경로 또는 자체 예외를 의미합니다.
채워진 결정 기록 사용
명시적으로 허구적인 이 두 경로 행렬을 고려해보세요. 결제 API A에는 From= brand.example , d=vendor.example, 선택자 Vendor1, MAIL FROM= bounce.brand.example , 원시 SPF 패스 및 원시 DKIM 패스. 완화된 SPF 정렬과 명시된 공유를 가정합니다. 조직 도메인: 성공적인 경로는 SPF 에만 정렬됩니다. 교체 릴레이 B에는 From= brand.example , d=brand.example, selector Relay2 및 MAIL FROM= vendor.example 이 있으며 두 원시 검사가 모두 통과되었습니다. 성공적인 경로는 DKIM 에만 정렬됩니다. 여기의 모든 기능과 결과는 공급자가 관찰하는 것이 아니라 가정된 것입니다.
이러한 필드 비교는 가정된 결과를 설명합니다. 픽스쳐 실행이나 공급자 확인이 요구되지 않습니다. Billing API A는 p=reject 배포에 허용되는 유일한 경로가 아닌 SPF 전용 결과를 보여줍니다. 두 설계 중 하나를 배포하기 전에 날짜가 지정된 경로별 공급자 지침, 생성된 DNS 값, 원시 수신 메일 및 신뢰할 수 있는 수신자 결과를 얻으세요. 의도한 신원과 관찰된 신원을 비교하고, 중요한 형식과 관련 전달을 테스트하고, 잔여 제한 사항을 수락한 소유자를 기록합니다. 이러한 실제 승인 필드는 아직 보류 중입니다.
지원되는 다음 단계를 선택하세요
- 알 수 없는 기능: 정확한 계정 계층 및 전송 경로에 대한 현재 지침을 얻습니다. DNS 값을 추측하지 마십시오.
- 정렬된 SPF 만 사용 가능: 직접 전달 제한 및 현재 정책을 기록합니다. p=reject. 에 대한 유일한 DMARC 경로로 사용하지 마십시오.
- 지원되는 서명 릴레이 사용 가능: 마이그레이션 전에 애플리케이션 동작, 최종 콘텐츠, 정렬된 d= 및 키 보관권을 확인합니다.
- 적합한 경로 없음: 공급자를 변경하거나 From ID에 대해 명시적인 제품 결정을 내립니다.
- 폐쇄: 수신된 메시지 증거, 남은 제한 사항, 책임 있는 소유자 및 다음 검토 트리거를 저장합니다.