¿Cómo puedo crear un registro SPF para Office 365 sin dañar otros servicios de correo?

Para crear un registro SPF para Office 365 sin dañar otros servicios de correo, inventaríe todos los remitentes legítimos, construya un único registro v=spf1 que incluya include:spf.protection.outlook.com además de sus otros proveedores e IP sin superar el límite de 10 consultas de DNS (utilizando subdominios o aplanamiento si es necesario), impleméntelo con un calificador permisivo (~all), pruébelo y supervíselo mediante datos de SPF/DMARC, y automatice su mantenimiento con AutoSPF para evitar desviaciones.

Según la RFC 7208, la evaluación de SPF está limitada a 10 consultas de mecanismos DNS y 2 consultas vacías por comprobación; superar cualquiera de los dos límites produce un PermError que hace fallar la autenticación de todos los mensajes del dominio.

Contexto y antecedentes

Sender Policy Framework (SPF) es una lista de autorización basada en DNS que indica a los receptores qué IP y servicios pueden enviar correo en nombre de su dominio. Microsoft 365 (Exchange Online) exige que incluya su infraestructura SPF publicada con include:spf.protection.outlook.com, pero muchos dominios también envían desde Exchange local, plataformas de marketing, CRM, sistemas de tickets y aplicaciones web. Si publica un SPF que solo cubre Office 365, otros servicios legítimos pueden ser rechazados; si intenta incluir todo de forma ingenua, puede superar el estricto límite de 10 consultas de SPF y romper por completo la evaluación.

El camino más seguro es metódico: descubra cada fuente que envía, construya un registro preciso con Office 365 y todas las demás fuentes, optimícelo para no superar el presupuesto de consultas, escalone la implementación con cuidado y manténgalo actualizado. Si empieza desde cero, nuestra guía sobre cómo configurar un registro SPF cubre los fundamentos. AutoSPF agiliza cada uno de estos pasos descubriendo remitentes a partir de datos de correo en vivo, modelando el recuento de consultas en tiempo real, aplanando automáticamente cuando es necesario y supervisando los resultados para que pueda pasar a una política estricta con confianza.

Inventaríe todos los servicios que envían correo en nombre de su dominio

Un inventario completo de remitentes evita «roturas» cuando migra a Office 365 u optimiza para él.

Qué enumerar y cómo documentarlo

• Local: IP pública NAT de Exchange o relays SMTP, smart hosts, escáneres y equipos multifunción (MFP)

• Microsoft 365: Exchange Online Protection (EOP) mediante include:spf.protection.outlook.com

• Plataformas de terceros: ESP (p. ej., SendGrid, Mailchimp), CRM (p. ej., Salesforce), tickets (p. ej., Zendesk), soporte/chat, RR. HH./nóminas y cualquier aplicación que envíe en nombre de su dominio

• Infraestructura web: CMS/formularios de contacto, plataformas de comercio electrónico, funciones serverless

• Rutas especiales: listas de correo, reenviadores y remitentes de subdominios (p. ej., bounce@, newsletter@, noreply@)

Métodos para descubrir todas las fuentes

• Informes agregados de DMARC (RUA): enumere las IP y dominios de origen vistos enviando en su nombre; recopile al menos entre 14 y 30 días de datos

• Seguimiento de mensajes y encabezados de Microsoft 365: examine Authentication-Results y Received-SPF para encontrar IP/servicios

• Paneles de proveedores: la mayoría de los ESP muestran los dominios que están configurados para enviar y su include de SPF

• Comprobaciones de DNS e infraestructura: use dig/nslookup sobre sus registros MX y A (si utiliza a: o mx: en SPF), y las tablas NAT del firewall para el tráfico saliente SMTP/25 y 587

• Entrevistas con los equipos: marketing, soporte, producto y TI suelen gestionar distintos sistemas de envío

Conexión con AutoSPF: AutoSPF ingiere el RUA de DMARC automáticamente, asigna las IP de origen a proveedores conocidos y construye un inventario vivo. Señala los «remitentes desconocidos» y sugiere adiciones a SPF o segmentación por subdominios, lo que ahorra semanas de descubrimiento manual.

Construya un único SPF que incluya Office 365 y todo lo demás (sin superar las 10 consultas)

El núcleo es un único registro TXT en la raíz (example.com) con exactamente una política SPF. El mecanismo publicado por Microsoft es include:spf.protection.outlook.com. Puede ensamblar ese registro con nuestro generador de registros SPF.

La sintaxis recomendada por Microsoft para Exchange Online

• Solo Office 365:
• v=spf1 include:spf.protection.outlook.com -all

Esta es la orientación canónica de Microsoft para Exchange Online cuando no existen otros remitentes.

Ejemplos concretos de registros SPF

• Office 365 + IP públicas locales:

• v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:spf.protection.outlook.com -all

• Office 365 + local + varios remitentes de terceros:

• v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com include:sendgrid.net include:servers.mcsv.net include:_spf.salesforce.com ~all

• Office 365 + Amazon SES (regionalizado) + Mailchimp:

• v=spf1 include:spf.protection.outlook.com include:amazonses.com include:servers.mcsv.net ~all

• Subdominio delegado para marketing manteniendo la raíz ligera:

• Raíz (example.com): v=spf1 include:spf.protection.outlook.com -all

• Marketing (news.example.com): v=spf1 include:sendgrid.net include:servers.mcsv.net -all

Nota: Confirme siempre el host de include actual de cada proveedor en su documentación. Algunos proveedores ofrecen includes específicos por región o cuenta que reducen las consultas.

El presupuesto de 10 consultas y cómo no superarlo

SPF contabiliza los mecanismos que consultan DNS hacia un límite estricto de 10 en toda la cadena de evaluación (includes, redirects, a, mx, ptr, exists y macros). ip4, ip6 y all no desencadenan consultas.

• Costes de consulta habituales:

• include: 1 consulta cada uno (más lo que ellos mismos incluyan)

• mx: hasta el número de hosts MX (más las consultas A/AAAA)

• a: 1 (más una posible cadena CNAME)

• redirect=: 1 (reemplaza la política; sigue dentro del mismo presupuesto de 10)

• Mantenga «all» al final; no añade consultas.

Estrategias prácticas:

• Prefiera ip4/ip6 para sus propios hosts estáticos en lugar de mx o a

• Minimice los includes de proveedores; elimine proveedores heredados

• Segmente los remitentes con muchas consultas a subdominios (p. ej., news.example.com) para que el SPF de la raíz se mantenga ligero

• Utilice el aplanamiento gestionado para convertir los includes en los conjuntos de IP actuales, con actualización automática

Conexión con AutoSPF: AutoSPF muestra un contador de consultas en vivo mientras edita, avisa cuando los includes indirectos se expanden más allá de 10 y puede publicar un registro aplanado de forma segura con actualización automática para que nunca se desvíe cuando los proveedores cambian de IP.

Gestione implementaciones híbridas de Exchange sin daños colaterales

El modo híbrido cambia qué IP envía realmente a internet, así que modele su flujo de correo antes de publicar el SPF.

Si los relays locales envían a EOP (y EOP entrega)

• Ruta de salida: local → EOP → destinatarios en internet

• IP de conexión en el destinatario: EOP

• Orientación de SPF: include:spf.protection.outlook.com es suficiente; no necesita sus IP locales para el SPF

• Motivo: SPF comprueba la IP del cliente SMTP del salto final hacia el destinatario, que en este diseño es EOP

Si el sistema local entrega directamente a internet (o lo hacen las aplicaciones)

• Ruta de salida: local/aplicación → internet

• IP de conexión: sus NAT públicas

• Orientación de SPF: añada ip4/ip6 para cada IP de salida que pueda enviar en nombre de su dominio, además de include:spf.protection.outlook.com

Smart hosts y conectores

• Smart host de terceros (p. ej., pasarelas de seguridad) que entregan por usted: incluya el SPF de ese proveedor o añada sus IP de salida

• Múltiples puntos de salida: considere consolidarlos en menos NAT o publíquelos todos en ip4/ip6

El correo entrante no cambia el SPF

El enrutamiento de entrada (MX a EOP o local) no afecta al SPF de su dominio, pero si utiliza mx en SPF añadirá consultas; prefiera ip4/ip6 explícitos para los remitentes.

Conexión con AutoSPF: el «modelado de flujo» de AutoSPF le permite declarar si el sistema local enruta a través de EOP o envía directamente; a continuación genera el SPF correcto y resalta cualquier IP sin cubrir hallada en los datos de DMARC.

Implemente de forma segura: calificadores, pruebas, supervisión, reversión y errores habituales

Elija el calificador SPF adecuado durante la implementación

• ~all (SoftFail): recomendado para la implementación inicial; los receptores aceptan el correo pero marcan el SPF como softfail cuando no hay coincidencia

• -all (Fail): apliquelo solo cuando esté seguro de que todas las fuentes legítimas están cubiertas

• ?all (Neutral): útil para el descubrimiento temprano si todavía no tiene DMARC, pero ofrece escasa aplicación

• es una autorización implícita; omítalo por brevedad (p. ej., ip4: en lugar de +ip4:)

Plan de implementación segura:

1. Reduzca el TTL de DNS del registro TXT a 300-600 segundos 24 horas antes de los cambios
2. Publique un registro completo con ~all
3. Active DMARC con p=none y recopile informes durante 2-4 semanas; confirme una aprobación ≥98-99 % para el tráfico legítimo
4. Cambie DMARC a quarantine (pct=25→100 con el tiempo)
5. Cambie el SPF a -all cuando DMARC muestre una cobertura casi perfecta y las configuraciones de terceros sean estables
6. Vuelva a subir el TTL a 1-4 horas cuando esté estable

¿Cómo se verifica y se supervisa?

• DNS: dig/nslookup -type=TXT example.com para verificar un único registro SPF

• Mensajes en vivo: compruebe los encabezados Authentication-Results y Received-SPF; busque spf=pass de los destinatarios

• Herramientas de Microsoft: seguimiento de mensajes en el centro de administración de Exchange; registros del conector de salida

• Validadores en línea: evalúan los recuentos de consultas y la expansión

• RUA de DMARC: observe las tendencias de aprobación/fallo por fuente; identifique IP desconocidas

Conexión con AutoSPF: AutoSPF ofrece un simulador «what-if» para probar registros antes de publicarlos, analíticas continuas de DMARC con atribución de fuente y alertas si los fallos de SPF se disparan tras un cambio; la reversión con un clic restaura el registro anterior.

¿Cuáles son los errores de configuración habituales y cómo se corrigen?

• Varios registros TXT de SPF en el mismo nombre de host

• Síntoma: «PermError: multiple SPF records»

• Solución: consolide los registros SPF fusionando todos los mecanismos en un único registro v=spf1; elimine los duplicados

• Superar las 10 consultas

• Síntoma: «PermError: too many DNS lookups»

• Solución: elimine proveedores sin uso, sustituya mx/a por ip4/ip6, segmente en subdominios o aplane con AutoSPF

• Sintaxis incorrecta de include/ip4/ip6

• Síntoma: «PermError: invalid SPF record» o desajuste silencioso

• Solución: valide la sintaxis; asegúrese de que el CIDR es correcto (p. ej., ip4:198.51.100.44/32 o ip4:198.51.100.0/24)

• Colocar all antes de otros mecanismos

• Síntoma: los mecanismos posteriores se ignoran

• Solución: all debe ir al final

• Usar ptr o mx/a amplios de forma involuntaria

• Síntoma: consultas excesivas, aprobaciones falsas

• Solución: elimine ptr; sustituya mx/a por ip4/ip6 explícitos

• Omitir los reenviadores en la estrategia

• Síntoma: el correo reenviado falla el SPF en los destinatarios

• Solución: apóyese en DKIM para la alineación y el éxito de DMARC; fomente SRS en los reenviadores

Conexión con AutoSPF: el análisis (linting) de AutoSPF señala estos problemas en tiempo real y recomienda la corrección precisa, incluido un registro fusionado seguro si existen duplicados.

Controle la complejidad de terceros y alinee con DKIM/DMARC y los casos especiales

Estrategias para múltiples remitentes de terceros

• Consolidación de proveedores: menos proveedores, menos includes, menos consultas

• Delegación por subdominios: envíe el marketing desde news.example.com y el producto desde updates.example.com; mantenga el SPF de la raíz al mínimo

• Redirect para facilitar el mantenimiento: v=spf1 redirect=_spf.example.com centraliza la política (sigue contando para las 10)

• Aplanamiento (gestionado): convierta los includes en IP; automatice la actualización para seguir los cambios de IP del proveedor

Contrapartidas:

• El aplanamiento reduce las consultas a casi cero, pero puede aumentar el tamaño del registro y debe actualizarse a medida que los proveedores cambian; el aplanamiento gestionado (AutoSPF) mitiga esto con actualizaciones automáticas y fragmentación en varias cadenas TXT

• Los subdominios requieren reconfigurar proveedores y DNS, pero aíslan los presupuestos de consultas y reducen el impacto cruzado

SPF, DKIM y DMARC en conjunto (con Microsoft 365)

• SPF autentica el MAIL FROM del sobre; DKIM autentica el contenido del mensaje; DMARC alinea uno o ambos con el dominio From visible

• DKIM de Office 365: active la firma DKIM en Microsoft 365; publique los CNAME para selector1/selector2

• Base de referencia de DMARC: v=DMARC1; p=none; rua=mailto:dmarc@…; aspf=r; adkim=r; pct=100

• Orientación de alineación: use la alineación relajada (aspf=r, adkim=r) al principio; pase a la estricta para dominios sensibles si es viable

• Reenvío y listas de correo: el SPF suele fallar tras el reenvío; DKIM sobrevive si el mensaje no se modifica; DMARC aprueba si DKIM alinea

• ARC: considere activar ARC en los intermediarios que usted opera; ayuda a preservar los resultados de autenticación originales aguas abajo

Casos especiales: subdominios, alojamiento compartido, listas y reenvío

• Subdominios: publique SPF por cada subdominio que envíe; si un subdominio no envía, puede omitir el SPF o publicar v=spf1 -all para indicar que no envía

• Alojamiento compartido/aplicaciones web: prefiera un relay SMTP a través de EOP o de un ESP dedicado para evitar exponer la rotación de IP del servidor web; de lo contrario, publique ip4/ip6

• Listas de correo: configure las listas para minimizar las reescrituras de asunto/cuerpo; siempre que sea posible, active la reescritura del From: para evitar fallos de DMARC en receptores que aplican p=reject

• Reenviadores: fomente SRS; apóyese en DKIM para la aprobación de DMARC; mantenga el rua de DMARC para detectar roturas

Conexión con AutoSPF: AutoSPF gestiona múltiples políticas de subdominio, valida la presencia de DKIM/DMARC y correlaciona los resultados de alineación de DMARC para que pueda ver si es el SPF o el DKIM el que sostiene el DMARC, especialmente en el correo reenviado.

Datos originales, conclusiones y ejemplos de resultados

• En un análisis de 30 días sobre 112 dominios del mercado medio que migraban a Microsoft 365 (conjunto de datos interno de AutoSPF), el 71 % tenía más de cinco fuentes de envío distintas; el 38 % superó el límite de 10 consultas de SPF en el primer borrador; el 19 % publicó varios registros TXT de SPF de forma involuntaria.

• Tras aplicar la segmentación por subdominios y el aplanamiento gestionado, el promedio de consultas por dominio raíz bajó de 11,8 a 4,2, y las tasas de aprobación de DMARC para el correo legítimo aumentaron del 96,4 % al 99,2 %.

• Caso práctico (hipotético pero representativo): AcmeCo utilizaba Office 365, un relay SMTP local (203.0.113.10), SendGrid, Mailchimp y Salesforce. Su SPF inicial tenía 14 consultas efectivas y PermErrors intermitentes en grandes receptores. El inventario de AutoSPF halló dos ESP heredados que seguían enviando rebotes. Al eliminar los includes heredados, trasladar el marketing a news.example.com y aplanar automáticamente el SPF de la raíz, AcmeCo publicó:

• example.com: v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all (IP de EOP aplanadas y descargadas por AutoSPF)

• news.example.com: v=spf1 include:sendgrid.net include:servers.mcsv.net -all Resultado: el recuento de consultas bajó a 5; los softfails se redujeron un 92 %; el éxito de entrega mejoró del 97,1 % al 99,0 % en 21 días.

Preguntas frecuentes

¿Debería usar -all o ~all para Office 365?

Use ~all durante el descubrimiento y la implementación inicial para evitar rechazar remitentes legítimos que podría haber pasado por alto; pase a -all cuando los datos de DMARC muestren una cobertura casi perfecta y ninguna fuente desconocida. AutoSPF puede recomendar el cambio según los umbrales de la tasa de aprobación.

¿Necesito incluir mis IP locales si enruto el correo saliente a través de EOP?

No. Si todo el correo saliente va local → EOP → internet, include:spf.protection.outlook.com es suficiente. Añada sus ip4/ip6 locales solo si algún sistema envía directamente a internet. El modelo de flujo de AutoSPF comprobará el comportamiento real a partir de los datos de DMARC.

¿Qué hago si mis proveedores me hacen superar las 10 consultas?

Consolide proveedores siempre que sea posible, traslade los remitentes de gran volumen a subdominios y use el aplanamiento gestionado. El aplanamiento como servicio de AutoSPF mantiene las IP actualizadas automáticamente y garantiza que el registro se mantenga dentro de los límites de tamaño y de consultas.

¿Puedo tener más de un registro SPF?

No. Puede tener varias cadenas TXT que juntas formen un único valor SPF si el servidor DNS divide las cadenas largas, pero debe publicar exactamente una política v=spf1 por nombre de host. AutoSPF fusiona los duplicados y publica un único registro conforme.