Suelta los archivos XML, gzip o zip en los que llegan tus informes DMARC y lee lo que dicen de verdad: cuánto de tu correo está aprobando, qué orígenes fallan y cuáles de esos fallos son una plataforma de envío que hay que configurar en lugar de alguien a quien bloquear. Cada archivo se procesa en tu navegador, sin registro y sin subir nada.
Suelta aquí tus informes agregados de DMARC
Los informes llegan por correo como adjuntos .xml, .xml.gz o .zip. Añade todos los que tengas: un informe es un receptor durante un día. Se leen en este navegador y nunca se suben.
Crea una cuenta gratuita de Unspam para guardar tus resultados y repetir estas comprobaciones cuando quieras, así detectas una configuración rota antes de que te cueste caro. Sin tarjeta de crédito.
En cuanto tu registro DMARC lleva una dirección rua, los proveedores de correo empiezan a enviarte un archivo XML al día cada uno. Cada archivo enumera todas las direcciones IP que enviaron correo diciendo ser tu dominio, cuántos mensajes salieron de cada una, si SPF y DKIM autenticaron, si alguno de los dos coincidió con la dirección de la cabecera From y qué hizo el receptor al respecto. Es la única vista que vas a tener de quién envía como tu dominio, y es la razón de que DMARC tenga una mitad dedicada a informes. Los archivos también son ilegibles a simple vista: un solo día de un proveedor grande son miles de líneas de XML, en un esquema que acaba de revisarse, con dos columnas que parecen la misma pregunta y no lo son. Esta herramienta lee las dos revisiones, suma los recuentos de mensajes en lugar de las filas y mantiene esas dos columnas separadas, porque la diferencia entre ellas es la diferencia entre un registro roto y uno que funciona pero que todavía no has alineado.
El resultado de alineación, y toma exactamente dos valores: pass o fail. Responde a una sola pregunta, si un identificador autenticado coincidió con el dominio de la cabecera From. Es sobre esto sobre lo que actúa DMARC, y un dominio aprueba si aprueba cualquiera de las dos patas, no las dos.
El resultado de autenticación en bruto, y toma siete u ocho valores, incluidos softfail, temperror y permerror. Responde a otra pregunta: si SPF o DKIM llegaron a funcionar, para el dominio contra el que se comprobaran. Una fila con SPF pass aquí y SPF fail arriba no es una contradicción, es la firma de una plataforma que envía con su propio return path.
El número de mensajes que representa una fila, desde uno hasta decenas de miles. Todos los totales de esta página son sumas de estos valores, nunca recuentos de filas. Contar filas es la forma más habitual de leer mal un informe agregado, porque la respuesta sigue siendo plausible y se mueve en la dirección correcta mientras está desviada por lo que dé la distribución de volumen.
La dirección que se conectó. Esta es la lista que hay que recorrer: ordenados por volumen, los primeros orígenes suelen ser tu plataforma de correo, tu web, tu sistema de tickets y tu propio servidor, y reconocerlos es la mayor parte del trabajo para llegar a una política que puedas aplicar.
La lectura errónea más común, y la que lleva a editar un DNS que ya es correcto. Si el resultado SPF en bruto es pass y el de alineación es fail, SPF funcionó: autenticó el dominio del sobre, que pertenece a la plataforma que envía por ti. La solución es un return path propio en tu dominio, o la alineación de DKIM. Nada de lo que añadas a tu registro SPF lo cambia.
Un archivo es un receptor durante un día. Un proveedor que no envía informes es invisible en él, y también lo es todo mensaje que nunca llegó al único proveedor cuyo informe tienes. Carga un par de semanas de tus receptores más grandes antes de sacar conclusiones sobre un origen que no reconozcas.
Una tasa alta dice que el correo que conoces está autenticado. No dice nada del correo que has olvidado, y los sistemas que se olvidan son los que envían poco: facturación, recuperación de contraseñas, el CRM que alguien montó hace dos años. Recorre la lista de orígenes hasta que puedas nombrar cada entrada, y entonces cambia la política.
El RFC 9989 eliminó pct de DMARC. Un receptor que siga la especificación actual aplica tu política a todos los mensajes que fallan y no a la proporción que pediste, así que un registro dejado en p=reject con pct=25 rechaza ahora cuatro veces más correo que antes, sin haber tocado el DNS. Si un informe cargado muestra una etiqueta pct, ese registro hay que revisarlo.
Los informes agregados llevan recuentos, direcciones y resultados. No llevan asuntos, ni cuerpos, ni direcciones de destinatarios, que es lo que hace que sea seguro enviarlos. Si necesitas ver un mensaje fallido en sí, eso es un informe de fallo, algo distinto y mucho más raro que la mayoría de proveedores no envía.
Cuando un receptor hace algo distinto de lo que pedía tu política, lo dice y da un motivo: una lista de correo, un reenviador en el que confía, su propia política local. Esas filas no son fallos de tu configuración y perseguirlas gasta el tiempo que rinde más en los orígenes que están por encima.
