존재는 하나의 레코드 유형이 아닌 도메인에 속합니다.
np 태그는 DMARC 해당 검색된 정책에 따라 존재하지 않는 하위 도메인에 대한 평가 정책입니다. 존재결정이 타당할 때만 유용하다. "아니요 기록,” “ DMARC 없음 TXT 레코드"와 "작성자 도메인이 존재하지 않습니다"는 서로 다른 설명입니다. 이를 동의어로 취급하면 실제 도메인에 잘못된 정책을 적용하거나 거짓 부정 응답 뒤에 해결 중단을 숨길 수 있습니다.
RFC 9989 섹션 4.7 np와 sp를 구별합니다. 전자는 존재하지 않는 하위 도메인을 다룹니다. 후자는 기존 하위 도메인을 다룹니다. 어느 정책 기록이 적용되는지 결정하는 것을 대체할 수 없습니다. 작성자 도메인 자체의 유효한 정책이 우선순위를 가지며, 해당 도메인에는 해당 p 태그가 사용됩니다. 상위 정책 계산은 나중에 작성자 도메인에 적용 가능한 자체 정책이 없을 때 수행됩니다.
상위 항목을 지정하고 예시를 허구로 유지하세요.
north.example 발명품으로 사용하세요. 조직 도메인 이 정책을 사용하면: v=DMARC1;p=none; sp=quarantine; np=reject; psd=n. 아래의 모든 사례는 인증이 정렬된 패스를 생성하지 않는 유효한 메시지를 사용한다고 가정합니다. 이는 DNS 관찰, 전달 시도 또는 조직 기록에 대한 설명이 아닌 수동으로 파생된 결과가 포함된 문서 고정물입니다.
live.north.example 의 경우 주소 레코드를 규정하고 자체 DMARC 정책은 지정하지 않습니다. 발견은 상위 경계에 도달하고 존재가 확립됩니다. 요청된 평가는 sp=quarantine. 상위의 p=none 보다 구체적인 기존 하위 도메인 기본 설정을 대체하지 않습니다. 검토자가 격리가 선택된 이유를 확인할 수 있도록 결과에서 선택한 태그를 보존합니다.
empty.north.example 의 경우 다음을 규정합니다. MX 레코드 하지만 A 레코드는 없습니다. A 쿼리의 신뢰할 수 있는 NOERROR/ NODATA 응답은 기존 이름과 호환됩니다. 자체 DMARC 정책이 없어도 sp=quarantine 계속 적용됩니다. 이 사례는 누락된 도메인에서 누락된 레코드 유형을 의도적으로 분리합니다. 단지 A만을 요청했기 때문에 존재하지 않는다고 라벨을 붙인 검사기는 예상된 결정에 실패할 것입니다.
NXDOMAIN 올바른 이름으로 해석하세요.
gone.north.example 의 경우 별칭 체인이나 자체 정책 없이 작성자 도메인 자체에 대해 신뢰할 수 있는 NXDOMAIN 응답을 규정합니다. 선택한 상위 정책은 np=reject. RFC 9989 부록 A.4 DMARC 존재에는 특정 메일 관련 기록 유형이 필요하지 않다고 설명합니다. 그 정의는 확인 가능한 대상에 대한 SMTP 의 좁은 개념이 아닌 DNS 존재를 따릅니다.
_dmarc.live.north.example 에 대한 NXDOMAIN 응답은 쿼리된 하위 이름을 거부하고 live.north.example 이 없음을 증명하지 않습니다. 추론의 방향이 중요합니다. RFC 8020 거부된 이름에는 하위 항목도 없다는 점을 설명합니다. 아이를 부정하면 그 부모가 지워진다고 말하지 않습니다. 별칭 처리를 통해 거부된 이름이 원래 질문과 다를 수도 있으므로 존재가 거부된 실제 이름을 유지하세요.
빈 비터미널은 또 다른 유용한 경계 사례입니다. 노드는 자체 레코드가 없는 경우에도 자손이 있기 때문에 DNS 계층 구조에 존재할 수 있습니다. 해당 구조적 존재를 NXDOMAIN 으로 축소하지 마십시오. 픽스처 디자이너는 단지 빈 답변에 첨부된 편리한 텍스트 라벨이 아닌 트리를 지정해야 합니다.
NODATA 및 해결 실패를 별도로 검사
NODATA 는 독립적인 DNS 응답 코드가 아닙니다. RFC 2308 섹션 2.2 응답 컨텍스트가 필요한 부정 응답 분류를 설명합니다. 빈 답변 섹션은 참조와 함께 제공될 수 있으며 별칭은 실제로 확인된 이름과 유형에 영향을 줄 수 있습니다. 존재 결론을 내리기 전에 질문, 응답 코드, 별명 체인 및 권한 정보를 저장하십시오.
SERVFAIL , 시간 초과 및 불완전한 응답은 존재하지 않는다는 증거가 아닙니다. RFC 1035 섹션 4.1.1 서버 오류와 이름 오류를 구별합니다. 가상의 broken.north.example 사례에서 SERVFAIL 존재를 해결되지 않은 상태로 둡니다. np 자체는 선택되지 않습니다. RFC 9989 섹션 4.10.1에서는 일시적인 연기를 포함하여 DNS 오류 처리를 수신자의 재량에 맡기고 있습니다. 평가자는 일반적인 부정 조회를 요청하는 대신 이 해결되지 않은 상태를 유지해야 합니다.
정책 우선순위 및 폴백을 의도적으로 적용
이제 own.north.example 유효한 v=DMARC1; p=none 정책은 정확한 _dmarc 이름으로 지정됩니다. 자체 p 값이 평가를 제공합니다. 상위의 np 및 sp 기본 설정은 이를 대체하지 않습니다. 이는 허용되는 하위 도메인에 대해 고안된 예외가 아닌 정책 검색 규칙입니다. 기존 하위 구성에는 여전히 승인된 소유자와 합리적인 보안 검토가 필요합니다.
선택한 상위 레코드에 np가 없으면 sp가 존재할 때 해당 섹션 4.7 기본값은 sp이고, 그렇지 않으면 p입니다. 예제 상위의 경우 np를 제거하면 존재하지 않는 하위 도메인 평가 격리가 생성됩니다. np와 sp를 모두 제거하면 아무 것도 남지 않습니다. 누락된 np에서 p로 직접 점프하는 바로가기는 문서화된 sp 기본값을 무시하므로 이 폴백은 별도의 테스트가 필요합니다.
테스트 모드와 수신기 처리는 추가 레이어로 남아 있습니다. 적용 가능한 레코드에 t=y, 포함된 경우 먼저 선택한 정책을 파생시킨 다음 해당 테스트 의미를 적용합니다. 요청된 거부 평가는 최종 거부를 보장하지도 않습니다. RFC 9989 의 수신자 분석 및 상호 운용성 요구 사항은 여전히 관련성이 있습니다. 이 문서와 함께 제공되는 표에는 관찰된 받은 편지함 배치가 아닌 정책 선택이 기록되어 있습니다.
녹색 배지 대신 증거 패킷 보존
정확한 수수료는 다음과 같습니다. 기존, NODATA 및 NXDOMAIN 사례를 비교하고 선택한 정책을 도출합니다. 허구적 비교는 예상되는 논리의 검토를 지원하지만 원래의 운영 증거 문을 닫지는 않습니다. 실시간 쿼리, 통제된 권한 설비 또는 수신자 결과는 수집되지 않았습니다. 액세스할 수 없는 엔드포인트가 중지된 후에도 현재 정오표 검토가 해결되지 않았습니다.
승인된 후속 조치에는 정확한 작성자 도메인, 해당 정책 기록, 존재 증거, 대체 경로, 수신자 버전 및 결과 평가가 유지되어야 합니다. DNS 엔지니어링 검토를 메일 정책 소유권과 별도로 유지하세요. 생산 적용 가능성, 전문가 검토, 시각적 승인 및 출판 허가가 보류 중입니다. 신뢰할 수 있는 np 설명은 부주의한 도구로 인해 숨길 수 있는 위치에서 불확실성을 정확하게 표시합니다.