¿Por qué una línea de tu informe DMARC muestra spf=fail cuando el dominio sigue protegido y el mensaje ha llegado igualmente a la bandeja de entrada? Para cada fuente de envío, un informe DMARC agregado indica el resultado de SPF. También añade el resultado de DKIM y la decisión que realmente aplica el servidor receptor. Un SPF fallido junto a un DKIM alineado en éxito no rompe nada: la especificación DMARC valida en cuanto uno de los dos mecanismos se alinea con el dominio visible en la cabecera From.
Es exactamente el tipo de línea que preocupa sin motivo cuando las campañas acaban en spam y la herramienta de email marketing muestra, sin embargo, una tasa de deliverability totalmente en verde. Si las bases de la autenticación de email (SPF, DKIM, DMARC) todavía no están claras, el protocolo DMARC explicado sienta las bases antes de seguir. Esta guía se centra en un único punto: leer un informe agregado campo por campo y distinguir una línea normal de una alerta real.
Dónde llega el informe y en qué formato
El informe agregado se envía a la dirección declarada en la etiqueta rua= del registro DNS _dmarc, normalmente una vez al día y por cada proveedor receptor (Google, Microsoft, Yahoo). El detalle de las etiquetas DNS que rigen este envío se cubre en el artículo sobre las etiquetas DMARCbis que hay que corregir antes del cambio de 2026; este artículo parte de la base de que el DNS ya está configurado. Cada mensaje llega como adjunto comprimido, un archivo XML dentro de un .zip o .gz. Hay que descomprimirlo antes de leerlo o usar un analizador que lo haga automáticamente.
MailerCheck distingue en 2024 los informes agregados de los informes forenses: los primeros resumen la actividad de autenticación durante un período determinado, los segundos detallan un fallo concreto y rara vez están implementados por los proveedores de correo (MailerCheck, 2024). No transita nada sensible por ellos. Casi toda la monitorización de DMARC se apoya, por tanto, en el agregado. Es también la política DMARC que Gmail y Yahoo exigen desde 2024 a los dominios que envían más de 5.000 mensajes al día. El agregado sigue siendo la principal herramienta para verificar su aplicación.
La estructura del XML, campo por campo
El archivo XML se organiza en tres bloques. report_metadata identifica al remitente del informe (org_name, email, período cubierto). policy_published recoge la política DMARC publicada por tu dominio en el momento del análisis. El bloque record contiene una o varias líneas row, cada una correspondiente a una combinación única de fuente y resultados.
Para interpretar una línea sin perderte, el orden de lectura importa.
- Identificar la fuente: source_ip indica la dirección IP que realmente envió el mensaje, que hay que cruzar con un reverse DNS para saber si se trata de tu ESP, de un relé de terceros o de una IP desconocida.
- Mirar el volumen: count indica el número de mensajes asociados a esa combinación exacta durante todo el período del informe.
- Leer la decisión aplicada: disposition (none, quarantine o reject) dentro del bloque policy_evaluated, la que realmente toma el servidor receptor.
- Comparar dkim y spf en policy_evaluated: estos dos valores indican el resultado de alineación, distinto del resultado bruto del protocolo.
- Comprobar auth_results para ver el resultado bruto de cada mecanismo y el dominio que realmente firma o se declara.
Esta distinción entre alineación (policy_evaluated) y resultado bruto (auth_results) es el origen de la mayoría de las confusiones. Un SPF técnicamente válido en el dominio del sobre puede mostrar fail en policy_evaluated porque ese dominio no coincide con el dominio visible en la cabecera From. Ese mecanismo explica el caso siguiente.
Las 4 combinaciones DKIM x SPF y su veredicto DMARC
Un informe agregado muestra 4 configuraciones recurrentes. Cada una cuenta una historia distinta sobre lo que ha pasado entre tu servidor de envío y la bandeja del destinatario.
| DKIM | SPF | Resultado DMARC | Causa más frecuente |
|---|---|---|---|
| Pass, alineado | Pass, alineado | Pass | Envío directo desde la infraestructura declarada en el DNS |
| Pass, alineado | Fail | Pass, vía DKIM | Reenvío, lista de distribución, redirección de buzón de correo |
| Fail | Pass, alineado | Pass, vía SPF | Relé que no firma el mensaje o firma rota en el camino |
| Fail | Fail | Fail | Suplantación del dominio o fuente de envío mal declarada en el DNS |
Solo la 4ª línea requiere una corrección inmediata. Las 3 primeras responden a un funcionamiento esperado de la especificación, cada una con su propia lectura.
SPF en fallo, DKIM en éxito: ¿hay que preocuparse?
No, en la mayoría de los casos. El SPF verifica la dirección MAIL FROM, transmitida mediante el comando del mismo nombre en el diálogo SMTP justo después del intercambio EHLO inicial, es decir, la dirección del sobre. El DKIM firma el contenido del mensaje con una clave privada vinculada al dominio remitente, una firma que viaja con el mensaje sea cual sea el servidor que lo retransmita después. Cuando un destinatario reenvía un correo a otro buzón o cuando una lista de distribución redistribuye un mensaje a sus suscriptores, el servidor relé se convierte en la nueva IP de envío. El SPF, que verifica la IP contra el registro del dominio de origen, falla automáticamente. La firma DKIM, en cambio, permanece intacta mientras el cuerpo y las cabeceras firmadas no se modifiquen por el camino.
Spamresource documenta en noviembre de 2025 un rechazo de Microsoft que ilustra bien el mecanismo, en sentido contrario: un mensaje con DKIM pass y DMARC pass fue bloqueado porque el SPF, en cambio, fallaba.
550 5.7.515 Access denied, sending domain doesn’t meet the required authentication level. Spf= Fail, Dkim= Pass, DMARC= Pass
El código de estado extendido 5.7.515 indica aquí un requisito propio de Microsoft, una capa añadida por encima del propio resultado DMARC. Desde mayo de 2025, Microsoft exige a los remitentes de gran volumen pasar simultáneamente los 3 mecanismos (SPF, DKIM, DMARC), aunque la propia especificación DMARC se conforme con una sola alineación correcta (spamresource.com, 2025). El SPF fail identificado en este caso concreto venía, según el mismo artículo, de un reenvío a un buzón alojado fuera de los servidores de Microsoft. Es un punto que conviene conocer antes de explicarle a un CMO que el open rate baja: DMARC puede mostrar pass en tu informe y aun así dejar algunos mensajes bloqueados por una regla propia del proveedor receptor.
Dos cosas distinguen este caso de un problema de configuración real que corregir. Primero, el volumen: unas pocas líneas aisladas con un count bajo, repartidas entre IPs variadas, corresponden más a un reenvío individual que a una campaña completa. Segundo, la fuente: un reverse DNS sobre esas source_ip suele apuntar a un proveedor de correo de consumo masivo o a un servidor de lista de distribución, nunca a tu propia infraestructura de envío. Un SPF fail repetido en tus propias IP de envío, sin ningún reenvío identificable, apunta a otra causa: el límite de los 10 lookups DNS del registro SPF, que conviene comprobar antes de concluir demasiado rápido que se trata de un simple reenvío.
Errores comunes al leer un informe agregado
Un primer error frecuente: confundir el resultado bruto de auth_results con el resultado de alineación de policy_evaluated. Un SPF puede tener éxito técnicamente en el dominio del sobre y aun así fallar en alineación porque ese dominio difiere del From visible, algo habitual en remitentes que comparten un grupo de IPs con un proveedor externo.
Otro error habitual: tratar un solo informe como una prueba definitiva. Los grandes proveedores (Google, Microsoft, Yahoo) envían informes diarios, y un incidente puntual puede aparecer un solo día y desaparecer al siguiente. Comprueba count y disposition durante al menos una semana antes de sacar conclusiones.
Y un tercero que se pasa por alto con facilidad: ignorar el campo org_name del bloque report_metadata. Ese campo identifica quién ha generado el informe, lo que sirve para detectar un proveedor secundario que aplica su propia política de filtrado además de la tuya, al margen de los feedback loops de los ISP a los que ya estés suscrito.
Qué cambia esto para tu deliverability
Un informe limpio, con un disposition en none o quarantine coherente en las líneas que no son de terceros, confirma una sender reputation estable en el lado de la autenticación. Es una señal distinta de la monitorización post-envío habitual: el open rate o el bounce rate muestra el efecto en el lado del destinatario, el informe DMARC muestra la causa en el lado del servidor receptor, incluso antes de que el mensaje llegue a un buzón. Ambos se complementan sin sustituirse. Postmaster de Gmail y su equivalente en Microsoft, el SNDS (Smart Network Data Services), ofrecen una vista similar del lado de la reputación de IP, que conviene cruzar con las mismas source_ip detectadas en el informe.
Una vez confirmada la autenticación limpia durante varios días, la siguiente variable que pesa sobre la reputación es la limpieza de la lista enviada. Una tasa de hard bounce elevada daña la sender reputation con la misma seguridad que un SPF mal alineado, y ninguna línea del informe DMARC lo revela. Pasar una muestra de la próxima lista por una verificación antes del envío permite saber si el freno viene de la autenticación o de la list hygiene.
Lo que el informe agregado no cubre
Un informe DMARC no dice nada sobre el contenido del mensaje, sobre la tasa de queja real en el lado del buzón, ni sobre los dominios similares (typosquatting) que nunca han publicado un registro DMARC y que, por tanto, escapan por completo a este mecanismo de generación de informes. Pasar a p=reject bloquea la suplantación directa de tu dominio, un requisito técnico para activar BIMI después. Esto no tiene ningún efecto sobre un dominio visualmente parecido registrado por un tercero. Las 5 cosas que DMARC no puede hacer detallan estos puntos ciegos más allá de los informes.
Guarda tus informes durante varias semanas antes de ajustar la política. Es la única forma de distinguir una señal real de un ruido pasajero. Un informe DMARC agregado cuenta el trayecto real de un mensaje, línea a línea, hasta la bandeja de entrada.
