A DMARC 결과는 진단 카테고리이지 게시된 정책을 변경하라는 지시가 아닙니다. 실패하다, 없음, temperror 그리고 permerror 다양한 조사를 지적합니다. 이를 상호 교환 가능한 것으로 취급하면 실제 결함이 해결되지 않고 불필요하게 보호 기능이 약화될 수 있습니다.
수신 시스템의 신뢰할 수 있는 증거로 시작하십시오. 안 Authentication-Results 헤더 시스템의 주장을 기록합니다. 그 존재만으로는 그 주장이 신뢰할 만하다는 것을 증명할 수 없습니다. 이를 생성한 수신 서비스와 해당 서비스가 신뢰하는 헤더를 식별합니다. 이 경계는 다음에서 설명됩니다. RFC 8601 §1.2 그리고 RFC 8601 §7.1.
방법과 결과를 함께 읽어보세요
다음을 포함하는 헤더에서 spf=pass; dkim=pass; dmarc=fail, 세 가지 결과 단어는 서로 다른 방법에 속합니다. 그만큼 SPF 그리고 DKIM 패스는 표시되는 보낸 사람 도메인과 일치하지 않는 도메인을 인증할 수 있습니다. 반대로, 다른 전달 경로가 일치하는 경우 DMARC 전달은 하나의 기본 메서드 실패와 공존할 수 있습니다.
다음 진단 맵을 사용하십시오. 결과 의미는 다음에서 비롯됩니다. RFC 9989 , 섹션 9.2; 다음 조치는 운영 권장 사항입니다.
- 결과:
dmarc=none; 해석: 작성자 도메인에 적용 가능한 정책을 찾을 수 없습니다. 첫 번째 유용한 작업: 실제 보낸 사람 도메인에 대한 정책 검색 재구성 - 결과:
dmarc=pass; 해석: 적용 가능한 정책이 존재하고 통과된 인증 ID가 일치합니다. 첫 번째 유용한 조치: 성공적인 경로를 식별하고 별도의 배송 문제를 조사합니다. - 결과:
dmarc=fail; 해석: 적용 가능한 정책이 존재하지만 통과된 일치 ID가 확립되지 않았습니다. 첫 번째 유용한 조치: SPF 및 모든 관련 DKIM 결과를 From과 비교합니다. - 결과:
dmarc=temperror; 해석: 평가 중에 일시적인 오류가 발생했습니다. 첫 번째 유용한 작업: DNS 또는 서비스 오류를 캡처하고 나중에 제어된 시도를 비교합니다. - 결과:
dmarc=permerror; 해석: 평가 중에 재시도만으로는 해결될 수 없는 오류가 발생했습니다. 첫 번째 유용한 작업: 지속적인 구성 문제에 대한 정확한 정책 데이터 및 수신기 진단을 검사합니다.
결과 단어만으로 원인을 추론하지 마십시오. 일시적인 DNS 오류와 잘못된 정책은 모두 정상적인 결론을 방해할 수 있지만 다른 소유자와 다른 수정 작업이 필요합니다. 증거를 대시보드 색상으로 축소하는 대신 진단 의견을 보존하세요.
dmarc=none 을 p=none 과 분리하세요.
dmarc=none 보고된 평가 결과입니다. p=none 게시된 정책의 값입니다. 유효한 모니터링 정책은 여전히 다음 중 하나를 생성할 수 있습니다. dmarc=pass 또는 dmarc=fail 개별 메시지에.
두 가지 합성 사례를 고려하십시오. 처음에는 example.com 유효한 모니터링 기록을 게시하고 메시지에 정렬된 전달이 있습니다. DKIM 서명. 정책에 아무 것도 없다고 나와 있어도 예상되는 DMARC 평가는 통과입니다. 두 번째에서는 메시지 작성자 도메인에 대해 적용 가능한 정책을 검색할 수 없습니다. 수신자가 신고할 수 있음 dmarc=none; 그 단어에서 추론할 수 있는 모니터링 정책 약속은 없습니다.
동료가 " DMARC 없음으로 설정되어 있습니다"라고 말하면 DNS 정책을 의미하는지, 메시지 결과를 의미하는지, 최종 처리를 의미하는지 물어보세요. 세 가지를 모두 별도로 녹음합니다. 이러한 짧은 설명으로 인해 잘못된 문제를 겨냥한 DNS 변경이 방지되는 경우가 많습니다.
신원을 통해 실패 조사
수신된 원본 메시지를 가져옵니다. 눈에 보이는 From 도메인, SPF ID 및 결과, d= 각 관련 DKIM 서명에 대한 도메인 및 결과. 구성된 적용 조정 ID 전달 모드. 에이 선택자 DKIM 정렬에 사용되는 도메인이 아닌 키 위치 지정자입니다.
SPF 공급업체 도메인에 대해 통과하고 DKIM 다른 공급업체 도메인에 대해 통과하는 경우 둘 다 보낸 사람 도메인과 일치하지 않을 수 있습니다. 루트 편집 SPF 레코드 자동으로 수정되지 않습니다. 서비스가 실제로 평가하는 ID와 지원하는 고객 도메인 인증 옵션을 설정합니다. 그만큼 정렬 실패 안내 그 비교를 살펴봅니다.
추측하지 않고 오류 조사
을 위한 temperror, 가능한 경우 메시지 시간, 수신자, 쿼리 이름, 오류 및 확인자 컨텍스트를 기록합니다. 신뢰할 수 있는 DNS 와 재귀적 결과를 비교하세요. 나중에 성공적인 조회는 일시적인 설명을 지원하지만 수신자가 이전에 본 것을 증명하지는 않습니다. 구별이 중요한 경우 수신 운영자에게 로그를 요청하세요.
을 위한 permerror, 전체 관련 항목을 검색합니다. TXT 레코드 세트. 게시 이름, 버전 배치, 중복된 정책 기록 및 잘못된 값을 확인하세요. 모든 잘못된 레코드가 동일한 라벨을 생성한다고 약속하지 마십시오. 현재 DMARC 는 RFC 9989 §4.10 그리고 RFC 9989 §4.10.1 일부 구문 및 정책 값 문제에 대한 특정 복구 및 기본 동작을 정의하며 구현은 다를 수 있습니다. 변경하기 전에 진단을 적용 가능한 규칙과 일치시키세요.
전후 샘플을 보존합니다. 새로운 시도가 성공하면 정확한 수리와 성공적인 결과를 함께 지켜보세요. 공개 검사원이 이제 녹색 결과를 제공한다는 이유만으로 사건을 종결하지 마십시오.
평가와 배송을 별도로 유지
아래에 RFC 9989 §5.4, 수신자는 로컬 처리 규칙에 따라 DMARC 실패 메시지를 전달할 수 있으며 스팸, 맬웨어 또는 기타 이유로 전달되는 메시지를 차단할 수 있습니다. 인증 결과와 별도로 SMTP 응답이나 전달 처리를 수집합니다.
최종 사건 메모에는 무엇을 평가했는지, 신뢰할 수 있는 수신자가 누구인지, 언제, 왜 결과가 발생했는지, 무엇이 변경되었는지 명시해야 합니다. "청구 서비스가 이제 생산 경로를 통해 정렬된 DKIM 패스를 생성합니다"와 같은 정확한 결론이 " DMARC 고정"보다 더 유용합니다. 정책이 누락된 경우 다음 단계를 따르세요. DMARC 레코드를 찾을 수 없습니다..
다음 결정을 명확하게 하라
모니터링 정책 고정 장치에서 다음을 기록합니다. p=none, dmarc=pass 및 실제 처리를 세 개의 개별 필드로 표시합니다. 유효한 정책이 존재하지만 전달 메커니즘 ID가 모두 정렬되지 않은 경우 완료된 평가는 실패합니다. 필요한 DNS 쿼리가 완료되지 않으면 RFC 9989 §5.3.6 정상적인 합격/불합격 결론을 방지합니다. 이는 수신자 로그가 아닌 분석 분류입니다.