DMARC, SPF y DKIM: guía completa de autenticación de email para empresas

El problema: cualquiera puede enviar un email como si fuera tu empresa

El protocolo SMTP no tiene autenticación de origen. Fue diseñado en 1982, cuando internet era una red académica donde todos se conocían. El campo `From:` que ves en tu cliente de correo es texto libre: cualquiera puede escribir lo que quiera ahí.

Un atacante puede enviar un email que parece venir de `facturacion@tuempresa.com.mx` a tus clientes, con una factura falsa y sus propios datos bancarios. Sin autenticación de email configurada, no hay nada técnico que lo impida.

Las consecuencias son concretas:

• Fraude de facturación. Un cliente paga una factura real por un monto real a una cuenta que no es tuya. El fraude se descubre semanas después, cuando tú reclamas el pago.
• Suplantación interna. Un empleado de finanzas recibe un correo "del director general" pidiendo una transferencia urgente y confidencial.
• Entregabilidad. Tus correos legítimos caen en spam porque tu dominio no está autenticado y los filtros no pueden distinguirlo de quien lo suplanta.
• Reputación de dominio. Tu dominio aparece en listas de bloqueo por el spam que alguien más envía en tu nombre.

Los tres protocolos, y cómo se relacionan

SPF, DKIM y DMARC se explican casi siempre como tres cosas independientes. No lo son: SPF y DKIM son mecanismos de verificación, y DMARC es la política que decide qué hacer con el resultado. Sin DMARC, SPF y DKIM producen un veredicto que nadie está obligado a respetar.

SPF — qué servidores pueden enviar por ti

SPF publica, en un registro TXT de tu DNS, la lista de servidores autorizados a enviar correo con tu dominio.

Para un tenant de Microsoft 365 el registro mínimo es:

```

v=spf1 include:spf.protection.outlook.com -all

```

El calificador final es la parte que casi todos configuran mal:

| Calificador | Significado | Resultado |

|---|---|---|

| `-all` | Hard fail | Rechaza lo no autorizado |

| `~all` | Soft fail | Marca como sospechoso, entrega igual |

| `?all` | Neutral | No dice nada. Equivale a no tener SPF |

| `+all` | Permite todo | Autoriza al mundo entero a suplantarte |

`~all` es el valor por defecto de muchas guías y es el que encontramos con más frecuencia. Su efecto real depende del receptor: algunos lo tratan como fallo, otros lo ignoran. Si tu DMARC está en `p=reject`, el calificador de SPF importa menos — pero mientras no lo esté, `~all` es una puerta abierta.

#### El límite de 10 búsquedas DNS: el fallo silencioso más común

Aquí está el error que rompe SPF sin que nadie se entere. La RFC 7208 §4.6.4 limita la evaluación de un registro SPF a 10 mecanismos que requieran una búsqueda DNS. Cuentan contra ese límite:

`include:` · `a` · `mx` · `ptr` · `exists:` · y los `redirect=` de cada nivel.

No cuentan: `ip4:`, `ip6:`, `all`.

El problema es que el límite es recursivo. Un `include:` no cuesta una búsqueda: cuesta una búsqueda más todas las que ese registro incluya a su vez. Un solo `include:` de una plataforma de marketing puede consumir cuatro o cinco por sí mismo.

Un registro que parece razonable:

```

v=spf1 include:spf.protection.outlook.com include:_spf.google.com

include:servers.mcsv.net include:sendgrid.net

include:_spf.salesforce.com mx a -all

```

…supera el límite con facilidad. Cuando eso ocurre, el resultado de la evaluación no es "fallo": es `permerror`. Y ese es el detalle importante — la mayoría de los receptores tratan `permerror` como SPF no verificado, no como SPF fallido. Tu correo legítimo empieza a fallar la alineación de DMARC de forma intermitente, según el receptor, y el registro se ve perfectamente bien a simple vista.

Cómo se corrige:

1. Elimina `include:` de servicios que ya no usas. Es la causa más frecuente y la más barata de arreglar.

2. Sustituye `include:` por `ip4:`/`ip6:` cuando el proveedor publique rangos estables. No consumen búsquedas.

3. Quita `mx` y `a` si tus servidores de correo ya están cubiertos por un `include:`.

4. Nunca uses `ptr`. Está formalmente desaconsejado por la propia RFC 7208.

DKIM — que el mensaje no fue alterado, y que salió de ti

DKIM firma criptográficamente cada mensaje. La clave privada vive en tu servidor de correo; la pública se publica en DNS. El receptor verifica la firma.

En Microsoft 365 la publicación se hace con dos CNAME por dominio:

```

selector1._domainkey.tudominio.com

selector2._domainkey.tudominio.com

```

Son dos porque Microsoft rota las claves alternando entre ambos selectores. Si publicas solo uno, la firma se rompe en la primera rotación.

El detalle que casi nadie menciona: Microsoft 365 firma todo el correo saliente desde el primer día, pero para un dominio personalizado lo hace con el dominio `onmicrosoft.com` del tenant hasta que habilitas DKIM explícitamente. Esa firma es válida — y no alinea con tu dominio, así que no sirve para DMARC. Un tenant recién configurado tiene DKIM "funcionando" y, aun así, no aporta nada a su política DMARC.

DMARC — la política, y los reportes

DMARC publica en `_dmarc.tudominio.com` qué debe hacer el receptor cuando un mensaje no se autentica, y a dónde enviarte los reportes.

```

v=DMARC1; p=reject; rua=mailto:dmarc@tuempresa.com.mx; sp=reject; adkim=s; aspf=s

```

Las tres políticas posibles:

1. `p=none` — no hagas nada, solo repórtame. Es un punto de partida, no un destino.

2. `p=quarantine` — envía a spam lo que no se autentique.

3. `p=reject` — rechaza en el servidor lo que no se autentique.

`p=none` no protege absolutamente nada. Es el equivalente a instalar cámaras y no mirarlas nunca. Es el estado más común que encontramos: el dominio publica DMARC, el administrador lo da por hecho, y la suplantación sigue siendo posible exactamente igual que antes.

Alineación: por qué tu correo pasa SPF y aun así falla DMARC

Esta es la parte que falta en casi todas las guías, y la razón por la que las migraciones a `p=reject` rompen correo legítimo.

DMARC no comprueba solamente que SPF o DKIM pasen. Comprueba que el dominio que pasó la verificación coincida con el dominio del `From:` que ve el usuario. A eso se le llama alineación.

Un mensaje tiene dos remitentes distintos:

• El `Return-Path` (o `MAIL FROM`), que es contra el que se evalúa SPF. El usuario nunca lo ve.
• El `From:` de la cabecera, que es el que aparece en el cliente de correo.

Una plataforma de marketing típicamente envía con `Return-Path: bounces@plataforma.com` y `From: tu@tuempresa.com`. SPF pasa — el servidor está autorizado para `plataforma.com`. Y DMARC falla, porque el dominio verificado no es el del `From:`.

Los dos modificadores controlan qué tan estricta es la comparación:

• `aspf=r` / `adkim=r` (relajado, el valor por defecto): basta con que coincida el dominio organizacional. `correo.tuempresa.com` alinea con `tuempresa.com`.
• `aspf=s` / `adkim=s` (estricto): el dominio debe coincidir exactamente.

De aquí salen dos conclusiones prácticas:

DKIM es más robusto que SPF para alineación. La firma DKIM viaja con el mensaje y sobrevive al reenvío; SPF se evalúa contra el último servidor que entregó, así que un reenvío lo rompe casi siempre. Si un servicio te permite firmar con DKIM usando tu propio dominio, hazlo: es lo que mantiene DMARC en pie cuando alguien reenvía tu correo.

Nunca actives el modo estricto sin haber leído los reportes primero. `adkim=s` rompe cualquier servicio legítimo que firme con un subdominio.

La ruta de implementación, sin romper correo

El fallo más caro no es no tener DMARC: es activar `p=reject` y bloquear tu propia facturación durante una semana.

Semana 1 — inventario. Lista todo lo que envía correo con tu dominio: Microsoft 365, el CRM, la plataforma de marketing, el sistema de facturación, el ERP, los formularios del sitio, las herramientas de firma electrónica. La lista siempre es más larga de lo que el administrador recuerda. Publica SPF cubriéndolos y verifica que estés por debajo de las 10 búsquedas.

Semana 2 — DKIM. Habilítalo en Microsoft 365 y publica los dos CNAME. Después, en cada servicio de terceros que lo permita, configura la firma con tu propio dominio en lugar de aceptar la del proveedor.

Semana 3 — DMARC en observación. Publica `p=none` con `rua=`. No cambies nada más.

Semanas 4 a 7 — leer. Los reportes agregados llegan como XML diario de cada receptor grande. Buscas una sola cosa: fuentes que envían correo legítimo tuyo y no están alineadas. Cada una es un servicio que hay que arreglar antes de endurecer la política.

Semana 8 — cuarentena. Pasa a `p=quarantine`, idealmente con `pct=` para hacerlo gradual. Vigila dos semanas.

Semana 10 — rechazo. `p=reject`, y `sp=reject` para los subdominios. Sin `sp=`, los subdominios heredan la política del dominio principal — pero declararlo explícitamente evita sorpresas cuando alguien crea `mail.tuempresa.com` el año que viene.

Los reportes se siguen leyendo después. DMARC no es un proyecto que se cierra; es una configuración que se mantiene.

La capa de transporte: MTA-STS, TLS-RPT, DNSSEC y BIMI

SPF, DKIM y DMARC autentican quién envía. No dicen nada sobre si la conexión que transporta el mensaje va cifrada, ni sobre si alguien puede degradarla.

MTA-STS (RFC 8461) obliga a que la entrega hacia tu dominio use TLS válido, cerrando el ataque de degradación en el que un intermediario suprime el `STARTTLS` y el correo viaja en claro. Se publica en dos partes: un TXT en `_mta-sts.tudominio.com` y un archivo de política servido por HTTPS en `mta-sts.tudominio.com`.

Aquí hay un detalle que importa: la política tiene tres modos, y `mode: testing` no protege nada. Anunciar MTA-STS sin poner `mode: enforce` es exactamente el mismo placebo que `p=none`: la configuración existe, se ve bien en una auditoría superficial, y no cambia el comportamiento de un solo mensaje.

TLS-RPT (RFC 8460) es el canal por el que te enteras de que la entrega TLS está fallando. Se publica en `_smtp._tls.tudominio.com`. Sin él, MTA-STS falla en silencio.

DNSSEC firma tus respuestas DNS. Sin él, todo lo anterior descansa sobre registros que un atacante en posición de red puede falsificar: tu SPF, tu DKIM y tu DMARC son solo tan confiables como el DNS que los publica.

BIMI muestra el logotipo de tu marca en el cliente de correo, y exige DMARC en `p=quarantine` o `p=reject` con un certificado de marca verificada (VMC). Es el único de los cuatro cuyo beneficio es comercial antes que técnico — y solo es alcanzable si ya hiciste bien todo lo demás.

Cómo leer un reporte agregado de DMARC

El `rua=` te trae un XML comprimido por receptor y por día. Es el documento que decide si puedes endurecer tu política, y casi nadie lo explica. Esta es la estructura que importa:

```xml

<record>

<row>

<source_ip>203.0.113.45</source_ip>

<count>128</count>

<policy_evaluated>

<disposition>none</disposition>

<dkim>fail</dkim>

<spf>pass</spf>

</policy_evaluated>

</row>

<identifiers>

<header_from>tuempresa.com.mx</header_from>

</identifiers>

<auth_results>

<spf><domain>plataforma.com</domain><result>pass</result></spf>

</auth_results>

</record>

```

Léelo así:

• `count` es cuántos mensajes vinieron de esa IP ese día. Te dice si la fuente es relevante o ruido.
• `policy_evaluated` es el resultado después de la alineación. Es el que manda.
• `auth_results` es el resultado crudo, antes de alineación.

El caso del ejemplo es exactamente el que rompe migraciones: `auth_results` dice `spf: pass`, y `policy_evaluated` dice `spf: pass` con `dkim: fail`. El mensaje sobrevive porque DMARC pasa si uno de los dos alinea. Si esa plataforma dejara de alinear SPF —un cambio de proveedor, un dominio de rebote nuevo— esos 128 mensajes diarios empezarían a rechazarse el día que pongas `p=reject`.

Lo que buscas en cada reporte es una sola cosa: filas donde `header_from` es tu dominio, el volumen no es trivial, y `policy_evaluated` muestra `fail` en ambos. Cada una es correo tuyo que se va a bloquear, o correo de alguien suplantándote. Distinguirlas es el trabajo real, y se hace por `source_ip`: si la IP pertenece a un proveedor que reconoces, es tuyo y hay que arreglarlo; si no, es la suplantación que DMARC existe para detener.

Los reportes forenses (`ruf=`) son otra cosa: llegan por mensaje fallido e incluyen cabeceras. La mayoría de los receptores grandes ya no los envían por privacidad, así que no construyas tu proceso sobre ellos.

Configuración por proveedor

La mayoría de los dominios envían desde cuatro o cinco sistemas distintos. Estos son los que encontramos con más frecuencia en tenants de Microsoft 365.

Microsoft 365. `include:spf.protection.outlook.com` en SPF; DKIM se habilita por dominio en el centro de administración de Defender (Directivas → Reglas → DKIM) y publica los dos CNAME de selector. Un dominio recién agregado no tiene DKIM habilitado aunque el correo ya salga.

Google Workspace, si conviven: `include:_spf.google.com`, y DKIM se genera en la consola de administración con el selector `google`.

Mailchimp / Intuit. `include:servers.mcsv.net`. Por defecto firma con su propio dominio, lo que no alinea. Hay que configurar la autenticación de dominio en la plataforma para que firme con el tuyo.

SendGrid. `include:sendgrid.net`, y su "Domain Authentication" publica CNAMEs bajo un subdominio tuyo. Ese es el modo correcto: firma alineada con tu dominio.

Salesforce / Dynamics. `include:_spf.salesforce.com` y equivalentes. Ambos permiten firma DKIM propia y ambos vienen desalineados de fábrica.

Sistemas de facturación y ERP. Los peores en la práctica: muchos envían por SMTP autenticado desde una IP fija sin soporte de DKIM. Para esos, `ip4:` directo en SPF y alineación por SPF, sin DKIM. Funciona, pero se rompe con cualquier reenvío.

Diagnóstico: síntoma, causa, corrección

| Síntoma | Causa más probable | Corrección |

|---|---|---|

| El correo de facturación cae en spam solo en Gmail | DMARC en `p=none` y sin alineación DKIM | Firma con tu dominio en el sistema de facturación |

| SPF "pasa" pero DMARC falla | Desalineación: el `Return-Path` es del proveedor | Configura la autenticación de dominio en el proveedor |

| Funcionaba y dejó de funcionar sin cambios | Se superó el límite de 10 búsquedas al crecer un `include:` de terceros | Audita el presupuesto de búsquedas; sustituye `include:` por `ip4:` |

| Falla solo cuando alguien reenvía | SPF no sobrevive al reenvío, por diseño | Depende de DKIM para alinear, no de SPF |

| DKIM se rompió a los meses | Se publicó un solo selector | Publica `selector1` y `selector2` |

| Los reportes DMARC nunca llegan | `rua=` apunta a un buzón de otro dominio sin registro de autorización | Usa un buzón de tu propio dominio, o publica el registro de autorización externa |

Ese penúltimo caso merece una nota: si tu `rua=` apunta a un dominio distinto del que publica el DMARC, el dominio receptor debe publicar un registro de autorización (`tudominio.com._report._dmarc.receptor.com`). Sin él, la mayoría de los receptores no envían nada, y el administrador concluye que "DMARC no funciona".

Preguntas frecuentes

¿Cuánto tarda en propagarse un cambio de DNS?

Lo que diga el TTL del registro, normalmente entre 5 minutos y una hora. Baja el TTL a 300 segundos antes de una migración de política, no durante.

¿Puedo tener dos registros SPF?

No. Un dominio con dos registros `v=spf1` produce `permerror` y falla todo. Si necesitas cubrir más servicios, combínalos en un solo registro respetando el límite de búsquedas.

¿DMARC protege mis subdominios?

Sí, por herencia, salvo que publiques una política distinta en el subdominio. Declara `sp=` explícitamente: es lo que protege los subdominios que aún no existen, que son el vector preferido para suplantar una marca.

¿Qué pasa con los dominios que no envían correo?

Publica igualmente. Un dominio parqueado sin SPF ni DMARC es suplantable, y es el que un atacante elegirá precisamente porque nadie lo vigila. Para esos: `v=spf1 -all` y `v=DMARC1; p=reject;`.

¿BIMI vale la pena?

Solo cuando ya tienes `p=quarantine` o `p=reject` funcionando. El certificado VMC tiene costo anual y exige una marca registrada. Es el último paso, no un atajo.

¿Esto me protege del phishing?

De la suplantación exacta de tu dominio, sí. No protege de dominios parecidos (`tuempresa-mx.com`), ni de nombres para mostrar falsificados en un dominio ajeno. Esas son otras defensas: monitoreo de dominios similares y reglas de anti-suplantación en el propio tenant.

Cómo verificar tu configuración

La auditoría gratuita de simiriki resuelve tu DNS en vivo y evalúa diez controles de autenticación de correo, cada uno contra su RFC: presencia y rigor de SPF (incluido el límite de 10 búsquedas de la RFC 7208), los selectores DKIM de Microsoft 365, presencia y nivel de aplicación de DMARC, y la capa de transporte — MTA-STS con verificación de `mode: enforce`, TLS-RPT, DNSSEC y BIMI.

Cuando un registro no se puede determinar —porque el resolutor devuelve SERVFAIL, o porque la política de MTA-STS no es alcanzable— el control se reporta como no determinado, nunca como aprobado ni como fallido. Un veredicto inventado sobre tu correo es peor que no dar ninguno.

Verifica la autenticación de correo de tu dominio →