TXT 레코드, SPF, 인증
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의 등록 데이터TXT 레코드는 DNS에 임의의 텍스트를 담으며, 이메일 인증(SPF), 도메인 소유권 검증, 서비스 구성에 널리 사용됩니다. 하나의 도메인이 여러 TXT 레코드를 동시에 게시할 수 있습니다. 유연하고 추가하기 쉬워서, TXT 레코드는 기계가 읽을 수 있는 정책과 증명을 도메인에 붙이는 표준 방식이 되었습니다.
원래는 자유 형식 메모를 위한 것이었지만, 이제 TXT 레코드는 다른 시스템이 읽는 구조화된 데이터를 담습니다. SPF 정책은 어떤 서버가 도메인을 대신해 메일을 보낼 수 있는지 나열합니다. TXT로 게시되는 DKIM과 DMARC 레코드는 이메일을 인증하고 보고합니다. Google, Microsoft, Atlassian을 비롯한 수많은 SaaS 도구의 검증 문자열은 도메인을 통제함을 증명합니다. 사이트 검증, BIMI, 사용자 지정 애플리케이션 설정을 위한 TXT 레코드도 볼 수 있습니다. 각각 다른 소비자를 위한 것이므로, 활동이 많은 도메인은 시간이 지나며 여러 개를 쌓아 갑니다.
IPeek는 도메인의 모든 TXT 레코드를 각각 따옴표로 묶인 문자열로 반환합니다. 접두사로 구분하세요. v=spf1은 SPF 정책을, v=DMARC1은 DMARC 정책(보통 _dmarc 하위 도메인에 있음)을, google-site-verification 같은 토큰은 소유권 증명을 표시합니다. 여러 따옴표 묶음으로 나뉜 긴 문자열은 리졸버가 이어 붙인 하나의 논리적 레코드입니다. 같은 이름에 SPF 레코드가 두 개 있는 것(유효하지 않음)과, 더 이상 사용하지 않는 서비스의 오래된 검증 토큰(안전하게 정리 가능)을 주의하세요.
SPF, DKIM, DMARC는 모두 TXT 레코드에 들어 있으며 함께 작동해 사칭을 막습니다. SPF(v=spf1)는 어떤 IP와 호스트가 도메인을 대신해 메일을 보낼 수 있는지 선언하고, 수신 서버는 그 외의 것을 거부하거나 표시합니다. DKIM은 공개 키를 게시해 수신 서버가 각 메시지의 암호화 서명을 검증할 수 있게 합니다. DMARC(v=DMARC1, _dmarc에 위치)는 둘을 묶어 실패를 어떻게 처리할지와 보고서를 어디로 보낼지를 수신 서버에 알려 줍니다. 도메인에는 정확히 하나의 SPF 레코드만 있어야 하지만, 그 옆에 다른 TXT 레코드는 여러 개 둘 수 있습니다.
네, 도메인은 여러 TXT 레코드를 동시에 게시할 수 있으며 대부분의 활성 도메인이 그렇게 합니다. 검증 토큰, DMARC 정책, 애플리케이션 설정이 흔히 같은 이름에 공존합니다. 한 가지 중요한 예외는 SPF입니다. 도메인에는 단 하나의 SPF(v=spf1) 레코드만 있어야 합니다. SPF 레코드가 여러 개이면 유효하지 않고 인증이 깨지기 때문입니다.
SPF 레코드는 v=spf1로 시작하는 TXT 레코드로, 도메인을 대신해 이메일을 보내도록 인증된 서버를 나열합니다. 수신 서버는 이를 확인해 들어오는 메일이 정말 귀하에게서 왔는지 판단합니다. 도메인의 루트 이름에 일반 TXT 레코드로 저장되며, 도메인에는 정확히 하나만 있어야 합니다.
많은 서비스가 제공하는 고유 토큰이 담긴 TXT 레코드를 추가하도록 요청한 뒤, DNS에서 이를 확인해 도메인을 통제함을 확인합니다. Google, Microsoft를 비롯한 대부분의 SaaS 플랫폼이 이 방법을 사용합니다. 검증이 끝나면 토큰은 보통 남겨 두거나 제거할 수 있으며, 사용하지 않는 토큰을 정리하면 DNS가 깔끔하게 유지됩니다.
DNS는 단일 TXT 문자열을 255자로 제한하므로, 더 긴 값은 하나의 레코드 안에서 여러 따옴표 묶음으로 나뉩니다. 리졸버와 IPeek는 이 묶음을 다시 하나의 논리적 값으로 이어 붙입니다. 이는 긴 DKIM 키나 상세한 SPF 정책에서 정상적이고 예상되는 일이며, 분할은 레코드를 읽는 방식에 영향을 주지 않습니다.
셋 다 TXT 레코드로 게시되는 이메일 인증 메커니즘입니다. SPF는 어떤 서버가 도메인을 대신해 보낼 수 있는지 나열하고, DKIM은 수신 서버가 게시된 키로 검증할 수 있는 암호화 서명을 추가하며, DMARC는 실패 처리 정책을 설정하고 보고서를 요청합니다. 함께 사용하면 도메인 사칭을 훨씬 어렵게 만듭니다.