SPF: qué es y cómo configurarlo bien en Microsoft 365 y Google Workspace

SPF es la lista de servidores que pueden enviar correo con tu dominio. Es el primero de los tres ajustes que piden Gmail, Yahoo y Outlook, y también el que más se rompe sin que nadie se entere: basta con contratar una herramienta de newsletters y no añadirla, o con añadir demasiadas. Si quieres la visión general de los tres, la tienes en SPF, DKIM y DMARC: qué son y por qué tus correos acaban en spam. Aquí vamos a lo práctico.

Es un registro TXT en el DNS de tu dominio que empieza por v=spf1, sigue con quién puede enviar y termina con qué hacer con el resto. Por ejemplo:

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

• include: autoriza a los servidores de un proveedor (aquí, Microsoft 365).
• ip4: e ip6: autorizan direcciones concretas.
• -all o ~all, al final, dicen qué hacer con los que no están en la lista.

Solo puede haber un registro SPF por dominio. Microsoft lo recuerda en su guía: dos registros SPF en el mismo dominio hacen que SPF devuelva un error («permerror»).

• Microsoft 365, si solo envías desde Microsoft: v=spf1 include:spf.protection.outlook.com -all. El dominio .onmicrosoft.com ya viene configurado; el registro de tu dominio lo creas tú en el DNS, porque Microsoft no tiene un panel para gestionarlo.
• Google Workspace: v=spf1 include:_spf.google.com ~all. Google avisa de que puede tardar hasta 48 horas en empezar a funcionar.

¿-all o ~all? Aquí los propios proveedores no coinciden: Microsoft recomienda -all («fallo») para sus dominios, porque también recomienda DKIM y DMARC, y Google recomienda ~all («fallo suave»). El estándar de DMARC (RFC 9989) añade un matiz: con -all, algunos servidores rechazan el correo antes de comprobar DMARC, y esos rechazos no aparecen en los informes de DMARC. Lo que de verdad protege tu dominio es DMARC; con él bien puesto, cualquiera de las dos opciones funciona.

Tu servidor de correo no es el único que envía con tu dominio: la herramienta de newsletters, la tienda online, el programa de facturación o el CRM también lo hacen. Cada uno tiene que estar autorizado, y lo más limpio, según Microsoft, es mandarlos a un subdominio (por ejemplo, boletin.tudominio.es), que tiene su propio SPF y su propio límite de consultas.

Cada servicio lo resuelve a su manera, y hay que seguir su documentación:

• Amazon SES usa por defecto un dominio suyo para el remitente técnico, así que SPF pasa pero no queda alineado con el tuyo. Para alinearlo se configura un subdominio propio con v=spf1 include:amazonses.com ~all y un registro MX que indica Amazon.
• SendGrid, con su autenticación automática, pide unos registros CNAME y no hay que tocar tu SPF.
• Mailchimp pide en su ayuda dos CNAME (para DKIM) y un TXT de DMARC, sin mencionar SPF.
• Brevo pide tres o cuatro registros: un «código Brevo» (TXT, para demostrar que el dominio es tuyo), DKIM y DMARC. SPF no está en su tabla de registros.

Es el error más habitual. El estándar de SPF (RFC 7208, sección 4.6.4) limita a 10 las consultas al DNS que puede hacer el servidor que comprueba tu SPF. Si se superan, el resultado es un error y SPF deja de valer.

• Cuentan: include, a, mx, ptr, exists y redirect.
• No cuentan: ip4, ip6 y all.
• Los include anidados también suman: el de un proveedor puede incluir a su vez otros. Microsoft lo advierte: tener menos de 10 include no garantiza tener menos de 10 consultas.
• Además, el estándar recomienda no pasar de 2 consultas «vacías» (las que no devuelven nada), algo que suele pasar con include de servicios que ya no existen.

Cómo bajar de 10, según Microsoft: usar subdominios para los terceros (cada uno tiene su propio límite) y quitar los servicios que ya no se usan. La otra técnica, el flattening o «aplanado», cambia los include por las direcciones IP que contienen; Microsoft desaconseja hacerlo con Microsoft 365 o con cualquier servicio en la nube cuyas IP cambien, y, si se hace, pide revisarlo al menos cada trimestre.

Si alguien reenvía automáticamente tu correo desde su buzón a otro, el servidor que reenvía no está en tu SPF, y SPF falla. No es un error de configuración: el propio estándar (RFC 7208, sección 10.3) explica que pasa por diseño. Microsoft reescribe el remitente técnico en los reenvíos (lo llama SRS) para que SPF pase, pero avisa de que eso no arregla DMARC. Lo que sobrevive al reenvío es la firma DKIM, si el mensaje no se modifica por el camino. Por eso no basta con SPF.

• Errores de escritura: include= en lugar de include:, un espacio después de los dos puntos o un punto al final del dominio.
• Un include que no existe también da error.
• Registros demasiado largos: cada cadena de un TXT admite 255 caracteres, y el estándar recomienda que el registro entero quepa en 512 bytes.
• Un TTL muy bajo: Microsoft recomienda al menos 3.600 segundos.

En las cabeceras de un correo que hayas enviado, busca Authentication-Results: verás spf=pass o spf=fail y el dominio que se ha comprobado (smtp.mailfrom=). Más rápido: pasa tu dominio por nuestro analizador de correo, que revisa tu SPF, cuenta las consultas y te dice si te pasas del límite.

Siguiente paso: DKIM, cómo firmar el correo de tu empresa.

No. Si necesitas autorizar a varios proveedores, van todos en el mismo registro, o algunos en subdominios.

Solo si la web envía correos con tu dominio (formularios, avisos de la tienda). En ese caso, el servidor o el servicio que los envía tiene que estar autorizado.

Depende del TTL del registro y del proveedor: Google habla de hasta 48 horas.

En LN Digital configuramos SPF, DKIM y DMARC para que tus correos no acaben en spam y nadie pueda hacerse pasar por ti, dentro de nuestro mantenimiento de servidores. Escríbenos.

Consultadas el 20 de octubre de 2026.

• RFC 7208 (SPF), secciones 3.3, 3.4, 4.6.4 y 10.3, y RFC 9989 (DMARC), sección 7.1.
• Microsoft Learn: configurar SPF y Sender Rewriting Scheme.
• Google Workspace: configurar SPF y solucionar problemas de SPF.
• Amazon SES: dominio MAIL FROM personalizado y SPF. SendGrid: autenticación de dominio. Mailchimp: autenticación del dominio. Brevo: autenticar tu dominio.