La migración parecía sencilla. Mover DNS a un nuevo proveedor, actualizar los servidores de nombres y listo. Excepto que alguien olvidó recrear el registro SPF. Durante tres días, cada correo de la empresa falló la autenticación. La entregabilidad se desplomó. Las quejas de clientes se acumularon. Todo por un registro TXT que faltaba.
El email y DNS están profundamente entrelazados. Los registros MX le dicen al mundo dónde entregar tu correo. Los registros TXT manejan la autenticación. Los registros CNAME habilitan el seguimiento y los dominios personalizados. Si te falta cualquiera de ellos, el email se rompe de formas que no siempre son obvias.
Esta lista de verificación cubre cada registro DNS que afecta al email, desde los esenciales hasta los opcionales pero recomendados.
Registros esenciales
MX records. Los registros Mail Exchanger indican a los servidores remitentes dónde entregar el correo de tu dominio. Sin registros MX, no puedes recibir correo. La mayoría de configuraciones tienen múltiples registros MX con diferentes prioridades para redundancia.
example.com. MX 10 mail1.example.com.
example.com. MX 20 mail2.example.com.
El número es la prioridad—los números más bajos se intentan primero. Si mail1 no está disponible, los remitentes intentan con mail2.
SPF record (TXT). Sender Policy Framework declara qué servidores pueden enviar correo como tu dominio. Es un registro TXT que lista direcciones IP autorizadas y includes para servicios de terceros.
example.com. TXT "v=spf1 include:_spf.google.com include:amazonses.com -all"
El -all al final significa "rechazar todo lo no listado". Usa ~all (soft fail) solo durante la configuración inicial.
DKIM records (TXT or CNAME). DomainKeys Identified Mail usa criptografía de clave pública para firmar correos. La clave pública se publica en DNS para que los receptores puedan verificar las firmas. El nombre del registro incluye un selector que identifica qué clave usar.
selector._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."
Algunos proveedores usan registros CNAME que apuntan a sus claves alojadas en lugar de publicar la clave directamente.
DMARC record (TXT). Domain-based Message Authentication, Reporting, and Conformance vincula SPF y DKIM y les dice a los receptores qué hacer con los fallos.
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
El valor de p= es tu política: none (solo monitorizar), quarantine (enviar a spam) o reject (bloquear por completo).
Registros recomendados
Reverse DNS (PTR). Los registros PTR asocian direcciones IP a nombres de host. Muchos servidores receptores verifican que tu IP emisora tenga un registro PTR y que resuelva de vuelta a la IP. Sin un reverse DNS adecuado, tus correos pueden ser rechazados o marcados como spam.
Los registros PTR los configura quien controla la dirección IP—normalmente tu proveedor de hosting o ISP, no en el DNS de tu dominio.
MTA-STS records. Mail Transfer Agent Strict Transport Security les dice a los servidores remitentes que exijan TLS al entregar a tu dominio. Evita ataques de degradación donde atacantes fuerzan la entrega sin cifrar.
_mta-sts.example.com. TXT "v=STSv1; id=20240115"
También necesitas alojar un archivo de política en https://mta-sts.example.com/.well-known/mta-sts.txt.
TLS-RPT record (TXT). TLS Reporting indica a los remitentes dónde enviar informes sobre fallos de conexión TLS. Te ayuda a identificar problemas de entrega causados por incidencias de TLS.
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:[email protected]"
BIMI record (TXT). Brand Indicators for Message Identification muestra tu logotipo en clientes de correo compatibles. Requiere la aplicación de DMARC y, para compatibilidad plena, un Verified Mark Certificate.
default._bimi.example.com. TXT "v=BIMI1; l=https://example.com/logo.svg"
Registros específicos de servicios
Verificación del proveedor de email. La mayoría de proveedores de email te piden añadir registros TXT o CNAME para verificar la propiedad del dominio. Google Workspace, Microsoft 365 y otros tienen cada uno sus propios registros de verificación.
CNAMEs para dominios de seguimiento. Los servicios de email que rastrean aperturas y clics suelen usar registros CNAME para habilitar dominios de seguimiento personalizados. En lugar de que los enlaces apunten a track.emailprovider.com, apuntan a click.yourdomain.com.
click.example.com. CNAME track.emailprovider.com.
Return-path personalizado. Algunos proveedores usan registros CNAME para dominios return-path personalizados, lo que ayuda con la alineación SPF y la entregabilidad.
Registros de seguridad
DANE records (TLSA). DNS-based Authentication of Named Entities proporciona pinning de certificados para email. Es más complejo que MTA-STS, pero ofrece garantías de seguridad más sólidas. Requiere DNSSEC.
_25._tcp.mail.example.com. TLSA 3 1 1 abc123...
CAA records. Certificate Authority Authorization especifica qué CAs pueden emitir certificados para tu dominio. Aunque no es específico de email, protege los certificados que usan tus servidores de correo.
example.com. CAA 0 issue "letsencrypt.org"
Lista de verificación
Después de configurar o modificar registros DNS, verifica que todo funcione:
Los registros MX resuelven. Usa dig MX example.com o MXToolbox para verificar que existan registros MX y que apunten a servidores válidos y accesibles.
SPF es válido. Usa un validador de SPF para verificar la sintaxis, el recuento de consultas y que todos tus remitentes estén incluidos. Envía un correo de prueba y revisa la cabecera Authentication-Results.
Las claves DKIM están publicadas. Usa un verificador de DKIM con tu selector para confirmar que la clave pública sea accesible. Envía un correo de prueba y verifica que la firma DKIM valide.
DMARC está publicado. Usa un verificador de DMARC para confirmar que el registro existe y es sintácticamente válido. Verifica que estés recibiendo informes agregados en la dirección especificada.
Reverse DNS está configurado. Usa dig -x [your-ip] para comprobar registros PTR. Verifica que el nombre de host devuelto resuelva de vuelta a tu IP.
TLS funciona. Usa CheckTLS o similar para verificar que tu servidor de correo acepte conexiones TLS y tenga un certificado válido.
Errores comunes
TTL demasiado alto durante cambios. Si vas a hacer cambios en DNS, baja primero el TTL (a 300 segundos o menos), espera a que caduque el TTL anterior, haz los cambios y luego vuelve a subirlo. Un TTL alto durante los cambios implica largos retrasos de propagación.
Olvidar los puntos finales. En los archivos de zona, los nombres de host deben terminar con un punto (p. ej., mail.example.com.). Sin el punto, se añade el nombre de la zona, creando registros inválidos.
Registros en conflicto. Solo puedes tener un registro SPF por dominio. Múltiples registros SPF provocan fallos. Si necesitas autorizar múltiples servicios, combínalos en un solo registro.
Registros obsoletos tras migraciones. Cuando cambias de proveedor de correo, hay que eliminar los registros antiguos (MX, includes de SPF, claves DKIM). Los registros obsoletos provocan fallos de autenticación o dirigen el correo a servidores retirados.
Frequently asked questions
¿Cuánto tardan en propagarse los cambios de DNS?
Depende del TTL (Time To Live). Los registros se almacenan en caché durante la duración de su TTL. Si el TTL es 3600 (1 hora), los cambios pueden tardar hasta una hora en propagarse globalmente. Baja el TTL antes de hacer cambios para acelerar la propagación.
¿Necesito todos estos registros?
MX, SPF, DKIM y DMARC son esenciales para el email moderno. MTA-STS y BIMI son recomendados pero no obligatorios. DANE es opcional y requiere DNSSEC. Los registros específicos de servicio dependen de los servicios que uses.
¿Qué pasa si estropeo un registro DNS?
Depende del registro. MX incorrectos significan que no podrás recibir correo. SPF/DKIM incorrectos implican fallos de autenticación y posible filtrado como spam. Prueba siempre los cambios en un entorno de pruebas o con un TTL bajo para poder revertir rápidamente.
¿Debo usar el DNS de mi registrador o un proveedor de DNS dedicado?
Los proveedores de DNS dedicados (Cloudflare, Route 53, etc.) suelen ofrecer mejor rendimiento, más funciones y mejores interfaces de gestión. Para infraestructura de email crítica, la fiabilidad y las prestaciones de un DNS dedicado valen la complejidad.