PTR 레코드 조회 — 리버스 DNS

PTR 레코드 조회로 모든 IPv4·IPv6 주소 뒤의 호스트명을 찾으세요: 역방향 존 자체 네임서버에서 직접 가져온 모든 PTR 레코드, 각 이름이 주소로 되돌아오는지(FCrDNS), 누가 존을 운영하는지, 메일 서버에 대한 Gmail, Yahoo, Microsoft의 규칙을 통과하는지 보여 줍니다.

업데이트: 2026년 10월 23일

출처: 루트 서버에서 찾아간 역방향 존의 네임서버 · Google Public DNS · Cloudflare 1.1.1.1 · Team Cymru

표기 방식에 상관없이 IPv4 또는 IPv6 주소, 호스트명(주소를 먼저 조회) 또는 in-addr.arpa 이름을 입력하세요.

예시

리버스 DNS(역방향 DNS, rDNS)란?

역방향 DNS는 IP 주소를 다시 호스트명으로 바꿉니다. 이름을 주소로 바꾸는 일반적인(정방향) 조회의 반대입니다. 응답은 주소 보유자가 DNS 안의 주소 전용 영역에 게시하는 PTR 레코드입니다.

DNS 이름은 오른쪽에서 왼쪽으로 읽으므로, 주소를 조회하려면 거꾸로 씁니다: 8.8.8.8은 8.8.8.8.in-addr.arpa, 203.0.113.7은 7.113.0.203.in-addr.arpa가 됩니다. 네트워크 부분이 오른쪽에 오므로 각 주소 블록을 그 보유자에게 넘길 수 있습니다(RFC 1035 §3.5).

IPv6는 ip6.arpa 아래에서 주소의 16진수 32자리(니블)를 모두 마지막 자리부터 씁니다: 자리를 뒤집기 전에 :: 표기를 펼치므로 2001:4860:4860::8888의 이름은 레이블 32개입니다(RFC 3596 §2.5). 입력하는 동안 도구가 질의할 이름을 입력란 아래에 보여 주며, 결과 옆의 역방향 경로에 니블 32개를 모두 적어 줍니다.

역방향 이름의 구조2026-10-23 실시간 조회

IPv4 주소OpenDNS

PTR을 질의하는 역방향 이름resolver1.opendns.com +3

옥텟을 거꾸로/8이 마지막에 옵니다: 208.in-addr.arpa는 ARIN의 존, 222.67.208.in-addr.arpa는 OpenDNS 자체의 존입니다.

in-addr.arpaIPv4 역방향 트리로, IANA가 관리하고 a~f.in-addr-servers.arpa가 제공합니다.

PTR이름에 들어 있는 값: resolver1.opendns.com 외 호스트명 3개.

전체를 적은 IPv6 주소Google

2001:4860:4860:0000:0000:0000:0000:8888

니블 32개, 마지막 자리부터

88880000000000000000068406841002.ip6.arpa

끝의 8888이 맨 앞에, Google의 2001:4860 /32가 맨 뒤에 오며, :: 표기로 숨겨졌던 0 16개를 모두 적습니다.

8.8.8.8.in-addr.arpaIPv4: 레이블 4개, 역순

8.8.8.8.0.0.0.0…ip6.arpaIPv6: 32자리 모두, 역순

~~8.8.8.8.0.6.8.4…ip6.arpa~~:: 압축을 그대로 두면 다른 이름이 되어 NXDOMAIN

8.8.8.8은 앞뒤로 읽어도 같으므로, 이 그림은 옥텟이 눈에 띄게 자리를 바꾸는 208.67.222.222를 사용합니다. 도구의 역방향 경로는 조회하는 모든 IPv4 주소에 대해 같은 뒤집기를 그려 줍니다.

PTR 레코드 조회 방법

위에 주소를 입력하고 PTR 조회를 누르세요. 도구는 루트 서버에서부터 역방향 존 자체 네임서버까지 따라 내려가 직접 질의한 다음, Google과 Cloudflare의 캐시된 사본과 비교합니다. 터미널에서는 macOS와 Linux의 dig -x 8.8.8.8, Windows의 nslookup 8.8.8.8, 또는 host 8.8.8.8 명령으로 같은 조회를 할 수 있습니다.

dig -x 명령은 in-addr.arpa 또는 ip6.arpa 이름을 대신 만들어 줍니다. @ 기호와 존의 네임서버, +norecurse 옵션을 추가하면(dig -x 8.8.8.8 @ns1.google.com +norecurse) 캐시 대신 존 자체의 응답과 전체 TTL을 읽을 수 있습니다. PowerShell용으로 Microsoft가 문서화한 형식은 역방향 이름을 넘깁니다: Resolve-DnsName -Name 8.8.8.8.in-addr.arpa -Type PTR.

% dig -x 8.8.8.8 +noall +answer

dig가 8.8.8.8.in-addr.arpa를 직접 만듭니다. IN 앞의 숫자는 사용 중인 리졸버에 남은 TTL입니다.

dig 응답 읽는 법Google Public DNS, 이어서 Google 자체 서버 · 2026-10-23 기록

bash · zsh

$ dig -x 8.8.8.8 @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, status: NOERROR1, id: 24160
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;8.8.8.8.in-addr.arpa.        IN   PTR2

;; ANSWER SECTION:
8.8.8.8.in-addr.arpa.  140033  IN   PTR   dns.google.4

;; SERVER: 8.8.8.8#53(8.8.8.8)5

$ dig -x 8.8.8.8 @ns1.google.com +norecurse
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
8.8.8.8.in-addr.arpa.  86400  IN   PTR   dns.google.
;; SERVER: 216.239.32.10#53(216.239.32.10)

상태: 응답 하나가 있는 NOERROR. NXDOMAIN이면 PTR이 설정되지 않은 것이고, SERVFAIL이면 역방향 존이 손상된 것입니다.
질의: dig가 주소로 8.8.8.8.in-addr.arpa를 만들어 PTR을 질의했습니다.
TTL: Google 캐시에 남은 시간 14,003초. 존 자체 서버는 전체 86,400초, 즉 하루를 줍니다.
호스트명: PTR의 값입니다. 끝의 점이 이름을 끝맺습니다.
응답한 서버: 8.8.8.8, 즉 캐시입니다. 두 번째 응답에서는 aa 플래그가 존 자체의 서버임을 나타냅니다.

PTR 하나를 두 번 질의한 결과: Google Public DNS는 캐시에서 줄어드는 TTL로 응답하고, +norecurse 옵션으로 질의한 ns1.google.com은 존을 대표해 전체 TTL로 응답합니다.

리버스 DNS 조회 결과 읽는 법

맨 위의 한 문장은 주소의 역방향 이름과 그 이름이 되돌아오는지를 존의 TTL, 응답한 서버와 함께 알려 줍니다. 그 아래 색이 칠해진 메모는 누가 이름을 바꿀 수 있는지, 무엇이 특이한지 알려 줍니다.

PTR 보기는 모든 이름을 TTL, 정방향 확인과 함께 나열합니다. 메일 보기는 수신 측 규칙에 따라 점수를 매기고, 위임 보기는 질의한 각 서버를, 사본 보기는 Google과 Cloudflare의 캐시된 응답을 비교하며, 명령어 보기는 같은 조회를 터미널용으로 보여 줍니다. 오른쪽의 역방향 경로는 전체 과정을 그림으로 보여 줍니다.

8.8.8.8의 리버스 DNS 조회: Google 네임서버가 응답한 PTR 레코드 dns.google, 정방향 확인, 위임 경로 — 8.8.8.8의 리버스 DNS 조회 예시입니다. 판정, TTL과 정방향 확인이 붙은 PTR 레코드, 루트에서 Google 존까지의 역방향 경로를 보여 줍니다. 번호를 선택하면 각 부분이 무엇을 보여 주는지 확인할 수 있습니다.

PTR 레코드란?

PTR(pointer, 포인터) 레코드는 DNS 유형 12로, 자신이 놓인 주소의 호스트명 하나를 담습니다: 8.8.8.8.in-addr.arpa. 86400 IN PTR dns.google. 단순한 데이터일 뿐, CNAME과 달리 다른 곳으로 보내지 않습니다(RFC 1035 §3.3.12).

PTR은 그 안에 든 이름의 소유자가 아니라 주소 보유자가 씁니다: Google의 역방향 존은 8.8.8.8이 dns.google이라고 말하고, 그 반대는 dns.google 존의 A 레코드만 말합니다. 한 주소에 PTR 레코드가 여러 개 있을 수 있으며(RFC 2181 §10.2), 208.67.222.222에는 4개가 있습니다. 이름은 별칭이 아닌 실제 호스트명이어야 합니다.

PTR에는 이름만 들어 있고, 소유자나 국가, 도시는 없습니다. 조회 결과 옆에 표시되는 위치는 운영자가 이름에 넣은 단어나 별도의 데이터베이스에서 온 것입니다.

이름 하나, 존 두 개8.8.8.8과 dns.google, 2026-10-23 실시간

정방향 존도메인의 존: dns.google

dns.google. A 8.8.8.8dns.google. A 8.8.4.4dns.google. AAAA 2001:4860:4860::8888dns.google. AAAA 2001:4860:4860::8844

dns.google 보유자를 위해 ns1.zdns.google에서 제공

존 두 개, 서버 세트 두 개

역방향 존주소 블록의 존: 8.8.8.0/24

8.8.8.8.in-addr.arpa. PTR dns.google.

ARIN이 Google에 위임, ns1.google.com에서 제공

8.8.8.8.in-addr.arpa.역방향 이름86400TTL · 1일IN클래스PTR유형dns.google.호스트명

주소 1개, 이름 4개208.67.222.222: resolver1.opendns.com 외 3개

주소 1개, 이름 48개apple.com의 주소인 17.253.144.10, 각각 TTL 5분

이름 1개, 주소 4개dns.google: 8.8.8.8, 8.8.4.4와 IPv6 2개

PTR은 8.8.8.8의 이름을, A 레코드는 dns.google이 가리키는 곳을 알려 줍니다. 마침 Google이 두 존을 모두 운영하지만, 서버는 서로 다릅니다.

정방향 확인을 거친 역방향 DNS(FCrDNS)란?

정방향 확인을 거친 역방향 DNS는 PTR의 이름이 같은 주소로 다시 해석된다는 뜻입니다: 8.8.8.8 → dns.google → 8.8.8.8. 메일 서버는 이 검사를 iprev라고 부릅니다(RFC 8601 §3): 주소의 PTR 이름을 조회하고, 각 이름의 A 또는 AAAA 레코드를 조회해, 그중에 주소가 있으면 통과입니다.

두 번째 단계가 중요한 이유는 주소를 보유한 쪽이 PTR에 google.com을 포함해 어떤 이름이든 쓸 수 있기 때문입니다. 도메인 소유자가 그 이름을 같은 주소로 되돌려 가리킬 때만 이름이 무언가를 증명합니다. 도구는 최대 10개까지 모든 PTR 이름을 확인하고 오른쪽에 고리를 그립니다: 고리가 닫히면 초록색, 이름이 다른 곳을 가리키면 주황색입니다.

PTR 레코드가 여러 개라면 하나만 되돌아와도 충분합니다. 이름의 A 레코드에 다른 주소도 들어 있어도, 이 주소가 그중 하나라면 통과합니다.

주소 셋, 고리 셋2026-10-23 실시간

정방향 확인됨Google

8.8.8.8dns.google8.8.8.8: 같은 주소

되돌아옴dns.google은 8.8.4.4도 돌려줍니다

다른 곳을 가리킴AdGuard

94.140.14.14dns.adguard-dns.com185.113.30.30: 다른 주소

확인 안 됨A 레코드가 185.113.30.30입니다

PTR 없음Cloudflare

104.18.0.1NXDOMAIN: 이름 없음

확인할 것 없음Cloudflare 존의 NXDOMAIN 응답

모든 결과의 오른쪽 가장자리에도 같은 고리가 그려집니다: 이름이 되돌아오면 초록색, 다른 곳으로 가면 주황색입니다.

메일 서버의 역방향 DNS 확인: Gmail, Yahoo, Outlook.com의 요구 사항

세 곳 모두 모든 발신 IP에 PTR 레코드를 요구합니다. Gmail은 그 이름이 같은 IP로 다시 해석될 것도 요구하고, Yahoo는 "유효한 정방향 및 역방향 DNS 레코드"를 요구하며, 둘 다 2024년 2월부터 모든 발신자에게 적용됩니다. Outlook.com 정책은 유효한 역방향 DNS를 요구할 뿐 정방향 단계는 언급하지 않습니다.

ec2-3-80-0-1.compute-1.amazonaws.com 같은 일반적인 이름은 어떤 규칙에도 어긋나지 않습니다: Yahoo는 도메인을 반영한, 의미 있고 일반적이지 않은 이름을 권장할 뿐입니다. Outlook.com은 동적 IP 공간에서 오는 연결이 수락되지 않을 수 있다고 경고하는데, 이는 클라우드 서버의 고정 기본 이름이 아니라 ISP의 풀 이름에 해당합니다. 메일 보기는 이런 경우를 경고로, 요구 사항은 통과 또는 실패로 표시하며, 끝나지 않은 검사는 그 어느 쪽도 아닙니다.

두 가지는 절대 실패가 아닙니다: RFC 2181이 허용하는 여러 개의 PTR 레코드, 그리고 서버의 HELO 이름과 다른 PTR입니다. RFC 5321 §4.1.4는 그 이유로 메일을 거부해서는 안 된다고 규정합니다. Gmail은 PTR이 없거나 되돌아오지 않으면 421 4.7.0 또는 451 4.7.23 코드로 속도를 제한하고 550 5.7.25 코드로 차단합니다.

필수, 권장, 언급 없음각 수신 측 자체 페이지, 2026-10-23 확인

항목	Gmail발신자 가이드라인	Yahoo Mail발신자 모범 사례	Outlook.com포스트마스터 정책
PTR 레코드 있음	필수	필수	필수
이름이 되돌아옴	필수	필수	언급 없음
일반적이거나 동적인 이름 아님	언급 없음	권장	동적 IP를 거부할 수 있음
실제 발신 서버 4곳, 실시간 확인
mail-sor-f41.google.com209.85.220.41 · Gmail 자체 발신 서버	통과	통과	통과
ec2-3-80-0-1.compute-1.amazonaws.com3.80.0.1 · AWS의 기본 이름	통과	통과경고	통과경고
dns.adguard-dns.com94.140.14.14 · 185.113.30.30을 가리킴	실패	실패	통과
PTR 없음104.18.0.1 · NXDOMAIN	실패	실패	실패

Gmail의 응답 코드

421 4.7.0 · 451 4.7.23속도 제한: PTR이 없거나, 정방향 항목이 발신 IP와 일치하지 않음

550 5.7.25차단: PTR이 없거나, 정방향 항목이 발신 IP를 참조하지 않음

550-5.7.1IPv6 경유: 메시지가 PTR 레코드와 인증에 관한 IPv6 발송 가이드라인을 충족하지 않음

요구 사항만 실패로 표시됩니다. Yahoo의 권장 사항과 Outlook.com의 동적 IP 경고는 경고로 표시됩니다. Gmail의 코드는 Gmail의 SMTP 오류 참조 문서에서 가져왔습니다.

역방향 DNS는 누가 관리하나요? PTR 레코드 설정 방법

도메인 소유자가 아니라 주소 블록의 보유자입니다. IANA는 각 블록의 역방향 존을 해당 지역 인터넷 레지스트리에 위임하고, 레지스트리는 주소를 보유한 네트워크에 위임하며, 그 네트워크가 존을 운영하거나 다시 넘깁니다(RFC 3172). example.com을 소유해도 주소에 이름을 붙일 수는 없습니다: 호스팅 업체나 ISP가 해야 합니다.

클라우드는 고객이 직접 설정할 수 있게 하며, 규칙은 저마다 다릅니다: AWS는 정방향 A 레코드를 먼저 요구하고, Azure는 IPv4만, 그것도 포털이 아닌 곳에서 설정하며, DigitalOcean은 Droplet 이름으로 PTR을 만들고, Google Cloud는 도메인 소유를 증명하게 합니다. 가정용 회선에서는 대개 고정 IP가 있는 비즈니스 요금제만 원하는 PTR을 받을 수 있으니 ISP에 문의하세요. /24보다 작은 블록은 CNAME으로 넘기는 경우가 많으며(RFC 2317), 도구는 그 CNAME이 가리키는 곳까지 따라갑니다.

변경 사항은 캐시가 이전 응답을 버려야 모두에게 반영됩니다: 이전 레코드의 TTL이 결정하며, 레코드가 없었다면 캐시된 "PTR 없음" 시간이 결정합니다(RFC 2308). 정해진 24~48시간이 아닙니다. Vultr는 자사 변경에 6~12시간이 걸린다고 밝힙니다.

존은 누가 넘겨주나2026-10-23 기록한 경로

in-addr.arpaIANA가 관리하고, a~f.in-addr-servers.arpa가 제공
8.in-addr.arpa · 208.in-addr.arpa블록의 지역 레지스트리: 8.0.0.0/8과 208.0.0.0/8은 ARINARINRIPE NCCAPNICLACNICAFRINIC
8.8.8.in-addr.arpa8.8.8.0/24의 보유자: Google이 ns1~ns4.google.com에서 PTR을 작성

17.in-addr.arpa레거시 /8, in-addr.arpa에서 Apple 자체 서버로 바로 위임

129.2.0.192.in-addr.arpa CNAME 129.128/26.2.0.192.in-addr.arpaRFC 2317 자체의 예시: 주소가 256개 미만인 블록이면 상위 존에 블록 보유자가 운영하는 존으로 향하는 CNAME을 둡니다. 하위 존의 이름은 관례일 뿐입니다.

각 단계는 2026-10-23에 기록한 위임 응답이며, RFC 2317 단계만 문서용 블록에 대한 RFC 자체의 예시입니다.

제공업체별 PTR 설정 위치각 제공업체 자체 문서, 2026-10-23 확인

제공업체	설정 방법	제한 사항
AWS문서	Elastic IP만 가능합니다. 이름의 A 레코드가 Elastic IP를 가리키도록 게시한 다음, EC2 console › Elastic IPs › 해당 주소 › Actions › Update reverse DNS를 선택하거나 `aws ec2 modify-address-attribute --allocation-id … --domain-name mail.example.com` 명령을 실행하세요.	정방향 A 레코드가 먼저 있어야 합니다. 역방향 레코드가 있는 동안 Elastic IP는 계정에 고정됩니다. GovCloud(US)에서는 AWS Support만 설정할 수 있습니다. 포트 25 제한은 별도로 요청해 해제합니다.
Microsoft Azure문서	공용 IP의 ReverseFqdn을 설정하세요: `az network public-ip update --resource-group RG --name PublicIp --reverse-fqdn mail.example.com.` 명령(이름은 점으로 끝남) 또는 PowerShell의 Set-AzPublicIpAddress를 사용합니다.	IPv4만 가능합니다: Azure 소유 IPv6 주소에는 PTR이 없습니다. Azure portal에서는 설정할 수 없습니다. 이름은 그 IP로 해석되거나 해당 구독에 속해야 합니다. 주소당 PTR 하나, 기본값은 없으며, App Service와 Application Gateway에는 설정할 수 없습니다.
Google Cloud문서	먼저 도메인을 인증하세요(Search Console 또는 VM의 외부 IP를 가리키는 A 레코드). 그다음 VM instances › 해당 인스턴스 › Edit › 기본 네트워크 인터페이스 › Public DNS PTR record를 설정하거나 `gcloud compute instances update-access-config INSTANCE --public-ptr --public-ptr-domain mail.example.com` 명령을 실행하세요.	기본 네트워크 인터페이스만 가능하며, 부하 분산기와 Cloud NAT에는 PTR을 설정할 수 없습니다. IPv6 PTR에는 외부 IPv6가 있는 이중 스택 또는 IPv6 전용 서브넷이 필요합니다. 기본 이름은 <reversed-ip>.bc.googleusercontent.com입니다.
Hetzner문서	Cloud: Hetzner Console › 해당 서버(또는 Primary IP, Floating IP) › Networking › IP 옆의 rDNS 편집. IPv6는 ::1처럼 인터페이스 부분만 입력합니다. Dedicated: Robot › 해당 서버 › IPs, 각 IP 옆의 입력란.	Hetzner가 역방향 존을 운영합니다. rDNS 항목은 양방향으로 해석될 때(FCrDNS)만 유효한 것으로 봅니다. 기본값은 static.<reversed-ip>.clients.your-server.de입니다.
DigitalOcean문서	PTR 편집기가 없습니다: Droplet의 이름을 mail.example.com처럼 원하는 전체 이름으로 짓거나 바꾸면 DigitalOcean이 그 이름으로 PTR을 만듭니다.	이름은 유효한 FQDN이어야 합니다(my-droplet으로는 PTR이 생기지 않음). Droplet의 첫 번째 IPv6 주소만 PTR을 받습니다. PTR은 직접 만들 수 없습니다.
OVHcloud문서	먼저 A 또는 AAAA 레코드가 IP를 가리키게 하세요. 그다음 Control Panel › Network › Public IP Addresses › IP 행의 작업 버튼 › Configure the reverse DNS를 선택합니다(Public Cloud: 해당 프로젝트 › Public IPs).	OVHcloud는 이름이 같은 IP로 되돌아오는지 즉시 확인하므로 레코드가 이미 적용되어 있어야 합니다. 이름은 소문자여야 하며 점으로 끝나야 합니다.
Vultr문서	Products › Compute › 해당 인스턴스 › Settings › IPv4 또는 IPv6 › Public Network: Reverse DNS 열의 이름을 클릭하고 전체 이름을 입력한 뒤 저장하세요.	Vultr는 이름이 같은 IP로 되돌아오도록 요구하며, 변경이 반영되기까지 6~12시간이 걸린다고 밝힙니다. 기본값은 <ip>.vultrusercontent.com입니다.
Akamai Cloud (Linode)문서	먼저 A(및 AAAA) 레코드를 추가하세요. 그다음 Cloud Manager › Linodes › 해당 Linode › Network › IP의 줄임표 메뉴 › Edit RDNS에서 전체 이름을 입력합니다. 입력란을 비우면 기본값으로 돌아갑니다.	A 레코드가 IP와 일치할 때까지 오류로 실패합니다. IPv6 범위: 범위에서 Edit rDNS를 선택한 뒤 주소마다 설정합니다. 기본값: <ip-with-dashes>.ip.linodeusercontent.com, 이전 형식은 li<n>-<n>.members.linode.com.
Oracle Cloud문서	먼저 A 또는 AAAA 레코드를 만든 다음, IP와 PTR에 넣을 이름, 정방향 레코드의 이름을 적어 서비스 요청을 여세요. Oracle이 확인한 뒤 PTR을 만듭니다.	IP당 PTR 하나이며, 지원 요청으로만 설정할 수 있습니다. 정방향 레코드가 그 IP로 해석되어야 합니다.
인터넷 제공업체RFC 8501	인터넷 제공업체에 요청하세요: 주소를 보유한 제공업체만 PTR을 설정할 수 있습니다. 실제로는 비즈니스 요금제의 고정 IP가 필요합니다.	가정용 회선은 제공업체의 풀 이름을 그대로 쓰며, Comcast 같은 수신 측은 이런 이름을 동적 주소로 보고 직접 보낸 메일을 거부합니다.

변경에 걸리는 시간: 캐시가 이전 PTR(그 TTL)이나 캐시된 “PTR 없음” 응답(RFC 2308)을 버릴 때까지입니다. 실제 TTL: 8.8.8.8은 1일, resolver1.opendns.com은 7일, EC2 기본 이름은 5분.

대부분의 IPv6 주소에 PTR 레코드가 없는 이유

하나씩 이름을 붙이기에는 너무 많기 때문입니다. ISP는 나눠 주는 IPv4 주소마다 PTR을 미리 채워 둘 수 있지만, /48 하나에는 2⁸⁰개의 주소가 있고, 기기는 주소를 스스로 고르며 그 주소는 수명이 짧은 경우가 많습니다(RFC 8501).

RFC 8501은 ISP의 선택지를 나열합니다: NXDOMAIN 응답(PTR 없음, 가장 정확함), 고객 프리픽스마다 와일드카드 PTR, 동적 DNS, 고객에게 존 위임, 일치하는 PTR과 AAAA 레코드를 즉석에서 생성. 정방향 확인을 깨뜨리는 것은 와일드카드뿐입니다. 가정 사용자에게는 깔끔한 NXDOMAIN이면 괜찮지만, 시간 초과는 그렇지 않습니다.

IPv6로 메일을 보내는 서버에는 여전히 정방향 확인된 PTR이 필요합니다: Gmail은 PTR이 없는 IPv6 메일을 550-5.7.1 Message does not meet IPv6 sending guidelines regarding PTR records and authentication 응답으로 거부합니다. Azure는 자체 IPv6 주소에 PTR을 아예 주지 않습니다.

주소마다 PTR 하나: IPv4와 IPv6 규모 비교RFC 8501

/24IPv4 블록 하나2⁸ = 256

/64IPv6 서브넷 하나2⁶⁴ = 18,446,744,073,709,551,616

/48IPv6 사이트 하나2⁸⁰ = 1,208,925,819,614,629,174,706,176

막대 길이: 주소 공간의 비트 수. 1비트마다 개수가 두 배가 됩니다.

초당 PTR 레코드 1,000개를 만들어도 /48 하나는 38조 년이 지나도 다 채우지 못합니다(RFC 8501).

RFC 8501이 제시하는 ISP의 선택지

NXDOMAIN이름 없음PTR이 전혀 없습니다: 가장 정확한 응답이지만, 메일 서버는 이런 발신자를 거부할 가능성이 높습니다.

와일드카드일치하지 않음프리픽스 전체에 이름 하나: 정방향 조회가 모든 주소로 되돌아갈 수는 없습니다.

동적 DNS일치함각 호스트가 주소가 정해지면 자신의 AAAA와 PTR 업데이트를 보냅니다.

존 위임고객에게 달림DNS 서버를 운영하는 고객은 자기 프리픽스의 역방향 존을 받습니다. 대부분의 가정은 할 수 없습니다.

즉석 생성일치함서버가 질의를 받을 때 일치하는 AAAA와 함께 PTR을 만듭니다.

메일 서버에는 여전히 정방향 확인된 고유한 PTR이 필요합니다:2001:4860:4860::8888 → dns.google → 2001:4860:4860::8888

Googlebot 및 기타 크롤러 검증 방법

방문자의 주소를 조회해 PTR 이름이 크롤러의 문서화된 도메인으로 끝나는지 확인한 다음, 그 이름을 정방향으로 조회해 같은 주소가 나오는지 확인하세요: 66.249.66.1 → crawl-66-249-66-1.googlebot.com → 66.249.66.1. 또는 주소를 운영자의 공개 목록과 대조하세요(Google의 방법).

문서화된 도메인: Google은 googlebot.com과 google.com, Bingbot은 search.msn.com, Applebot은 applebot.apple.com, Yandex는 yandex.ru, yandex.net, yandex.com입니다. DuckDuckBot은 주소 목록만 공개합니다.

googleusercontent.com 이름만으로는 아무것도 증명하지 않습니다: 모든 Google Compute Engine VM이 기본으로 그 아래의 이름을 받으므로, 도구는 주소가 Google의 공개 목록에 있을 때만 Google로 인정합니다. 끝부분은 맞지만 되돌아오지 않는 이름은 가짜이며, 도구는 그렇게 알려 줍니다.

두 번의 조회로 판가름66.249.66.1, 2026-10-23 실시간

역방향 조회방문한 주소의 PTR.66.249.66.1 → crawl-66-249-66-1.googlebot.com
Google 도메인인가?googlebot.com으로 끝납니다. googleusercontent.com 이름이라면 주소가 Google 목록에도 있어야 합니다.
정방향 조회crawl-66-249-66-1.googlebot.com → 66.249.66.1같은 주소: 진짜 Googlebot입니다.

가짜: 사용자 에이전트에는 “Googlebot”, 출발지는 203.0.113.9역방향 조회가 NXDOMAIN으로 응답하므로 1단계에서 확인이 멈춥니다. (문서용 주소, RFC 5737.)

크롤러	PTR 이름의 끝	공개 IP 목록
GooglebotPTR과 정방향 조회, 또는 목록	googlebot.com	common-crawlers.json
Google 특수 크롤러PTR과 정방향 조회, 또는 목록	rate-limited-proxy-….google.com	special-crawlers.json
Google 사용자 트리거 가져오기 도구PTR과 정방향 조회, 또는 목록	google-proxy-….google.com….gae.googleusercontent.com목록이 있을 때만	user-triggered-fetchers-google.json user-triggered-fetchers.json user-triggered-agents.json
BingbotPTR과 정방향 조회, 또는 목록	search.msn.com	bingbot.json
ApplebotPTR과 정방향 조회, 또는 목록	applebot.apple.com	applebot.json
YandexBotPTR과 정방향 조회	yandex.ruyandex.netyandex.com	없음
DuckDuckBotIP 목록만	없음	duckduckbot.json

오늘 실제로 확인한 이름, 모두 되돌아옴:crawl-66-249-66-1.googlebot.commsnbot-157-55-39-1.search.msn.com17-58-101-179.applebot.apple.com

도메인과 목록은 각 운영자 자체 페이지에서 가져왔으며 2026-10-23에 확인했습니다. Bing은 목록을 매일 새로 받으라고 요청합니다.

역방향 DNS 오류의 의미

NXDOMAIN은 역방향 이름이 존재하지 않는다는 뜻입니다: 아무도 그 주소에 PTR을 설정하지 않았습니다. 응답이 없는 NOERROR(NODATA)는 이름은 있지만 PTR이 없다는 뜻입니다. 리졸버는 둘 중 어느 응답이든 존의 SOA에 있는 네거티브 캐시 시간 동안 보관하므로(RFC 2308), 새 PTR이 보이기까지 그만큼 걸릴 수 있습니다.

SERVFAIL은 존이 손상되었다는 뜻으로, 대개 레임 위임입니다: 존의 서버로 지정된 서버가 존을 제공하지 않아 모든 리졸버가 포기합니다. REFUSED는 존에 아예 응답하지 않는 서버가 보냅니다. 사설 주소와 문서용 주소에는 공개 PTR이 없습니다: 도구는 누구에게도 묻지 않고 IANA 레지스트리로 답합니다.

응답마다 실제 예시2026-10-23 실시간

NOERROR8.8.8.8이름이 설정됨: PTR이 TTL과 함께 돌아옵니다.PTR dns.google. · TTL 86400ns1.google.com · aa

NXDOMAIN104.18.0.1그런 이름 없음: Cloudflare 존에 PTR이 없으며, 그렇다고 응답합니다.SOA 18.104.in-addr.arpacruz.ns.cloudflare.com … 3600

NODATANOERROR, 0 answers2001:4860:4860::/48이름은 있지만 PTR은 없음: 하위에 이름이 있는 Google /48의 이름입니다.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpaSOA ns1.google.com … 60

SERVFAIL203.0.113.50지어낸 예시, 문서용 주소레임 위임: 레지스트리가 존을 제공하지 않는 서버 두 대를 지정하므로 리졸버가 포기합니다.APNIC → ns1, ns2.example.net: lameEDE 22: No Reachable Authority

NXDOMAINAS112192.168.1.1사설 주소: 공개 트리는 168.192.in-addr.arpa를 IANA의 AS112 서버에 넘기며, 이 서버는 NXDOMAIN으로 응답합니다.blackhole-1.iana.orgSOA prisoner.iana.org … 604800

“없음” 응답은 SOA의 네거티브 시간 동안 캐시됩니다(RFC 2308): Cloudflare는 1시간, Google은 60초, AS112는 7일.

리버스 DNS 조회 자주 묻는 질문

리버스 DNS 조회란 무엇인가요?

리버스 DNS 조회는 IP 주소의 PTR 레코드를 읽어 그 뒤의 호스트명을 찾는 것으로, 이름을 주소로 바꾸는 일반 조회의 반대입니다. 주소를 8.8.8.8.in-addr.arpa 같은 특수한 이름으로 뒤집어, 그 이름을 가진 네임서버에 질의합니다. 8.8.8.8의 응답은 dns.google입니다. 이 도구는 그 이름이 같은 주소로 되돌아오는지도 확인합니다.

dig나 nslookup으로 PTR 레코드를 조회하려면 어떻게 하나요?

macOS나 Linux에서 dig -x 8.8.8.8을 실행하세요: dig가 주소를 직접 뒤집으며, PTR은 answer 섹션에 나옵니다. Windows에서는 nslookup 8.8.8.8이 Name: 줄에 이름을 출력합니다. 모든 캐시를 건너뛰려면 존 자체 네임서버에 질의하세요: dig -x 8.8.8.8 @ns1.google.com +norecurse. 여기의 명령어 보기는 각 명령에 입력한 주소와 그 존의 서버를 채워 줍니다.

내 IP 주소에 역방향 DNS가 없는 이유는 무엇인가요?

아무도 그 주소에 PTR 레코드를 설정하지 않았기 때문입니다. 주소 블록의 보유자만 설정할 수 있으므로, 호스팅 업체나 ISP가 추가할 때까지 응답은 NXDOMAIN입니다. 대부분의 가정용 회선과 대부분의 IPv6 주소에는 PTR이 없습니다. 조회 결과가 SERVFAIL이라면 역방향 존 자체가 손상된 것으로, 대개 제공업체가 고쳐야 하는 레임 위임입니다.

PTR 레코드는 어떻게 설정하거나 변경하나요?

주소를 받은 곳에서 설정합니다. AWS에서는 정방향 A 레코드를 먼저 게시한 뒤 Elastic IP의 역방향 DNS를 업데이트합니다. Azure는 공용 IP에 ReverseFqdn을 설정하고, DigitalOcean은 Droplet 이름을 쓰며, Hetzner, OVHcloud, Vultr, Linode는 각 주소 옆에 rDNS 입력란이 있습니다. 가정이나 사무실 회선이라면 ISP에 문의하세요: 대개 고정 IP가 있는 비즈니스 요금제만 가능합니다.

PTR 레코드 변경은 반영되기까지 얼마나 걸리나요?

캐시가 이전 응답을 보관하는 시간만큼 걸립니다. 각 리졸버는 TTL이 끝날 때까지(보통 1시간에서 1일) 이전 PTR을 제공할 수 있고, 캐시된 "PTR 없음" 응답은 존의 네거티브 캐시 시간 동안 제공할 수 있습니다. 정해진 24~48시간은 없습니다. 사본 보기에서 Google과 Cloudflare의 사본에 남은 시간을 확인할 수 있습니다.

IP 주소 하나에 PTR 레코드가 여러 개 있을 수 있나요?

네. DNS는 한 주소에 여러 PTR 레코드를 허용하며, RFC 2181은 개수에 제한이 있다고 가정하지 말라고 합니다: 208.67.222.222에는 4개가 있습니다. 그중 하나라도 주소로 되돌아오면 메일 검사는 통과합니다. 첫 번째 이름만 읽는 도구도 있으므로 메일에 쓰는 이름은 정방향 확인되어 있어야 합니다. PTR 하나는 가장 단순한 설정일 뿐 요구 사항은 아닙니다.

FCrDNS란 무엇인가요?

정방향 확인을 거친 역방향 DNS입니다: PTR의 이름을 정방향으로 조회하면 같은 주소가 나옵니다. 8.8.8.8의 역방향 이름은 dns.google이고 dns.google은 8.8.8.8로 해석되므로 통과합니다. 메일 서버는 이 검사를 iprev라고 부릅니다. 주소를 보유한 쪽은 PTR에 어떤 이름이든 쓸 수 있으므로 중요하며, 도메인 소유자가 동의하는지는 정방향 조회로만 알 수 있습니다.

이메일을 보내려면 역방향 DNS가 필요한가요?

네, 메일을 직접 보내는 모든 서버에 필요합니다. Gmail은 모든 발신 IP에 그 IP로 다시 해석되는 PTR을 요구하고, Yahoo는 유효한 정방향 및 역방향 DNS를, Outlook.com은 유효한 역방향 DNS를 요구합니다. 없으면 메일 속도가 제한되거나 거부되며, Gmail의 550 5.7.25가 그 예입니다. 제공업체의 일반적인 이름은 규칙은 통과하지만 경고를 받습니다.

"reverse DNS is not a valid hostname"은 무슨 뜻인가요?

메일 서버 테스트에서 발신 IP의 PTR 이름이 그 IP의 호스트명으로 제대로 작동하지 않을 때 표시하는 메시지입니다: 대개 PTR이 아예 없거나, 이름에 같은 주소로 되돌아오는 A 레코드가 없습니다. 여기서 발신 IP를 조회하세요: PTR 보기에 이름과 정방향 확인이, 메일 보기에 어긋난 규칙이 나옵니다.

리버스 DNS와 리버스 IP 조회는 같은 것인가요?

아닙니다. 리버스 DNS는 주소 보유자가 PTR 레코드에 게시한 이름(하나 또는 여러 개)을 읽습니다. 리버스 IP 조회는 한 주소에서 호스팅되는 모든 웹사이트를 나열하려는 것으로, 여러 리졸버에서 오랜 기간 수집한 패시브 DNS 데이터가 필요합니다. 두 용어를 섞어 쓰는 사이트가 많습니다. 각 방법으로 무엇을 찾을 수 있는지는 저희 IP로 호스트명 찾기 페이지에서 설명합니다.

역방향 DNS는 IPv6에서도 작동하나요?

네. IPv6 주소는 16진수 32자리를 모두 뒤집어 ip6.arpa 아래에서 조회하므로, 2001:4860:4860::8888은 레이블 32개짜리 이름이 되며 이 도구가 그 이름을 만들어 대신 질의합니다. ISP가 그 많은 주소에 이름을 미리 채워 둘 수 없어 대부분의 IPv6 주소에는 PTR이 없지만, IPv6로 메일을 보내는 서버에는 필요합니다.

사설 IP 주소에는 왜 PTR이 없나요?

192.168.1.1이나 10.0.0.1 같은 사설 주소는 여러 네트워크 안에서 동시에 쓰이므로 공개 DNS가 이름을 붙일 수 없습니다. 이 주소의 역방향 조회는 자체 네트워크의 리졸버가 담당하며, 밖으로 새어 나간 질의는 그런 이름이 없다고 응답하는 AS112 서버에서 끝납니다. 도구는 누구에게도 묻지 않고 각 특수 용도 범위를 해당 RFC와 함께 설명합니다.

PTR 레코드 조회 — 리버스 DNS

리버스 DNS(역방향 DNS, rDNS)란?

PTR 레코드 조회 방법

리버스 DNS 조회 결과 읽는 법

PTR 레코드란?

정방향 확인을 거친 역방향 DNS(FCrDNS)란?

메일 서버의 역방향 DNS 확인: Gmail, Yahoo, Outlook.com의 요구 사항

역방향 DNS는 누가 관리하나요? PTR 레코드 설정 방법

대부분의 IPv6 주소에 PTR 레코드가 없는 이유

Googlebot 및 기타 크롤러 검증 방법

역방향 DNS 오류의 의미

리버스 DNS 조회 자주 묻는 질문

리버스 DNS 조회란 무엇인가요?

dig나 nslookup으로 PTR 레코드를 조회하려면 어떻게 하나요?

내 IP 주소에 역방향 DNS가 없는 이유는 무엇인가요?

PTR 레코드는 어떻게 설정하거나 변경하나요?

PTR 레코드 변경은 반영되기까지 얼마나 걸리나요?

IP 주소 하나에 PTR 레코드가 여러 개 있을 수 있나요?

FCrDNS란 무엇인가요?

이메일을 보내려면 역방향 DNS가 필요한가요?

"reverse DNS is not a valid hostname"은 무슨 뜻인가요?

리버스 DNS와 리버스 IP 조회는 같은 것인가요?

역방향 DNS는 IPv6에서도 작동하나요?

사설 IP 주소에는 왜 PTR이 없나요?

IP에서 호스트명으로

DNS 조회

IP 조회

MX 조회

IP 블랙리스트 확인

SPF 레코드 확인

SMTP 테스트 도구

도메인에서 IP로

리버스 DNS(역방향 DNS, rDNS)란?

PTR 레코드 조회 방법

리버스 DNS 조회 결과 읽는 법

PTR 레코드란?

정방향 확인을 거친 역방향 DNS(FCrDNS)란?

메일 서버의 역방향 DNS 확인: Gmail, Yahoo, Outlook.com의 요구 사항

역방향 DNS는 누가 관리하나요? PTR 레코드 설정 방법

대부분의 IPv6 주소에 PTR 레코드가 없는 이유

Googlebot 및 기타 크롤러 검증 방법

역방향 DNS 오류의 의미

리버스 DNS 조회 자주 묻는 질문

리버스 DNS 조회란 무엇인가요?

dig나 nslookup으로 PTR 레코드를 조회하려면 어떻게 하나요?

내 IP 주소에 역방향 DNS가 없는 이유는 무엇인가요?

PTR 레코드는 어떻게 설정하거나 변경하나요?

PTR 레코드 변경은 반영되기까지 얼마나 걸리나요?

IP 주소 하나에 PTR 레코드가 여러 개 있을 수 있나요?

FCrDNS란 무엇인가요?

이메일을 보내려면 역방향 DNS가 필요한가요?

"reverse DNS is not a valid hostname"은 무슨 뜻인가요?

리버스 DNS와 리버스 IP 조회는 같은 것인가요?

역방향 DNS는 IPv6에서도 작동하나요?

사설 IP 주소에는 왜 PTR이 없나요?

더 많은 DNS, IP 및 이메일 도구

IP에서 호스트명으로

DNS 조회

IP 조회

MX 조회

IP 블랙리스트 확인

SPF 레코드 확인

SMTP 테스트 도구

도메인에서 IP로