세 가지 도메인 필드는 메시지의 서로 다른 부분을 설명하는 동안 대시보드에서 서로 바꿔서 표시될 수 있습니다. 헤더 보낸 사람 에서 사용하는 작성자 도메인을 식별합니다. DMARC. 봉투 보낸 사람 관련된 SMTP 발신자 신원을 설명합니다. SPF. 봉투 제공된 경우 SMTP 수신자 도메인을 설명합니다. 친숙해 보이는 도메인을 선택하는 대신 해당 역할에 레이블을 지정하는 것부터 시작하세요.
필드 사전 구축
참고자료: RFC 9990 §3.1.1.10, RFC 9989 §3.2.4, RFC 7208 §2.4.
RFC 9990 섹션 3.1.1.10 에서는 header_from이 필요하며 봉투_from 및 봉투_to를 선택 사항으로 만듭니다. 이러한 필드에는 사서함 주소의 전체 목록이 아닌 도메인이 포함됩니다. 누락된 선택 필드는 보고서에서 해당 필드를 제공하지 않았음을 의미합니다. 이는 SMTP 트랜잭션에 해당 ID가 부족하다는 것을 증명하지 않습니다.
envelope_from 요소가 존재할 수 있지만 null reverse-path의 경우 비어 있을 수 있습니다. 파서에서 누락된 것과 비어 있는 것의 구별을 유지하십시오. Header From에서 빈 값을 채우거나 추측된 반송 주소가 평가되었다고 가정하지 마십시오. RFC 9989 섹션 3.2.4는 MAIL FROM ID의 SPF 유효성 검사에 의존하고 null 역방향 경로에 대해 RFC 7208 섹션 2.4를 명시적으로 참조합니다. SPF 해당 ID를 postmaster로 구성합니다. HELO 도메인. 구성된 MAIL FROM ID에 대한 통과 SPF 결과는 해당 도메인이 작성자 도메인과 일치할 때 DMARC 에 기여할 수 있습니다. 이는 비어 있지 않은 MAIL FROM ID를 독립적으로 평가된 HELO 결과로 대체하는 것과 다릅니다. 평가된 정체성과 결과를 그리기 전에 보존하십시오. 조정 결론.
인증된 식별자도 읽어보세요.
참고자료: RFC 9990 §3.1.1.12, RFC 9990 §3.1.1.13.
SPF 검증 중에 실제로 사용된 도메인과 검증에 사용된 d 및 s 값을 보고하는 auth_results와 식별자를 비교합니다. DKIM 확인. 표시되는 작성자 도메인 자체는 SPF 이를 인증했다는 증거가 아닙니다. 마찬가지로 DKIM d 도메인은 두 봉투 도메인과 다를 수 있습니다.
Envelope To는 유용한 수신자-도메인 컨텍스트입니다. 이는 DMARC SPF 또는 DKIM 과 일치하는 도메인이 아니며 메시지의 표시되는 받는 사람 필드로 처리되어서는 안 됩니다. 전달, 별칭 및 숨은 복사본으로 인해 표시되는 헤더가 SMTP 수신자 경로의 빈약한 계정이 될 수 있습니다.
합성 결과 재현
참고자료: RFC 9989 §5.3.5.
적용 가능한 유효한 정책, 완료된 확인 및 관련 없는 brand.example / vendor.example 조직 도메인을 가정합니다. header_from= brand.example , envelope_from= bounces.vendor.example 및 envelope_to= recipient.example 을 고려하세요. bounces.vendor.example 에 대해 SPF 통과하고 DKIM 서명 d=brand.example. SPF 도메인이 관련이 없기 때문에 brand.example 과 일치하지 않습니다. DKIM 정확하게 정렬되므로 DMARC 정렬되지 않은 SPF 결과에도 불구하고 DKIM 통과할 수 있습니다.
봉투_to만 다른 수신자 도메인으로 변경해도 해당 정렬 계산은 변경되지 않습니다. 전달되는 DKIM d 값을 vendor.example 로 변경하면 이 예에서 정렬된 DKIM 경로가 제거됩니다. 이는 실제 수신기 테스트나 완전한 XML 보고서가 아닌 현장 수준 연습을 위한 가정된 입력입니다.
조사의 불확실성 유지
해석 옆에 보고자, 기간, 소스 IP, 행 수 및 원시 필드 값을 기록합니다. 대시보드에 봉투 필드가 누락된 경우 해당 필드가 없다고 결론을 내리기 전에 원본 보고서를 검사하세요. 보고서 자체에서 이를 생략한 경우 값을 생성하는 대신 관련 경로에서 승인된 제어 메시지를 얻습니다.
유용한 워크시트에는 작성자, SMTP 발신자, SMTP 수신자, 인증된 SPF 도메인, 각 DKIM 도메인 및 DMARC 관련 결과에 대한 별도의 열이 있습니다. DNS 변경하기 전에 모순을 조정하십시오. 목표는 재현 가능한 신원 비교이며 모든 열에 브랜드 이름이 포함되도록 하는 것이 아닙니다.
재현 가능한 신원 확인 케이스 5개를 확인하세요.
참고자료: RFC 9989 §3.2.10.2, RFC 9989 §5.3.5.
이 연습에서는 두 메커니즘 모두에 대해 엄격한 정렬을 사용합니다. 기본 합성 행에는 header_from= brand.example , envelop_from= bounces.vendor.example , envelope_to= recipient.example , Bounces.vendor.example 에 대한 원시 SPF 패스 및 bounces.vendor.example 과 같은 brand.example 에 대한 원시 DKIM 패스가 있습니다. 선택자 송장1. 소스 IP는 192.0.2.40 이고 개수는 12입니다. 암호화 및 SPF 결과는 입력으로 간주됩니다. 운동은 실제 인증이 아닌 신원 비교를 통해 확인합니다.
- 기본 행의 변형: 없음; 정렬된 SPF : 아니요; 정렬된 DKIM : 예; DMARC : 통과
- 기본 행의 변형: 봉투_to만 another.example 이 됩니다. 정렬된 SPF : 아니요; 정렬된 DKIM : 예; DMARC : 통과
- 기본 행의 변형: DKIM 도메인만 vendor.example 이 됩니다. 정렬된 SPF : 아니요; 정렬된 DKIM : 아니요; DMARC : 실패
- 기본 행의 변형: envelope_from 생략; 원본 원시 SPF 결과가 유지됩니다. 정렬된 SPF : 아니요; 정렬된 DKIM : 예; DMARC : 통과
- 기본 행의 변형: 봉투_로부터 비어 있음; 원시 SPF ID 및 결과가 제공되지 않았습니다. 정렬된 SPF : 널 경로 SPF ID 및 결과 없이는 설정되지 않습니다. 정렬된 DKIM : 예; DMARC : 통과
제공된 로컬 엄격한 평등 연습은 누락 및 빈 필드 사례에서 사용할 수 있는 정렬된 DKIM 사용하여 5가지 결과를 재현합니다. 모든 null 역방향 경로에 대해 SPF 결과를 설정하지는 않았습니다. 누락 필드 사례는 의도적으로 관련되지 않은 원시 SPF 도메인을 유지합니다. 생략된 envelope_from 필드 자체가 SPF 실패를 초래하지는 않습니다. 빈 필드의 경우 null 경로 ID를 고안하는 대신 원래 원시 SPF 입력을 명시적으로 제거합니다. 이 경우 정렬을 평가하기 전에 RFC 9989 섹션 3.2.4 및 RFC 7208 섹션 2.4에 설명된 SPF 검증으로 구성된 MAIL FROM ID를 얻습니다. 테이블의 DMARC 패스는 DKIM 에서 계속 제공됩니다. 예를 들어 적용 가능한 DMARC 정책과 엄격한 정렬을 가정하면 postmaster@brand.example 에 대한 통과 SPF 결과는 정렬된 DKIM 없이도 header_from= brand.example 에 대한 정렬된 SPF 경로를 제공할 수 있습니다. postmaster@other.example 에 대한 통과 결과는 불가능합니다. 이 두 가지 추가 예제는 새로 실행된 픽스처가 아니라 가정된 결과입니다. 실제 수신된 메시지는 표시되지 않습니다.
범위 내에서 운동을 유지하세요.
예는 스키마가 유효한 보고서나 측정된 트래픽이 아닌 부분적인 필드 예측입니다. 로컬 검사에서는 명시적으로 제공된 인증 결과와 조직 관계를 사용합니다. DNS 검색, SPF 평가, 암호화 확인, 보고서 수집 또는 수신자 전달 테스트를 수행하지 않습니다. 프로덕션을 변경하기 전에 원본 보고서와 신뢰할 수 있는 메시지 증거를 보존하세요.