Para proteger el dominio de correo de una empresa configure tres mecanismos de autenticación mediante DNS: SPF enumera los servidores autorizados a enviar en nombre de su dominio, DKIM añade una firma que el receptor puede verificar y DMARC expresa lo que usted quiere que haga el receptor cuando ni SPF ni DKIM producen un resultado válido y alineado con el dominio visible del campo De, y adónde enviar los informes. Configúrelos en ese orden, empiece DMARC en modo de supervisión, lea los informes y solo después endurezca la política.
Sin ellos, los servidores receptores tienen menos en qué basarse cuando alguien envía un mensaje que dice venir de su dominio. Esta guía es general y está pensada para empresas con poco o ningún equipo de IT propio. Los registros de SPF, de DKIM y de dominios aparcados proceden de la documentación oficial de Microsoft y de Google, enlazada para que pueda comprobar los valores vigentes en su caso; el registro DMARC inicial es un ejemplo construido con la misma sintaxis.
¿Dudas sobre esta guía? Hable con nosotros
¿Qué hace cada uno: SPF, DKIM y DMARC?
Cada registro responde a una pregunta distinta cuando un mensaje llega al servidor de correo de otra empresa.
| Registro | Pregunta que responde | Dónde está en el DNS | Qué publica usted |
|---|---|---|---|
| SPF | ¿Está este servidor autorizado a enviar correo del dominio de la dirección del sobre (la de retorno) del mensaje? | Un registro TXT en el dominio | Una lista de remitentes permitidos y una regla para todos los demás |
| DKIM | ¿Firmó el dominio este mensaje y llega sin cambios? | Registros publicados bajo un nombre de selector, como selector1._domainkey | La clave pública que le da su servicio de correo |
| DMARC | ¿Supera SPF o DKIM la comprobación para el dominio que ve el lector en el campo De y qué debe pasar si no? | Un registro TXT llamado _dmarc | Una política (none, quarantine o reject) y una dirección de informes |
Las definiciones formales están en la RFC 7208 para SPF, la RFC 6376 para DKIM y la RFC 9989 para DMARC (los textos están en inglés). Como explica Microsoft, un mensaje supera DMARC si la comprobación de SPF o la de DKIM es correcta y el dominio autenticado está alineado con el dominio visible del campo De. La alineación relajada admite normalmente el mismo dominio organizativo; la estricta exige dominios idénticos. Una autenticación válida sin esa alineación puede seguir dando un fallo DMARC en un remitente de terceros.
Leer los pasos en texto
DKIM y DMARC antes de aplicar una política
¿Estas reglas afectan a una pequeña empresa?
Sí, por dos motivos. Primero, Microsoft presenta estos registros como una forma de ayudar a evitar los remitentes falsificados que se usan en el fraude por compromiso del correo empresarial y en el phishing, y ese riesgo no depende del tamaño de la empresa. Segundo, algunos receptores los piden. Las directrices para remitentes de correo de Google indican que quien envíe a cuentas de Gmail debe configurar SPF o DKIM, y que quien envíe más de 5.000 mensajes al día a cuentas de Gmail debe configurar SPF, DKIM y DMARC, alinear el dominio del campo De con el de SPF o el de DKIM y ofrecer la baja con un solo clic en los mensajes de marketing. Por debajo de ese volumen las reglas para grandes remitentes no se aplican directamente, pero una herramienta de boletines puede cambiar el panorama, así que configure los tres. Compruebe las reglas vigentes, porque cambian.
¿Qué necesita saber antes de tocar el DNS?
La mayoría de los problemas de autenticación del correo vienen de una lista de remitentes incompleta, no de la sintaxis. Elabore esta lista antes de cambiar ningún registro.
- Todos los dominios y subdominios desde los que se envía correo y todos los dominios que posee pero no usa para correo.
- Todos los servicios que envían correo con su dominio: la plataforma de correo principal, los formularios de la web, las herramientas de boletines, de facturación o de CRM, un servicio de asistencia (help desk), escáneres e impresoras y cualquier servidor de correo propio.
- Quién controla el DNS. En Microsoft 365, los registros SPF y DMARC de su propio dominio se crean en su registrador o en su proveedor de DNS, porque no existe un portal de administración para ellos. Mantenga ese acceso a nombre de su empresa.
- Un buzón o un grupo compartido para los informes DMARC, no la bandeja de entrada de una persona.
Añada los accesos al registrador y al DNS a su documentación de IT y a su rutina de bajas, como la de nuestro checklist de alta y baja de empleados en IT, para que no se vayan con una sola persona.
¿Cómo se configura SPF?
SPF es un único registro TXT en cada dominio o subdominio que envía correo. Su forma básica es v=spf1, después los orígenes permitidos y, por último, una regla para todo lo demás.
El registro para Microsoft 365 y para Google Workspace
La guía de SPF de Microsoft da este registro para un dominio cuyo único origen de correo es Microsoft 365: v=spf1 include:spf.protection.outlook.com -all. La página de SPF de Google da este otro para un dominio que envía solo con Google Workspace: v=spf1 include:_spf.google.com ~all. Algunas nubes para administraciones públicas y regionales usan valores distintos, detallados en la página de Microsoft. Si además envía desde un servidor de correo propio, añada su dirección IP pública con ip4: o ip6:. Si otro servicio le indica que añada un include, añádalo al mismo registro en lugar de crear un segundo, pero para los servicios que no controla Microsoft recomienda un subdominio (véase el apartado de DKIM más abajo).
Las tres reglas que rompen SPF
- Un registro por dominio o subdominio. Microsoft indica que varios registros SPF con el mismo nombre provocan un error permanente, y la RFC 7208 dice lo mismo. Reúna todos los remitentes en un solo registro.
- No más de 10 consultas DNS. Cuentan cada include, a, mx, exists y redirect (la RFC 7208 cuenta también ptr), y los include anidados suman más. Las direcciones ip4: e ip6: no cuentan. Superado el límite, SPF falla con un error permanente. Un subdominio da a un servicio masivo o de terceros su propio límite.
- Sintaxis cuidadosa. Compruebe el contenido TXT, la versión v=spf1, los mecanismos admitidos y sus separadores. No confunda el campo del nombre DNS con el valor TXT ni introduzca espacios dentro de un mecanismo include. Valide el registro final y las consultas de sus include antes de confiar en él.
Los subdominios necesitan su propio registro SPF: el de example.com no cubre marketing.example.com. Para los dominios que posee pero no usa para correo, Microsoft recomienda v=spf1 -all.
-all o ~all: qué dicen los dos fabricantes
El calificador cambia el resultado SPF de un origen no autorizado: -all indica fail y ~all indica softfail. Ninguno es un resultado SPF válido para superar DMARC. Una firma DKIM válida y alineada todavía puede hacer que DMARC se supere. Elija el final de SPF según la guía vigente de su proveedor y un inventario completo de remitentes; no desactiva DMARC ni sustituye su despliegue gradual.
¿Cómo se configura DKIM?
DKIM necesita un par de claves: su servicio de correo guarda la clave privada y firma los mensajes salientes, y usted publica la clave pública en el DNS. Los nombres y valores exactos de los registros se generan para usted, así que tómelos siempre de su propia consola de administración.
Microsoft 365: dos registros CNAME y un interruptor
Para cada dominio propio, Microsoft usa dos registros CNAME, en selector1._domainkey y selector2._domainkey, que apuntan a las claves que Microsoft guarda. Los valores son específicos de su dominio, y Microsoft advierte de que sus ejemplos son solo ilustrativos. Los dominios propios nuevos usan un formato introducido en mayo de 2025, así que copie los valores del portal de Defender o del comando Get-DkimSigningConfig en Exchange Online PowerShell. Publique los dos CNAME en su proveedor de DNS, espere a que Microsoft los detecte y active después la firma del dominio. Microsoft indica que un dominio propio necesita este paso y que cada subdominio desde el que se envía necesita su propia configuración de DKIM. Consulte la guía de DKIM de Microsoft.
Google Workspace: generar el registro, publicarlo y iniciar la autenticación
En la consola de administración de Google, abra la configuración de autenticación DKIM de Gmail, elija el dominio y genere su registro. Siga las instrucciones vigentes de Google enlazadas aquí para localizar la opción exacta en su consola. El selector predeterminado es google, de modo que el nombre del registro TXT es del tipo google._domainkey. Google ofrece una clave de 2048 bits si su proveedor de DNS la admite y una de 1024 bits si no. Active la autenticación solo cuando el registro ya esté publicado; Google indica que DKIM puede tardar hasta 48 horas en empezar a funcionar. Consulte la página de DKIM de Google.
Otros servicios que envían con su dominio
Una herramienta de boletines, de facturación o de asistencia firma con su propio dominio salvo que usted la configure para firmar con el suyo. La tabla de resolución de problemas de Microsoft describe este caso: SPF se supera para el dominio del servicio, pero DMARC falla porque ni SPF ni DKIM coinciden con su dominio del campo De. La solución es configurar en el servicio la firma DKIM con su dominio o cambiar su remitente del sobre (la dirección técnica de retorno, también llamada MAIL FROM) a su dominio o a un subdominio. Para servicios que no controla, Microsoft recomienda un subdominio como marketing.example.com, de modo que los problemas allí no afecten a la reputación de su dominio principal.
¿Cómo se configura DMARC sin bloquear su propio correo?
Google pide que SPF o DKIM estén activos antes de DMARC y sugiere esperar 48 horas tras configurarlos. El registro DMARC es un registro TXT en el nombre de host _dmarc. Un primer registro seguro es v=DMARC1; p=none más una etiqueta rua que indique un buzón que usted controle. Google recomienda incluir siempre rua, y su valor es la dirección del buzón escrita con el prefijo mailto.
- Publique p=none y déjelo el tiempo suficiente para recibir informes de todos sus remitentes habituales, incluidos los periodos de más actividad.
- Lea los informes agregados: suelen ser archivos XML diarios, a menudo comprimidos, que enumeran los servidores que envían con su dominio y si superan la comprobación. Un servicio externo de informes DMARC puede hacer los datos legibles.
- Corrija cada remitente legítimo que falle: añada sus propios servidores a SPF y, en los servicios de terceros, configure DKIM con su dominio o alinee su remitente del sobre, porque añadir un include a SPF no basta para alinear a un remitente que usa su propio dominio.
- Pase a p=quarantine, observe los resultados y pase a p=reject cuando el correo legítimo supere la comprobación. Microsoft recomienda hacerlo de forma gradual, empezando por un dominio o subdominio de poco volumen.
Si no se encuentra un registro del subdominio emisor, la búsqueda de política DMARC puede encontrar una política superior; sus opciones para subdominios afectan al resultado. Compruebe la política efectiva de cada subdominio emisor. Para los dominios aparcados, Microsoft recomienda v=DMARC1; p=reject; y indica que no se publiquen registros DKIM para ellos.
Un detalle ha cambiado. La página de despliegue de Microsoft, la página de DMARC de Google y muchas guías usan una etiqueta pct para aplicar la política solo a un porcentaje del correo. La RFC 9989, publicada en mayo de 2026, deja obsoleta la RFC 7489 y elimina pct, porque normalmente no se aplicaba con exactitud salvo con los valores 0 o 100; añade una etiqueta t (prueba sí o no) para esos dos casos y establece que las etiquetas desconocidas deben ignorarse. Un valor pct puede por tanto no tener efecto con los receptores que sigan la norma nueva, así que planifique el despliegue en pasos claros y lea los informes antes de cada uno. Las opciones de política figuran en la página de DMARC de Google y en la guía de DMARC de Microsoft.
La política p=none pide al receptor que no aplique una medida de bloqueo por DMARC. No garantiza la entrega: siguen contando los filtros de spam, malware, reputación y otras comprobaciones. Los informes pueden contener información del dominio y su infraestructura; elija conscientemente el buzón o servicio que los recibe y limite el acceso.
Leer los pasos en texto
Las correcciones, la cuarentena y el rechazo
¿Cómo comprueba que funciona?
Envíe un mensaje de prueba desde cada remitente a un buzón de otro proveedor, por ejemplo una dirección de Gmail, abra las cabeceras completas del mensaje y mire Authentication-Results. Debe ver spf=pass, dkim=pass y dmarc=pass; la página de DKIM de Google propone además buscar DKIM=pass en el mensaje original. Las causas habituales de dmarc=fail son un remitente externo cuyo SPF o DKIM no se alinea con su dominio del campo De (cada uno puede superarse sin alinearse) y el correo reenviado. Microsoft señala que el reenvío cambia el remitente del sobre, lo que rompe la alineación de SPF, mientras que DKIM puede sobrevivir al reenvío si siguen siendo válidos las cabeceras firmadas y el cuerpo; las modificaciones pueden invalidarlo. Repita la comprobación tras cualquier cambio, como una herramienta nueva o un cambio de plataforma; nuestra guía para migrar de Google Workspace a Microsoft 365 trata el enrutamiento del correo.
¿Quién lo mantiene en marcha después?
Los registros no son una tarea de una sola vez. Designe a un responsable del acceso al DNS y de los informes, fije una fecha de revisión y haga una pregunta cada vez que compre una herramienta nueva: ¿enviará correo con nuestro dominio y cómo superará SPF o DKIM? Quite remitentes de SPF cuando deje de usar un servicio, porque los include antiguos consumen su límite de consultas. El apartado de protección del correo de nuestra lista de comprobación de seguridad de Microsoft 365 cubre lo mismo en versión breve. Nuestra revisión de ciberseguridad examina el correo, incluida la protección del remitente, y el alcance se acuerda con cada organización. Damos soporte en inglés y en español, de lunes a viernes de 09:00 a 18:00 (CET).
Una buena autenticación del correo es una lista corta: conocer todos los remitentes, publicar un solo registro SPF, firmar con DKIM para su propio dominio, empezar DMARC en p=none con informes y endurecer por pasos. Tome cada valor de la documentación vigente de su proveedor, porque los registros y las recomendaciones cambian.
