Resumen

  • Palisade observó registros DMARC válidos en el 58,1 % de una muestra de 99.300 dominios; Internet Society Pulse presentó el estudio el 1 de septiembre.
  • El 20,7 % de quienes publicaban DMARC no indicaba una dirección para informes agregados. El dato no revela quién debía revisar la política ni qué incluía el contrato de correo.

Un servicio de correo tiene una fecha de alta. La lista de sistemas autorizados a enviar con el dominio, en cambio, puede cambiar mucho después: facturación, atención al cliente o campañas comerciales añaden nuevos remitentes. La contratación inicial no permite saber quién se ocupará de ese trabajo continuado.

Esta es una lectura de gobernanza del artículo invitado que Internet Society Pulse publicó el 1 de septiembre. Samuel Chenard, CEO y cofundador de Palisade, expone allí una investigación de su empresa. Internet Society advierte que las opiniones invitadas no representan necesariamente su posición.

Contar registros no equivale a auditar servicios

El benchmark de Palisade examina 99.300 dominios durante un escaneo de ocho minutos del 14 de agosto. Publicaban DMARC válido 57.732 dominios, el 58,1 % del total observado. Entre esos publicadores, 36.938 solicitaban cuarentena o rechazo —el 64 %— y 11.959 no incluían dirección de informes agregados —el 20,7 %—.

Son cifras publicadas por el investigador, no resultados que hayamos reproducido. Tampoco describen todo el correo empresarial: la muestra procede de dominios web muy bien situados en un ranking.

El proveedor visible en MX corresponde a la recepción del correo y puede ser una pasarela situada delante de otra plataforma. Aunque Palisade ajusta las comparaciones por franjas del ranking, la asociación observada no demuestra que contratar a una empresa cause una determinada política. No hay aquí base para declarar ganador a un proveedor ni para atribuir incumplimientos contractuales.

Hacer explícita la tarea que sigue

La pregunta aprovechable es quién mantiene la política una vez contratado el buzón. RFC 9989 relaciona DMARC con la autenticación alineada, el análisis de información recibida y la reparación de problemas de los remitentes legítimos. Su definición de propietario del dominio admite a proveedores que actúan para clientes. Delegar estas funciones es perfectamente compatible con el estándar.

Un servicio gestionado puede, por tanto, resolver el problema. Pero su alcance debe decir si cubre el inventario de remitentes, la lectura de informes, los ajustes de DNS y la aprobación de cambios. El nombre comercial del alojamiento no sustituye esa asignación.

Tampoco una política p=none demuestra desatención. RFC 9989 la recomienda al inicio para descubrir envíos legítimos y corregir su autenticación antes de pedir medidas más estrictas. La frecuencia del correo importa: una actividad ocasional puede requerir más tiempo de observación.

Los informes tienen una cautela parecida. No publicar una dirección no acredita que falte cualquier otra vigilancia; publicarla no acredita recepción ni análisis. RFC 9990 contempla condiciones de autorización de destinos externos y de entrega. Una consulta DNS no descubre quién está trabajando tras ese registro.

Externalizar con un reparto claro

Lu Heng distingue la especificación común mínima de las decisiones locales. Aplicada como interpretación editorial, no como requisito nuevo de la IETF, esa distinción permite ver la utilidad de DMARC sin pedirle que distribuya responsabilidades comerciales.

La organización puede conservar una parte de las tareas y encargar las demás, o contratar una gestión integral. Lo importante no es imponer que todo se haga internamente. Es que los nuevos remitentes, las correcciones y las decisiones posteriores a la compra tengan un responsable acordado. El estudio muestra configuraciones; la contratación debe concretar el trabajo que las mantiene.

Fuentes