Inicio / Guías / DNSSEC para email: cuándo firmar tu zona y qué impacto tiene

DNSSEC para email: firmar la zona del dominio y proteger SPF, DKIM y DMARC

4,3 · 31 valoraciones
· Actualizado el 9 de agosto de 2025

Qué es DNSSEC, cómo firmar la zona de tu dominio y por qué importa para SPF, DKIM, DMARC y MTA-STS. Riesgos, implementación y verificación con dig.

DNSSEC para email: cuándo firmar tu zona y qué impacto tiene

Toda la pila de autenticación de email se apoya en DNS: SPF, DKIM, DMARC, MTA-STS, BIMI, TLS-RPT son registros TXT o CNAME que un receptor consulta antes de decidir si tu mensaje es legítimo. Si alguien envenena las respuestas DNS que ese receptor recibe, puede convencerle de que un mensaje fraudulento está autenticado. DNSSEC firma criptográficamente las respuestas DNS de tu zona para que el receptor pueda verificar que vienen realmente de ti y no de un atacante.

Qué hace DNSSEC

DNSSEC, DNS Security Extensions, añade firmas criptográficas a las respuestas DNS. Cada registro de tu zona (incluyendo los TXT que usan SPF, DKIM, DMARC) se firma con una clave privada. Los receptores que validen DNSSEC obtienen también la firma y, recorriendo una cadena de confianza desde la raíz, verifican que el contenido no se ha manipulado.

Sin DNSSEC, un atacante con capacidad de envenenar caché DNS (ataque clásico Kaminsky, BGP hijacking) puede:

  • Suplantar tu registro SPF para autorizar IPs ajenas.
  • Inyectar un selector DKIM falso con su clave pública.
  • Cambiar tu MX para interceptar correo entrante.
  • Modificar tu política DMARC a none.

Con DNSSEC, esas manipulaciones se detectan: la firma no coincide y el resolver descarta la respuesta.

La cadena de confianza

DNSSEC se basa en una jerarquía:

  1. La raíz DNS (.) tiene una clave pública conocida y publicada.
  2. La raíz firma la clave de cada TLD (.com, .es, .org).
  3. El TLD firma la clave de tu dominio (tudominio.com).
  4. Tu dominio firma sus propios registros.

El registro DS (Delegation Signer) en el TLD apunta a tu KSK (Key Signing Key) y cierra la cadena. Si falta el DS, los resolvers ven la zona como “insegura” y tratan los registros como no firmados.

Verificar la cadena:

dig DS tudominio.com +short

Si devuelve algo así:

12345 13 2 A1B2C3D4E5F6...

la cadena está cerrada. Si está vacío, la zona no está firmada o el DS no se ha publicado en el TLD.

Cómo firmar tu zona

El proceso depende de tu proveedor DNS. Hay dos modelos:

DNS gestionado (Cloudflare, Route 53, Google Cloud DNS, etc.)

La mayoría de proveedores ofrecen DNSSEC con un clic:

  1. Activas DNSSEC en el panel del proveedor.
  2. Te dan un registro DS para publicar en el registrador (donde compraste el dominio).
  3. Lo copias y pegas en el panel del registrador.
  4. Esperas propagación (1-24 horas).

Cloudflare, por ejemplo, muestra:

Algorithm: 13 (ECDSA P-256)
Digest Type: 2 (SHA-256)
Digest: A1B2C3...
Key Tag: 12345

Llevas eso al registrador y se publica en .com.

DNS autogestionado (BIND, Knot, NSD)

Aquí firmas tú la zona. En BIND moderno, con auto-dnssec maintain y dnssec-policy default, el servidor genera claves, firma y rota automáticamente. Necesitas:

  • KSK (Key Signing Key): firma DNSKEY.
  • ZSK (Zone Signing Key): firma el resto de registros.

Generación tipo:

dnssec-keygen -K /etc/bind/keys -a ECDSAP256SHA256 -f KSK tudominio.com
dnssec-keygen -K /etc/bind/keys -a ECDSAP256SHA256 tudominio.com

Y configuración en named.conf:

zone "tudominio.com" {
    type master;
    file "/etc/bind/db.tudominio.com";
    dnssec-policy default;
    inline-signing yes;
};

Tras firmar, exportas el DS y lo subes al registrador.

Verificar que DNSSEC funciona

Tres comandos básicos:

dig +dnssec TXT tudominio.com
dig DS tudominio.com
dig DNSKEY tudominio.com

La primera consulta debe devolver el TXT y, junto a él, un registro RRSIG con la firma. Si solo ves el TXT pero no RRSIG, la zona no está firmada.

Para validar la cadena completa, herramientas como delv:

delv +rtrace TXT tudominio.com

Te muestra paso a paso cómo el resolver valida raíz → TLD → tu zona. Cualquier rotura en la cadena se reporta como BOGUS.

Sitios como dnsviz.net ofrecen una visualización gráfica útil para detectar problemas de cadena, claves expiradas o algoritmos no soportados.

DNSSEC y email: dónde aporta

Protección de SPF, DKIM, DMARC

Si un atacante envenena el SPF de tu dominio para incluir su IP, podría enviar mensajes que pasen autenticación SPF en nombre tuyo. Con DNSSEC, la firma RRSIG no coincide con el TXT manipulado y el resolver del receptor descarta la respuesta.

Lo mismo aplica a DKIM, donde un selector falso podría aceptar firmas con clave del atacante, y a DMARC, cuya política se puede aflojar de reject a none si se manipula.

Requisito para DANE en SMTP

DANE (DNS-based Authentication of Named Entities) permite publicar en DNS los certificados TLS válidos para tu MX, evitando depender de la lista de CAs. DANE solo funciona sobre DNSSEC: sin firma, los resolvers no pueden confiar en los registros TLSA.

_25._tcp.mx.tudominio.com. IN TLSA 3 1 1 abc123...

Algunos receptores europeos (Posteo, Mailbox.org, Tutanota) usan DANE además de MTA-STS para forzar TLS hacia dominios firmados.

Refuerzo de MTA-STS

MTA-STS publica una política HTTPS y un TXT en DNS. DNSSEC firma ese TXT, evitando que un atacante lo elimine y haga downgrade a TLS oportunista vulnerable.

BIMI y certificados VMC

BIMI consulta un TXT con la URL del logo. DNSSEC dificulta suplantar ese registro y servir un logo falso.

Riesgos y cosas a considerar

Romper la zona si las claves caducan

Las claves DNSSEC tienen un periodo de validez. Si caducan y no rotas a tiempo, los resolvers que validan ven la zona como BOGUS y dejan de devolver registros. Resultado: tu correo no se entrega porque los receptores no pueden resolver tu MX, SPF o DKIM.

Mitigaciones:

  • Usar auto-dnssec maintain o el equivalente del proveedor.
  • Monitorizar fechas de expiración (Cloudflare avisa, otros no).
  • Tener alertas de validación DNSSEC desde un punto externo.

Aumento de tamaño de respuestas DNS

Las firmas RRSIG son grandes. Las respuestas pueden superar los 512 bytes y forzar fallback a TCP. La mayoría de resolvers modernos lo soportan, pero algunas redes corporativas con firewalls antiguos bloquean DNS sobre TCP. Si tu correo entrante depende de esos receptores, monitoriza.

Algoritmos obsoletos

RSA/SHA-1 (algoritmo 5) está obsoleto. Usa ECDSA P-256 (13) o RSA/SHA-256 (8). Algunos proveedores aún ofrecen 5 por defecto: cámbialo.

DS sin publicar

Error frecuente: activar DNSSEC en el proveedor pero no copiar el DS al registrador. Resultado: la zona está firmada pero los resolvers no validan porque la cadena no está cerrada. Equivalente a no tener DNSSEC.

Cambios de proveedor DNS

Migrar a otro proveedor con DNSSEC activo es delicado: hay que coordinar la transición de claves para no dejar la zona en estado BOGUS. Una opción segura es desactivar DNSSEC antes de migrar y reactivarlo después.

Errores frecuentes

Activar DNSSEC y no monitorizar

Sin alertas, una caducidad pasa desapercibida hasta que tu MX no resuelve. Configura monitorización externa que valide DNSSEC al menos cada hora.

Firmar solo SPF/DKIM y dejar otros registros sin firmar

DNSSEC firma toda la zona de golpe; no firmas registros individuales. Si has firmado, está todo firmado o nada.

Confundir DNSSEC con cifrado de consultas

DNSSEC firma el contenido pero no oculta las consultas. Para cifrar consultas DNS hacia tu autoritativo se usan DNS-over-TLS o DNS-over-HTTPS, que son ortogonales.

No probar tras activar

Tras activar DNSSEC, valida con dig +dnssec, delv y dnsviz.net. Una validación que da BOGUS significa que algo está roto y los resolvers que validan ya no resuelven tu zona.

Cuándo activar DNSSEC

  • Recomendado: dominios de empresas con riesgo elevado (banca, salud, gobierno), dominios principales que envían correo crítico, dominios con DANE.
  • Útil: dominios de marketing con BIMI y MTA-STS.
  • Innecesario: dominios de prueba, subdominios efímeros, dominios donde el proveedor DNS no lo soporta de forma estable.

Si activas, prepara monitorización antes. DNSSEC mal mantenido es peor que no tenerlo: rompe la zona y bloquea todos los registros, incluyendo SPF, DKIM y MX.

Recursos relacionados

Si quieres profundizar, prueba estas herramientas gratuitas: Domain Health, mail tester, validador SPF y validador DMARC.

¿Necesitas que alguien lleve tu canal de email entero? Abalola Mail es la agencia de email marketing en España de Abalola para ecommerce: estrategia, producción y operación del stack sobre Klaviyo, Mailchimp o Brevo.

Preguntas frecuentes

¿DNSSEC es obligatorio para email?
No es obligatorio pero protege la integridad de SPF, DKIM y DMARC frente a envenenamiento de DNS. Para BIMI y para casos donde la confianza en DNS es crítica, conviene activarlo.
¿DNSSEC mejora directamente la entregabilidad?
No de forma directa en filtros de Gmail o Yahoo. Sí de forma indirecta porque protege los TXT de autenticación que sostienen tu reputación frente a manipulación.
¿Cuál es el riesgo principal de DNSSEC mal configurado?
Un fallo de firma o expiración de claves deja la zona inválida y los resolvers compatibles dejan de resolver el dominio. Es un riesgo operativo real si no se monitoriza la rotación de claves.
¿Cómo verifico que DNSSEC funciona en mi dominio?
Con dig +dnssec tudominio.com debe devolver registros RRSIG. También sirve un validador online tipo DNSViz o Verisign DNSSEC Analyzer para detectar cadenas rotas.
¿DNSSEC requiere DANE para email?
No. DNSSEC se puede activar sin DANE. DANE (TLSA) es una capa adicional que requiere DNSSEC y publica el certificado del MX, pero la mayoría de dominios usan MTA-STS en su lugar.
¿DANE es alternativa a MTA-STS?
DANE y MTA-STS son complementarios. MTA-STS funciona sin DNSSEC; DANE lo requiere. Algunos servidores soportan ambos: prueba MTA-STS primero y DANE después si tu proveedor DNS lo permite.
¿Cómo afecta a la latencia?
Añade una consulta extra (DNSKEY) y validación criptográfica. En resolvers cacheados es despreciable. En consultas frías, 10-50 ms más.