DMARC ha sido público desde 2012, pero la mayoría de los dominios de empresas todavía no lo aplican

Artículo original ↗ Discusión en Hacker News ↗

A pesar de ser un estándar desde 2012, el protocolo de autenticación de correo DMARC todavía no está aplicado por la mayoría de los dominios, dejando margen para direcciones de remitente falsificadas y ataques de suplantación. Los comentaristas describen cómo DMARC, combinado con SPF y DKIM, puede reducir el backscatter y mejorar la verificación de la identidad del remitente, pero también destacan la complejidad operativa, las herramientas deficientes, las configuraciones incorrectas incluso en grandes empresas y el impacto limitado sobre el spam que ya supera la autenticación. Muchos señalan que los opacos sistemas de reputación de los grandes proveedores de correo y su indiferencia ante los informes de abuso representan ahora un obstáculo mayor para un correo fiable y digno de confianza que la mera ausencia de registros DMARC.

Qué añade DMARC más allá de SPF/DKIM

  • Varios comentarios explican DMARC como una capa de política y alineación encima de SPF/DKIM: indica a los receptores qué hacer cuando las comprobaciones fallan (none/quarantine/reject) y garantiza que el “From” visible se alinee con los dominios autenticados.
  • Beneficios citados:
    • Reduce el spoofing y el backscatter (por ejemplo, menos rebotes falsos y respuestas OOO).
    • Hace más difícil suplantar grandes marcas y dominios bien configurados.
    • Algunos proveedores supuestamente tratan con más favor los dominios con DMARC aplicado para la colocación en la bandeja de entrada; otros se muestran escépticos.

Retos prácticos y configuraciones incorrectas

  • Muchas pequeñas organizaciones y personas no tienen tiempo ni experiencia; en DNS abundan los copiar y pegar, con registros de ejemplo p=none que quedan sin cambiar.
  • DMARC se describe como simple en teoría pero complicado en la práctica (subdominios, múltiples remitentes, reenvío, herramientas de marketing).
  • Las configuraciones incorrectas son comunes incluso en grandes empresas; algunos administradores ignoran fallos de SPF/DKIM/DMARC para evitar perder correo de clientes.
  • Otros se niegan a hacer whitelist y, en su lugar, presionan a TI remota para que arregle sus configuraciones, con resultados mixtos y mucha frustración.

Informes y herramientas

  • Algunos consideran que los informes agregados de DMARC (RUA) son ruidosos o inútiles, especialmente cuando todo el correo procede de un único servidor.
  • Otros usan herramientas o scripts personalizados para analizar los informes y verificar que todos los servicios de envío estén configurados.
  • Varios comentaristas dicen usar LLMs o herramientas en línea para analizar la configuración de DNS/DMARC e incluso automatizar cambios.

Eficacia contra spam y abuso

  • Hay un fuerte desacuerdo sobre su valor:
    • A favor: DMARC “resuelve” la identificación (quién envió realmente esto), lo cual es un requisito previo para otras defensas; detiene la suplantación directa de dominios.
    • En contra: hoy en día la mayor parte del spam y phishing pasa SPF/DKIM/DMARC mediante grandes proveedores o SaaS; DMARC aporta poco a la confianza del usuario, y el contenido sigue siendo lo que impulsa el filtrado.
  • Algunos sostienen que DMARC es ruido que bloquea correo legítimo cuando la gente configura mal los sistemas o rota mal las claves.

Problemas más amplios del ecosistema del correo electrónico

  • Quejas de que los grandes proveedores ignoran los informes de abuso, pero dominan el volumen de spam y los sistemas de reputación.
  • Quienes alojan su propio correo, especialmente los remitentes de bajo volumen, informan de buena configuración pero mala entregabilidad debido a la reputación de la IP y a heurísticas de volumen.
  • Algunos proponen correo comunitario/federado o incluso un protocolo nuevo con cifrado e identidad integrados; otros ven esto como poco práctico dada la forma en que se usa actualmente.