[ DNS 및 도메인 ]

인프라 전송을 위한 역방향 DNS 및 PTR 레코드

송신 IP의 역방향 DNS 제어하는 ​​운영자를 찾아 도메인 인증과 혼동하지 않고 반환된 호스트 이름을 확인합니다.

EmailAuth 연구팀 제공

[ 핵심사항 ]

  • 실제 공개 소스 IP와 역방향 영역 권한을 사용하세요.
  • 모든 PTR 결과를 유지하고 관련 정방향 매핑을 확인합니다.
  • 역방향 이름 지정은 보낸 사람 인증이나 배달 보장이 아닙니다.
이 페이지에서

역방향 DNS IP 주소와 관련된 이름을 묻습니다. 메일 발신자의 경우 관련 주소는 SMTP 연결에 사용되는 공개 소스입니다. 해당 주소의 PTR 레코드는 유용한 인프라 증거이지만 그렇지 않습니다. SPF 승인, DKIM 서명 또는 메시지가 합법적이라는 증거.

실제 주소와 권한을 확인하세요.

참고자료: RFC 1035 §3.5, RFC 3596 §2.5.

수신 시스템 또는 제어된 외부 SMTP 관찰에서 본 IP로 시작합니다. 애플리케이션의 개인 주소, 로드 밸런서 주소 및 공급자의 송신 주소는 다를 수 있습니다. 서비스에서 사용할 수 있는 모든 아웃바운드 주소 계열 및 풀을 나열합니다.

IPv4 역방향 쿼리는 in-addr.arpa에서 역방향 옥텟을 사용합니다. IPv6 ip6.arpa에서 역방향 16진수 니블을 사용합니다. 해당 역방향 영역에 대한 권한은 IP 할당 및 위임을 따릅니다. 일반적으로 발신자의 표시 도메인에 대한 등록 기관이나 DNS 호스트가 아닌 호스팅 또는 네트워크 공급자입니다. 관련되지 않은 정방향 영역에 PTR과 유사한 이름을 게시해도 실제 역방향 답변은 변경되지 않습니다.

양방향 조정

참고자료: RFC 1912 §2.1, RFC 2181 §10.2.

지원되는 변경 프로세스와 정확한 공용 IP는 역방향 운영자에게 문의하세요. 원하는 인프라 호스트 이름을 선택하고 전달 주소 데이터에 해당 IP가 포함되어 있는지 확인하세요. RFC 1912 역방향 및 순방향 데이터 일치를 권장합니다. 이는 보편적인 수신자 수락 계약이 아닌 운영 지침입니다.

RFC 2181 DNS 주소를 정확히 하나의 PTR 로 제한하지 않음을 명시합니다. 반환된 여러 이름은 자동으로 폐기되지 않고 증거로 보관되어야 합니다. 예측 가능한 관리를 위해 안정적으로 문서화된 호스트 이름이 더 간단한 경우가 많지만 수신기별 요구 사항에는 자체 최신 문서가 필요합니다. 하나의 PTR 패턴이 모든 제공자에게 전달을 보장한다고 주장하지 마십시오.

역방향 조회 재현

합성 IPv4 고정 장치: 소스 주소 192.0.2.25; 역 소유자 25.2.0.192.in -addr.arpa.; PTR 타겟 smtp.example.com.; 해당 목표로 A를 전달하세요. 192.0.2.25. 예상되는 역방향 응답은 호스트 이름이고 예상되는 순방향 확인에는 원래 IP가 포함됩니다.

격리된 역방향 영역에서 쿼리 발굴 @AUTH -x 192.0.2.25 +norecurse 그런 다음 쿼리 smtp.example.com. A 연구실 전달 권한에 반대합니다. 동일한 조직일 필요는 없으므로 각 방향에 사용되는 권한을 유지하십시오. 두 번째 픽스처에 대한 PTR 제거합니다. 예상되는 증거는 새로 발명된 호스트 이름이 아니라 실제 응답에서 분류된 오류이거나 부재입니다.

IPv6 의 경우 니블 이름을 수동으로 축약하는 대신 조회 도구의 주소-역방향 변환을 사용하십시오. 질문 발굴 @AUTH -x 2001:db8::25 +norecurse, AUTH를 구성된 랩 해석기로 대체합니다. 생산 확인에서는 관찰된 실제 소스 주소를 사용해야 합니다. 이러한 문서 범위는 실시간 발신자를 설명하지 않습니다.

인프라와 인증 구별

참고자료: RFC 7208 §5.5, RFC 9989 §5.3.5.

메일이 해당 도메인을 사용하기 때문에 PTR 대상이 표시되는 보낸 사람 도메인일 필요는 없습니다. 공급자는 자체 호스트 이름을 사용하여 공유 전송 인프라를 운영할 수 있습니다. 특정 수신 정책에 중요한 사항은 SPF 와 별도로 확인해야 합니다. DKIM 조정.

권장되지 않는 SPF 추가하지 마세요 ptr 역방향 DNS SPF 와 관련되게 만드는 메커니즘입니다. PTR 인프라 문제로 유지하고 실제 지원되는 발신자 인증으로 SPF 구성합니다. 변경 후 정방향 및 역방향 응답, SMTP 소개 및 관련 수신자 응답을 확인합니다. 배송 결론을 테스트된 경로와 시간으로 제한하십시오.

증거 범위를 명시적으로 유지하세요.

로컬 주소 라이브러리 변환은 192.0.2.25 25.2.0.192.in -addr.arpa로 매핑되는 것을 확인하고 완전한 IPv6 니블 이름을 생성합니다. 해당 계산은 역방향 영역을 쿼리하거나 PTR 존재하는지 확인하지 않습니다. 전송 또는 수신자 정책 테스트가 수행되지 않았습니다.

[ 테이크아웃 ]

실제 공개 소스 IP와 역방향 영역 권한을 사용하세요. 모든 PTR 결과를 유지하고 관련 정방향 매핑을 확인합니다. 역방향 이름 지정은 보낸 사람 인증이나 배달 보장이 아닙니다.

[ 역할별 ]

이것이 당신에게 의미하는 바

실용적인 다음 단계를 위해 역할을 선택하세요.

IT/메일 관리자

관찰된 소스 IP에서 시작

내부 주소와 가정된 풀 구성원 자격은 역방향 DNS 진단에 충분하지 않습니다.

다음 단계

  1. 실제 공개 소스 주소를 캡처합니다.
  2. 순방향 주소 데이터로 PTR 조정합니다.
  3. 각 역방향 권한을 기록합니다.

CISO/SecOps

PTR 보증을 제한적으로 유지

인프라 호스트 이름은 표시되는 발신자 도메인의 사용을 승인하지 않습니다.

다음 단계

  1. 인프라 이름 지정과 인증을 분리하세요.
  2. 공유 풀 소유권을 검토하고 제어를 변경합니다.
  3. PTR 신원 증명으로 취급하지 마십시오.

창립자 / 비기술자

네트워크 소유자 찾기

주소를 관리하는 조직은 도메인을 관리하는 조직과 다를 수 있습니다.

다음 단계

  1. 공급자 관계 소유자를 할당합니다.
  2. 아웃바운드 IP 인벤토리를 최신 상태로 유지합니다.
  3. 배송 청구 전에 증거가 필요합니다.

[ 자주 묻는 질문 ]

자주 묻는 질문

공용 IP의 PTR 일반적으로 누가 변경합니까?

권한이 위임되지 않는 한 역방향 영역 운영자(일반적으로 IP 또는 호스팅 공급자)입니다.

내 도메인 등록기관이 항상 이를 설정할 수 있나요?

아니요. 정방향 도메인 등록과 역방향 영역 제어는 다릅니다.

어떤 IP를 검사해야 합니까?

SMTP 연결에서 관찰된 공개 소스입니다.

PTR 표시되는 보낸 사람 도메인과 동일해야 합니까?

일반적인 DNS 규칙이 아닙니다. 실제 인프라 및 수신기 요구 사항을 확인하세요.

IP에 여러 PTR 레코드가 있을 수 있나요?

예. DNS 이를 허용합니다. 전체 세트를 보존하고 적용 가능한 운영 규칙을 확인하십시오.

RFC 2181 §10.2

PTR 전송을 승인합니까?

아니요. SPF , DKIM 또는 DMARC 대체할 수 없습니다.

SPF ptr을 추가해야 하나요?

아니요. RFC 7208 해당 메커니즘을 권장하지 않습니다. 역방향 DNS 유지 관리는 별도의 작업입니다.

RFC 7208 §5.5

성공적인 역응답이 전달을 보장합니까?

아니요. 수신자 정책과 기타 메시지 및 인프라 검사는 계속 적용됩니다.

[ 출처 ]

출처

  1. RFC 9989

    섹션 §5.3.5

  2. RFC 7208

    섹션 §5.5

  3. RFC 1035

    섹션 §3.5

  4. RFC 2181

    섹션 §10.2

  5. RFC 1912

    섹션 §2.1

  6. RFC 3596

    섹션 §2.5

  7. ISC BIND 발굴 참조

    섹션 구문, -x 역방향 조회, 비반복 쿼리 옵션

[ 어휘 ]

어휘

PTR 레코드
정식 도메인 이름에 대한 포인터입니다. 역 소유자는 둘 이상의 PTR 가질 수 있습니다.

RFC 2181 §10.2

IPv6 역방향 이름
ip6.arpa 아래 IPv6 주소의 역방향 16진수 니블입니다.

RFC 3596 §2.5

기업 출처

최고의 금융 기관과 정부가 필요한 이유 이메일 보안 대시보드를 폐기했습니다.

기존 이메일 인증 플랫폼은 대시보드를 판매하고 엔지니어에게 작업을 요청합니다. 위험이 높은 환경에서 수동 감독은 시행 지연, 구성 드리프트 및 모니터링되지 않는 섀도우 도메인을 의미합니다.

EmailAuth 는 에이전트 이메일 출처 플랫폼입니다. 우리 대리인은 집행합니다 p=reject, 제3자 발신자를 정렬하고 도메인을 전체로 이동하세요. RFC 9989 인간 참여형 감사 기능을 갖춘 새로운 DMARC 표준을 준수합니다.

정부 대기업 1등급 금융기관

SaaS · 전용 테넌시 · Air-Gapped 온프레미스 · BYOK 암호화

기술 자료