¿Puedo tener dos registros SPF si uso Office 365 y una herramienta de mercadeo?

No. Microsoft indica que solo se permite un registro SPF por dominio o subdominio, y un receptor que encuentra dos termina la evaluación en error permanente. Une los dos remitentes en un solo registro, por ejemplo v=spf1 include:spf.protection.outlook.com include:_spf.tuherramienta.com -all.

¿El registro SPF de Office 365 debe terminar en -all o en ~all?

Microsoft recomienda -all (fallo duro) para los dominios de Microsoft 365, partiendo de que también tienes DKIM y DMARC. El fallo suave ~all pide al receptor que acepte y marque el mensaje, lo cual sirve una semana mientras todavía descubres remitentes, no como configuración permanente.

Cómo revisar el registro SPF en Office 365: el valor exacto

Q: ¿Cómo reviso el registro SPF de mi dominio en Office 365?

En dos lugares, y necesitas los dos. El centro de administración de Microsoft 365, en Configuración, Dominios, tu dominio, registros DNS, te dice el valor que Microsoft espera. Después consulta los registros TXT del dominio desde fuera de tu red para ver lo que reciben de verdad los servidores receptores. El panel solo confirma que su propio valor está presente: no evalúa el resto del registro ni cuenta tus consultas DNS.

Una correduría de seguros de 14 personas nos llama un lunes. Sus cotizaciones dejaron de llegar a las direcciones de Gmail desde el viernes. No cambiamos nada, dicen. Después alguien recuerda que mercadeo contrató una herramienta de boletines hace tres semanas, y quien la configuró pegó una línea en el DNS porque un artículo de soporte se lo indicó.

Así se ve la mayoría de los problemas de SPF en un tenant de Microsoft 365. El registro estaba bien el día que se conectó el dominio. Luego la empresa creció, sumó un remitente y nadie contó lo que costaba. Esto es lo que revisamos primero en el dominio de un cliente, el orden en que lo reparamos y las trampas que aparecen una y otra vez en Microsoft 365.

Dónde te dice Microsoft qué publicar

Empieza en el centro de administración de Microsoft 365. La documentación de Microsoft sobre configuración de dominios te lleva a Configuración, luego Dominios, luego tu dominio y la vista de registros DNS, donde aparecen los valores que tu tenant espera. Esa pantalla sirve para una cosa: decirte qué quiere Microsoft que esté presente.

No es un veredicto sobre tu registro. El centro de administración verifica que su propio valor esté ahí. No evalúa el resto del registro, no cuenta tus consultas DNS y puede mostrarte todo en verde sobre un registro que falla del lado del receptor. Así que lee el panel para saber el valor requerido y después mira lo que internet devuelve de verdad para tu dominio: consulta los registros TXT del dominio desde fuera de tu red.

; lo que lee un servidor de correo receptor
example.com.   3600   IN   TXT   "v=spf1 include:spf.protection.outlook.com -all"

Esa sola línea es toda la política publicada de un tenant que envía únicamente a través de Exchange Online. Microsoft documenta exactamente ese valor como el registro SPF de Microsoft 365.

Qué hace cada parte del registro

v=spf1 marca el registro como SPF. Cualquier cosa en tus TXT que no empiece así no es un registro SPF, por mucho que lo parezca.

include:spf.protection.outlook.com apunta al nombre que mantiene Microsoft, donde están las fuentes de envío de Exchange Online. Nunca listas tú las direcciones IP de Microsoft; el include es lo que te mantiene al día cuando Microsoft las cambia.

-all es el calificador para todo lo demás. La guía de SPF de Microsoft para Microsoft 365, en la versión de esa página fechada el 3 de julio de 2026 y consultada el 21 de septiembre de 2026, recomienda el fallo duro: "For Microsoft 365 domains, we recommend -all (hard fail) because we also recommend DKIM and DMARC for the domain." El más suave ~all pide al receptor que acepte el mensaje pero lo marque, lo cual es razonable durante una semana mientras todavía descubres remitentes, y mala idea como estado permanente.

Hay dos reglas estructurales que importan más que la sintaxis. Primero, en palabras de Microsoft, "only one SPF record is allowed per domain or subdomain": un solo registro SPF por dominio o subdominio. Segundo, SPF autoriza al remitente del sobre, la dirección que se usa en la conversación SMTP, no la dirección From que tus destinatarios ven en su cliente de correo. La documentación de Microsoft lo dice sin rodeos: SPF no intenta hacer coincidir el dominio del sobre con el del From. DMARC es la pieza que exige que coincidan. Un dominio puede pasar SPF y aun así fallar DMARC, y por eso a veces arreglar solo el SPF no cambia nada.

Agregar un segundo remitente sin romper el registro

Aquí fue donde se equivocó la correduría, y es la herida autoinfligida más común que vemos. Su DNS terminó con dos registros SPF separados:

; roto: dos registros SPF en el mismo nombre
example.com.   TXT   "v=spf1 include:spf.protection.outlook.com -all"
example.com.   TXT   "v=spf1 include:_spf.herramientaboletines.com ~all"

Un receptor que encuentra dos registros no puede elegir entre ellos, así que la evaluación termina en error permanente y los dos remitentes pierden el beneficio. La guía de Microsoft para dominios que ya tienen un registro es agregar el valor de Microsoft al registro existente, no publicar un segundo. La versión reparada es un solo registro con ambos remitentes:

; correcto: un registro, los dos remitentes
example.com.   TXT   "v=spf1 include:spf.protection.outlook.com include:_spf.herramientaboletines.com -all"

Antes de agregar nada, saca el include de la documentación del propio proveedor. Las respuestas de foros envejecen, y un include que apunta a un nombre que el proveedor retiró es una consulta que estás pagando sin recibir nada a cambio.

Contar consultas, y por qué el flattening es el último recurso

SPF tiene un techo duro. La sección 4.6.4 del RFC 7208 limita una evaluación a diez términos que requieren consulta DNS, y una implementación que se pase debe devolver un error permanente. Microsoft dice la consecuencia sin adornos: "If the number of DNS lookups is greater than 10, the message fails SPF with a permanent error."

Los términos que cuestan una consulta son include, a, mx, ptr, exists y el modificador redirect. Los que salen gratis son ip4, ip6 y all, porque la respuesta ya está en el registro.

La trampa es que un include no es una consulta. Cuesta una consulta por sí mismo más todas las que haga el registro al que apunta, hasta el final de la cadena. El include de Microsoft resuelve a un registro que contiene otros includes, y varias plataformas de mercadeo y CRM hacen lo mismo. No asumas un número para ningún proveedor. Mide tu propio registro tal como está publicado, porque tu total es el único que importa.

Pega tu dominio y mira lo que ve un receptor antes de tocar el DNS:

Cuando la cuenta pasa de diez, trabaja en este orden. Cada paso es más seguro que el siguiente.

Borra los includes de servicios que ya no usas. En un dominio que viene operando desde 2018, esto solo suele bastar para bajar del límite. El CRM viejo, la prueba de un helpdesk, la herramienta de facturación que reemplazaron hace dos años.
Quita los mecanismos a y mx que quedaron sueltos. Suelen ser un recuerdo del hosting compartido donde vivía el dominio antes de pasar a Microsoft 365. Si ese host ya no envía tu correo, son dos consultas recuperadas.
Mueve a un subdominio el remitente más ruidoso. Que facturación envíe como facturas.example.com, con su propio registro SPF y su propio presupuesto de consultas. Te cuesta una conversación con el proveedor sobre el dominio del sobre, y es la solución más duradera de esta lista.
Reemplaza un include por rangos de IP publicados, y solo donde el proveedor se comprometa por escrito a direcciones estables. Las entradas ip4 no gastan consultas y también quedan congeladas en el tiempo, así que este paso viene con un recordatorio en el calendario para revisarlo, no sin él.
Apóyate en DKIM para lo que quede. Un remitente que firma con DKIM alineado a tu dominio pasa DMARC sin estar en el registro SPF. Para una plataforma de mercadeo suele ser la respuesta más limpia.

Los servicios de flattening automático, que expanden cada include en una lista de direcciones y la mantienen actualizada, quedan fuera de esa lista a propósito. Funcionan hasta que el proveedor mueve una IP y la actualización no ocurre, y entonces el correo falla un sábado sin causa visible. Los usamos solo cuando un cliente no tiene otra ruta, y nunca sin monitoreo.

Verifica con un mensaje real, no solo con un validador

Un validador de sintaxis te dice que el registro se interpreta bien. No te dice que tu app de facturación pasa. Así que envía un mensaje real desde cada sistema que usa tu dominio, a una dirección de Gmail y a una de Outlook.com, y lee las cabeceras de lo que llega.

En la cabecera Authentication-Results quieres tres cosas: spf=pass con un smtp.mailfrom que sea de tu dominio, dkim=pass y dmarc=pass. Si SPF pasa pero DMARC no, el dominio del sobre es el del proveedor y el del From es el tuyo, y ninguna edición del SPF lo va a arreglar. Nuestro analizador de cabeceras desglosa una cabecera pegada si prefieres no leerla a ojo, y la versión larga de esa habilidad está en nuestra guía para leer cabeceras de correo y saber por qué un mensaje cayó en spam.

Los dos receptores grandes ya esperan esto. Las directrices de remitentes de Google exigen que todo remitente configure SPF o DKIM, y exigen SPF, DKIM y DMARC juntos a quien envía más de 5,000 mensajes al día a cuentas personales de Gmail, además de una tasa de quejas por spam bajo 0.3 por ciento y un enlace de baja en un clic en el correo de mercadeo. Microsoft publicó requisitos equivalentes para remitentes de alto volumen hacia Outlook.com, Hotmail.com y Live.com, en vigor desde el 5 de mayo de 2025, con el correo no conforme enviado primero a la carpeta de no deseados. Ninguna de las dos reglas es nueva, y vale la pena contrastarlas antes de dar tu registro por terminado.

Las trampas más frecuentes en tenants de Microsoft 365

El registro en el nombre equivocado. SPF va en el dominio que aparece en el remitente del sobre. Con frecuencia lo encontramos publicado en spf.example.com o _spf.example.com, donde ningún receptor lo va a buscar.
Subdominios sin registro propio. Si un subdominio envía correo y no publica nada, los receptores no heredan el registro SPF del dominio padre. Cada subdominio que envía necesita el suyo.
Escáner a correo y aplicaciones internas. La multifuncional y el sistema de gestión mandan a Exchange Online usando tu dominio, y son invisibles hasta que un reporte DMARC los muestra fallando. Inventaríalos antes de apretar nada.
El registro partido mal en cadenas. Un registro TXT guarda cadenas de hasta 255 caracteres cada una. Los SPF largos hay que partirlos, y algunos paneles de DNS lo hacen metiendo un espacio o perdiendo un carácter. Vuelve a leer siempre el valor publicado después de guardar.
~all sin DMARC detrás. Un fallo suave sin política DMARC es casi lo mismo que no tener política. Si te vas a quedar en ~all, publica DMARC y lee los reportes, y después aprieta los dos.

Si estás armando un dominio de Microsoft 365 desde cero en lugar de repararlo, nuestra guía de configuración de SPF, DKIM y DMARC en Microsoft 365 cubre los tres registros en orden, y la guía del registro DMARC en Office 365 se encarga después de subir la política. Si el problema entero es la cuenta de consultas, la versión a fondo está en cómo arreglar el SPF con demasiadas consultas DNS.

Cómo ayuda Guanacos Tech

Hacemos esto para empresas pequeñas y medianas de Norteamérica y Latinoamérica, normalmente en una sola sesión: inventariamos cada sistema que envía con tu dominio, reconstruimos el registro en una sola línea que pasa y se mantiene bajo el límite, confirmamos la alineación con mensajes reales en Gmail y Outlook, y después miramos los reportes DMARC durante un mes para cazar al remitente que nadie mencionó. Si prefieres delegarlo, nuestra consultoría de entregabilidad de correo arranca con una llamada corta para ver tu registro actual y decirte qué está roto de verdad.

El registro SPF de Office 365: cómo revisarlo, actualizarlo y no pasar de 10 consultas