수신 메일에 대한 강제 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의 등록 데이터MTA-STS는 도메인이 수신 메일을 인증된 TLS로 전송하도록 요구할 수 있게 해 다운그레이드와 중간자 공격을 방어합니다. IPeek는 _mta-sts TXT 레코드를 읽고 mta-sts.귀하의-도메인에 게시된 정책 파일을 가져옵니다. 이는 공격자가 조용히 제거할 수 있는 기회주의적 STARTTLS가 남기는 빈틈을 메웁니다.
MTA-STS는 두 부분을 사용합니다. _mta-sts.귀하의-도메인의 TXT 레코드는 버전과 정책 ID를 담아 발신 서버에 정책이 존재함을 알리고, 정책을 갱신하면 이 ID가 바뀝니다. 정책 자체는 https://mta-sts.귀하의-도메인/.well-known/mta-sts.txt에 HTTPS로 제공되는 평문 파일에 들어 있습니다. 이 파일은 버전, 모드, 허용되는 MX 호스트명, max_age 캐싱 수명을 나열합니다. MTA-STS를 지원하는 발신 서버는 정책을 가져와 캐시한 뒤, 인증서가 정책에 대해 검증되지 않는 MX로의 전송을 거부합니다.
IPeek는 _mta-sts TXT 레코드가 존재하는지와 정책 파일이 HTTPS로 도달 가능한지 보여 줍니다. 가장 중요한 것은 mode 값입니다. none은 적용 중인 정책이 없음을, testing은 실패가 보고되지만 메일은 여전히 흐름을, enforce는 TLS 인증에 실패하면 발신 서버가 전송을 중단해야 함을 뜻합니다. 정책의 mx 항목이 실제 MX 레코드와 일치하는지, 정책 호스트의 HTTPS 인증서가 유효한지 확인하세요. max_age가 높으면(흔히 604800초) 캐시된 정책이 실시간 변조에 견디므로 보호가 강화됩니다.
가장 흔한 실수는 TXT 레코드는 존재하는데 정책 파일이 404나 리디렉션을 반환해 정책을 쓸 수 없게 만드는 것입니다. 정책 호스트는 유효한 HTTPS를 제공해야 하므로, mta-sts.귀하의-도메인의 인증서가 만료되거나 일치하지 않으면 강제가 완전히 깨집니다. MX 항목이 DNS와 어긋나면 enforce로 전환한 뒤 전송 실패가 발생합니다. 먼저 testing으로 배포하고, TLS-RPT 보고서로 실패를 모니터링하며, 모든 MX가 유효하고 일치하는 인증서를 제시함을 확인한 뒤에야 enforce로 넘어가세요.
testing 모드에서는 TLS 실패를 감지한 발신 서버가 메일을 여전히 전송하되 문제를 보고하므로, 트래픽을 차단하지 않으면서 문제를 찾을 수 있습니다. enforce 모드에서는 인증서 검증에 실패한 MX로의 전송을 발신 서버가 반드시 중단해야 합니다. testing으로 시작해 TLS-RPT 보고서를 지켜보고, 실패가 나타나지 않을 때만 enforce로 전환하세요.
정책 파일은 mta-sts라는 하위 도메인에서 https://mta-sts.귀하의-도메인/.well-known/mta-sts.txt에 HTTPS로 제공됩니다. _mta-sts.귀하의-도메인의 DNS TXT 레코드는 정책이 존재한다는 것을 알리고 ID를 담을 뿐이며, mode와 허용 MX 호스트를 비롯한 실제 규칙은 그 HTTPS 파일에 들어 있습니다. MTA-STS가 작동하려면 둘 다 존재하고 유효해야 합니다.
STARTTLS는 기회주의적입니다. 암호화를 제공하지만 네트워크 공격자가 STARTTLS 광고를 제거해 평문 전송을 강제할 수 있으며 이는 감지되지 않습니다. MTA-STS는 발신 서버에 TLS가 필수이며 어떤 MX 인증서를 신뢰해야 하는지 알려 주는 게시된 정책을 추가하므로, 제거되거나 유효하지 않은 TLS 연결은 조용히 다운그레이드되는 대신 전송 실패를 일으킵니다. 이는 STARTTLS를 다운그레이드 공격에 견디도록 강화합니다.
아니요. MTA-STS는 의도적으로 DNSSEC가 아니라 HTTPS와 웹 PKI에 신뢰를 의존하므로 DANE보다 배포하기 쉽습니다. 정책 파일의 HTTPS 인증서가 인증을 제공합니다. 도메인에 이미 DNSSEC가 있다면 MTA-STS와 함께 DANE를 운영할 수 있습니다. 두 메커니즘은 충돌하지 않고 서로 보완하기 때문입니다.
먼저 TXT 레코드와 정책 파일을 testing 모드로 게시한 뒤, TLS-RPT를 활성화해 발신 서버가 TLS 실패 보고서를 이메일로 보내게 하세요. 정책의 MX 호스트명이 DNS와 일치하고 모든 MX가 유효한 인증서를 제시하는지 확인하세요. 정상적인 보고 주기 동안 보고서에 실패가 나타나지 않으면 모드를 enforce로 바꾸고 정책 ID를 갱신하세요.