Deja de adivinar tu DNS: un recorrido para desarrolladores por MX, SPF, DKIM y DMARC

Por qué importan ahora los registros DNS de correo

La autenticación de correo solía ser opcional. En 2026, es un requisito básico. Gmail y Outlook exigen SPF y DKIM para remitentes masivos, y DMARC se está convirtiendo rápidamente en obligatorio para cualquier dominio que envíe correo transaccional. Si tus registros DNS están mal, tus correos no llegan: sin rebote, sin aviso, solo silencio.

El problema es que estos registros están documentados como RFC, no como herramientas. La mayoría de los desarrolladores copian y pegan ejemplos de la guía de configuración de su proveedor de correo y esperan que todo salga bien. Eso funciona hasta que necesitas depurar, añadir un segundo servicio de envío o explicar a un cliente por qué los correos de su formulario de contacto están llegando a spam.

Esta guía recorre MX, SPF, DKIM y DMARC en el orden en que realmente los encontrarás, con suficiente detalle para configurarlos correctamente y suficiente contexto para depurarlos cuando fallen.

Registros MX: a dónde va el correo entrante

Los registros MX indican a internet qué servidores de correo aceptan email para tu dominio. Son los más sencillos de los cuatro, pero también de los más fáciles de configurar mal.

Un registro MX tiene dos partes: un número de prioridad y un hostname. Los números de prioridad más bajos se prueban primero. Si usas Google Workspace, tus registros MX podrían verse así:

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

Los puntos finales importan: indican que el hostname está completamente cualificado. La mayoría de los proveedores DNS los añaden automáticamente, pero no todos.

Errores comunes: apuntar registros MX a un registro A en lugar de a un hostname, establecer todas las prioridades con el mismo número (lo que anula el sentido de tener respaldos) u olvidar eliminar registros MX antiguos al migrar de proveedor. Los registros MX obsoletos no se quedan ahí de forma inocua: pueden causar bucles de correo o dividir la entrega entre dos buzones.

Si estás ejecutando tu propio formulario de contacto y quieres evitar el spam sin depender de servicios de terceros, entender cómo los formularios se convierten en vectores de spam es un buen punto de partida.

SPF: qué servidores pueden enviar como tú

SPF (Sender Policy Framework) es un registro TXT que enumera las direcciones IP y los dominios autorizados para enviar correo en nombre de tu dominio. Es la primera comprobación que realizan la mayoría de los servidores de correo cuando reciben un mensaje que dice venir de ti.

Un registro SPF básico se ve así:

v=spf1 include:_spf.google.com ~all

Desglosado:

• v=spf1 declara la versión de SPF
• include:_spf.google.com delega en el registro SPF de Google
• ~all es un fallo suave: rechaza correo de fuentes no listadas, pero sin ser demasiado estricto

También puedes usar ip4: o ip6: para permitir direcciones específicas, o a y mx para hacer referencia a los registros A y MX de tu dominio. El mecanismo all al final controla qué ocurre con el correo de fuentes que no has listado: -all es un fallo duro (rechazar), ~all es un fallo suave (marcar como sospechoso), ?all es neutral (sin opinión) y +all es una barra libre (no lo uses).

SPF tiene dos aristas peligrosas. Primero, se rompe cuando se reenvía el correo, porque el servidor de reenvío no está en tu registro SPF. Segundo, los registros SPF tienen un límite de búsqueda de diez consultas DNS. Si incluyes demasiados servicios de terceros, superarás el límite y SPF dejará de funcionar. La solución es aplanar tu registro SPF: reemplazar las directivas include: por los rangos IP reales, pero esto requiere mantenimiento cuando los proveedores cambian sus IP.

DKIM: prueba criptográfica de identidad del remitente

DKIM (DomainKeys Identified Mail) añade una firma digital a tu correo saliente. El servidor receptor comprueba la firma contra una clave pública publicada en tu DNS. Si la firma es válida y el mensaje no ha sido manipulado, DKIM pasa.

A diferencia de SPF, DKIM sobrevive al reenvío, porque la firma viaja con el mensaje. También es más flexible: puedes tener varias claves DKIM para distintos servicios de envío, cada una con su propio selector.

Un registro DNS de DKIM se ve así:

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

El selector (default en este ejemplo) es arbitrario: lo elige tu proveedor de correo. El valor p= es la clave pública, normalmente una cadena larga codificada en base64. Tu proveedor de correo genera la clave privada y la usa para firmar los mensajes salientes.

La configuración de DKIM casi siempre la gestiona tu proveedor de correo. Tu trabajo es copiar el registro TXT que te da y pegarlo en tu DNS. La parte complicada es que algunos proveedores DNS no manejan bien los registros TXT largos: los truncan o requieren que dividas el valor en varias cadenas entrecomilladas.

Para verificar que DKIM funciona, envía un correo de prueba a una dirección de Gmail y revisa los encabezados. Busca dkim=pass en el encabezado Authentication-Results.

DMARC: aplicación de políticas e informes

DMARC (Domain-based Message Authentication, Reporting and Conformance) une SPF y DKIM e indica a los servidores receptores qué hacer cuando la autenticación falla. También habilita informes, para que puedas ver quién está enviando correo como tu dominio, tanto legítimo como suplantado.

Un registro DMARC mínimo se ve así:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none significa solo monitorizar: no rechazar ni poner en cuarentena los mensajes fallidos
• rua=mailto:[email protected] especifica dónde enviar los informes agregados

Cuando tengas confianza en que SPF y DKIM funcionan, puedes endurecer la política a p=quarantine (enviar los fallos a spam) o p=reject (rebotarlos directamente). También puedes establecer una política de subdominio con sp= y especificar con pct= el porcentaje de mensajes al que aplicar la política.

Los informes DMARC son archivos XML enviados a diario por los principales receptores. Son verbosos y difíciles de leer en bruto, pero te dicen exactamente qué mensajes pasaron o fallaron la autenticación y por qué. Si ves que se rechaza correo legítimo, los informes te mostrarán qué comprobación SPF o DKIM está fallando.

Un detalle importante: DMARC requiere alineación. Para SPF, el dominio del encabezado Return-Path debe coincidir con el dominio del encabezado From (o ser un subdominio). Para DKIM, el dominio d= de la firma DKIM debe coincidir con el dominio From. Si usas un servicio de envío de terceros, debe admitir rutas de retorno personalizadas o firma DKIM con tu dominio, no con el suyo.

Cómo auditar tu configuración actual

La mayoría de los problemas DNS son invisibles hasta que causan un fallo. Así puedes comprobar tus registros antes de que algo se rompa:

1. Consulta tus registros MX: dig MX example.com debería devolver los hostnames y prioridades de tus servidores de correo. Verifica que coincidan con la documentación de tu proveedor de correo.

1. Comprueba la sintaxis de SPF: dig TXT example.com y busca el registro v=spf1. Pásalo por un validador SPF para detectar errores de sintaxis e infracciones del límite de búsqueda.

1. Verifica las claves DKIM: Envía un correo de prueba e inspecciona el encabezado DKIM-Signature. Extrae el selector y el dominio, y luego consulta dig TXT selector._domainkey.example.com para confirmar que existe la clave pública.

1. Valida la política DMARC: dig TXT _dmarc.example.com debería devolver tu registro DMARC. Asegúrate de que rua= apunte a una dirección que realmente supervises.

1. Prueba de extremo a extremo: Usa un servicio como mail-tester.com o envía a una dirección de Gmail y revisa los encabezados completos. Busca spf=pass, dkim=pass y dmarc=pass en el encabezado Authentication-Results.

Si estás depurando por qué los correos no llegan, los encabezados son tu mejor herramienta. La mayoría de los clientes de correo permiten ver los encabezados sin procesar: en Gmail, abre el mensaje, haz clic en los tres puntos y selecciona 'Mostrar original'. El encabezado Authentication-Results te dirá exactamente qué comprobación falló y por qué.

Cuándo usar políticas de subdominio

Si envías correo desde varios subdominios —por ejemplo, newsletter.example.com para marketing y app.example.com para correo transaccional— puedes establecer políticas DMARC por subdominio. Esto te permite aplicar políticas estrictas en subdominios que controlas mientras mantienes una política más laxa en tu dominio principal.

La contrapartida es la complejidad. Cada subdominio necesita sus propios registros SPF, DKIM y DMARC, y necesitas llevar el control de qué servicios de envío están autorizados para qué subdominios. Para la mayoría de los equipos pequeños, un único dominio bien configurado es más sencillo e igual de seguro.

Qué hacer cuando la autenticación falla

El modo de fallo más común es añadir un nuevo servicio de envío sin actualizar DNS. Si empiezas a usar un nuevo proveedor de correo transaccional, necesitas añadir su include de SPF o rango IP, configurar la firma DKIM con tu dominio y verificar la alineación DMARC.

El segundo problema más común es el reenvío. Si los usuarios reenvían tu correo a otra dirección, SPF fallará porque el servidor de reenvío no está en tu registro SPF. DKIM suele sobrevivir al reenvío, así que mientras DKIM pase y tu política DMARC permita alineación parcial, el mensaje debería seguir entregándose. Si ves que se rechaza correo reenviado, revisa tu política DMARC: p=reject con alineación estricta romperá el reenvío.

El tercer problema es la propagación DNS. Los cambios en registros DNS pueden tardar horas en propagarse, y distintos servidores de correo almacenan en caché los registros durante tiempos diferentes. Si acabas de actualizar un registro y no funciona, espera unas horas y prueba de nuevo. Puedes comprobar la propagación con una herramienta como whatsmydns.net.

Puntos clave

• Los registros MX enrutan el correo entrante; SPF, DKIM y DMARC autentican el correo saliente. Resuelven problemas distintos y necesitas los cuatro.
• SPF se rompe con el reenvío y tiene un límite de diez búsquedas. DKIM sobrevive al reenvío, pero requiere configuración por servicio. DMARC los une y habilita informes.
• Empieza con p=none en DMARC, supervisa los informes durante unas semanas y luego endurece a p=quarantine o p=reject cuando tengas confianza en que el correo legítimo está pasando.
• Los errores DNS son silenciosos. Prueba tu configuración con correo real e inspecciona los encabezados para confirmar que SPF, DKIM y DMARC están pasando.
• Si la autenticación falla después de añadir un nuevo servicio de envío, revisa los includes de SPF, los selectores DKIM y la alineación DMARC. Los encabezados te dirán qué comprobación falló.

FAQ

Q: ¿Puedo tener varios registros SPF?

A: No. Varios registros SPF harán que todos se ignoren. Si necesitas autorizar varios servicios, usa directivas include: dentro de un único registro SPF, o lista rangos IP directamente. Vigila el límite de diez búsquedas.

Q: ¿Necesito DMARC si solo envío unos pocos correos al día?

A: Sí. DMARC no va de volumen: va de demostrar que eres quien dices ser. Incluso los dominios pequeños se benefician de DMARC porque evita la suplantación y te da visibilidad sobre problemas de entrega. Empieza con p=none y una dirección de informes.

Q: ¿Qué ocurre si DKIM y SPF fallan ambos, pero el correo parece legítimo?

A: Depende de tu política DMARC. Si p=none, el correo se entrega con una advertencia. Si p=quarantine, va a spam. Si p=reject, rebota. Por eso deberías supervisar los informes DMARC antes de aplicar una política estricta: puede que tengas remitentes legítimos que no conocías.

Q: ¿Puedo usar la misma clave DKIM para varios dominios?

A: Técnicamente sí, pero no lo hagas. Cada dominio debería tener su propio par de claves DKIM. Compartir claves dificulta la rotación y aumenta el radio de impacto si una clave privada se ve comprometida.

Q: ¿Con qué frecuencia debería rotar las claves DKIM?

A: No hay una regla universal, pero una vez al año es razonable para la mayoría de los dominios. Si sospechas que una clave ha sido comprometida, rótala de inmediato. Asegúrate de publicar la nueva clave pública en DNS antes de empezar a firmar con la nueva clave privada, y deja la clave antigua en DNS durante unos días después de la rotación para gestionar correo retrasado.

<!-- tool-cta:start -->

💡 Prueba esto: Inspecciona la política publicada de cualquier dominio con DMARC Lookup para ver cómo encajan en la práctica los registros MX, SPF y DMARC.

<!-- tool-cta:end -->

Fuentes

• RFC 7208: Sender Policy Framework (SPF) — La especificación SPF, incluidas las reglas de sintaxis y el límite de diez búsquedas.
• RFC 6376: DomainKeys Identified Mail (DKIM) — La especificación DKIM, que cubre la generación y verificación de firmas.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — La especificación DMARC, incluida la sintaxis de políticas y el formato de informes agregados.
• Google Workspace: Prevent spoofing and spam — Orientación práctica sobre la configuración de SPF, DKIM y DMARC para dominios de Google Workspace.