¿Por qué su correo falla DMARC cuando SPF pasa?

Encontraron un correo en la carpeta de spam y abrieron su código fuente para ver qué salió mal. Una línea dice spf=pass. La línea justo debajo dice dmarc=fail. Mismo mensaje. Dos respuestas opuestas.

Ambas respuestas son ciertas, y sus registros probablemente están bien. SPF y DMARC hacen preguntas diferentes. SPF pregunta: ¿este equipo tenía permiso para enviar este correo? DMARC pregunta: ¿el remitente que pasó la prueba lleva su dominio, el de la línea From que la gente ve? Con la mayoría de las herramientas de envío, no lo lleva. Ese desajuste es todo el problema, y tiene nombre: alineación. La causa más común es una plataforma de envío que manda correo desde su propio dominio. La verificación más rápida son dos líneas en los encabezados del mensaje, y este artículo las recorre.

Requisitos para pasar de DMARC frente a los de SPF en el correo

Todo correo tiene dos direcciones de remitente. La línea From es la que la gente ve. La otra se esconde dentro del mensaje, y los servidores de correo la usan para pasar el mensaje adelante. Esa dirección oculta es el sobre. Piensen en una carta real: el nombre en la parte superior de la hoja es la línea From, y la dirección del exterior es el sobre.

SPF funciona como una lista de invitados. Su registro DNS enumera los equipos autorizados a enviar correo para un dominio. El receptor coteja el equipo que envía contra la lista que pertenece al dominio del sobre. Estar en la lista significa spf=pass. SPF nunca mira la línea From.

DMARC funciona como un control de identidad. Pregunta: ¿el dominio que pasó SPF, o el dominio que firmó el mensaje con DKIM, coincide con el dominio de la línea From? Esa coincidencia se llama alineación. Una sola coincidencia, de cualquiera de las dos rutas, basta para pasar.

Estos son los encabezados de un mensaje que falla en ambas rutas, recortados a las líneas que importan:

From: Ana <ana@example.com>
Return-Path: <bounces+7c2f-jane=example.net@mailpilot.example>
DKIM-Signature: v=1; a=rsa-sha256; d=mailpilot.example; s=s1; ...
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounces+7c2f@mailpilot.example
         designates 198.51.100.7 as permitted sender)
       dkim=pass header.i=@mailpilot.example
       dmarc=fail (p=NONE dis=NONE) header.from=example.com

Léanlo como lo leyó el receptor. SPF pasó, para mailpilot.example. DKIM también pasó, para mailpilot.example. La línea From dice example.com. Ninguna verificación superada nombra ese dominio. Así que no queda probado que el mensaje venga del dominio que dice tener.

Si SPF en sí está fallando, con softfail, permerror o un límite de lookups, esa es otra reparación, cubierta en el artículo sobre fallos de SPF.

Hagan esto: antes de tocar ningún DNS, abran un mensaje que falle y encuentren el dominio dentro de su línea spf=pass. Si ese dominio no es suyo, es un problema de alineación, no de registros.

Las tres causas por orden de frecuencia

Causa uno: su plataforma envía desde su propio dominio de rebote

La respuesta más común por mucho. Todo ESP, herramienta de facturación, helpdesk y plataforma de cursos envía a través de su propio equipo al principio. Con esos valores predeterminados, el sobre y la firma DKIM llevan ambos el dominio de la herramienta, no el suyo. SPF revisa el dominio de la herramienta y pasa. DMARC revisa su dominio de From y falla.

Gmail a veces muestra este mismo problema en plena bandeja de entrada: una pequeña línea gris bajo su nombre que dice via mailpilot.example. Misma causa raíz, dos síntomas. El artículo sobre el correo con “via” cubre el lado de la visualización.

La pista: el dominio que va después de domain of en la línea spf=pass pertenece a su plataforma, y ustedes nunca publicaron registros DNS para él.

Qué hacer: activen el custom sending domain de la plataforma, que se muestra en la sección de la corrección más abajo.

Causa dos: DKIM no puede rescatar el correo

Cuando SPF no se alinea, DKIM es la única ruta que queda para pasar DMARC. Tres cosas rompen esa ruta. La firma falta por completo, así que dkim=none. La firma existe pero falla, dkim=fail, normalmente porque se eliminó un registro DNS o la plataforma cambió su clave de firma. O la firma pasa, pero para el dominio de la plataforma, como la línea d=mailpilot.example de arriba. Pasar para el dominio de otro no les sirve a ustedes.

Esta causa suele llegar despacio. Los registros estuvieron bien durante un año. Luego una migración de DNS eliminó un registro, la última ruta que funcionaba se apagó, y DMARC empezó a fallar. Ningún error en ninguna parte.

La pista: dkim=none, dkim=fail, o un dkim=pass válido cuyo dominio en header.i= no es su dominio de From.

Qué hacer: vuelvan a publicar o completen los registros DKIM de su dominio en la plataforma. La guía de configuración de DKIM tiene los pasos.

Causa tres: un servicio de reenvío o una lista de correo lo volvió a enviar

A veces su configuración está bien y el último salto la rompió. Un servicio de reenvío o una lista de correo toma su mensaje y lo vuelve a enviar bajo su propio sobre. SPF entonces revisa el dominio del reenviador, y puede pasar para él. Las listas de correo también añaden un pie al cuerpo y cambian la línea de asunto, lo que rompe la firma DKIM, porque la firma cubre las palabras exactas del mensaje. La copia reenviada falla en DMARC. La copia en su propia carpeta de enviados pasó.

La pista: los fallos aparecen en un destinatario, una empresa o una lista, mientras que todos los demás reciben su correo sin problema. El dominio de spf=pass nombra al reenviador, muchas veces el propio empleador del destinatario.

Qué hacer: comprueben que sus propios encabezados se alinean, y mantengan viva su firma DKIM, porque esa es la ruta que el reenvío rompe. El salto del reenviador le toca arreglarlo a él.

Alineación de SPF frente a DKIM en el correo: cuál falló

El bloque Authentication-Results nombra los tres dominios que necesita. Comparen primero smtp.mailfrom con header.from. Cuando el dominio del mailfrom coincide con su dominio de From, SPF se alineó, y un dmarc=fail justo al lado apunta al lado de DKIM, o al modo strict, más abajo.

Una configuración cambia lo que cuenta como coincidencia. Por defecto, ambas rutas usan la alineación relaxed: los dos dominios solo necesitan coincidir en su parte principal. em892.example.com coincide con example.com. Un registro puede exigir coincidencias exactas en su lugar:

v=DMARC1; p=quarantine; aspf=s; adkim=s; rua=mailto:dmarc@example.com

Con aspf=s, un correo desde billing.example.com con From: ana@example.com pasa SPF y aun así falla la alineación. El modo strict es raro, y la mayoría de quienes lo tienen lo heredaron. Si sus informes muestran fallos de correo que se ve bien, revisen el registro antes de culpar al correo.

Hagan esto: lean primero smtp.mailfrom y header.from. Definen la alineación de SPF de un vistazo. Después lean header.i=, o el d= de la firma, para el lado de DKIM.

Qué hace p=quarantine cuando DMARC falla en un correo

El fallo y lo que pasa después son dos cosas separadas. La etiqueta p= en su registro DMARC dice a los receptores qué hacer con el correo que falla. none significa recopilar informes, no cambiar nada. quarantine significa ponerlo en la carpeta de spam. reject significa rechazarlo en la puerta. Un registro también puede empezar con suavidad con pct=, poniendo en cuarentena solo el 10% de los fallos al principio.

El encabezado muestra qué regla aplicó el receptor. dmarc=fail (p=NONE ...) significa que su registro dice none, así que ese mensaje fue calificado e informado, no mandado a spam por el propio DMARC. Pasar de none hacia reglas más fuertes es un proceso aparte, y el artículo sobre DMARC en none lo recorre.

Hagan esto: miren qué dice realmente su registro antes de asumir lo peor. Un fail bajo p=none es una entrada del informe, no un envío a spam.

Cómo comprobar la alineación de DMARC para SPF y DKIM en el correo

Peguen el código fuente sin procesar de un mensaje que falle en el analizador de encabezados gratuito. Pone el dominio del sobre, el de la firma y el de From lado a lado, así que la comparación toma segundos. Dos comprobaciones más terminan el trabajo. El generador de DMARC muestra lo que su registro dice hoy, incluido el modo de alineación. El chequeo de salud del correo lee sus registros DNS en vivo como lo haría un receptor, y detecta un registro faltante que el panel de la plataforma sigue marcando como verificado.

Hagan esto: ejecuten el analizador en un mensaje primero, y después el chequeo de salud en el dominio. El mensaje les dice qué ruta falló. El dominio les dice por qué.

Fallos de DMARC en el correo de Google Workspace y Office 365

Cada suite tiene su propia versión de este problema.

En Google Workspace, el correo enviado desde la propia suite se alinea de entrada: el sobre lleva su dominio. Los fallos vienen de los bordes: una dirección From en un dominio que nunca se añadió ni verificó en la consola de administración, una herramienta de flujos de trabajo que retransmite por Gmail con su propio sobre, un dominio alias con registros en el dominio principal pero ninguno propio.

En Office 365, DKIM para un dominio personalizado está desactivado hasta que alguien lo activa, lo que sorprende a casi todos. Hasta entonces, su correo no lleva ninguna firma, dkim=none, o está firmado por el dominio predeterminado onmicrosoft.com. SPF a través de Microsoft todavía puede sostener el mensaje. Pero en cuanto el correo pasa por un conector de terceros, la segunda ruta que falta se convierte en dmarc=fail.

Hagan esto: en el centro de administración de 365, abran DKIM para su dominio personalizado y actívenlo, publicando los dos registros CNAME que pide. En Workspace, asegúrense de que todo dominio que aparezca en una dirección From en cualquier punto de su stack esté añadido, verificado y autenticado.

Lo que un fallo de DMARC le cuesta a la entregabilidad de su correo

Bajo p=none, un fallo no filtra correo por sí solo, pero igual les cuesta. Gmail y Yahoo exigen a los remitentes masivos publicar DMARC desde febrero de 2024, y el correo que falla DMARC es justo el correo que sus filtros miran con desconfianza, así que puede hundirse hacia el spam antes de que su política diga una palabra. Las reglas completas están en el artículo sobre requisitos para remitentes. El correo sin alinear también parece spoofing, y el spoofing es donde empieza toda la historia del correo que cae en spam.

Hagan esto: traten cada veredicto de fallo como información gratuita de los receptores a los que envían. Corrijan la alineación, y después dejen que los informes lo confirmen.

La corrección

La reparación es la misma en todas las plataformas, con nombres distintos. Mailchimp la llama authenticated domain. SendGrid la llama sending domain authentication. Amazon SES la llama custom MAIL FROM domain. Activen la función para el dominio de su dirección From, publiquen todos los registros que les entregue, el subdominio de Return-Path y los registros DKIM juntos, y esperen la propagación de DNS. Media configuración funciona bien hasta que la mitad alineada se rompe, así que publiquen el conjunto completo. La guía de configuración de DMARC tiene los pasos, y el artículo sobre el correo con “via” muestra cómo son esos registros.

Los encabezados de un mensaje corregido se leen así:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounces+7c2f@em892.example.com
         designates 198.51.100.7 as permitted sender)
       dkim=pass header.i=@example.com
       dmarc=pass (p=NONE dis=NONE) header.from=example.com

El sobre se movió a em892.example.com. La firma se movió a example.com. Ambas rutas se alinean. DMARC pasa.

Hagan esto: después de la propagación de DNS, envíen una prueba nueva a una dirección real y lean sus encabezados en el analizador antes de darlo por corregido.

Lo que una revisión puntual no puede ver

La alineación es un estado, no un arreglo de una sola vez, y los estados se desplazan. Una plataforma cambia sus claves de firma y los registros viejos dejan de funcionar. Una migración de DNS elimina el registro del sobre en silencio. Una herramienta nueva entra a su stack y empieza a enviar con sus valores de fábrica, fallando DMARC desde el primer día. Cada una devuelve el pass de hoy a dmarc=fail, sin ningún error a la vista. El primer signo suele ser correo cayendo en spam, semanas después.

Esa es la diferencia entre revisar y vigilar. LitInboxes vuelve a revisar sus registros SPF, DKIM y DMARC cada seis horas. Guarda historial con fechas, así que “la alineación se rompió el mes pasado” se convierte en “el registro DKIM se rompió el día 14”. Envía una alerta en cuanto un registro se mueve. Las alertas por correo están en todos los planes. Las alertas por Slack, Discord y webhook están en Pro. Un solo panel cubre todos los dominios de clientes para agencias y consultores. Hay una demostración en vivo por si quieren verla primero.

La lista de verificación

1. Abran un mensaje que falle y encuentren sus Authentication-Results.
2. Encuentren el dominio dentro de spf=pass. ¿No es su dominio? Ese es el fallo.
3. Lean dkim= y el d= de la firma. Cuando SPF no se alinea, esta ruta debe pasar y alinearse.
4. Comparen smtp.mailfrom con header.from para ver qué alineación falló.
5. Revisen la etiqueta p= en su registro DMARC para saber si los fallos solo se informan o también se filtran.
6. Activen el custom sending domain de la plataforma y publiquen el conjunto completo de registros.
7. Después de la propagación de DNS, revisen un mensaje nuevo con el analizador de encabezados y el chequeo de salud del correo.
8. Pongan los registros en un ciclo de vigilancia, semanal y a mano, o con monitoreo continuo. Los cambios de claves y las migraciones de DNS rompen la alineación en silencio.