Lo que hace DMARC y SPF y DKIM no pueden hacer
SPF autentica el remitente del sobre y DKIM firma el mensaje, pero ninguno de los dos mira la dirección From que ve realmente el destinatario. DMARC (Domain-based Message Authentication, Reporting and Conformance) cierra ese hueco. Le dice al receptor que compruebe que al menos SPF o DKIM han pasado y que el dominio que pasó está alineado con el dominio de la cabecera From, y que aplique después la política que tú elijas a todo lo que falle. También pide a los receptores que te envíen informes sobre cada mensaje que usó tu dominio, que es la única visibilidad que tienes sobre la suplantación y sobre las herramientas mal configuradas.
La alineación es el concepto clave. En modo relajado, al dominio autenticado le basta con compartir el dominio organizativo con la cabecera From, de modo que mail.ejemplo.com alinea con ejemplo.com. En modo estricto tienen que coincidir de forma exacta. El modo relajado es el adecuado para casi cualquier montaje de cold email, porque los proveedores usan a menudo un subdominio como remitente del sobre o como dominio d= de DKIM. La alineación estricta de SPF en particular rompe muchas herramientas y no aporta nada una vez que DKIM alinea.
El registro vive en _dmarc.tudominio.com como registro TXT. Publicarlo en el dominio organizativo cubre por defecto todos los subdominios, así que no necesitas uno por subdominio salvo que quieras una política distinta para ellos con la etiqueta sp.
Todas las etiquetas de DMARC, explicadas
Un registro DMARC es una lista de pares etiqueta=valor separados por punto y coma. Solo v y p son obligatorios; todo lo demás tiene un valor por defecto. El generador incluye únicamente las etiquetas que se apartan del valor por defecto, lo que mantiene el registro corto y evita erratas.
- v=DMARC1: versión, tiene que ir primero. p: política para el correo del dominio que falla, uno de none, quarantine o reject.
- sp: política para los subdominios. Omítela para que hereden p. Pon sp=none mientras aplicas p=reject solo si un subdominio envía correo sin autenticar a propósito.
- pct: porcentaje del correo fallido al que se aplica la política, de 1 a 100. Al resto se le aplica la política inmediatamente más suave. No tiene efecto con p=none.
- rua: dirección mailto para los informes agregados, resúmenes XML diarios por IP emisora. ruf: dirección para las muestras forenses por mensaje, que la mayoría de grandes receptores no envían.
- adkim y aspf: modo de alineación, r (relajado) o s (estricto). fo: cuándo generar informes forenses, 0 por defecto, es decir solo cuando fallan SPF y DKIM a la vez.
- ri: intervalo de informes solicitado en segundos, 86400 por defecto. La mayoría de receptores envían a diario sea cual sea el valor.
- Si rua apunta a otro dominio, ese dominio tiene que publicar tudominio.com._report._dmarc.dominioinformes.com TXT "v=DMARC1" o los receptores descartan los informes.
Plan de despliegue para dominios de cold email
Los dominios de cold email son un caso particular: son nuevos, envían un volumen constante desde un puñado de buzones y una autenticación rota cuesta respuestas de inmediato. Empieza cada dominio nuevo en p=none con una dirección rua el mismo día en que lo registras. Eso cumple el requisito de Gmail y Yahoo para remitentes masivos, que piden un registro DMARC con al menos p=none, mientras confirmas que cada buzón del dominio pasa SPF y DKIM con alineación.
Después de dos a cuatro semanas de informes que muestren solo tus propias IPs de envío, pasa a p=quarantine con pct=25. El correo legítimo no se ve afectado porque ya pasa; el único efecto recae sobre el correo suplantado. Vigila los rebotes y las tasas de respuesta durante una semana, sube pct a 100 y cambia después a p=reject. Un dominio que se queda en p=none durante meses es el hallazgo más común del verificador de arriba, y significa que cualquiera puede suplantar el dominio con libertad mientras su dueño se cree protegido.
- Fase 1, semanas 1 a 4: p=none; rua=mailto:… Entrega todo y corrige cualquier buzón o herramienta que falle la alineación.
- Fase 2, semanas 4 a 6: p=quarantine; pct=25. Confirma que las tasas de respuesta se mantienen.
- Fase 3, semanas 6 a 8: p=quarantine; pct=100.
- Fase 4, a partir de la semana 8: p=reject. Mantén rua y revisa los informes cada mes.
Cómo leer los informes agregados y los errores que dejan DMARC sin efecto
Los informes agregados llegan como XML comprimido, uno por receptor y día, con cada IP emisora, sus resultados de SPF y DKIM, la alineación y cuántos mensajes envió. Leerlos a mano es tedioso a escala, así que la mayoría de equipos dirigen rua a un servicio de procesamiento que los convierte en un panel. Lo que buscas es sencillo: toda IP que sea tuya debería salir con pass en las dos comprobaciones y con los dominios alineados, y toda IP que no reconozcas es o bien un reenviador, que es inofensivo, o bien alguien que suplanta tu dominio, que es exactamente para lo que existe la política de rechazo.
Los errores se repiten siempre. Publicar el registro en la raíz en lugar de en _dmarc. Dos registros DMARC en el mismo host, lo que invalida ambos. Escribir [email protected] sin el prefijo mailto:. Poner pct con p=none, que no hace nada. Olvidar el registro de autorización de informes externos cuando rua apunta a un servicio. Y, sobre todo, no volver a mirar el registro nunca más: las claves se rotan, se añaden herramientas nuevas y un dominio en p=reject con una fuente de envío olvidada pierde correo en silencio. ColdBox muestra el estado de DMARC de cada dominio conectado junto a la salud de sus buzones, así que una política atascada en none o una alineación rota salen a la luz antes de costarte una campaña.