Herramientas populares

Tema

DNS Reverso — Consulta de Registros PTR

Consulta de DNS reverso (reverse DNS lookup) para cualquier dirección IPv4 o IPv6: encuentre el hostname que hay detrás, con cada registro PTR leído directamente de los servidores de nombres de la zona inversa, si cada nombre apunta de vuelta a la dirección (FCrDNS), quién opera la zona y si cumple las reglas de Gmail, Yahoo y Microsoft para servidores de correo.

Fuentes: los servidores de nombres de la zona inversa, alcanzados desde un servidor raíz · Google Public DNS · Cloudflare 1.1.1.1 · Team Cymru

IPv4 o IPv6 en cualquier notación, un nombre de host (se resuelve primero) o un nombre in-addr.arpa.

Pruebe

¿Qué es el DNS reverso (DNS inverso o rDNS)?

El DNS reverso convierte una dirección IP en un nombre de host: lo contrario de la consulta habitual (directa), que convierte un nombre en una dirección. La respuesta es un registro PTR que el titular de la dirección publica en una parte del DNS reservada para direcciones.

Los nombres DNS se leen de derecha a izquierda, así que para consultar una dirección se escribe al revés: 8.8.8.8 se convierte en 8.8.8.8.in-addr.arpa y 203.0.113.7 en 7.113.0.203.in-addr.arpa. Con la parte de la red a la derecha, cada bloque de direcciones puede delegarse a su titular (RFC 1035 §3.5).

IPv6 usa ip6.arpa y los 32 dígitos hexadecimales (nibbles) de la dirección, empezando por el último dígito: :: se expande antes de invertir los dígitos, así que 2001:4860:4860::8888 tiene un nombre de 32 etiquetas (RFC 3596 §2.5). Mientras usted escribe, la herramienta muestra bajo el campo el nombre que consultará, y escribe los 32 nibbles en la ruta inversa junto al resultado.

Anatomía de un nombre inversoen vivo, 23/10/2026

Dirección IPv4OpenDNS

208.67.222.222222.222.67.208.in-addr.arpa

Su nombre inverso, consultado para PTRresolver1.opendns.com +3

Octetos invertidosEl /8 va al final: 208.in-addr.arpa es la zona de ARIN, 222.67.208.in-addr.arpa la de OpenDNS.
in-addr.arpaEl árbol inverso de IPv4, administrado por IANA y servido por a hasta f.in-addr-servers.arpa.
PTRLo que contiene el nombre: resolver1.opendns.com y tres hostnames más.

Dirección IPv6, escrita completaGoogle

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

32 nibbles, empezando por el último dígito

El 8888 del final va primero, el /32 2001:4860 de Google va al final, y se escriben los 16 ceros que :: ocultaba.

8.8.8.8.in-addr.arpaIPv4: cuatro etiquetas, invertidas
8.8.8.8.0.0.0.0…ip6.arpaIPv6: los 32 dígitos, invertidos
8.8.8.8.0.6.8.4…ip6.arpa:: sin expandir: otro nombre, y NXDOMAIN
8.8.8.8 se lee igual en ambos sentidos, así que la figura usa 208.67.222.222, cuyos octetos cambian de lugar a la vista. La ruta inversa de la herramienta dibuja el mismo intercambio para cada dirección IPv4 que consulta.

Cómo hacer una consulta de DNS reverso

Escriba una dirección arriba y haga clic en Consultar PTR. La herramienta desciende desde un servidor raíz hasta el propio servidor de nombres de la zona inversa y le pregunta directamente; luego compara las copias en caché de Google y Cloudflare. Desde una terminal, dig -x 8.8.8.8 en macOS y Linux, nslookup 8.8.8.8 en Windows o host 8.8.8.8 hacen lo mismo.

dig -x construye el nombre in-addr.arpa o ip6.arpa por usted; agregue @ y el servidor de nombres de la zona con +norecurse (dig -x 8.8.8.8 @ns1.google.com +norecurse) para leer la respuesta de la propia zona y su TTL completo en lugar de una caché. Para PowerShell, la forma documentada por Microsoft usa el nombre invertido: Resolve-DnsName -Name 8.8.8.8.in-addr.arpa -Type PTR.

dig -x 8.8.8.8 +noall +answer

dig construye 8.8.8.8.in-addr.arpa por sí mismo. El número antes de IN es el TTL que le queda a su resolutor.

Cómo leer la respuesta de digGoogle Public DNS, luego el propio servidor de Google · registrado el 23/10/2026
bash · zsh
$ dig -x 8.8.8.8 @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24160
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

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

;; SERVER: 8.8.8.8#53(8.8.8.8)

$ 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)
  1. Estado. NOERROR con una respuesta. NXDOMAIN significaría que no hay PTR configurado; SERVFAIL, una zona inversa rota.
  2. La consulta. dig construyó 8.8.8.8.in-addr.arpa a partir de la dirección y pidió su PTR.
  3. TTL. Quedan 14.003 segundos en la caché de Google. El propio servidor de la zona da el valor completo, 86.400: un día.
  4. El hostname. El valor del PTR. El punto final cierra el nombre.
  5. Quién respondió. 8.8.8.8, una caché. En la segunda respuesta, la marca aa señala al propio servidor de la zona.
Un PTR, consultado dos veces: Google Public DNS responde desde su caché, en cuenta regresiva; ns1.google.com, consultado con +norecurse, responde por la zona con el TTL completo.

Cómo leer el resultado

El encabezado dice en una frase cuál es el nombre inverso de la dirección y si ese nombre apunta de vuelta, con el TTL de la zona y el servidor que respondió. Las notas de color debajo dicen quién puede cambiar el nombre y qué tiene de inusual.

La vista PTR lista cada nombre con su TTL y su comprobación directa; Correo lo evalúa según las reglas de los receptores; Delegación muestra cada servidor consultado; Copias compara las respuestas en caché de Google y Cloudflare; Comandos da la misma consulta para una terminal. A la derecha, la ruta inversa dibuja todo el recorrido.

DNS reverso de 8.8.8.8: registro PTR dns.google desde el servidor de Google, su comprobación directa y la delegaciónDNS reverso de 8.8.8.8: registro PTR dns.google desde el servidor de Google, su comprobación directa y la delegaciónEl veredictoCuál es el nombre inverso de la dirección, si ese nombre apunta de vuelta y quién lo configuró, con el TTL y el servidor que respondió.Los registros PTRCada nombre que la zona tiene para la dirección, con su TTL y las direcciones que devuelve su consulta directa.Las vistasLas reglas de correo, la delegación paso a paso, las copias en caché con su cuenta regresiva y los comandos.La ruta inversaLa dirección invertida en su nombre DNS, luego la raíz, IANA, el registro y la zona que respondió.
Una consulta de DNS reverso de 8.8.8.8: el veredicto, el registro PTR con su TTL y su comprobación directa, y la ruta inversa desde la raíz hasta la zona de Google. Seleccione un número para ver qué muestra cada parte.

¿Qué es un registro PTR?

Un registro PTR (puntero), tipo DNS 12, contiene un nombre de host para la dirección bajo la que está: 8.8.8.8.in-addr.arpa. 86400 IN PTR dns.google. Es un dato simple: a diferencia de un CNAME, no remite a ninguna otra parte (RFC 1035 §3.3.12).

Lo escribe el titular de la dirección, no el dueño del nombre que contiene: la zona inversa de Google dice que 8.8.8.8 es dns.google, y solo el registro A de la zona dns.google dice lo contrario. Una dirección puede tener varios registros PTR (RFC 2181 §10.2): 208.67.222.222 tiene cuatro. El nombre debe ser un nombre de host real, nunca un alias.

Un PTR contiene un nombre y nada más: ni dueño, ni país, ni ciudad. Una ubicación mostrada junto a una consulta sale de palabras que el operador puso en el nombre, o de una base de datos aparte.

Un nombre, dos zonas8.8.8.8 y dns.google, en vivo, 23/10/2026
Zona directala del dominio: 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

Servida por ns1.zdns.google para el titular de dns.google

dos zonas, dos grupos de servidores
Zona inversala del bloque de direcciones: 8.8.8.0/24
8.8.8.8.in-addr.arpa. PTR dns.google.

Delegada por ARIN a Google, servida por ns1.google.com

8.8.8.8.in-addr.arpa.Nombre inverso86400TTL · 1 díaINClasePTRTipodns.google.Hostname
1 dirección, 4 nombres208.67.222.222: resolver1.opendns.com y tres más
1 dirección, 48 nombres17.253.144.10, la dirección de apple.com, cada uno con un TTL de 5 minutos
1 nombre, 4 direccionesdns.google: 8.8.8.8, 8.8.4.4 y dos IPv6
El PTR dice cómo se llama 8.8.8.8; los registros A dicen adónde apunta dns.google. Da la casualidad de que Google opera ambas zonas, en servidores distintos.

¿Qué es el DNS reverso confirmado en sentido directo (FCrDNS)?

El DNS reverso confirmado en sentido directo significa que el nombre del PTR resuelve de vuelta a la misma dirección: 8.8.8.8 → dns.google → 8.8.8.8. Los servidores de correo llaman a esta comprobación iprev (RFC 8601 §3): consultar los nombres PTR de la dirección, consultar los registros A o AAAA de cada nombre y aprobar cuando la dirección está entre ellos.

El segundo paso importa porque quien tiene una dirección puede escribir cualquier nombre en su PTR, incluido google.com. El nombre solo prueba algo cuando el dueño del dominio lo hace apuntar de vuelta. La herramienta comprueba cada nombre PTR, hasta diez, y dibuja el bucle a la derecha: verde cuando se cierra, ámbar cuando el nombre apunta a otra parte.

Con varios registros PTR, basta con que uno apunte de vuelta. Un nombre cuyo registro A también incluye otras direcciones sigue aprobando, siempre que esta dirección sea una de ellas.

Tres direcciones, tres buclesen vivo, 23/10/2026
Confirmado en sentido directoGoogle
8.8.8.8dns.google8.8.8.8: la misma dirección
Apunta de vueltadns.google también devuelve 8.8.4.4
Apunta a otra parteAdGuard
94.140.14.14dns.adguard-dns.com185.113.30.30: otra dirección
No confirmadosu registro A es 185.113.30.30
Sin PTRCloudflare
104.18.0.1NXDOMAIN: sin nombre
Nada que confirmarNXDOMAIN desde la zona de Cloudflare
El mismo bucle aparece en el borde derecho de cada resultado: verde cuando el nombre lleva de vuelta, ámbar cuando lleva a otra parte.

Verificar el DNS reverso de un servidor de correo: lo que exigen Gmail, Yahoo y Outlook.com

Los tres quieren un registro PTR en cada IP de envío. Gmail además exige que el nombre resuelva de vuelta a la misma IP, y Yahoo exige «un registro DNS directo e inverso válido», ambos para todos los remitentes desde febrero de 2024. La política de Outlook.com pide un DNS reverso válido y no dice nada del paso directo.

Un nombre genérico como ec2-3-80-0-1.compute-1.amazonaws.com no incumple ninguna regla: Yahoo solo recomienda un nombre significativo y no genérico que refleje su dominio. Outlook.com advierte que es posible que no se acepten conexiones desde espacio de IP dinámico, lo que afecta a los nombres de pool de un ISP, no al nombre estático por defecto de un servidor en la nube. La vista Correo muestra esos casos como advertencias y los requisitos como cumple o falla; una comprobación que no pudo terminar no es ninguna de las dos cosas.

Dos cosas nunca son fallos: tener varios registros PTR, que el RFC 2181 permite, y un PTR distinto del nombre HELO del servidor: el RFC 5321 §4.1.4 dice que un servidor no debe rechazar correo por eso. Gmail limita la tasa con 421 4.7.0 o 451 4.7.23 y bloquea con 550 5.7.25 cuando el PTR falta o no apunta de vuelta.

Obligatorio, recomendado, no indicadola propia página de cada receptor, revisada el 23/10/2026
ComprobaciónGmaildirectrices para remitentesYahoo Mailbuenas prácticas para remitentesOutlook.compolítica para postmasters
Tiene un registro PTRobligatorioobligatorioobligatorio
El nombre apunta de vueltaobligatorioobligatoriono lo indica
No es genérico ni dinámicono lo indicarecomiendapuede rechazar IP dinámicas
Cuatro remitentes reales, comprobados en vivo
mail-sor-f41.google.com209.85.220.41 · el propio servidor de salida de Gmailcumplecumplecumple
ec2-3-80-0-1.compute-1.amazonaws.com3.80.0.1 · el nombre por defecto de AWScumplecumpleadvertenciacumpleadvertencia
dns.adguard-dns.com94.140.14.14 · apunta a 185.113.30.30fallafallacumple
Sin PTR104.18.0.1 · NXDOMAINfallafallafalla

Las respuestas de Gmail

421 4.7.0 · 451 4.7.23Tasa limitada: sin PTR, o su entrada directa no coincide con la IP de envío
550 5.7.25Bloqueado: sin PTR, o la entrada directa no hace referencia a la IP de envío
550-5.7.1Por IPv6: el mensaje no cumple las directrices de envío por IPv6 sobre registros PTR y autenticación
Solo fallan los requisitos. La recomendación de Yahoo y la advertencia de Outlook.com sobre IP dinámicas aparecen como advertencias. Los códigos de Gmail provienen de su referencia de errores SMTP.

Quién controla el DNS reverso y cómo configurar un registro PTR

El titular del bloque de direcciones, nunca el dueño de un dominio. IANA delega la zona inversa de cada bloque a su Registro Regional de Internet, y el registro a la red titular de las direcciones, que opera la zona o la delega a su vez (RFC 3172). Ser dueño de example.com no le permite nombrar una dirección: debe hacerlo su hosting o su ISP.

Las nubes permiten que el cliente lo configure, cada una con su propia regla: AWS exige antes el registro A directo, Azure solo configura IPv4 y no desde su portal, DigitalOcean construye el PTR a partir del nombre del Droplet, Google Cloud le pide demostrar que el dominio es suyo. En una línea doméstica, normalmente solo un plan empresarial con IP estática obtiene un PTR personalizado: pregunte a su ISP. Los bloques menores que un /24 suelen delegarse con CNAME (RFC 2317), que la herramienta sigue adondequiera que apunten.

Un cambio llega a todos cuando las cachés descartan la respuesta antigua: decide el TTL del registro antiguo, o el tiempo durante el que se guarda en caché el «sin PTR» si no había ninguno (RFC 2308), no un plazo fijo de 24 a 48 horas. Vultr dice que sus propios cambios tardan de 6 a 12 horas.

Quién delega la zonarecorridos registrados, 23/10/2026
  1. in-addr.arpaAdministrado por IANA, servido por a hasta f.in-addr-servers.arpa
  2. 8.in-addr.arpa · 208.in-addr.arpaEl registro regional del bloque: ARIN para 8.0.0.0/8 y 208.0.0.0/8ARINRIPE NCCAPNICLACNICAFRINIC
  3. 8.8.8.in-addr.arpaEl titular de 8.8.8.0/24: Google escribe el PTR, en ns1 a ns4.google.com
17.in-addr.arpaUn /8 heredado, delegado por in-addr.arpa directamente a los servidores propios de Apple
129.2.0.192.in-addr.arpa CNAME 129.128/26.2.0.192.in-addr.arpaEl propio ejemplo del RFC 2317: para un bloque de menos de 256 direcciones, la zona padre contiene un CNAME hacia una zona que opera el titular del bloque. El nombre de la zona hija es solo una convención.
Cada paso es una remisión registrada el 23/10/2026, excepto el del RFC 2317, que es el propio ejemplo del RFC sobre un bloque de documentación.
Dónde configura el PTR cada proveedorla propia documentación de cada proveedor, revisada el 23/10/2026
ProveedorCómo configurarloLímites
AWSDocumentaciónSolo Elastic IP. Publique un registro A para su nombre que apunte a la Elastic IP y luego vaya a EC2 console › Elastic IPs › la dirección › Actions › Update reverse DNS, o use aws ec2 modify-address-attribute --allocation-id … --domain-name mail.example.com.El registro A directo debe existir antes. Mientras tenga un registro inverso, la Elastic IP queda bloqueada en su cuenta. En GovCloud (US), solo AWS Support puede configurarlo. Los límites del puerto 25 se levantan con una solicitud aparte.
Microsoft AzureDocumentaciónConfigure el ReverseFqdn de la IP pública: az network public-ip update --resource-group RG --name PublicIp --reverse-fqdn mail.example.com. (el nombre termina en punto), o Set-AzPublicIpAddress en PowerShell.Solo IPv4: las direcciones IPv6 propiedad de Azure no reciben PTR. No está en el portal de Azure. El nombre debe resolver a esa IP o pertenecer a su suscripción. Un PTR por dirección, ninguno por defecto, y ninguno para App Service ni Application Gateway.
Google CloudDocumentaciónVerifique primero el dominio (Search Console, o un registro A hacia la IP externa de la VM). Luego VM instances › la instancia › Edit › la interfaz de red principal › Public DNS PTR record, o gcloud compute instances update-access-config INSTANCE --public-ptr --public-ptr-domain mail.example.com.Solo la interfaz de red principal; sin PTR para balanceadores de carga ni Cloud NAT. Los PTR de IPv6 necesitan una subred de doble pila o solo IPv6 con IPv6 externa. El nombre por defecto es <reversed-ip>.bc.googleusercontent.com.
HetznerDocumentaciónCloud: Hetzner Console › el servidor (o Primary IP, Floating IP) › Networking › edite el rDNS junto a la IP; para IPv6, escriba solo la parte de la interfaz, como ::1. Dedicados: Robot › el servidor › IPs, el cuadro junto a cada IP.Hetzner opera la zona inversa. Solo considera válida una entrada rDNS que resuelve en ambos sentidos (FCrDNS). El valor por defecto es static.<reversed-ip>.clients.your-server.de.
DigitalOceanDocumentaciónNo hay editor de PTR: ponga al Droplet, o cámbiele, el nombre completo que quiera, como mail.example.com, y DigitalOcean crea el PTR a partir de él.El nombre debe ser un FQDN válido (my-droplet no da PTR). Solo la primera dirección IPv6 del Droplet recibe un PTR. Los PTR no se pueden crear a mano.
OVHcloudDocumentaciónApunte primero un registro A o AAAA a la IP. Luego Control Panel › Network › Public IP Addresses › el botón de acciones en la fila de la IP › Configure the reverse DNS (Public Cloud: su proyecto › Public IPs).OVHcloud comprueba al instante que el nombre apunte de vuelta a la misma IP, así que el registro ya debe estar activo. El nombre debe ir en minúsculas y terminar en punto.
VultrDocumentaciónProducts › Compute › la instancia › Settings › IPv4 o IPv6 › Public Network: haga clic en el nombre de la columna Reverse DNS, escriba el nombre completo y guarde.Vultr pide que el nombre resuelva de vuelta a la misma IP, y dice que los cambios tardan de 6 a 12 horas en verse. El valor por defecto es <ip>.vultrusercontent.com.
Akamai Cloud (Linode)DocumentaciónAgregue antes el registro A (y AAAA). Luego Cloud Manager › Linodes › el Linode › Network › el menú de puntos suspensivos de la IP › Edit RDNS, y escriba el nombre completo; un campo vacío restablece el valor por defecto.Falla con un error hasta que el registro A coincida con la IP. Rangos IPv6: Edit rDNS en el rango y luego en cada dirección. Valores por defecto: <ip-with-dashes>.ip.linodeusercontent.com, antes li<n>-<n>.members.linode.com.
Oracle CloudDocumentaciónCree primero el registro A o AAAA y luego abra una solicitud de servicio con la IP, el nombre que quiere en el PTR y el nombre del registro directo; Oracle lo comprueba y crea el PTR.Un PTR por IP, solo mediante solicitud a soporte; el registro directo debe resolver a esa IP.
Su proveedor de internetRFC 8501Pídaselo a su proveedor de internet: solo el proveedor, titular de la dirección, puede configurar su PTR. En la práctica, eso exige una IP estática en un plan empresarial.Las líneas domésticas conservan el nombre de pool del proveedor, y receptores como Comcast tratan esos nombres como dinámicos y rechazan el correo directo desde ellos.
Cuánto tarda un cambio: hasta que las cachés descartan el PTR antiguo (su TTL) o la respuesta «sin PTR» en caché (RFC 2308). TTL en vivo: 1 día para 8.8.8.8, 7 días para resolver1.opendns.com, 5 minutos para un nombre por defecto de EC2.

Por qué la mayoría de las direcciones IPv6 no tienen registro PTR

Porque son demasiadas para nombrarlas una por una. Un ISP puede llenar de antemano un PTR para cada dirección IPv4 que asigna, pero un solo /48 contiene 2⁸⁰ direcciones, y los dispositivos eligen las suyas, a menudo de corta duración (RFC 8501).

El RFC 8501 enumera las opciones del ISP: responder NXDOMAIN (sin PTR, lo más exacto), un PTR comodín para el prefijo de cada cliente, DNS dinámico, delegar la zona al cliente o generar al vuelo registros PTR y AAAA que coincidan. Solo el comodín rompe la comprobación directa; para usuarios domésticos un NXDOMAIN limpio está bien, un tiempo de espera agotado no.

Los servidores que envían correo por IPv6 sí necesitan un PTR confirmado en sentido directo: Gmail rechaza el correo IPv6 sin él con 550-5.7.1 Message does not meet IPv6 sending guidelines regarding PTR records and authentication. Azure no da ningún PTR a sus propias direcciones IPv6.

Un PTR por dirección, a escala IPv4 e IPv6RFC 8501
/24un bloque IPv428 = 256
/64una subred IPv6264 = 18.446.744.073.709.551.616
/48un sitio IPv6280 = 1.208.925.819.614.629.174.706.176

Longitud de la barra: bits de espacio de direcciones. Cada bit duplica la cantidad.

A 1000 registros PTR por segundo, un /48 seguiría sin completarse después de 38 billones de años (RFC 8501).

Las opciones del RFC 8501 para un ISP

NXDOMAINsin nombreNingún PTR: la respuesta más exacta, pero es probable que los servidores de correo rechacen a esos remitentes.
Un comodínno coincideUn nombre para todo un prefijo: su consulta directa no puede llevar de vuelta a cada dirección.
DNS dinámicocoincideCada host envía sus propias actualizaciones AAAA y PTR una vez fijada su dirección.
Delegar la zonadepende del clienteLos clientes que operan servidores DNS reciben la zona inversa de su prefijo; la mayoría de los hogares no pueden.
Al vuelocoincideEl servidor genera un PTR cuando se le pregunta, con el AAAA correspondiente.

Un servidor de correo sigue necesitando el suyo, confirmado en sentido directo:2001:4860:4860::8888 → dns.google → 2001:4860:4860::8888

Cómo verificar Googlebot y otros rastreadores

Consulte la dirección del visitante, compruebe que el nombre PTR termine en el dominio documentado del rastreador, y luego consulte ese nombre en sentido directo y confirme que devuelve la misma dirección: 66.249.66.1 → crawl-66-249-66-1.googlebot.com → 66.249.66.1. O coteje la dirección con la lista publicada por el operador (el método de Google).

Los dominios documentados: googlebot.com y google.com para Google, search.msn.com para Bingbot, applebot.apple.com para Applebot, yandex.ru, yandex.net y yandex.com para Yandex. DuckDuckBot solo publica una lista de direcciones.

googleusercontent.com por sí solo no prueba nada: toda VM de Google Compute Engine recibe por defecto un nombre bajo ese dominio, así que la herramienta lo cuenta como Google solo cuando la dirección está en las listas publicadas de Google. Un nombre con la terminación correcta que no apunta de vuelta es un falso, y la herramienta lo dice.

Dos consultas lo deciden66.249.66.1, en vivo, 23/10/2026
  1. Consulta inversaEl PTR de la dirección que visita.66.249.66.1 → crawl-66-249-66-1.googlebot.com
  2. ¿Dominio de Google?Termina en googlebot.com. Un nombre googleusercontent.com también necesitaría la dirección en las listas de Google.
  3. Consulta directacrawl-66-249-66-1.googlebot.com → 66.249.66.1La misma dirección: un Googlebot real.
Un falso: «Googlebot» en el user agent, desde 203.0.113.9Su consulta inversa responde NXDOMAIN, así que la comprobación se detiene en el paso 1. (Una dirección de documentación, RFC 5737.)
RastreadorEl nombre PTR termina enLista de IP publicada
GooglebotPTR y consulta directa, o la listagooglebot.comcommon-crawlers.json
Rastreadores de casos especiales de GooglePTR y consulta directa, o la listarate-limited-proxy-….google.comspecial-crawlers.json
Recuperadores activados por usuarios de GooglePTR y consulta directa, o la listagoogle-proxy-….google.com….gae.googleusercontent.comsolo con la listauser-triggered-fetchers-google.jsonuser-triggered-fetchers.jsonuser-triggered-agents.json
BingbotPTR y consulta directa, o la listasearch.msn.combingbot.json
ApplebotPTR y consulta directa, o la listaapplebot.apple.comapplebot.json
YandexBotPTR y consulta directayandex.ruyandex.netyandex.comninguna
DuckDuckBotSolo lista de IPningunaduckduckbot.json

En vivo hoy, cada uno apuntando de vuelta:crawl-66-249-66-1.googlebot.commsnbot-157-55-39-1.search.msn.com17-58-101-179.applebot.apple.com

Dominios y listas de la propia página de cada operador, revisada el 23/10/2026. Bing pide que su lista se actualice a diario.

Errores de DNS reverso explicados

NXDOMAIN significa que el nombre inverso no existe: nadie configuró un PTR para la dirección. NOERROR sin respuesta (NODATA) significa que el nombre existe pero no contiene ningún PTR. Los resolutores guardan cualquiera de las dos respuestas durante el tiempo de caché negativa de la zona, tomado de su SOA (RFC 2308), así que un PTR nuevo puede tardar ese tiempo en aparecer.

SERVFAIL significa que la zona está rota, casi siempre por una delegación coja (lame delegation): los servidores nombrados para la zona no la sirven, y todos los resolutores se rinden. REFUSED viene de un servidor que se niega a responder por la zona. Las direcciones privadas y de documentación nunca tienen un PTR público: la herramienta las responde desde el registro de IANA sin preguntar a nadie.

Cada respuesta, un ejemplo realen vivo, 23/10/2026
NOERROR8.8.8.8Hay un nombre configurado: el PTR vuelve con su TTL.PTR dns.google. · TTL 86400ns1.google.com · aa
NXDOMAIN104.18.0.1No existe ese nombre: la zona de Cloudflare no contiene ningún PTR para ella, y lo dice.SOA 18.104.in-addr.arpacruz.ns.cloudflare.com … 3600
NODATANOERROR, 0 answers2001:4860:4860::/48El nombre existe, sin PTR: el nombre del /48 de Google, que tiene nombres por debajo.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpaSOA ns1.google.com … 60
SERVFAIL203.0.113.50inventado, dirección de documentaciónDelegación coja: el registro nombra dos servidores que no sirven la zona, así que los resolutores se rinden.APNIC → ns1, ns2.example.net: lameEDE 22: No Reachable Authority
NXDOMAINAS112192.168.1.1Una dirección privada: el árbol público entrega 168.192.in-addr.arpa a los servidores AS112 de IANA, que responden NXDOMAIN.blackhole-1.iana.orgSOA prisoner.iana.org … 604800
Un «no» se guarda en caché durante el tiempo negativo del SOA (RFC 2308): 1 hora en Cloudflare, 60 segundos en Google, 7 días desde AS112.

DNS reverso: preguntas frecuentes

¿Qué es una consulta de DNS reverso?

Una consulta de DNS reverso encuentra el nombre de host que hay detrás de una dirección IP leyendo su registro PTR, lo contrario de una consulta normal, que convierte un nombre en una dirección. La dirección se invierte en un nombre especial, como 8.8.8.8.in-addr.arpa, que se consulta a los servidores de nombres que lo contienen. Para 8.8.8.8 la respuesta es dns.google. Esta herramienta además comprueba que el nombre apunte de vuelta.

¿Cómo verificar un registro PTR con dig o nslookup?

Ejecute dig -x 8.8.8.8 en macOS o Linux: dig invierte la dirección por sí mismo y el PTR aparece en la sección de respuesta. En Windows, nslookup 8.8.8.8 lo muestra en su línea Name:. Para saltarse todas las cachés, pregunte al propio servidor de nombres de la zona: dig -x 8.8.8.8 @ns1.google.com +norecurse. La vista Comandos de esta herramienta completa cada comando con la dirección consultada y el servidor de su zona.

¿Por qué mi dirección IP no tiene DNS reverso?

Porque nadie ha configurado un registro PTR para ella. Solo el titular del bloque de direcciones puede hacerlo, así que la respuesta es NXDOMAIN hasta que su proveedor de hosting o su ISP agregue uno. La mayoría de las conexiones domésticas y la mayoría de las direcciones IPv6 no tienen ninguno. Si la consulta muestra SERVFAIL, la propia zona inversa está rota, normalmente por una delegación coja que el proveedor debe corregir.

¿Cómo configurar o cambiar un registro PTR?

Con quien le dio la dirección. En AWS, publique primero el registro A directo y luego actualice el DNS reverso de la Elastic IP. Azure configura ReverseFqdn en la IP pública, DigitalOcean usa el nombre del Droplet, y Hetzner, OVHcloud, Vultr y Linode tienen un campo rDNS junto a cada dirección. Para una línea doméstica o de oficina, pregunte a su ISP: normalmente solo cumplen los requisitos los planes empresariales con IP estática.

¿Cuánto tarda un cambio en un registro PTR?

Tanto como las cachés conserven la respuesta antigua. Cada resolutor puede servir el PTR antiguo hasta que se agote su TTL, a menudo de una hora a un día, o la respuesta «sin PTR» en caché durante el tiempo de caché negativa de la zona. No hay un plazo fijo de 24 a 48 horas. La vista Copias muestra cuánto tiempo les queda a las copias de Google y Cloudflare.

¿Una dirección IP puede tener más de un registro PTR?

Sí. El DNS permite varios registros PTR para una dirección, y el RFC 2181 dice que no debe suponerse ningún límite: 208.67.222.222 tiene cuatro. Las comprobaciones de correo pasan cuando cualquiera de ellos apunta de vuelta a la dirección. Algunas herramientas solo leen el primer nombre, así que el que use para el correo debería estar confirmado en sentido directo. Un solo PTR es la configuración más simple, no un requisito.

¿Qué es FCrDNS?

Es el DNS reverso confirmado en sentido directo: el nombre del PTR, consultado en sentido directo, devuelve la misma dirección. El nombre inverso de 8.8.8.8 es dns.google, y dns.google resuelve a 8.8.8.8, así que cumple. Los servidores de correo llaman a esta comprobación iprev. Importa porque cualquiera que tenga una dirección puede escribir cualquier nombre en su PTR; solo la consulta directa muestra que el dueño del dominio está de acuerdo.

¿Necesito DNS reverso para enviar correo?

Sí, para cualquier servidor que envíe correo directamente. Gmail exige que cada IP de envío tenga un PTR que resuelva de vuelta a ella, Yahoo exige un DNS directo e inverso válido, y Outlook.com exige un DNS reverso válido. Sin él, el correo se limita o se rechaza, por ejemplo con el 550 5.7.25 de Gmail. Un nombre genérico del proveedor cumple las reglas, pero genera advertencias.

¿Qué significa «reverse DNS is not a valid hostname»?

Las pruebas de servidores de correo muestran ese mensaje cuando el nombre PTR de la IP de envío no funciona como nombre de host para esa IP: casi siempre no hay ningún PTR, o el nombre no tiene un registro A que apunte de vuelta a la misma dirección. Consulte aquí la IP de envío: la vista PTR muestra el nombre y su comprobación directa, y la vista Correo indica qué regla incumple.

¿El DNS reverso es lo mismo que una búsqueda de IP inversa?

No. El DNS reverso lee el nombre o los nombres que el titular de la dirección publicó en sus registros PTR. Una búsqueda de IP inversa (reverse IP lookup) intenta listar todos los sitios web alojados en una dirección, lo que requiere datos de DNS pasivo recopilados de muchos resolutores a lo largo del tiempo. Muchos sitios usan los dos términos sin precisión. Nuestra página IP a Hostname explica qué puede encontrar cada método.

¿El DNS reverso funciona con IPv6?

Sí. Las direcciones IPv6 se consultan bajo ip6.arpa con los 32 dígitos hexadecimales invertidos, así que 2001:4860:4860::8888 da un nombre de 32 etiquetas que esta herramienta construye y consulta por usted. La mayoría de las direcciones IPv6 no tienen PTR, porque los ISP no pueden llenar de antemano nombres para tantas direcciones, pero los servidores que envían correo por IPv6 necesitan uno.

¿Por qué una dirección IP privada no tiene PTR?

Las direcciones privadas como 192.168.1.1 o 10.0.0.1 se usan dentro de muchas redes a la vez, así que el DNS público no puede nombrarlas. Sus consultas inversas corresponden al resolutor de su propia red; las que se filtran terminan en los servidores AS112, que responden que no existe ese nombre. La herramienta explica cada rango de uso especial con su RFC sin preguntar a nadie.

Más herramientas de DNS, IP y correo