En algún lugar de tus resultados de test o de las cabeceras de tu bandeja de entrada aparece el veredicto dmarc=fail, y lo confuso es que rara vez significa lo que parece. La mayoría de los fallos de DMARC no son falsificaciones. Son correo legítimo que se autenticó como el dominio equivocado: SPF respondiendo por tu ESP en lugar de por ti, DKIM firmado con una clave compartida, o un reenvío que reescribe justo lo suficiente para romper ambas comprobaciones a la vez.
Primero la respuesta directa: DMARC falla cuando un mensaje no puede mostrar ni una sola comprobación de autenticación que pase y que además coincida con el dominio de tu cabecera From. Todo lo demás en esta guía es el diagnóstico y la reparación: de qué se compone el veredicto, las siete causas que veo una y otra vez en los resultados del test de spam, la solución para cada una y cómo endurecer tu política cuando los fallos paren.
Fallar también te coloca en la mayoría. En las comprobaciones realizadas con Unspam, el 90% de los remitentes pasan SPF y el 88% pasan DKIM, pero solo el 55% pasa DMARC. Es con diferencia el eslabón más débil de la cadena de autenticación, y las causas de abajo son las razones de esa brecha.
Qué significa realmente dmarc=fail
DMARC no inspecciona el contenido, los enlaces ni el volumen de envío. Hace exactamente dos preguntas sobre un mensaje que dice venir de yourbrand.com:
- ¿Pasó SPF, y el dominio para el que pasó está alineado con el dominio del From? SPF valida el remitente del sobre (la dirección Return-Path usada durante la conversación SMTP), que el lector nunca ve. La alineación significa que ese dominio oculto y tu dominio From visible coinciden.
- ¿Pasó DKIM, y el dominio firmante (la etiqueta
d=de la firma) está alineado con el dominio del From?
Con un solo pase alineado basta. SPF puede fallar por completo y DMARC seguir pasando si una firma DKIM alineada se verifica, y al revés. Ese único OR es el dato más práctico de todo este tema, y también la razón de que tantos fallos confundan a la gente: ambas comprobaciones pueden pasar por separado mientras DMARC falla, porque ninguna pasó para tu dominio.
DMARC nunca pregunta "¿pasó la autenticación?". Pregunta "¿pasó la autenticación para el dominio que el lector realmente ve?"
Por defecto, la alineación es relajada: cuenta cualquier subdominio del mismo dominio organizativo, así que el correo firmado por mail.yourbrand.com se alinea con un From de yourbrand.com. Tu registro puede exigir alineación estricta (adkim=s, aspf=s), que requiere una coincidencia exacta; es una decisión deliberada de endurecimiento y un fallo autoinfligido muy común, como veremos. Para una comparación más profunda de cómo difieren las dos comprobaciones subyacentes, consulta DMARC vs DKIM.
Primero, averigua por qué falla el tuyo
No arregles a ciegas. Cada veredicto DMARC llega con las pruebas adjuntas, en tres sitios.
Haz un test antes de enviar. El test de spam gratuito de Unspam autentica el mensaje exacto que estás a punto de enviar y muestra los resultados de SPF, DKIM y DMARC uno junto a otro, incluyendo qué dominios evaluó cada comprobación, junto a las comprobaciones de SpamAssassin, listas negras y contenido. Es la única vía que detecta el fallo antes de que lo vea un suscriptor.
Lee la cabecera Authentication-Results. En cualquier mensaje entregado, el servidor receptor escribe su veredicto en las cabeceras. En Gmail, abre un mensaje y elige Mostrar original; el resumen de la parte superior y la línea Authentication-Results en bruto cuentan toda la historia:
Este ejemplo es el fallo real más común de todos. Ambas comprobaciones pasan, y DMARC falla igualmente, porque bounce.esp-mail.com y esp-mail.com no se alinean con yourbrand.com. La cabecera te entrega el diagnóstico: los dominios que aparecen tras smtp.mailfrom= y header.d= son los que se ganaron el pase, y ninguno es el tuyo.
Lee tus informes agregados. Si tu registro DMARC incluye una dirección rua, los receptores te envían por correo resúmenes XML diarios de cada fuente que envió correo como tu dominio: las IP, los volúmenes y cómo se autenticó cada una. Los informes son la única forma de ver fallos en correo que nunca pasó por tus manos, incluidas las copias reenviadas y los intentos de suplantación.
Antes de tocar nada más, pasa también tu dominio por el comprobador de DMARC gratuito para confirmar que el registro existe y que su sintaxis es correcta.
Las siete razones por las que DMARC falla, y la solución para cada una
Casi todos los dmarc=fail se remontan a una de estas causas. Están ordenadas por la frecuencia con la que las veo, así que empieza por arriba.
| # | Causa | Qué muestra la cabecera | Solución en una línea |
|---|---|---|---|
| 1 | El ESP se autentica como él mismo | spf=pass y dkim=pass para los dominios del ESP | Activa la autenticación de dominio personalizado |
| 2 | El reenvío rompió SPF | spf=fail desde una IP que no es tuya, dkim=pass | Alinea DKIM; sobrevive al reenvío |
| 3 | Una lista de correo reescribió el mensaje | dkim=fail (el hash del cuerpo no coincide) | Nada por tu parte; para eso existe ARC |
| 4 | Alineación estricta con remitente en subdominio | pase para mail.yourbrand.com, fallo de alineación | Usa alineación relajada o haz coincidir el dominio exacto |
| 5 | Permerror de SPF | spf=permerror | Baja de las 10 consultas DNS |
| 6 | Registro DMARC roto | dmarc=none o las herramientas no encuentran política | Un único registro válido en el host _dmarc |
| 7 | Suplantación real | IP desconocidas que fallan todo | Nada; DMARC está haciendo su trabajo |
1. Tu ESP se autentica como él mismo, no como tú
De serie, la mayoría de las plataformas de envío usan sus propios dominios de infraestructura: el remitente del sobre es algo como bounce.esp-mail.com para poder procesar tus rebotes, y la firma DKIM usa su clave compartida con su dominio en d=. Ambas comprobaciones pasan, para ellos. Tu dominio From no consigue ningún pase alineado, y DMARC falla como muestra la cabecera de arriba.
La solución es el ajuste que toda plataforma seria ofrece bajo un nombre como autenticación de dominio personalizado, verificación de dominio o envío con tu marca: publicas unos cuantos registros CNAME que ellos te dan, y a partir de ahí los mensajes se firman con DKIM como yourbrand.com (o un subdominio, que se alinea en modo relajado) y usan un dominio de rebote personalizado como bounce.yourbrand.com para la alineación de SPF. Empieza por DKIM; una firma DKIM alineada, por sí sola, hace que DMARC pase aunque el lado SPF siga apuntando al ESP.
2. Un reenvío rompió SPF
Cuando alguien reenvía tu correo automáticamente (una dirección universitaria que reenvía a Gmail, un dominio antiguo que reenvía a uno nuevo), el servidor de reenvío lo entrega desde su IP, que no está en tu registro SPF, así que SPF falla. Los reenviadores que "arreglan" esto reescribiendo el remitente del sobre con su propio dominio hacen que SPF vuelva a pasar, pero para su dominio, lo que rompe la alineación. En cualquier caso, la vía SPF está muerta en el correo reenviado, de forma permanente y por diseño.
La solución es dejar de depender solo de SPF. Una firma DKIM viaja dentro del mensaje y se verifica sin importar qué servidor lo haya retransmitido, así que un reenvío limpio conserva un dkim=pass alineado y DMARC sigue pasando. Si tus informes agregados muestran una cola de fallos solo de SPF desde los rangos de IP de los propios proveedores de buzón, eso es reenvío, es normal, y es exactamente la razón por la que nunca deberías publicar una política DMARC de aplicación estricta apoyándote solo en la alineación de SPF.
3. Una lista de correo reescribió el mensaje
Las listas de discusión son la prima más difícil del reenvío: suelen añadir una etiqueta al asunto como [members], añaden un pie con el enlace de baja y reenvían desde la propia dirección de la lista. Los cambios en el pie y el asunto alteran el contenido firmado, así que tu firma DKIM ya no se verifica. El sobre de la lista rompe la alineación de SPF. Las dos vías fallan en correo que todos los implicados querían recibir.
La solución está casi toda fuera de tus manos, y aquí la honestidad gana a los rodeos. Las listas modernas lo mitigan por su cuenta, ya sea reescribiendo la cabecera From con el dominio de la lista (sacando tu dominio de la ecuación DMARC) o añadiendo un sello ARC que permite a los receptores dar fe de los resultados de autenticación originales. Por tu parte: mantén DKIM alineado para que el reenvío simple sobreviva, y cuenta con un residuo pequeño e inofensivo de fallos relacionados con listas en tus informes. Si la lista la gestionas tú, activa sus opciones de mitigación de DMARC.
4. Alineación estricta cuando necesitas la relajada
Si tu registro establece adkim=s o aspf=s, solo cuenta una coincidencia exacta de dominio: el correo firmado con DKIM por mail.yourbrand.com con un From de yourbrand.com pasa la alineación relajada pero falla la estricta. Los equipos activan el modo estricto como medida de endurecimiento, olvidan que su plataforma de newsletters firma con un subdominio delegado y fabrican sus propios fallos.
La solución: comprueba si tu registro lleva adkim=s o aspf=s (el comprobador de DMARC muestra todas las etiquetas). Si los dominios que envían legítimamente por ti incluyen algún subdominio, vuelve a la alineación relajada (borra la etiqueta; la relajada es el valor por defecto) o reconfigura el remitente para que firme con el dominio From exacto. La alineación estricta solo merece la pena cuando tus informes muestran una racha larga y limpia con cada fuente coincidiendo de forma exacta.
5. Permerror de SPF: el límite de diez consultas
Los registros SPF se evalúan con un presupuesto rígido: los mecanismos que generan consultas DNS (include, a, mx, redirect, exists) no pueden superar diez en total, contadas de forma recursiva a través de cada include anidado. Acumula suficientes herramientas (un ESP, un CRM, un helpdesk, un include antiguo que nadie recuerda) y la evaluación se aborta con permerror. Un permerror nunca puede convertirse en un pase alineado, así que la vía SPF se apaga para todos los receptores, en todos los mensajes.
La solución: pasa tu dominio por el comprobador de SPF, que cuenta las consultas por ti. Elimina los include de servicios que ya no usas y plantéate consolidar o aplanar el resto. Ya que estás ahí, asegúrate de que el registro termina en ~all o -all; un +all le dice al mundo que cualquiera puede enviar como tú, lo que anula el sentido de toda la pila de autenticación.
6. El propio registro DMARC está roto
Una parte sorprendente de los fallos ocurre antes de evaluar ningún mensaje, en el registro DNS:
- Dos registros DMARC. Fusionar dominios, o que dos equipos añadan uno cada uno, deja varios registros TXT en
_dmarc. El estándar no perdona: los receptores que encuentran más de un registro no aplican ninguno. - Host equivocado. El registro debe vivir en
_dmarc.yourbrand.com, no en la raíz ni endmarc.sin el guion bajo. - Deslices de sintaxis. El registro debe empezar por
v=DMARC1, las etiquetas se separan con punto y coma, y las direccionesruanecesitan el prefijomailto:. Una errata comop=noninvalida la política.
La solución: pega tu dominio en el comprobador de DMARC y corrige lo que señale. Si prefieres no montar la cadena a mano, el generador de registros DMARC gratuito construye uno válido a partir de opciones desplegables.
7. Alguien está suplantando tu dominio de verdad
Una vez descartadas las seis malas configuraciones, lo que queda en tus informes agregados (IP desconocidas, a menudo geográficamente improbables, que fallan ambas comprobaciones con volumen que tú nunca enviaste) es DMARC haciendo su trabajo: cazar falsificaciones. Este es el fallo que quieres.
La solución es resistirte a la equivocada: no suavices tu política porque los informes den miedo. Confirma que las fuentes no son tuyas (el shadow IT existe; esa IP desconocida a veces es el sistema de facturación que alguien conectó en 2019), y después deja que tu política p=quarantine o p=reject se coma las falsificaciones. Esta protección es la razón de que la reputación del remitente y la aplicación de DMARC vayan de la mano.
"No se ha encontrado registro DMARC": la solución de cinco minutos
Las herramientas y las páginas de postmaster informan de esto cuando no hay ningún registro TXT en _dmarc.yourdomain.com. No es un fallo de ningún mensaje concreto, pero dejó de ser un hueco cosmético en 2024: Gmail y Yahoo exigen ahora a los remitentes de correo masivo (Google pone el listón en unos 5.000 mensajes al día hacia Gmail) publicar al menos una política DMARC mínima, con SPF o DKIM alineado con el dominio From, y Microsoft aplica el mismo requisito a los dominios de consumo de Outlook desde mayo de 2025. Sin registro, hoy eso significa limitaciones de velocidad, carpeta de spam o rechazo directo en los mayores proveedores de buzón, que se manifiesta exactamente como el correo no entregado que la gente luego pasa días persiguiendo.
El registro inicial es una línea, publicada como TXT en el host _dmarc:
v=DMARC1; p=none; rua=mailto:dmarc@yourbrand.com
No aplica nada, satisface el mínimo de los proveedores de buzón y empieza a recopilar los informes agregados que necesitas para todo lo demás de esta guía. Genera el tuyo con el generador de registros mencionado arriba si prefieres que la sintaxis la resuelvan por ti.
Qué hacen los receptores con un mensaje que falla
La consecuencia de dmarc=fail es lo que pida tu propio registro, aplicado a discreción del receptor:
| Política | Qué publicaste | Qué suele pasar con el correo que falla |
|---|---|---|
p=none | Solo monitorizar | Se entrega con normalidad; el fallo se registra y se te informa |
p=quarantine | Tratar con sospecha | Se envía a la carpeta de spam |
p=reject | Rechazarlo | Rebota durante la entrega; el lector nunca lo ve |
Dos apuntes que importan en la práctica. Primero, los receptores pueden anular tu política en ambos sentidos; una etiqueta pct también te permite aplicar quarantine o reject solo a una muestra del correo que falla mientras ganas confianza. Segundo, p=none no está libre de consecuencias: los filtros de Gmail y Outlook ponderan los resultados de autenticación como señal de reputación al margen de tu política, así que un flujo con fallos crónicos de DMARC consigue una llegada a la bandeja de entrada cada vez peor aunque técnicamente todos los mensajes se entreguen.
Cómo solucionar los fallos de DMARC, paso a paso
Este es el orden que funciona, tanto si estás arreglando una campaña que falla como un dominio entero:
- Publica o repara el registro, en
p=none, con una direcciónrua. Verifícalo con el comprobador de DMARC. La aplicación estricta llega al final, no al principio. - Inventaría tus remitentes. Deja que los informes agregados corran de dos a cuatro semanas, y después lista cada servicio que envía como tu dominio: ESP, correo transaccional, CRM, helpdesk, facturación, la impresora de la oficina.
- Alinea DKIM en todas partes primero. Para cada remitente legítimo, activa la firma con dominio personalizado para que
d=sea tu dominio. DKIM sobrevive al reenvío, así que es la alineación que sigue funcionando cuando el mensaje sale de tus manos. - Alinea SPF después. Configura dominios de rebote personalizados donde la plataforma los admita, y deja tu registro por debajo del límite de diez consultas con el comprobador de SPF.
- Verifica por mensaje, no por dominio. Envía un mensaje real desde cada plataforma a través del test de spam y comprueba los tres veredictos con el comprobador de DKIM al lado. Los registros pueden ser perfectos mientras un flujo de correo concreto sigue firmando con la clave equivocada.
- Endurece la política por tramos. Cuando los informes muestren que tus fuentes legítimas pasan, muévete a
p=quarantine(opcionalmente con una muestra víapct), observa, y despuésp=reject. Ese paso final es el sentido de todo el ejercicio: es lo que de verdad impide que tus clientes reciban facturas falsas con tu nombre.
Comprueba el veredicto antes de que lo hagan tus suscriptores
Un fallo de DMARC descubierto en un informe agregado ya te ha costado una campaña. El test de spam gratuito de Unspam muestra el mismo veredicto antes de enviar: SPF, DKIM y DMARC evaluados sobre tu mensaje exacto, con los dominios que vio cada comprobación, junto al spam score, las listas negras y las comprobaciones de contenido, en unos 30 segundos y sin necesidad de registrarte. Si dice que pasa y está alineado, envía. Si dice dmarc=fail, ya sabes cuál de las siete causas corregir, y ninguna lleva más de una tarde.
