DMARC explicado: por qué su correo es vulnerable y cómo arreglarlo en 24h

DMARC es uno de los controles de ciberseguridad más baratos al alcance de una empresa mediana europea. Implementarlo bien no requiere comprar licencia, ni montar infraestructura nueva, ni contratar, ni obtener un certificado de cumplimiento. Implementarlo mal cuesta lo mismo. La diferencia entre ambas es un par de días de disciplina operativa.

Abrimos cada encargo OSINT defensivo con una comprobación de DMARC, SPF y DKIM sobre los dominios principales del cliente. En 2025 y la primera mitad de 2026, la empresa mediana europea típica que analizamos tenía al menos uno de estos tres controles mal configurado. Lo más habitual era DMARC en `p=none` desde el día en que se publicó, sin nadie monitorizando los informes agregados que debía generar.

Este artículo es un plan operativo para pasar de "tenemos DMARC sobre el papel" a "estamos protegidos al nivel que la directiva espera". Asumimos que su empresa usa Microsoft 365 o Google Workspace como plataforma principal; los pasos son equivalentes en ambos casos, con detalles propios de cada proveedor cuando difieren.

Qué hace DMARC y qué no hace

DMARC son las siglas de Domain-based Message Authentication, Reporting and Conformance. Es una política expresada en un registro TXT de DNS que indica a los servidores receptores qué hacer con un mensaje que dice venir de su dominio pero falla las comprobaciones SPF o DKIM subyacentes. La política puede ser `none` (solo monitorizar), `quarantine` (mover a no deseados) o `reject` (rechazar entrega).

DMARC no cifra su correo, no impide que sus cuentas se comprometan por reutilización de credenciales y no le protege de mensajes enviados desde dominios parecidos. Protege la entregabilidad y la autenticidad del correo realmente enviado desde su dominio y hace que su dominio sea muy difícil de suplantar a escala.

Para el fraude del CEO o BEC, la amenaza más cara por correo para empresas medianas europeas en los últimos años, DMARC en `p=reject` corta uno de los cuatro pretextos más comunes: el mensaje que dice venir del dominio del CEO en sí mismo, no de uno parecido.

Por qué la mayoría de empresas medianas está en p=none

La razón rara vez es desconocimiento. La razón es miedo a romper el correo. Pasar de `p=none` a `p=quarantine` o `p=reject` puede, mal hecho, hacer que correo legítimo caiga en no deseados o sea rechazado. La dirección suele recordar el día en que una notificación del consejo cayó en spam con más viveza que el día en que una factura fraudulenta no llegó.

La solución a ese miedo es el informe agregado. La etiqueta `rua` de DMARC pide a los servidores receptores que envíen informes diarios resumiendo quién intentó enviar correo desde su dominio y si SPF y DKIM pasaron. Con dos semanas de esos informes puede construir una imagen completa de cada remitente legítimo que necesita autorizar, antes de endurecer la política.

El arreglo de 24 horas, hora a hora

Asumimos que ya ha publicado un registro DMARC en `p=none` con una `rua` que funciona. Si no, la primera acción es hacerlo y esperar dos semanas. El plan siguiente aplica a la segunda fase.

Hora 0 a 4 · Inventario de remitentes legítimos

Recoja los últimos 14 días de informes agregados. Clasifique las IP de origen en cuatro grupos:

1. Su plataforma de correo principal (M365 o Google Workspace).

2. Sus plataformas transaccionales y de marketing (AWS SES, Mailgun, SendGrid, Mailchimp, Acumbamail, su propia instancia Auctimail si la tiene).

3. Sus herramientas de soporte y CRM que envían correo en su nombre (Zendesk, HubSpot, Intercom, Front).

4. Fuentes desconocidas.

El cuarto grupo es el trabajo. Cada IP allí es o un remitente legítimo no documentado o un intento de suplantación. Trace cada una. Las sorpresas más comunes son: un servidor de aplicación local heredado que sigue enviando facturas por un relay olvidado, una herramienta de RR. HH. contratada el año pasado por un equipo sin coordinar con TI y un asesor externo que configuró su dominio en su propio cliente de correo porque nadie le dijo que no lo hiciera.

Hora 4 a 8 · Limpieza del SPF

Su registro SPF es una lista de remitentes que autoriza. Edítelo de modo que:

• Cada remitente legítimo del inventario esté incluido vía el mecanismo `include:` adecuado (p. ej. `include:_spf.google.com`, `include:amazonses.com`).
• Se eliminen direcciones IP fijas salvo que correspondan a un remitente que controla y quiere conservar.
• El registro no supere 10 búsquedas DNS (una causa silenciosa frecuente de fallo). Si las supera, aplane con un servicio o reestructure por subdominios.
• El mecanismo final sea `-all` (fallo duro), no `~all` (fallo suave).

Un SPF limpio para una empresa mediana en Google Workspace, AWS SES y HubSpot se lee algo así: `v=spf1 include:_spf.google.com include:amazonses.com include:_spf.hubspot.com -all`. Cualquier cosa sustancialmente más compleja es síntoma de deriva acumulada.

Hora 8 a 12 · Verificación de DKIM

Para cada remitente legítimo que admita firma DKIM en su nombre, verifique que el selector está publicado y la clave pública es actual. Microsoft 365 usa `selector1` y `selector2`. Google Workspace usa un selector configurable, típicamente `google`. AWS SES usa tres registros CNAME apuntando a su infraestructura de firma DKIM.

La comprobación es simple: envíe un mensaje de prueba desde cada plataforma a un buzón que exponga las cabeceras crudas (`mailtester.com`, buzón de prueba de `dmarcian.com`, o una cuenta de Gmail con "mostrar original" activado) y verifique `spf=pass` y `dkim=pass` para el alineamiento relevante.

Si algún remitente legítimo no admite DKIM en su nombre, tiene una decisión estratégica. O bien acepta que esos mensajes fallarán el alineamiento DMARC (y pide al remitente que actualice o lo sustituye), o bien mantiene la política en `p=quarantine` en vez de `p=reject` hasta que cierre la brecha. Hemos dejado de recomendar lo segundo; los proveedores que en 2026 no firman con DKIM en su nombre son proveedores de los que debería alejarse.

Hora 12 a 16 · Mover a p=quarantine, pct=100

Actualice el registro DMARC a `p=quarantine; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]; sp=quarantine; adkim=s; aspf=s`. Las marcas estrictas (`adkim=s; aspf=s`) no siempre hacen falta; el modo relajado por defecto es aceptable para la mayoría de empresas medianas. Lo importante es comprometerse con una acción de cuarentena real y monitorizar.

Vigile los informes agregados las siguientes 24 horas. Si un remitente legítimo no identificado empieza a fallar, añádalo a la configuración SPF o DKIM antes de seguir al siguiente paso.

Hora 16 a 24 · Mover a p=reject

Actualice el registro DMARC a `p=reject; pct=100; rua=...; ruf=...; sp=reject; adkim=s; aspf=s`. Comunique a su dirección que el correo que suplante su dominio será rechazado por los servidores receptores que respeten DMARC, lo que incluye esencialmente a toda la población de grandes proveedores de correo.

Programe una cita en su calendario a 14 días vista para revisar los informes agregados de nuevo en busca de algún remitente legítimo que el cambio haya roto. Para entonces las sorpresas suelen ser pequeñas y fáciles de arreglar.

Sobre BIMI

BIMI (Brand Indicators for Message Identification) es un control complementario que permite que su logo verificado aparezca junto a mensajes autenticados en clientes de correo compatibles. Requiere DMARC en `p=quarantine` o `p=reject` con `pct=100`, un SVG verificado del logo y un Verified Mark Certificate emitido por una autoridad autorizada.

Para una empresa mediana, BIMI es un complemento, no una necesidad de seguridad. El orden honesto es DMARC primero, BIMI después y solo si la exposición de marca justifica el coste del certificado y la sobrecarga operativa de mantener el VMC.

Trampas honestas

• Subdominios heredados. Muchas empresas refuerzan DMARC en el dominio raíz y olvidan `marketing.sudominio.com` o `mail.sudominio.com`. Son obligatorios registros DMARC explícitos por subdominio, o un `sp=reject` estricto en la raíz.
• Herramientas "DMARC" de terceros. Varios SaaS gestionarán DMARC por usted. Son cómodos y son también un tercero que ve los metadatos de cada mensaje que dice venir de su dominio. Lea el acuerdo de tratamiento de datos antes de firmar.
• Fusiones y adquisiciones. Cuando adquiere una empresa, hereda su postura DMARC. Conviértalo en un punto de día uno de la lista de integración.

> "Hemos medido el tiempo desde un DMARC `p=none` hasta una postura `p=reject` operativa en empresas medianas, cuando el trabajo lo lleva un único ingeniero con cobertura ejecutiva. La mediana es de 28 horas. El propósito del plan de 24 horas es que el segundo día sea de pulido, no de pánico." — Nota de campo IBL, 2026

Qué hacemos en IBL

Nuestro sprint DMARC es un encargo fijo: dos días de trabajo, uno de monitorización y uno de pulido. El entregable es el registro DMARC operativo, el registro SPF, la documentación de la configuración DKIM, un inventario de cada remitente autorizado y un runbook de una página para el ingeniero que va a sostener el control en adelante.

Si quiere conversar sobre su postura DMARC actual, escriba a [email protected]. Respondemos en un día hábil.

---

Ibida Black Level S.L. es una consultora boutique de ciberseguridad con sede en Málaga y equipo operativo en Rumanía. Trabajamos con empresas medianas europeas que prefieren la honestidad técnica al envoltorio comercial. Fuimos fundados en 2026; no inventamos una historia más larga.

Lectura relacionada

• OSINT 101: 7 cosas que un atacante encuentra sobre su empresa en 30 minutos (cluster pillar Q4)
• Autoevaluación NIS2: 25 preguntas para saber si su empresa cumple (cluster pillar Q3)
• Email exposure scanner: cómo leer el informe sin entrar en pánico (cluster Q4)

Etiquetas: dmarc, spf, dkim, seguridad-correo, anti-suplantación, bec, cumplimiento