Su política DMARC está en none. ¿Qué está haciendo realmente?
Su registro DMARC existe. Es válido. Aun así, algo les indica que la política está en none, y la implicación es que no han terminado.
Es justo. Una política p=none es una política real, publicarla fue el primer paso correcto y dejarla ahí de forma indefinida da solo una fracción de lo que DMARC ofrece. La respuesta corta: recopila evidencia y no aplica nada, lo que significa que un mensaje suplantado que diga ser de su dominio todavía llega hoy a la bandeja de entrada.
¿Qué recopila un registro p=none?
Un registro DMARC se ve así:
v=DMARC1; p=none; rua=mailto:reports@example.com; fo=1La etiqueta p les dice a los servidores receptores qué hacer con el correo que dice ser de su dominio y falla DMARC. Hay tres valores: none, quarantine y reject.
Con p=none, el receptor evalúa el mensaje exactamente como lo haría con cualquier otra política. Comprueba si SPF pasó y si el dominio SPF se alinea con el dominio From que su lector ve. Comprueba lo mismo con DKIM. Llega a un veredicto. Después entrega el mensaje como lo habría hecho si nunca hubieran publicado DMARC, y les envía por correo un reporte con lo que vio.
Así que p=none cambia sus reportes, no su entrega. Un mensaje suplantado que dice ser de su dominio sigue llegando a la bandeja de entrada de su cliente. Solo se enteran al día siguiente, en XML.
Eso es genuinamente útil, y es la razón por la que toda implementación segura empieza aquí. Deja de ser útil en el momento en que nadie lee los reportes.
Hagan esto: abran su registro DMARC y confirmen que contiene una dirección rua=. Un registro p=none sin rua es la única configuración que no les da absolutamente nada.
Por qué los dominios se quedan atascados en none
Tres razones cubren casi todos los casos.
Nadie leyó los reportes. Los reportes agregados llegan como adjuntos XML comprimidos en gzip, una vez al día, desde cada proveedor al que envían. Son ilegibles por diseño a cualquier volumen. Si los reportes van a un buzón compartido que nadie abre, el dominio se quedará en none para siempre, porque pasar a hacer cumplir la política sin leerlos es genuinamente peligroso.
Hay una fuente sin alinear y nadie la reclama como propia. Los reportes muestran una IP de envío que falla la alineación, envía volúmenes pequeños y nadie en la empresa la reconoce. Suele ser una herramienta de facturación olvidada, un plugin de formularios o un buzón que configuró un ex empleado. Hacerla cumplir la rompería, así que la política se queda como está.
Un proveedor no puede alinearse. Algunas plataformas envían como su dominio From pero firman con el suyo y no ofrecen forma de agregar una clave DKIM para el de ustedes. En ese caso la fuente nunca pasará la alineación, y tienen que reemplazar al proveedor, moverlo a un subdominio con su propia política o aceptar que su correo termine en cuarentena.
La pista de cada caso está en los reportes: el primero se ve como una bandeja de entrada llena que nadie abrió, el segundo como una IP de bajo volumen sin dominio DKIM que coincida, y el tercero como una fuente de alto volumen que falla la alineación de forma consistente mientras su propio SPF pasa.
Hagan esto: clasifiquen cada fuente de las últimas dos semanas de reportes en esos tres grupos antes de tocar la política.
La alineación es lo que la gente pasa por alto
DMARC no pregunta si SPF pasó. Pregunta si el dominio que pasó coincide con el dominio que su lector ve en la línea From.
Un mensaje enviado a través de un proveedor puede pasar SPF perfectamente, para el dominio de rebote del propio proveedor, y aun así fallar DMARC porque ese dominio de rebote no tiene nada que ver con el de ustedes. En el reporte agregado se ve así:
<row>
<source_ip>198.51.100.24</source_ip>
<count>412</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<spf><domain>vendor-bounces.net</domain><result>pass</result></spf>
</auth_results>SPF pasó. DMARC falló. El resultado spf dentro de policy_evaluated es el veredicto alineado, y es el único que decide algo.
Esta es la razón más común por la que una configuración que se ve correcta en todos los verificadores igual falla DMARC. Los verificadores confirman que sus registros se interpretan bien. La alineación tiene que ver con la relación entre dos dominios al momento del envío, algo que ninguna comprobación estática de registros puede ver.
Hagan esto: para cada fuente que falla, comparen header_from con los dominios SPF y DKIM en auth_results. Si no coinciden, tienen un problema de alineación, no un problema de registro.
Cómo subir la escalera con seguridad
El camino es none, luego quarantine con un porcentaje y después reject. La condición entre cada peldaño es la misma: ninguna fuente legítima está fallando.
Quarantine con porcentaje es el paso que la gente se salta, y es el que hace que todo el proceso sea seguro:
v=DMARC1; p=quarantine; pct=25; rua=mailto:reports@example.comEso envía un cuarto del correo que falla a la carpeta de spam y deja el resto intacto. Si algo salió mal, se enteran con un cuarto del radio de impacto. Suban pct a 50, luego a 100, y después cambien a p=reject y eliminen la etiqueta.
Si tienen un proveedor que no pueden alinear, pónganlo en un subdominio y denle al subdominio su propia política más débil con sp=. Eso permite que el dominio raíz llegue a reject mientras el remitente problemático sigue funcionando.
Hagan esto: establezcan p=quarantine; pct=25 hoy si cada fuente que les pertenece ya pasa, y dejen anotado el siguiente paso para dentro de dos semanas.
Cómo verificar que el cambio se aplicó
Después de cualquier edición de DMARC, hay dos cosas por confirmar: que el registro se interprete como quieren y que los reportes sigan llegando.
El generador gratuito de registros DMARC les muestra la cadena exacta del registro para la política que quieren, que es la forma más rápida de comprobar que no escribieron mal ninguna etiqueta. El chequeo gratuito de salud del correo vuelve a leer el registro publicado desde DNS después de que expire el TTL, junto con su SPF y DKIM, para que vean lo que los receptores realmente ven en lugar de lo que intentaron publicar.
Ambos responden para un dominio, en el momento en que preguntan.
Ese es el límite honesto. Una política DMARC no es algo que se configura y se termina. Los registros se editan durante migraciones de DNS sin relación. Un colega agrega un nuevo proveedor que empieza a fallar la alineación el lunes, y los reportes que lo dirían llegan el martes, en XML, en un buzón que nadie abre. La brecha entre publicar una política reject y saber que sigue vigente, con cada fuente legítima aún pasando, es donde los dominios se rompen en silencio.
Esa brecha es el producto. LitInboxes vuelve a revisar cada dominio monitoreado cada 6 horas, convierte los reportes agregados y forenses de DMARC en una vista fuente por fuente en lugar de XML, conserva el historial con fechas para que vean cuándo apareció una fuente y les alerta ante el cambio en lugar de hacerlo según un calendario. Las alertas salen por correo en todos los planes, y por Slack, Discord o webhook en Pro. Hay una demostración en vivo si quieren ver la vista de reportes antes de registrarse en nada.
Si la pregunta de fondo es por qué el correo cae en la carpeta de spam, DMARC es una de las cuatro señales que vale la pena revisar, y el diagnóstico completo cubre las otras tres.
La lista de verificación
- Confirmen que su registro tiene una dirección
rua=y que los reportes llegan a un lugar donde alguien los revisa. - Reúnan al menos dos semanas de reportes, idealmente un ciclo de facturación completo.
- Enumeren cada fuente de envío y clasifíquenla: propia, un proveedor autorizado o desconocida.
- Comparen
header_fromcon los dominios SPF y DKIM de cada fuente que falla para encontrar las brechas de alineación. - Corrijan la alineación de todo lo que les pertenece, dando prioridad a DKIM.
- Muevan cualquier proveedor que no puedan alinear a un subdominio con su propia política
sp=. - Publiquen
p=quarantine; pct=25y vigilen los conteos de fallos durante dos semanas. - Suban
pcta 100 y luego publiquenp=reject.
Cómo pasar una política DMARC de none a reject
- Confirmar que los reportes realmente lleganUn registro p=none sin dirección rua no recopila nada. Verifiquen que su registro DMARC contenga una dirección rua= y que los reportes agregados hayan estado llegando ahí durante al menos dos semanas.
- Enumerar cada fuente que envía como su dominioLean los reportes y anoten cada IP de envío y cada dominio del encabezado From. Marquen cada uno como propio, como un proveedor que autorizaron o como desconocido.
- Corregir la alineación de las fuentes que les pertenecenPara cada fuente legítima, logren que SPF o DKIM pasen en un dominio que coincida con su dominio From. DKIM es el más duradero de los dos porque sobrevive al reenvío.
- Pasar a quarantine con un porcentaje bajoCambien p=none por p=quarantine y agreguen pct=25. Un cuarto del correo que falla va a la carpeta de spam y el resto queda intacto, así que un error es sobrevivible.
- Subir el porcentaje y luego cambiar a rejectSuban el valor de pct a 100 a lo largo de unas semanas mientras vigilan los conteos de fallos. Solo cuando nada legítimo esté fallando deben establecer p=reject y eliminar la etiqueta pct.
Preguntas frecuentes
¿Qué significa p=none en DMARC?
Significa solo monitoreo. Los servidores receptores evalúan la alineación de SPF y DKIM, les envían reportes sobre el resultado y luego entregan el mensaje exactamente como lo harían sin DMARC. Cambia los reportes, no la entrega.
¿Es p=none mejor que no tener registro DMARC?
Sí, pero solo por los reportes. También cumple con lo mínimo que Google y Yahoo les piden a los remitentes masivos. No da ninguna protección contra alguien que suplante su dominio.
¿Cuánto tiempo hay que permanecer en p=none?
El tiempo suficiente para ver cada fuente que envía como su dominio, lo que normalmente significa al menos un ciclo de facturación completo para que aparezca el correo trimestral y anual. Dos semanas es el mínimo, no la meta.
¿Cambiar a p=reject romperá su correo?
Solo si alguna fuente legítima sigue fallando la alineación cuando hagan el cambio. Para eso son exactamente los reportes en p=none. Pasen primero por quarantine con un valor de pct y el riesgo será pequeño.