Qué aprenderá en este artículo
- Un registro SPF de Google Workspace es un registro TXT de DNS que indica a los servidores de correo receptores qué sistemas están autorizados a enviar correos electrónicos en nombre de su dominio.
- En el caso de una configuración exclusiva de Google Workspace, el valor SPF de referencia documentado por Google es v=spf1 include:_spf.google.com ~all. Si hay otras herramientas que también envían correo para su dominio, deben incluirse en el mismo registro SPF.
- El SPF contribuye a reducir la suplantación de identidad y favorece la entregabilidad del correo electrónico, pero ofrece mejores resultados cuando se utiliza junto con DKIM y DMARC, como parte de una estrategia más amplia de autenticación del correo electrónico.
- Una configuración sólida del SPF comienza por identificar a todos los remitentes legítimos del dominio, incluidas las plataformas de terceros, las aplicaciones internas, los escáneres, los servidores de retransmisión y otros servicios.
- La sintaxis, la consolidación y la validación son importantes. Las políticas duplicadas, los problemas de formato y el límite de 10 consultas DNS del SPF pueden impedir la evaluación del SPF o debilitar la protección.
¿Qué es un registro SPF de Google Workspace?
Un registro SPF de Google Workspace es un registro TXT de DNS que utiliza el Marco de políticas del remitente (, SPF) para indicar a los servidores de correo receptores qué sistemas están autorizados a enviar correos electrónicos en nombre de un dominio. En términos sencillos, ayuda a un servidor receptor de a comprobar si la dirección IP remitente está autorizada a utilizar su dominio en la ruta del mensaje.
Cómo utiliza Google Workspace el SPF
En Google Workspace, el registro SPF « » autoriza a Gmail y a cualquier otro servicio de envío autorizado a enviar correo en nombre del dominio. Si Google Workspace es el único sistema de « » que envía correo, el valor de referencia documentado por Google es v=spf1 include:_spf.google.com ~all.
Esa es la sintaxis SPF correcta que debe publicarse. Las versiones informales como «spf1 include spfgooglecom», «include spfgooglecom» o « vspf1 include spfgooglecom» no son valores válidos por sí mismos en un entorno de producción.
Por qué las organizaciones deberían configurar el SPF
Las organizaciones deberían configurar el SPF en Google Workspace, ya que contribuye a reducir la suplantación de dominio al dificultar que los remitentes no autorizados se hagan pasar por el dominio.
SPF no bloquea por sí solo todas las amenazas de correo electrónico, pero ayuda a los servidores receptores a evaluar si una fuente remitente es la esperada. Google también recomienda utilizar SPF (),DKIM( ) y DMARC para reforzar la autenticación y garantizar un envío de correo electrónico más fiable.
Cómo funciona el SPF de Google Workspace
El SPF funciona comparando el origen de envío de un mensaje con la política SPF activa publicada en el DNS para el dominio. Dicha política recoge la infraestructura de correo autorizada de Google y cualquier otro remitente aprobado, lo que permite al servidor receptor comprobar en si la dirección IP del remitente está autorizada.
En el caso de Google Workspace, la política suele incluir los sistemas de correo electrónico de Google a través de include:_spf.google.com, junto con y cualquier otra fuente autorizada. Los términos del SPF se evalúan por orden, por lo que la estructura del registro es tan importante como la lista de remitentes.
Los resultados habituales son:
- Aceptado: la dirección IP remitente está autorizada a enviar correos electrónicos en nombre del dominio.
- Error: la fuente no está autorizada, lo que puede indicar una suplantación de identidad o una brecha en la política de seguridad.
- Softfail: la fuente no está autorizada, pero la política indica al receptor que trate el mensaje como sospechoso en lugar de rechazarlo directamente. La recomendación estándar de Google para Workspace utiliza «~all», lo que da lugar a un comportamiento de «softfail» en el caso de fuentes no autorizadas.
- Neutro: el dominio no se pronuncia claramente sobre si la fuente debería superar o no la verificación SPF.
- No se ha encontrado ningún registro SPF: no hay ninguna política SPF aplicable disponible para ese nombre de host en el DNS, por lo que el destinatario no dispone de información sobre el SPF por parte del dominio.
Pasos para configurar el SPF de Google Workspace
Configurar un registro SPF de Google Workspace es muy sencillo si se sigue el orden correcto. La clave consiste en identificar primero todos los remitentes autorizados y, a continuación, publicar y validar una política SPF precisa.
Paso 1: Identifique a todos los remitentes de correo electrónico de su dominio
Comience la configuración de SPF con un inventario de remitentes antes de realizar cualquier cambio en el DNS. Google Workspace es el remitente principal, pero puede que no sea el único. También debe tener en cuenta a los proveedores que envían correo en nombre de su dominio, entre los que se incluyen:
- Plataformas de terceros
- Servicios de retransmisión
- Escáneres
- Aplicaciones internas
- Formularios web
- Herramientas de gestión de entradas
Este paso es importante porque el SPF debe reflejar íntegramente su entorno de correo saliente. Si falta tan solo un remitente legítimo , los mensajes procedentes de esa fuente podrían no superar la verificación SPF, ser marcados como sospechosos o afectar a la capacidad de entrega. En entornos de « » más complejos, conviene revisar tanto los sistemas internos como los proveedores externos antes de publicar cualquier cambio.
Paso 2: Configure el registro SPF correcto de Google Workspace
Una vez identificados todos los remitentes, cree un registro SPF consolidado. Si Google Workspace es el único remitente autorizado, el valor recomendado por Google es v=spf1 include:_spf.google.com ~all. Este registro de referencia autoriza la infraestructura de Google a través de include:_spf.google.com y aplica un «softfail» a las fuentes no autorizadas, lo que lo convierte en un punto de partida limpio para los dominios que envían correo únicamente a través de Gmail.
Si hay otros remitentes, es necesario añadirlos a la misma política SPF. La regla principal es la consolidación: un dominio debería tener una política SPF por nombre de host, y no varios registros SPF. La publicación de entradas SPF independientes para Google Workspace y otras plataformas puede provocar que falle la validación de SPF, ya que los destinatarios no las consideran políticas válidas e independientes de .
Paso 3: Añada el registro SPF a su DNS
El SPF se publica como un registro TXT de DNS a través de su proveedor de alojamiento de dominios o de DNS, y no a través de la Consola de administración de Google. La interfaz concreta depende del proveedor, pero el proceso suele ser el mismo: acceda a la configuración de su DNS, cree o edite la entrada TXT, asigne el nombre de host correcto y guarde los cambios.
Antes de publicar, asegúrese de que está actualizando el dominio y el nombre de host correctos. Una ubicación incorrecta es una causa habitual de problemas con el SPF en . También es importante recordar que el SPF es independiente de su registro MX, ya que el MX controla el enrutamiento del correo entrante , mientras que el SPF define qué fuentes pueden enviar correo saliente en nombre del dominio.
Paso 4: Combine Google Workspace con remitentes externos con precaución
Muchas organizaciones utilizan Google Workspace para el correo electrónico de los usuarios, aunque también recurren a otras herramientas para enviar mensajes salientes. Entre ellos pueden figurar plataformas de marketing, sistemas de venta de entradas, servidores SMTP, herramientas de facturación, plataformas de CRM y dispositivos multifunción .
Cuando existan dichas herramientas, deben integrarse en la misma política SPF, en lugar de añadirse como entradas SPF independientes. Esto cobra aún más importancia en las organizaciones de mayor tamaño, en las que distintos equipos pueden gestionar a distintos remitentes. Sin una coordinació , las políticas de SPF pueden resultar incompletas o contradictorias, por lo que el SPF debe considerarse una tarea de mantenimiento continua, en lugar de un cambio puntual en el DNS.
Paso 5: Compruebe la sintaxis de SPF y los límites de consulta
Una vez creado el registro, el siguiente paso consiste en asegurarse de que esté estructurado correctamente y pueda procesarse sin errores de « ». Esto significa que debe comprobarse tanto la sintaxis del SPF como el funcionamiento de la consulta DNS antes de dar por concluida la configuración.
Compruebe la sintaxis del registro SPF
La validación sintáctica es un paso obligatorio en la configuración del SPF. Un registro puede incluir las fuentes adecuadas y, aun así, no ser válido si el formato de es incorrecto. Revisar la sintaxis de los registros SPF permite confirmar que la política se inicia correctamente, que utiliza únicamente los términos previstos en y que no contiene errores que impidan su evaluación.
Además, cada mecanismo SPF debe utilizarse con precaución, ya que la estructura del registro influye en la forma en que los servidores receptores lo procesan.
Supervisar los límites de las consultas DNS
Los equipos también deben vigilar el uso de las consultas DNS. La RFC 7208 limita la evaluación del SPF a 10 mecanismos de consulta DNS y modificadores, , y superar ese límite puede dar lugar a un error permanente.
Esto suele suponer un problema en entornos de mayor tamaño, en los que varios proveedores añaden inclusiones anidadas, por lo que conviene simplificar el registro, retirar los remitentes antiguos y revisar cualquier lógica SPF heredada que ya no refleje el flujo real de correo .
Paso 6: Compruebe que el registro SPF se haya publicado correctamente
Tras la publicación, compruebe que el registro SPF activo sea visible en el DNS y que se ajuste exactamente a la política prevista. Los cambios en el DNS ( ) pueden tardar un tiempo en propagarse, por lo que guardar la actualización no siempre significa que la configuración haya finalizado.
Para este paso, los equipos suelen utilizar un verificador de SPF de o herramientas de Google Admin Toolbox, como Check MX y Messageheader. El objetivo es confirmar que el registro TXT de SPF aparece en el nombre de host correcto y coincide con el valor que usted pretendía publicar.
Paso 7: Comprobar los resultados de la autenticación y resolver los problemas
Una vez que el registro esté activo, compruebe que el SPF funciona correctamente revisando los encabezados de los mensajes enviados o los registros de correo. La función «Messageheader» de Google Admin Toolbox puede ayudarle a analizar las cabeceras SMTP y a mostrar los resultados de SPF en las líneas «Authentication-Results» o « » de «Received-SPF».
Si los mensajes no se transmiten como se esperaba, comience por las causas más habituales:
- pólizas duplicadas
- errores de sintaxis
- faltan remitentes externos
- colocación incorrecta del disco
- Errores en la publicación del DNS
Para obtener una visión continua del rendimiento del envío de mensajes dirigidos a Gmail, Postmaster Tools también puede resultarle de ayuda, ya que muestra paneles de control sobre la tasa de spam de , la reputación, la autenticación de mensajes y los errores de entrega.
Errores habituales en los registros SPF que debe evitar en Google Workspace
Configurar correctamente el SPF no consiste únicamente en añadir una entrada DNS. Además, requiere un inventario completo de remitentes, una estructura clara de políticas de « » y una revisión continua a medida que su entorno de correo electrónico vaya cambiando.
Omisión de fuentes de envío legítimas
Un error muy común es olvidarse de incluir todas las fuentes de envío autorizadas. Un dominio puede contar con Google Workspace ( ), pero aún así carecer de una plataforma de gestión de incidencias, una herramienta de marketing, un escáner, un servidor de retransmisión o una aplicación que envíe mensajes en nombre del dominio. Ese tipo de discrepancia puede provocar errores en el SPF, incluso cuando la configuración general de Workspace parece correcta.
Uso de varios registros SPF
Otro problema habitual es publicar varios registros SPF en lugar de una única política TXT consolidada. La herramienta « » de Google Admin Toolbox, en la sección «Comprobación de MX», advierte de que no debe haber más de un registro SPF. Si un dominio publica varias políticas independientes, la evaluación de SPF puede fallar.
Errores de sintaxis y de formato
También suelen surgir problemas de sintaxis. Esto incluye errores de formato, calificadores incorrectos, mecanismos no válidos, una ubicación errónea del nombre de host « », o intentar añadir nuevas entradas a un registro SPF obsoleto sin limpiarlo primero. Incluso los pequeños errores en la sintaxis de los registros SPF o un uso incorrecto del mecanismo SPF pueden afectar a la autenticación.
Adoptar una política excesivamente amplia
Las políticas excesivamente generales suponen otro riesgo. Permitir un número excesivo de fuentes puede parecer práctico, pero debilita la protección, ya que facilita la suplantación de identidad si una de las fuentes autorizadas se ve comprometida o se hace un uso indebido de ella.
El SPF debe incluir únicamente los sistemas que realmente necesitan enviar mensajes en nombre del dominio. Esto cobra aún más importancia cuando, además, mantiene un registro DMARC, ya que una configuración incorrecta de DMARC puede provocar problemas de autenticación y entrega en las etapas posteriores.
Ignorar los límites de búsqueda y los casos extremos
También hay que tener en cuenta ciertas limitaciones técnicas y casos extremos de funcionamiento. El límite de 10 consultas de SPF puede provocar problemas de evaluación de « » cuando se acumulan demasiadas inclusiones anidadas. El reenvío también puede hacer que el SPF falle, incluso cuando el remitente original estaba correctamente configurado, ya que el SPF evalúa la ruta utilizada durante la entrega final y no solo la intención original .
Considerar el SPF como una tarea que solo hay que realizar una vez
Los registros del SPF deben revisarse periódicamente. Los proveedores cambian, se incorporan nuevas herramientas y se retiran los servicios antiguos. Las directrices de Google sobre el servicio « » indican expresamente que se debe actualizar la política cuando se incorporen nuevos servidores de correo o remitentes externos. Esa revisión continua de contribuye a proteger tanto la capacidad de entrega como la autenticación del correo electrónico a medida que cambia el entorno.
Cómo configurar correctamente el SPF de Google Workspace
La seguridad de un registro SPF de Google Workspace depende en gran medida de la calidad del inventario de remitentes que lo respalda. Identificar todas las fuentes de correo aprobadas antes de realizar cambios en el DNS ayuda a evitar lagunas que puedan provocar fallos en el SPF, un tratamiento anómalo de los mensajes o una capacidad de entrega inconsistente .
Para aquellas organizaciones que deseen una mayor visibilidad de las fuentes de envío, una supervisión más rigurosa de las políticas y un mayor apoyo en para reducir los riesgos derivados del correo electrónico, Mimecast puede ayudarles a ampliar el control más allá de la configuración nativa.