검사 결과 해석과 확인 방법

최근 개정 2026-09-07

점수보다 실제 장애부터 확인하세요

WebsiteInfo는 공개 DNS 레코드, TLS·HTTP 응답과 일부 공개 파일을 확인합니다. 결과에 표시된 시각에 외부에서 관측한 정보이며, 서버에 로그인하거나 소스 코드를 분석하지 않습니다. 높은 점수가 쇼핑몰의 신뢰성이나 사이트 전체의 안전을 보증하지는 않습니다.

사이트가 열리지 않으면 DNS, 인증서, 리다이렉트 목적지부터 확인하세요. 발신 메일이 문제라면 SPF·DKIM·DMARC를 함께 봅니다. 사이트는 정상이고 헤더만 빠졌다면 그 헤더를 추가했을 때 어떤 기능이 달라지는지부터 검토하세요. 모든 경고가 같은 우선순위는 아닙니다.

해석 예시: DMARC가 있는데 메일이 실패한다면

DNS에 v=DMARC1; p=reject가 있는데 뉴스레터가 스팸함에 들어가는 상황을 가정해 봅시다. 레코드 발견은 정책이 게시됐다는 뜻이지 뉴스레터 인증에 성공했다는 뜻이 아닙니다. 실제 수신한 테스트 메일의 원문에서 Authentication-Results, 화면에 보이는 From 도메인, DKIM 서명 도메인을 확인합니다.

DMARC는 SPF 또는 DKIM 중 적어도 하나가 통과하면서 From 도메인과 정렬되어야 합니다. 다른 return-path 도메인으로 SPF만 통과했다고 충분한 것은 아닙니다. 정책을 강화하기 전에 문의 폼·청구 시스템·뉴스레터 등 정상 발송 경로를 모두 목록으로 만들고 각각의 정렬 상태와 집계 보고서를 확인하세요. 이 예시는 특정 도메인의 실제 검사 결과가 아닙니다.

DKIM 미발견은 미설정을 뜻하지 않습니다

현재 검사하는 셀렉터는 google, default, selector1, selector2, k1, mail, dkim, s1의 여덟 개입니다. 서비스가 다른 이름을 쓴다면 키가 있어도 찾지 못할 수 있습니다. 반대로 DNS에서 키를 찾았다고 실제 발신 메일의 서명 검증까지 성공한 것은 아닙니다.

수신 메일 원문의 DKIM-Signature에서 s=와 d= 값을 찾으세요. dig가 설치되어 있다면 dig +short TXT SELECTOR._domainkey.DOMAIN에서 두 자리표시자를 해당 값으로 바꿔 조회합니다. 수신 측 Authentication-Results와 메일 제공자의 안내를 대조하세요. 개인 서명 키는 공개 도구에 넣지 마세요.

DNS 응답 차이와 저장된 결과의 시각

전파 검사는 Google·Cloudflare·Quad9·KT 네 리졸버의 A 레코드를 비교합니다. 전 세계 모든 지역을 조사하는 것은 아닙니다. CDN은 지역에 따라 다른 주소를 의도적으로 반환할 수 있으므로, 답이 다르다는 이유만으로 전파 실패라고 판단하지 마세요. 의도한 호스팅 구성과 먼저 비교합니다.

검사 후 한 시간 이내의 결과는 보통 재사용됩니다. DNS를 바꿨다면 결과 시각을 확인하고 새로 검사 기능을 이용하세요. 새로 검사해도 DNS 리졸버에는 TTL이 만료되지 않은 응답이 남아 있을 수 있습니다. 전체 요청 제한 상황에서는 더 오래된 저장본이 표시될 수 있으므로 페이지를 연 시간보다 검사 기준 시각을 확인해야 합니다.

DNSSEC 항목은 DS 레코드 존재를 확인합니다. 신뢰 체인과 모든 서명의 유효성을 끝까지 검증하는 기능은 아닙니다. DNSSEC 오류는 설정을 반복해서 껐다 켜기보다 DNS 제공자와 서명·위임 구성을 확인하세요.

인증서와 리다이렉트: 어느 서버를 확인했나요?

CDN을 사용하면 공개 HTTPS 연결이 원본 서버보다 앞에서 종료될 수 있습니다. 이때 보이는 인증서는 방문자와 CDN 사이의 인증서입니다. CDN과 원본 서버 사이의 인증서까지 정상이라는 뜻은 아닙니다. 원본 TLS 오류가 나면 호스팅 관리 화면에서 두 구간을 따로 확인하세요.

보고서에 이동한 주소가 표시되면 의도한 대표 주소인지 확인합니다. 기본 도메인과 www를 함께 사용한다면 둘 다 검사하세요. 이 서버에서 연결이 성공했다고 모든 클라이언트·TLS 버전과 호환된다는 뜻은 아닙니다.

보안 헤더는 존재 여부 다음에 내용을 보세요

헤더 검사는 확인한 HTTPS 응답에 특정 헤더가 있는지를 우선 확인합니다. 매우 느슨한 Content-Security-Policy도 존재한다는 이유로 표시될 수 있습니다. 반대로 정책을 그대로 복사하면 결제·외부 임베드·분석 기능이 멈출 수 있습니다.

브라우저 개발자 도구에서 실제 응답을 확인하세요. CSP는 Content-Security-Policy-Report-Only로 실제 기능을 사용하며 위반 항목을 관찰한 뒤 적용합니다. HSTS는 HTTPS가 안정적으로 작동하는지 먼저 확인하고, includeSubDomains가 하위 도메인에도 영향을 준다는 점을 고려하세요. 리다이렉트가 끝난 응답과 주요 내부 페이지도 다시 확인합니다.

수정 전후를 비교할 수 있게 기록하세요

도메인, 검사 기준 시각, 문제가 된 항목, 바꿀 설정을 적어 두세요. 한 가지씩 수정하고 실제 기능을 확인한 다음 다시 검사합니다. 메일은 실제 테스트 발송으로, 웹 변경은 영향을 받는 페이지를 열어 확인하세요. 문제가 생기면 되돌릴 수 있도록 이전 설정을 보관합니다.

판정이 이상하다면 문의 페이지로 공개 보고서 주소, 검사 시각, 항목과 기대한 결과를 보내 주세요. 증거 자료에서 비밀번호·쿠키·개인 키·개인 메일 본문은 제거하세요.