Cómo configurar SPF, DKIM y DMARC en Microsoft 365

Antes de mandar el primer correo de una campaña de outreach dirigido desde un dominio corporativo en Microsoft 365, hay tres registros DNS que tienen que estar publicados y verificados. El proceso tiene sus particularidades frente a Google Workspace — sobre todo en cómo Microsoft gestiona el SPF por defecto — y equivocarse en el orden es la causa más habitual de que un dominio nuevo arranque con entregabilidad baja sin que nadie entienda por qué.

Antes de empezar: qué necesitas y dónde se publica cada cosa

Los tres registros se publican en el DNS del dominio, no dentro de Microsoft 365. Necesitas acceso al panel donde está delegado el dominio — GoDaddy, Cloudflare, Namecheap, o el propio panel de dominios de Microsoft si lo compraste ahí. Si no tienes ese acceso, es el primer bloqueo a resolver antes de tocar nada del lado de Microsoft.

El orden recomendado es SPF, luego DKIM, luego DMARC, porque DMARC depende de que al menos uno de los dos anteriores esté funcionando correctamente. Saltarse el orden no rompe nada de forma irreversible, pero complica el diagnóstico si algo falla: es más fácil verificar un registro a la vez que los tres juntos.

SPF en Microsoft 365: el include que casi todos olvidan revisar

Microsoft 365 usa el include spf.protection.outlook.com para autorizar sus propios servidores de envío. Un registro SPF típico para una empresa que solo usa Microsoft 365 sería: v=spf1 include:spf.protection.outlook.com -all. Si además envías desde una plataforma de outreach, un CRM o un servicio de facturación que manda correo por SMTP, cada uno necesita su propio include añadido al mismo registro.

El fallo más común en este paso es publicar dos registros SPF distintos — uno para Microsoft y otro para la herramienta de envío — en lugar de fusionarlos en uno solo. El estándar SPF no permite dos registros TXT tipo spf1 en el mismo dominio; si existen ambos, la mayoría de servidores receptores los invalida por completo.

Para publicar el registro entras en tu panel de DNS, añades un registro tipo TXT en el host raíz (@ o directamente el nombre de dominio) con el valor completo del SPF, y esperas la propagación, que normalmente tarda entre unos minutos y unas pocas horas.

DKIM en Microsoft 365: hay que activarlo, no viene por defecto

A diferencia de SPF, que Microsoft 365 configura parcialmente solo, DKIM hay que activarlo a mano. Se hace desde el Centro de administración de Microsoft 365, dentro de Microsoft Defender, en la sección de políticas de autenticación de correo electrónico (Email authentication settings). Ahí seleccionas el dominio y activas la firma DKIM.

Al activarlo, Microsoft genera dos registros CNAME que hay que publicar en el DNS, con nombres del tipo selector1._domainkey y selector2._domainkey. A diferencia de un TXT normal, estos son CNAME que apuntan a un dominio de Microsoft — cópialos exactamente como los muestra el panel, sin modificar mayúsculas ni añadir puntos de más.

Una vez publicados ambos CNAME, vuelves al panel de Microsoft y confirmas la activación. El estado pasa de deshabilitado a habilitado, y a partir de ese momento todo el correo saliente de Microsoft 365 lleva firma DKIM. La propagación de estos CNAME suele tardar algo más que un TXT simple, así que conviene esperar un par de horas antes de dar por fallida la verificación.

DMARC: el mismo registro, independientemente del proveedor de correo

DMARC no depende de si usas Microsoft 365 o Google Workspace: es un registro TXT que se publica en _dmarc.tudominio.com, con un valor del tipo v=DMARC1; p=none; rua=mailto:dmarc-reports@tudominio.com. La política p=none es el punto de partida obligado — activa la recolección de informes sin bloquear nada.

Durante las primeras dos o tres semanas, revisa los informes agregados que llegan a la dirección rua. Ahí verás, por ejemplo, si el correo transaccional de una herramienta de facturación está fallando la alineación porque nadie la incluyó en el SPF. Solo cuando esos informes muestren que todo el correo legítimo pasa la verificación tiene sentido subir a p=quarantine y, más adelante, a p=reject.

Diferencias frente a Google Workspace y Gmail

En Google Workspace el SPF usa include:_spf.google.com en lugar del include de Microsoft, pero la lógica del registro es idéntica: un único TXT con todos los servicios autorizados. DKIM en Google Workspace se activa desde el panel de administración, en Apps > Google Workspace > Gmail > Autenticación de correo electrónico, y genera un único registro TXT con un selector propio de Google, en vez de los dos CNAME que usa Microsoft.

Si tu equipo usa Gmail con una cuenta personal o un alias sin Google Workspace de por medio, no puedes publicar DKIM porque no controlas el dominio de envío — @gmail.com no es tu dominio. Para outreach B2B corporativo esto descarta directamente el uso de cuentas Gmail gratuitas como remitente principal: no hay forma de autenticar un dominio que no es tuyo.

DMARC es idéntico en ambos casos porque no depende del proveedor de correo, solo del DNS del dominio. Esto significa que si en algún momento migras de Microsoft 365 a Google Workspace o viceversa, el registro DMARC no cambia — solo tendrás que actualizar SPF y volver a activar DKIM en la plataforma nueva.

• Microsoft 365: SPF con include:spf.protection.outlook.com, DKIM con dos CNAME que activas manualmente.
• Google Workspace: SPF con include:_spf.google.com, DKIM con un único TXT desde el panel de administración.
• DMARC: idéntico en ambos, un TXT en _dmarc.tudominio.com que no depende del proveedor.
• Gmail personal sin Google Workspace: no se puede autenticar como dominio propio, descartado para outreach corporativo.

Verificación final antes de lanzar la campaña

Con los tres registros publicados y propagados, el paso final es mandar un correo de prueba real desde la cuenta que vas a usar en la campaña hacia una dirección de Gmail y otra de Outlook que controles. Revisa los encabezados del mensaje recibido — en Gmail, "Mostrar original"— y confirma que aparecen spf=pass, dkim=pass y dmarc=pass.

Si alguno falla, no lances la campaña todavía. Un fallo en esta fase con volumen bajo de prueba es barato de corregir; el mismo fallo detectado después de mandar doscientos correos a decisores reales cuesta reputación de dominio que tarda semanas en recuperarse.

Preguntas frecuentes