A DMARC 롤백은 무슨 일이 일어났는지 설명하는 데 필요한 증거를 보존하면서 의도한 통신을 복구해야 합니다. 기록을 편집하는 것은 해당 작업의 한 부분일 뿐입니다. 또한 팀은 어떤 합법적인 서비스가 실패했는지, 수신자가 볼 수 있었던 정책은 무엇인지, 그리고 또 다른 시도를 정당화할 수 있는 것이 무엇인지 알아야 합니다.
변경하기 전에 해당 복구 경로를 준비하십시오. 사건이 발생하면 스크린샷을 통해 즉석에서 검색하는 것보다 이전 값, 명명된 소유자 및 테스트된 승인 경로가 더 유용합니다.
복원이 필요할 수 있는 상태를 기록합니다.
TTL, 권한 있는 서버 및 수집 시간과 함께 영향을 받은 정확한 DNS 소유자 이름으로 전체 레코드 세트를 저장합니다. 검색에 중요한 경우 적용 가능한 상위 및 하위 도메인 정책을 유지하세요. 복사된 p 값만으로는 보고 주소가 누락되거나 조정 동시에 변경된 설정입니다.
승인된 변경 사항을 읽을 수 있는 차이점으로 유지하세요. 변경된 모든 태그의 목적과 이전 구성을 복원할 수 있는 승인된 사람을 식별합니다. 검토 하위 도메인 정책 검색 부모 기록을 편집하면 모든 자녀의 평가가 변경된다고 가정하기 전에.
민감한 메시지 샘플과 별도로 DNS 관리 증거를 저장합니다. 둘 다 적절한 액세스가 필요하지만 사고 기록에 고객의 기밀 콘텐츠를 재현할 필요는 없습니다.
실패와 의심을 구별하는 트리거 정의
변경 사항에 대한 구체적인 롤백 기준을 선택합니다. 예를 들어 새 정책으로 인한 중요한 적법한 흐름의 확인된 거부와 합의된 응답 창 내에서 해당 흐름을 복구할 수 없는 경우입니다.
지원 불만 사항만으로도 조사가 시작됩니다. DMARC 원인으로 설정하지 않습니다. 반환된 전체 SMTP 텍스트, 서비스 및 계정, 시간, 수신자 도메인, 표시되는 보낸 사람 도메인 및 사용 가능한 전송 로그를 캡처합니다. 배달된 메일의 경우 대표 원본 메시지와 신뢰할 수 있는 수신자 인증 결과를 보관합니다. RFC 8601 §7.1.
낮은 총 합격률에도 맥락이 필요합니다. 정상적인 배포 중에는 승인되지 않은 트래픽이 실패할 수 있습니다. 정책을 약화시키기 전에 어떤 합법적인 비즈니스 경로가 영향을 받는지 물어보십시오.
정책 복원과 보낸 사람 수리를 분리하세요.
하나의 애플리케이션에 잘못된 서명 ID가 있는 경우 지원되는 애플리케이션 수정이 적절한 복구일 수 있습니다. 광범위한 정책 변경으로 인해 결과적인 영향이 발생하는 경우 해당 응용 프로그램을 조사하는 동안 승인된 이전 정책을 복원하십시오.
변화를 피하세요 SPF, DKIM, DMARC 및 전송 플랫폼은 사고에 필요한 경우를 제외하고 동시에 전송되며 각 변경 사항이 기록됩니다. 여러 번 동시에 편집하면 개선 또는 실패 원인을 파악하기가 더 어려워집니다.
정책을 복원해도 기본 인증 또는 정렬 결함이 복구되지는 않습니다. 소유자, 증거 및 재테스트 요구 사항을 통해 해당 결함을 공개 상태로 유지하십시오.
제어된 복원 연습
이 가상의 연습에서는 실제 생산 테스트가 아닌 기록 유지를 보여줍니다.
- 시간: UTC 10:00; 이벤트: 승인된 정책 변경이 없음에서 격리로 변경되었습니다. 보존된 증거: 이전 및 새 기록 세트, TTL 및 승인 완료
- 시간: 10:08 UTC; 이벤트: 송장 워크플로가 정책 관련 거부를 받았습니다. 보관된 증거: 반환된 응답, 전송 계정 및 메시지 식별자
- 시간: 10:13 UTC; 이벤트: 사고 소유자가 계획된 복원을 승인합니다. 보유 증거: 결정 및 영향을 받는 범위
- 시간: 10:16 UTC; 이벤트: 이전의 전체 DMARC 값이 동일한 소유자 이름으로 복원되었습니다. 보관된 증거: 신뢰할 수 있는 DNS 응답 및 변경 사항 수신
- 시간: 10:26 UTC; 이벤트: 테스트 수신자에서 제어 송장 재시도가 승인되었습니다. 보존된 증거: 새로운 SMTP 결과 및 수신된 인증 증거
마지막 행은 해당 경로를 통한 특정 재시도를 보여줍니다. 이는 모든 수신자가 이전에 캐시된 답변을 삭제했거나 모든 고객 메시지가 복구되었음을 증명하지 않습니다.
리허설 중에 적절한 테스트 환경에서 실제 관리 및 승인 경로를 연습합니다. 변경할 수 있는 사람과 해당 사람이나 DNS 공급자를 사용할 수 없는 경우 어떤 일이 발생하는지 기록합니다.
DNS 조회수와 보고 기간이 겹칠 것으로 예상됩니다.
확인자는 이전 DNS 응답을 유지할 수 있습니다. RFC 8767 §4 TTL 만료 이후에 적격한 오래된 답변 사용을 허용하므로 TTL은 보장된 전역 제거 기한이 아닙니다. 확인자가 더 오래 지속되는 답변을 캐시한 후 TTL을 낮추더라도 해당 답변의 남은 캐시 수명이 소급하여 단축되지는 않습니다.
레코드를 복원한 후 권한 있는 서버 및 관련 재귀 보기를 쿼리한 다음 영향을 받는 메일 경로를 다시 테스트합니다. 새롭고 권위 있는 답변은 해당 영역의 현재 데이터를 입증합니다. 모든 원격 수신기가 현재 사용하는 것을 증명하지는 않습니다.
적절한 경우 보고를 계속 활성화하십시오. RFC 9990 §3.3 보고 기간 내에 정책이 변경되면 다양한 정책 버전에 따른 처분을 결합한 보고서가 생성될 수 있다고 설명합니다. 일부 구현에서는 대신 여러 보고서를 생성할 수 있습니다. 단일 정책 필드를 해당 기간의 모든 메시지가 정확한 버전을 사용했다는 증거로 처리하는 대신 사건 타임라인에 주석을 답니다.
완전하고 유효한 구성을 복원합니다.
정확한 의도된 소유자 이름을 사용하고 기존 레코드 세트를 조정하십시오. 아래에 RFC 9989 §4.10, 재정의하기 위해 첫 번째 DMARC 정책 옆에 두 번째 DMARC 정책을 추가하지 마세요. 승인된 보고 대상 및 필요한 외부 대상 권한을 유지합니다. RFC 9990 §4 복구가 명시적으로 변경하지 않는 한.
의도하지 않은 변경 사항이 있는지 전체 결과 정책을 확인하세요. 정렬 또는 하위 도메인 범위를 자동으로 변경하는 복원은 단순한 복구가 아닌 새로운 정책 결정입니다.
사용 기록 작업 흐름 출판을 위해 그리고 보고 가이드 후속 증거를 해석하기 위해.
복구 및 수정을 별도로 종료합니다.
정의된 영향을 받는 워크플로우가 합의된 테스트를 충족하고 구성이 알려진 제한 내에서 확인되면 복구가 설정됩니다. 원인을 파악하고 전송 경로를 수정하거나 의도한 정책을 재검토한 경우에만 교정이 종료됩니다.
다음 변경에는 첫 번째 시도 실패의 원인이 된 누락된 증거가 포함되어야 합니다. 상호 운용성 지침 RFC 9989 §7.4 이는 또한 거부가 범용 직원 도메인에 부적절할 수 있음을 의미합니다. 변경이 실패하면 제안된 정책 자체에 다른 결정이 필요하다는 사실이 드러날 수 있습니다.
원래의 증거, 실패한 결과, 복원 결정 및 성공적인 재시험을 함께 유지하십시오. 이 추적을 통해 변경된 사항, 복구된 사항, 해결되지 않은 사항을 설명하므로 다음 승인이 더 빨라집니다.
다음 작업을 구체적으로 유지하세요
가상의 타임라인에서 10시 26분 수락은 하나의 복구 관찰일 뿐 인증 결함이 복구되었다는 증거는 아닙니다. 보낸 사람-교정 항목을 열어두고 실제 새 방법 결과를 별도로 비교하십시오. 26분이라는 시간은 회복을 약속하거나 권장되는 대기 시간이 아닙니다. 이 문서에서는 DNS 복원, 승인 또는 메시지 재시도가 발생하지 않았습니다.