Un registro DMARC puede parecer avance en email security y aun así no bloquear casi nada. Ese es el punto incómodo de las cifras de CipherCue: en 67,336 company domains revisados entre el 14 de abril y el 28 de julio de 2026, el 68.4% no tenía DMARC o seguía en p=none.

Política DMARC pasando de monitoring a quarantine y reject gates

No es un zero-day. Es un control incompleto. DMARC existe públicamente desde 2012 y en mayo de 2026 el IETF sustituyó RFC 7489 por RFC 9989, RFC 9990 y RFC 9991. El protocolo central ya está en Standards Track como Proposed Standard. El problema no es conocimiento; es pasar de “recibimos informes” a “pedimos rechazar la suplantación de nuestro dominio”.

DMARC es útil, pero no es magia anti-phishing. Ayuda contra exact-domain spoofing en el From visible. No detiene dominios parecidos, display-name spoofing, cuentas reales comprometidas ni phishing enviado desde plataformas grandes con autenticación válida. Aun así, si tu dominio puede falsificarse directamente, dejas abierto un atajo innecesario.

DMARC funciona sobre SPF y DKIM. SPF define qué servidores pueden enviar por el dominio. DKIM firma correo con una clave de dominio. DMARC comprueba si esa identidad autenticada se alinea con el visible From domain y dice qué hacer si falla.

Las políticas comunes son tres. p=none monitoriza y genera reports. p=quarantine pide tratar el mensaje fallido como sospechoso. p=reject pide rechazarlo. Los receptores conservan discreción, pero la diferencia práctica es clara: p=none es una alarma que escribe logs, no una puerta cerrada.

En el snapshot de CipherCue, 30,362 domains, el 45.1%, no tenían DMARC record. Entre los que sí tenían registro, 15,709 estaban en p=none, 10,258 en p=quarantine y 10,963 en p=reject. CipherCue cuenta enforcement como p=quarantine o p=reject, así que 46,071 domains del sample eran non-enforcing.

Hay que leer esos números con cuidado. CipherCue habla de su tracked entity set, no de una muestra representativa de todas las empresas del mundo. En Hacker News también se planteó una duda razonable: cuántos dominios eran parked, inactive, send-only o sin MX normal. Eso no borra el problema, pero evita convertir un dataset grande en una afirmación global excesiva.

La brecha existe porque p=reject no es solo editar DNS. Es inventario.

La organización necesita saber todos los servicios que envían como su dominio: Microsoft 365 o Google Workspace, CRM, marketing automation, billing, helpdesk, HR tools, ticketing, servidores antiguos, scanners y aplicaciones olvidadas. Cada flujo necesita SPF o DKIM alignment. Los unknown senders se arreglan, se mueven a subdominios o se apagan.

Los reports tampoco ayudan si nadie los entiende. Los aggregate reports de DMARC, ahora descritos en RFC 9990, son XML para máquinas. Para una organización pequeña que copió un DNS example, pueden ser archivos comprimidos sin una acción clara.

El miedo a romper correo legítimo es real. Si el sistema de facturas falla DKIM alignment, p=reject puede perder facturas. Si una plataforma de soporte envía con una ruta mal configurada, enforcement puede crear quejas de clientes. Nadie quiere mejorar seguridad y romper password resets.

Microsoft describió en enero de 2026 phishing que explotaba complex routing y spoof protections mal configurados. El mensaje práctico es sobrio: routing, connectors, forwarding y gateways cambian cómo se ve authentication desde el receptor.

El camino seguro es gradual. Primero, inventario de dominios: primary sending domains, marketing subdomains, transactional subdomains, parked domains y dominios que nunca deben enviar correo. Para no-send domains, SPF v=spf1 -all y DMARC p=reject; sp=reject suelen cerrar una vía fácil de abuso.

Para active domains, p=none debe ser una fase temporal. Usa una dirección de reporting que alguien lea y una herramienta que convierta XML en decisiones. Luego corrige alignment, sobre todo DKIM para servicios externos y correo reenviado.

Después avanza por etapas: p=none, p=quarantine, p=reject. Vigila helpdesk tickets, bounce logs, deliverability dashboards y DMARC reports. Documenta owner, platform, domain/subdomain, authentication method y rollback contact para cada sender.

DMARC no elimina phishing. Pero enforcement sí elimina el truco barato de enviar correo que parece venir directamente de tu dominio cuando authentication falla. Por eso p=none no debería ser destino final. Es útil para aprender quién envía por ti; dejado indefinidamente, es seguridad que solo mira.