Cuando el correo legítimo falla DMARC, la causa es casi siempre una de pocas cosas predecibles: un resultado SPF o DKIM ausente o desalineado, un reenvío que rompe SPF, o un remitente externo que nunca fue autenticado para tu dominio. La solución rara vez es relajar tu política. Lo que necesitas es encontrar el origen y autenticarlo correctamente.
¿Cómo sé qué está fallando?
Empieza por tus reportes, porque te dicen exactamente qué origen está fallando y por qué. Tus reportes agregados desglosan el correo por IP de envío y muestran los resultados de SPF y DKIM junto con la alineación de cada uno. Un origen que muestra pass en la verificación sin procesar pero fail tras la alineación es el patrón más común, y apunta directamente al problema. Si aún no te sientes cómodo leyéndolos, cómo leer un reporte DMARC recorre cada campo.
Una vez que puedes ver qué origen está fallando, casi siempre se trata de una de las causas que siguen.
Causa 1: Una brecha de alineación
Esta es la más importante. SPF o DKIM pasa, pero para un dominio que no coincide con tu dirección From visible, así que DMARC lo cuenta como fallo. Normalmente significa que un servicio de envío se autentica con su propio dominio en lugar del tuyo.
La solución es alinear el servicio. Para SPF, eso significa enviar con un Return-Path (dominio de rebote) en tu propio dominio. Para DKIM, significa firmar con una clave publicada en tu dominio, de modo que el dominio de firma coincida con tu From. La mayoría de las plataformas de correo admiten un dominio personalizado precisamente para esto: publicas uno o dos CNAME y la alineación encaja. El concepto se explica en cómo funciona DMARC.
Causa 2: Reenvío
El reenvío rompe SPF de forma silenciosa. Cuando un mensaje se reenvía, el servidor de reenvío lo envía al siguiente destino, y ese servidor no está en tu registro SPF, así que la verificación SPF falla en el destino final. No puedes hacer mucho respecto a las reglas de reenvío de otras personas.
La buena noticia es que DKIM suele sobrevivir al reenvío, porque la firma viaja con el mensaje. Por eso exactamente DMARC pasa con SPF o DKIM: mientras tu DKIM sea sólido y esté alineado, el correo reenviado sigue pasando DMARC incluso cuando SPF falla. La solución práctica para los fallos de reenvío es asegurarte de que DKIM esté correctamente configurado y alineado, y luego dejar de preocuparte por la columna SPF en el correo reenviado.
Causa 3: Un remitente externo que olvidaste
Casi toda organización envía correo a través de más servicios de los que recuerda: un CRM, un servicio de soporte, una herramienta de facturación, una plataforma de marketing, un servicio de encuestas. Cada uno necesita estar autenticado para tu dominio, o su correo falla DMARC. Los nuevos orígenes que aparecen en tus reportes suelen ser uno de estos.
Trabájalos uno por uno. Para cada servicio legítimo, sigue sus instrucciones para configurar SPF y DKIM en tu dominio (la expresión habitual es "authenticate your domain" o "use a custom sending domain"). Luego confirma en tus siguientes reportes que el origen ya pasa y está alineado. Mantén una lista actualizada, porque esta es la parte que se desajusta a medida que los equipos adoptan nuevas herramientas.
Causa 4: SPF demasiado amplio o por encima del límite de consultas
Dos trampas específicas de SPF. Si tu registro SPF ha superado las 10 consultas DNS (un límite estricto en la especificación), puede fallar por completo y arrastrar consigo correo que de otro modo pasaría. Y un registro demasiado permisivo puede dejar pasar correo que no pretendías autorizar. Audita tu registro SPF, consolida las entradas include: si estás cerca del límite y elimina los servicios que ya no uses.
Lo que no debes hacer
No soluciones los fallos debilitando tu política de vuelta a p=none y dejándola ahí. Eso hace que los reportes dejen de molestarte, pero también deja de proteger a cualquiera, así que el problema de suplantación que estabas resolviendo queda completamente abierto de nuevo. Trata un fallo como una señal para autenticar un origen, no como una razón para retroceder. La forma legítima de aliviar la presión es retroceder p= un nivel y seguir leyendo los reportes, que es lo que cubre qué es una política DMARC.
Ponlo todo junto
Lee el reporte, encuentra el origen que falla, decide si es legítimo y autentícalo o reconócelo como suplantación que ahora estás bloqueando. Trabaja la lista hasta que cada remitente real pase y esté alineado, y tu política pueda quedarse tranquilamente en reject. Si todavía estás configurando todo, cómo configurar DMARC cubre los fundamentos, y la guía de autenticación de Bird tiene los registros específicos del dominio. La mayoría de los fallos parecen alarmantes y resultan ser una corrección de alineación de cinco minutos una vez que sabes qué origen perseguir.