Red
Guía de referencia de tipos de registros DNS
Referencia de los tipos de registros DNS necesarios para gestionar correo y sitios web —A, MX, TXT, SPF, DKIM, DMARC y más— con su propósito, ejemplos de sintaxis y puntos a tener en cuenta.
Tipos de registros DNS
| Tipo | Propósito | Ejemplo | Nota |
|---|---|---|---|
| Registro A | El tipo de registro más básico: asocia un nombre de dominio a una dirección IPv4, indicando dónde reside realmente un servidor web o de correo. | example.com. 3600 IN A 192.0.2.1 |
Un TTL demasiado corto (3600 segundos = 1 hora en este ejemplo) aumenta las consultas al servidor autoritativo y la carga; uno demasiado largo retrasa la propagación cuando cambia la IP. |
| Registro AAAA | Asocia un nombre de dominio a una dirección IPv6; es, esencialmente, la versión IPv6 del registro A. | example.com. 3600 IN AAAA 2001:db8::1 |
Mantener también un registro A permite que redes sin soporte IPv6 puedan usar IPv4 como respaldo (funcionamiento dual-stack). |
| Registro CNAME | Trata un nombre de host como alias de otro nombre de host canónico, por ejemplo apuntando www.example.com hacia example.com. | www.example.com. 3600 IN CNAME example.com. |
Un nombre de host con CNAME no puede tener otros registros (como MX o TXT) coexistiendo (restricción de la RFC 1034). Tampoco se puede definir un CNAME en la raíz de la zona (@). |
| Registro MX | Especifica qué servidor de correo debe recibir los mensajes dirigidos a un dominio. Se pueden indicar varios servidores con un valor de prioridad. | example.com. 3600 IN MX 10 mail.example.com. |
Un valor de prioridad más bajo indica mayor prioridad. Es habitual listar varios servidores con distintas prioridades para redundancia. El destino de un MX debe ser un nombre de host con registro A, no un CNAME. |
| Registro TXT | Registro genérico que añade texto arbitrario a un dominio. Se usa para SPF, DKIM y DMARC, así como para verificar la propiedad de un dominio, entre otros usos. | example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all" |
Un dominio puede tener varios registros TXT, pero colocar más de uno con el mismo propósito (por ejemplo, SPF) provoca errores de interpretación; deben consolidarse en un único registro. |
| Registro SPF (un tipo de registro TXT) | Enumera los servidores (direcciones IP) autorizados a enviar correo en nombre de un dominio, proporcionando autenticación del remitente para prevenir la suplantación. Se configura como registro TXT. | example.com. 3600 IN TXT "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all" |
Solo un registro SPF es válido por dominio. Vigile las cadenas de "include", ya que superar el límite de 10 consultas DNS provoca un error permanente. El tipo de registro dedicado (RRTYPE 99) quedó obsoleto en 2014, así que hoy el SPF se expresa únicamente mediante registros TXT. |
| Registro DKIM (un tipo de registro TXT) | Añade una firma digital al correo saliente para que el destinatario pueda verificar que no fue alterado en tránsito y que proviene de un remitente legítimo. La clave pública se publica como registro TXT. | selector._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..." |
El selector (la parte inicial del nombre de host) varía según el servicio de envío. La clave privada permanece en el servidor de envío; en el DNS solo se publica la clave pública. |
| Registro DMARC (un tipo de registro TXT) | Declara, a partir de los resultados de SPF y DKIM, cómo debe tratar el destinatario el correo que falla la autenticación (entregarlo, ponerlo en cuarentena o rechazarlo), y ofrece un canal para recibir informes agregados. | _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]" |
Empezar con p=none solo para monitorizar, y endurecer gradualmente hacia quarantine y reject una vez confirmado que no hay problemas, es la forma segura de implementarlo. |
| Registro NS | Indica cuáles son los servidores DNS autoritativos de un dominio (zona); es el punto de partida para resolver cualquier nombre dentro de él. | example.com. 86400 IN NS ns1.example-dns.com. |
Si los servidores de nombres registrados en el registrador no coinciden con los registros NS dentro de la zona, la resolución de nombres se vuelve inestable (delegación defectuosa o "lame delegation"). |
| Registro SOA | Contiene la información administrativa de una zona —servidor primario, correo del administrador, número de serie, intervalos de reintento, etc.—. Cada zona debe tener exactamente uno. | example.com. 86400 IN SOA ns1.example-dns.com. admin.example.com. (2026071200 3600 900 604800 86400) |
Cada vez que actualice el archivo de zona debe incrementar el número de serie; de lo contrario, los servidores secundarios nunca recibirán el cambio mediante transferencia de zona. |
| Registro CAA | Restringe qué autoridades de certificación (CA) pueden emitir certificados para un dominio, evitando que CA no deseadas emitan certificados fraudulentos. | example.com. 3600 IN CAA 0 issue "letsencrypt.org" |
Si un dominio no tiene ningún registro CAA, se considera que cualquier CA está autorizada a emitir certificados. Los certificados comodín requieren una etiqueta issuewild independiente. |
| Registro PTR | Resuelve una dirección IP hacia un nombre de host, en sentido inverso al registro A. Se configura en una zona inversa (in-addr.arpa / ip6.arpa). | 1.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com. |
Muchos servidores de correo marcan como spam o rechazan mensajes de remitentes sin PTR inverso o cuyo PTR no coincide con el registro A, por lo que es prácticamente obligatorio para los servidores de envío. |
Consejos
- Si tiene dudas sobre SPF, DKIM o DMARC, diagnostique primero sus registros actuales con la herramienta "Verificador de registros SPF/DKIM/DMARC" y luego compárelos con los ejemplos de sintaxis de esta página.
- Un TTL de alrededor de una hora (3600 segundos) es un valor predeterminado seguro para registros ordinarios; reducirlo a unos 300 segundos justo antes de una migración de DNS acelera la propagación del cambio, y luego puede volver a subirlo.
- Los valores de registros TXT de más de 255 caracteres pueden dividirse automáticamente en varias cadenas, así que compruebe que las comillas coincidan correctamente al copiar y pegar.
- Si también quiere comprobar el formato de una dirección de correo en sí, la herramienta "Validador de formato de dirección de correo" cubre ese aspecto.
- Al implementar un nuevo servicio de envío de correo, comience DMARC con p=none, revise los informes durante una o dos semanas para confirmar que no hay problemas y luego cambie a una política de aplicación estricta: es el camino más seguro.
Preguntas frecuentes
SPF verifica la legitimidad de la dirección IP de origen, es decir, "desde qué servidor se envió"; DKIM verifica la integridad del mensaje mediante una firma digital, es decir, "si el contenido fue alterado". Solo cuando ambos se superan, la autenticación del remitente ofrece una protección significativa.
No es un requisito legal, pero los principales proveedores de correo, como Gmail y Yahoo Mail, exigen de hecho DMARC a los remitentes masivos, y no tenerlo aumenta considerablemente el riesgo de ser marcado como spam o rechazado.
Las causas más habituales son que el destino del MX apunte a un CNAME en lugar de a un nombre de host con registro A, que el valor de prioridad esté mal configurado, o que el propio servidor de correo no esté configurado para aceptar mensajes de ese dominio.
Use un registro A/AAAA cuando la dirección IP sea fija y quiera configurarla en la raíz del dominio (@); use CNAME cuando quiera que el nombre de host actúe como alias de otro host, por ejemplo apuntando a un endpoint de CDN.
Para el funcionamiento normal, alrededor de una hora (3600 segundos) es habitual. Reducirlo a unos 300 segundos justo antes de una migración de servidor o un cambio de DNS hace que la propagación sea más rápida una vez realizado el cambio.
A propósito — la historia detrás de los registros DNS y la autenticación de correo
El DNS es conocido sobre todo por asociar nombres de dominio a direcciones IP, pero en realidad existen muchos más tipos de registros además de A y AAAA, cada uno con un papel distinto. En el mundo de la entrega de correo, en particular, varios registros —MX, TXT (que transporta SPF/DKIM/DMARC) y PTR— solo dan como resultado un correo "legítimo y no suplantado" cuando funcionan todos juntos; si falta uno solo, aumenta el riesgo de acabar en la carpeta de spam o de ser rechazado directamente.
Repasando la historia de la autenticación del remitente, SPF se propuso a principios de la década de 2000 como medida contra el spam, y DKIM, orientado a detectar la manipulación del contenido del mensaje, se estandarizó hacia 2007. Sin embargo, ninguno de los dos, por sí solo, definía qué debía hacer el destinatario cuando fallaba la autenticación: DMARC llegó en 2012 para cubrir ese vacío. DMARC evalúa conjuntamente los resultados de SPF y DKIM y aporta tanto una política de aplicación para los fallos como un mecanismo de informes, funcionando como una especie de centro de mando de la autenticación.
Algunos registros DNS han cambiado de forma con el tiempo por razones históricas. Un tipo de registro dedicado a SPF (RRTYPE 99) se definió en una RFC de 2006, pero causó confusión en su implementación y fue formalmente desaprobado por la RFC 7208 en 2014; hoy el SPF se expresa exclusivamente mediante registros TXT. Del mismo modo, DKIM y DMARC tampoco tienen un tipo de registro propio: ambos se implementan por completo dentro de registros TXT usando una sintaxis específica (cadenas que comienzan con v=DKIM1 o v=DMARC1), lo que dice mucho sobre lo extensible que es realmente el DNS.