SMTP TLS 보고 정책
DNS 및 레코드
DNS 조회 모든 도메인의 전체 DNS 레코드 A 레코드 조회 도메인의 IPv4 주소 AAAA 레코드 조회 도메인의 IPv6 주소 MX 조회 도메인의 메일 서버 NS 조회 권한 있는 네임 서버 TXT 조회 TXT 레코드, SPF, 인증 CNAME 조회 정규 이름(별칭) 레코드 SOA 조회 Start of Authority 레코드 SRV 조회 서비스 위치 레코드 CAA 조회 어떤 CA가 인증서를 발급할 수 있는지 역방향 DNS (PTR) IP 주소에서 호스트명으로 DNSSEC 점검 도메인이 서명되고 검증되는가? DNS 헬스 체크 위임 및 DNS 전체를 진단하는 종합 리포트이메일 전달성
SPF 점검 Sender Policy Framework 레코드 검증 DMARC 점검 DMARC 정책 검사 및 등급 평가 DKIM 점검 DKIM 공개 키 찾기 및 검증 블랙리스트 점검 이메일 차단 목록(DNSBL)에 대해 IP 점검 SMTP 테스트 메일 서버에 연결하여 STARTTLS 점검 MTA-STS 점검 수신 메일에 대한 강제 TLS 정책 BIMI 점검 이메일용 브랜드 로고 레코드 TLS-RPT 점검 SMTP TLS 보고 정책네트워크 및 웹
SSL 인증서 점검 사이트의 TLS 인증서 및 만료 검사 HTTP 헤더 점검 응답 헤더, 리디렉션 및 보안 검사 핑 (TCP) TCP를 통한 도달성 및 지연 시간 포트 점검 어떤 일반 포트가 열려 있는지도메인
WHOIS 조회 도메인, IP 및 ASN의 등록 데이터TLS-RPT(SMTP TLS Reporting)는 도메인이 발신 서버로부터 TLS 연결 실패에 대한 일일 보고서를 받게 해, 메일이 안전하지 않게 전송되는지 감지할 수 있게 합니다. IPeek는 _smtp._tls TXT 레코드를 읽어 보고 대상을 보여 줍니다. 이는 MTA-STS와 DANE를 보완하여, 그 정책들이 실제 환경에서 어떻게 작동하는지에 대한 가시성을 제공합니다.
TLS-RPT는 _smtp._tls.귀하의-도메인에 단일 DNS TXT 레코드로 게시됩니다. 이 레코드는 버전 태그와, 보고서를 보낼 곳을 나열하는 rua= 태그(mailto 주소 또는 HTTPS 엔드포인트)를 담습니다. 이 표준을 지원하는 발신 서버는 하루 동안 귀하의 MX 호스트와의 TLS 협상 결과를 집계해 그 대상으로 JSON 보고서를 전달합니다. 각 보고서는 성공한 세션과 실패한 세션을 집계하고 인증서 검증 오류나 STARTTLS 미사용 같은 실패를 분류하여, 실제 전송에 대한 피드백 루프를 제공합니다.
IPeek는 _smtp._tls TXT 레코드가 존재하는지 확인하고 파싱한 rua 대상을 보여 줍니다. 버전이 TLSRPTv1인지, 각 rua 대상이 실제로 모니터링하는 유효한 사서함이나 HTTPS URL인지 검증하세요. 레코드 자체는 아무것도 강제하지 않으며 보고서를 요청할 뿐이므로, 그 존재는 발신 서버가 TLS 실패 데이터를 어디로 보낼지 안다는 뜻입니다. 보고서가 도착하면 실패 유형을 살펴보세요. certificate-expired, 검증 실패, starttls-not-supported는 각각 조용한 전송 문제를 일으키기 전에 수신 인프라에서 고쳐야 할 구체적인 지점을 가리킵니다.
MTA-STS와 DANE는 수신 메일에 TLS를 강제하지만, 강제가 실제 트래픽에 미치는 영향을 볼 수 있어야만 안전합니다. TLS-RPT가 그 가시성을 제공합니다. MTA-STS를 testing 모드로 배포할 때, 보고서는 enforce로 전환하기 전에 어떤 발신자가 TLS 실패를 겪는지 드러냅니다. DANE TLSA 불일치에도 같은 원리가 적용됩니다. TLS-RPT를 TLS 태세의 모니터링 계층으로 다루어, 강제 메커니즘 대신이 아니라 함께 배포하면 인증서와 구성 문제를 조기에 잡을 수 있습니다.
TLS 실패 보고서를 요청하기 위해 _smtp._tls.귀하의-도메인에 게시하는 TXT 레코드입니다. 이 레코드에는 v=TLSRPTv1 버전 태그와, 보고서를 보낼 곳을 mailto 주소나 HTTPS URL로 지정하는 rua= 태그가 들어 있습니다. TLS-RPT를 지원하는 발신 서버는 이를 통해 귀하의 도메인에 대한 TLS 연결의 일일 집계 보고서를 어디로 전달할지 알게 됩니다.
TLS-RPT 보고서는 발신 서버와 귀하의 MX 호스트 간 하루 동안의 TLS 협상을 요약한 JSON 문서입니다. 성공한 세션과 실패한 세션을 집계하고, 만료된 인증서, 인증서 검증 오류, STARTTLS 미사용 같은 유형별로 실패를 나눕니다. 이로써 어떤 수신 호스트나 인증서가 안전하지 않거나 실패한 전송을 일으키는지 정확히 짚어 낼 수 있습니다.
아니요. TLS-RPT는 순수하게 보고 메커니즘이며 그 자체로는 아무것도 강제하지 않습니다. 강제는 TLS를 요구하고 안전하지 않은 전송을 차단할 수 있는 MTA-STS나 DANE에서 옵니다. TLS-RPT는 그 정책들 옆에서 모니터링 계층으로 자리하며, TLS가 얼마나 자주 성공하거나 실패하는지에 대한 가시성을 제공해 자신 있게 강제를 배포하도록 돕습니다.
_smtp._tls.귀하의-도메인에 v=TLSRPTv1과, 모니터링하는 사서함이나 HTTPS 엔드포인트를 가리키는 rua= 태그(예: rua=mailto:tlsrpt@귀하의-도메인)를 담은 TXT 레코드를 게시하세요. 보고서가 매일 JSON으로 도착하므로 실제로 지켜보는 대상을 고르세요. MTA-STS나 DANE와 함께 사용해, 보고서가 강제된 TLS 정책의 작동 상황을 설명하도록 하세요.
TLS-RPT는 MTA-STS를 안전하게 배포할 수 있게 하는 가시성을 제공합니다. MTA-STS 정책을 testing 모드로 게시하면 발신 서버가 TLS 실패를 TLS-RPT로 보고하므로, enforce로 전환하기 전에 어떤 발신자가 차단될지 알 수 있습니다. 둘은 함께 작동하도록 설계되었습니다. MTA-STS는 정책을 설정하고, TLS-RPT는 그것이 실제로 어떻게 작동하는지 알려 줍니다.