Hosted Exchange를 레거시 서비스 이름으로 취급
보내는 인벤토리에 여전히 Rackspace Hosted Exchange가 표시되면 먼저 조직의 메일을 보내는 항목을 설정하세요. 랙스페이스의 2023년 1월 5일 사건 업데이트 Hosted Exchange 환경은 지속적인 서비스로 재구축되지 않을 것이라고 명시되어 있습니다. 이 업데이트는 Microsoft 365 마이그레이션과 Rackspace Email을 대안으로 식별합니다. 이는 현재 제안, 가격 약속 또는 마이그레이션 확인이 아닌 과거 제품 증거입니다.
따라서 이 가이드에서는 레거시 종속성을 해결하고 대체 경로를 확인하는 방법을 다룹니다. 새로운 Hosted Exchange 등록 단계는 제공하지 않습니다. DKIM 스위치 또는 재사용 가능한 DNS 값. 이전 공급자 라벨은 DMARC 보고서는 중단된 사서함 서비스가 활성 발신자로 남아 있다는 증거가 아니라 조사의 단서입니다.
변화에 집중하세요. 제어된 사서함의 최근 일반 메시지부터 시작하여 한 번에 하나의 비즈니스 경로를 조정합니다. 단지 오래된 지원 문서와 유사하다는 이유만으로 기록을 제거하지 마십시오. 동일한 조직이 별도의 애플리케이션 릴레이, 전달 배열 또는 보관 종속성을 유지하면서 직원 메일을 이동할 수 있습니다.
오늘 실제로 보내는 서비스를 확인하세요
현재 서비스 이름, 관리자 포털, 도메인 인벤토리 및 마이그레이션 기록은 계정 소유자에게 문의하세요. 어떤 플랫폼에서 메시지를 내보내는지 누가 지원 비용을 청구하는지 구분하세요. Rackspace에서 관리하는 Microsoft 365 계정은 실제 Microsoft 365 테넌트 및 경로를 사용하여 평가해야 합니다. Rackspace Email은 해당 제품의 최신 지침에 따라 평가되어야 합니다. 둘 다 이전 호스팅 Exchange 체크리스트의 증거를 상속받지 않습니다.
직원 사서함, 공유 주소, 애플리케이션, 다기능 장치 및 외부에서 호스팅되는 도구를 포함하는 경로 목록을 작성하십시오. 의도한 보낸 사람 주소, 책임 소유자, 현재 제출 방법 및 각각에 대한 대표 메시지를 기록합니다. 몇 년 전에 구성된 애플리케이션은 여전히 사용자의 데스크톱 클라이언트와 다른 아웃바운드 경로를 사용하고 있을 수 있습니다.
불일치를 해결하려면 관리 증거와 수신된 메시지를 모두 사용하십시오. 송장은 상업적 관계를 설정할 수 있는 반면, 새로운 헤더에는 특정 배송이 표시됩니다. MX 레코드 수신 메일이 어디로 향하는지 보여줍니다. 그 자체만으로는 아웃바운드 메일 전송이 허용된 모든 서비스를 식별할 수 없습니다. 불확실한 경로를 가장 가까운 친숙한 제품 범주에 넣기보다는 해결되지 않은 경로로 표시하십시오.
정리하기 전에 DNS 기준을 보존합니다.
관련 영역 레코드를 내보내고 정확한 소유자, 유형, 값 및 TTL을 문서화합니다. 포함하다 SPF, DKIM 선택기, DMARC 및 기타 반환 경로 대표단. 각 종속성을 소유한 애플리케이션 또는 서비스와 승인된 교체 지침을 찾을 수 있는 위치를 기록합니다. 다른 관리자가 의도적인 마이그레이션과 우발적인 삭제를 구별할 수 있도록 변경 요청과 함께 이 기준을 유지하십시오.
SPF SMTP 에 적용됩니다. 메일 보낸 사람 아이덴티티, 별도의 HELO 평가는 단순히 메시지에 표시된 주소가 아닌 RFC 7208 또한 단일 SPF 정책을 올바르게 선택해야 하며 DNS 쿼리 메커니즘과 수정자를 제한합니다. 승인을 추가하거나 제거하기 전에 실제 평가된 소유자의 전체 정책을 검토하세요.
두 번째를 만들지 마십시오 SPF 레코드 마이그레이션 단축키로. 현재 서비스에 필요한지 확인하지 않고 기록 포함을 새 정책에 붙여넣지 마십시오. 마찬가지로, 포함에 종속된 모든 경로가 승인된 처리를 가질 때까지 포함을 제거하지 마십시오. 공유 인증은 정당한 이유로 사서함 마이그레이션 후에도 유지될 수 있지만 해당 비즈니스 소유자와 목적은 명시적이어야 합니다.
교체 경로에 대한 구성 가져오기
인증된 관리 표면 또는 검증된 지원 채널에서 현재 플랫폼의 도메인별 지침을 요청하세요. 필요한 증거는 정확한 레코드 세트, 지원되는 서명 ID, 봉투 도메인 동작 및 해당 계정에 대한 활성화 단계입니다. 공개 문서에서는 절차를 설명할 수 있지만 도메인이 등록되었는지 또는 표시된 예가 할당된 값인지 확인할 수는 없습니다.
지침이 기존 소유자와 충돌하는 경우 해당 개별 변경 사항을 일시 중지하세요. 충돌하는 서비스를 기록하고 관련 제공업체에 지원되는 해결 방법을 문의하세요. 발명하지 마세요 DKIM 선택기, 다른 고객의 공개 키를 재사용하거나 기존 키를 리디렉션합니다. CNAME 마법사가 완전한 것처럼 보이도록 합니다. 승인된 소유자가 별도의 정책 변경을 승인하지 않는 한 조직의 기존 DMARC 정책을 유지합니다.
활성화하기 전에 복구 조치를 정의하십시오. 마지막으로 승인된 발신자 구성을 복원하거나, 영향을 받은 애플리케이션을 일시 중지하거나, 정확하게 식별된 DNS 변경 사항을 되돌리는 것일 수 있습니다. 중단된 Hosted Exchange 서비스를 복원하는 것은 유효한 롤백 계획이 아닙니다. 복구 경로는 자체적으로 사용 가능해야 하며 대체할 비즈니스 기능에 대해 검증되어야 합니다.
수신자에서 새 ID를 확인하세요.
모든 범위 내 경로를 통해 제어된 외부 사서함으로 무해한 메시지를 보냅니다. 내부 전달이 중요한 경우 별도의 내부 테스트를 포함합니다. 메시지 ID, UTC 시간, 보낸 도메인, Return-Path , 각 DKIM 서명 도메인 및 선택기, 신뢰할 수 있는 수신 시스템에서 스탬프를 찍은 인증 결과를 기록합니다. 불필요한 개인 콘텐츠를 유지하지 않고 메시지를 올바른 애플리케이션과 연결할 수 있도록 충분한 컨텍스트를 저장하세요.
A DKIM 서명'sd= 및 s=는 다음에 정의된 대로 서명 도메인과 해당 키를 찾는 데 사용되는 선택기를 식별합니다. RFC 6376. 관련되지 않은 공급자 도메인의 통과 서명만으로는 조정 당신의 보이는 보낸 사람과 함께. 리포팅 툴에 표시된 제품명이 아닌 관찰된 아이덴티티를 비교해보세요.
아래에 RFC 9989, 통과 SPF 또는 DKIM ID가 보낸 사람 도메인과 일치하면 DMARC 통과될 수 있습니다. 실제로 구성된 정렬 모드를 적용합니다. 관련 하위 도메인은 완화된 설정과 엄격한 설정에서 다르게 동작할 수 있습니다. 정렬된 패스를 제공한 메커니즘을 기록합니다. 녹색 DNS 확인 또는 성공적인 받은 편지함 배치는 이 메시지 수준 증거를 대체하지 않습니다.
Rackspace 레거시 경로 워크시트
각 사서함 또는 애플리케이션 경로에 대해 별도의 행을 작성하십시오.
- 과거 서비스 라벨 및 현재 확인된 서비스: ____.
- 사업주, 관리자 및 현재 지침 참조: ____.
- 보낸 사람 주소 및 제출 경로: ____.
- 기준 DNS 내보내기 및 다른 서비스와 공유되는 레코드: ____.
- 대체 기록 소유자, 가치 및 활성화 증거: ____.
- 기존 DMARC 정책 및 적용 가능한 정렬 모드: ____.
- 메시지 ID, UTC 시간 및 제어된 수신 사서함: ____.
- 관찰된 Return-Path , DKIM d= 및 s=, 신뢰할 수 있는 결과: ____.
- 정렬된 전달 메커니즘 및 해결되지 않은 예외: ____.
- 승인된 복구 경로 및 은퇴 소유자: ____.
알 수 없는 현재 서비스 또는 누락된 수신기 결과로 인해 경로가 계속 열려 있습니다. 데이터 복구, 기록 사서함 보존 및 실시간 전송을 별도의 작업 항목으로 추적합니다. 하나의 진전이 다른 것의 완성을 증명하지는 않습니다.
더 이상 사용되지 않는 발신자 라벨의 가상 진단
가상의 예일 경우: Birch Engineering은 Hosted Exchange라는 보고 항목을 확인하고 이전 SPF 인증 복원을 제안합니다. 관리자는 직원 메일이 Microsoft 365 로 이동한 반면 스캐너는 다른 릴레이를 사용하는지 확인합니다. 제어된 테스트에서는 직원 메일에 대해 정렬된 인증과 스캐너 메일에 정렬되지 않은 공급자 서명을 표시합니다.
팀은 두 경로를 분리하고 현재 릴레이 지침을 얻은 다음 스캐너가 지원하는 발신자 구성을 수정합니다. 직원 메일 인증은 변경되지 않습니다. 새로운 스캐너 테스트에서 정렬이 입증된 후 나머지 인벤토리에 대한 기록 권한을 검토합니다. Birch 테넌트, 도메인 또는 메시지가 검사되지 않았습니다. 이 예는 확인된 사고가 아닌 진단 결정을 보여줍니다.
증거로 레거시 종속성을 닫습니다.
이전 레코드를 사용하는 활성 경로가 없고 교체 레코드가 통제된 테스트를 통과했음을 소유자가 확인한 후에만 이전 레코드를 폐기하십시오. 폐기 결정, 승인된 롤백 및 관찰된 결과를 함께 유지합니다. 메일 플랫폼 변경, DNS 마이그레이션 또는 보고서의 예상치 못한 소스 후에 다시 확인하세요. 라이브 테넌트 액세스, 현재 계정 발급 구성, 공용 DNS 및 헤더 확인, 시각적 검토, SME 승인 및 게시가 보류 중입니다.
청구서에 과거 날짜를 첨부해 두십시오.
상태 페이지에는 최신 아카이브 제목과 날짜가 기록된 사건 항목이 혼합되어 있습니다. 2023년 1월 5일 항목은 재구축 불가 선언을 제공합니다. 2026년 11월 마이그레이션 제안이 아닙니다. 가상의 스캐너 예에서 다른 정렬된 전달 메커니즘이 존재하는 경우 정렬되지 않은 서명만으로는 DMARC 실패를 설정하지 않습니다. 이 예에서는 다른 결과를 지정하지 않은 채로 둡니다.
정책 출시와 별도의 메시지 승인
정렬된 SPF 결과를 통과하면 메시지 평가를 만족할 수 있지만 전체 도메인을 거부하도록 이동하는 것만으로는 충분하지 않습니다. RFC 9989 섹션 7.4에서는 p=reject 게시하는 도메인에 유효한 DKIM 필요하며 간접 메일 상호 운용성에 대해 경고합니다. 정책 소유자가 시행을 승인하기 전에 모든 합법적인 발송인과 간접 경로의 목록을 작성하십시오. 이 문서에서는 DNS 변경, 테넌트 작업 또는 메시지 수신 테스트가 실행되지 않았습니다.