Defaults.Exposed › Soluciones › Guides
¿SPF falla con sus herramientas SaaS? Por qué ocurre y el orden de reparación — Edición Europa (2026)
Publicado 2026-07-08
Cifras a fecha de 2026-06-29 · metodología v7. Datos agregados del censo sobre 261 millones de dominios calificados. Consulte cómo calificamos.
Cuando una herramienta SaaS “falla SPF”, su registro normalmente no es el problema: el correo está fallando la alineación DMARC, o su cadena de includes ha reventado el límite de SPF de 10 consultas DNS. 2.119.539 de los 138.927.207 dominios que publican SPF están en 9–10 consultas — a un include de SaaS del precipicio — según el censo de Defaults.Exposed de 261.086.232 dominios.
A continuación: cómo distinguir cuál de los dos problemas tiene, y luego el orden de reparación — analice primero, encuentre el dominio desde el que la herramienta envía realmente, cambie al proveedor a DKIM de dominio propio y añada un include de SPF solo donde ayude de verdad — más los detalles para HubSpot, Salesforce, Mailchimp y SendGrid.
¿Por qué falla SPF en el correo de una herramienta SaaS?
Tres patrones cubren casi todos los casos:
| Lo que dice el informe o el rebote | Lo que falla en realidad | La solución |
|---|---|---|
| SPF pasa, DMARC sigue fallando | Alineación: la herramienta pasó SPF en su propio dominio de rebote, no en el suyo | Active el DKIM de dominio propio del proveedor (CNAMEs) |
SPF permerror | Su cadena de includes supera el límite de SPF de 10 consultas DNS | Pode los includes; vea la solución de demasiadas consultas |
SPF fail / softfail | La herramienta sí envía con su return-path y no está en su registro | Añada el include del proveedor o active su dominio de rebote personalizado |
Datos a fecha de 2026-06-29.
La fila en negrita es donde está la mayoría de la gente. Añadir líneas include: para cada herramienta no la toca — y cada línea le acerca a la segunda fila: al menos 797.263 dominios ya han cruzado el límite de 10 consultas, y su SPF ahora devuelve un PermError que no protege nada. Cifras completas en el informe de PermError de SPF.
¿Qué dominio comprueba SPF en realidad?
No el de su cabecera From. Los sistemas de correo receptores evalúan SPF contra el dominio del Return-Path (el RFC5321.MailFrom, también llamado dirección de rebote o envelope-from) — la cabecera From que ve su destinatario no interviene en la comprobación de SPF en sí.
Este único hecho explica la mayoría de los “fallos de SPF por SaaS”. Su plataforma de marketing envía con un Return-Path del tipo [email protected]; SPF se comprueba contra vendor.com y pasa sin problema. Luego DMARC pregunta si ese dominio verificado por SPF coincide con su dominio From. No coincide, así que la pata SPF de DMARC falla y su panel dice “SPF failing”. Editar su propio registro SPF no puede arreglar eso — su registro nunca fue consultado.
¿Cuál es el orden de reparación?
- Ejecute primero el análisis gratuito. Le dice de una sola pasada si su SPF falta, está duplicado, supera el límite de consultas o está bien, y en qué punto está DMARC — antes de tocar el DNS.
- Encuentre el Return-Path que la herramienta usa de verdad. Envíese una prueba desde la herramienta y lea la cabecera Return-Path (y Authentication-Results) en el mensaje sin procesar. Eso le dice en qué fila de la tabla anterior está usted.
- Active el DKIM de dominio propio del proveedor. Toda herramienta SaaS seria ofrece “autenticación de dominio”: unos pocos registros CNAME que le permiten firmar con DKIM como su dominio. Esa firma se alinea con su dominio From, así que DMARC pasa vía DKIM — de forma duradera, e incluso cuando el correo se reenvía. Esta es la solución que perdura.
- Añada el include de SPF del proveedor solo si usa su return-path — porque ha activado su dominio de rebote personalizado, o porque envía de verdad con su dominio en el sobre. Un include para un proveedor que rebota vía su propio dominio no aporta nada y gasta su presupuesto de consultas.
- Cuente sus consultas DNS antes de guardar. El límite es de 10 consultas resueltas, los includes cuentan de forma recursiva, y 2.119.539 dominios ya están en 9–10 — el p99 del censo es 9. ¿Está cerca del borde? Elimine primero los includes de herramientas que ya no usa. ¿Acaba de cambiar de proveedor de correo? Compruebe si quedó un segundo registro — dos registros SPF equivalen a un PermError.
- Vuelva a analizar y confirme. SPF pasando en el dominio correcto, DKIM alineado, DMARC pasando. La referencia completa está en cómo arreglar SPF; las guías paso a paso por proveedor como SPF en GoDaddy y DMARC en IONOS cubren los clics en el panel DNS.
¿Qué debe hacer para HubSpot, Salesforce, Mailchimp y SendGrid?
HubSpot. Conecte su dominio de envío en la configuración de HubSpot y publique los dos CNAME de DKIM que emite (hs1-… / hs2-…). Eso alinea DKIM con su dominio From. No necesita un include de SPF para HubSpot salvo que haya configurado HubSpot para usar su propio dominio de rebote.
Salesforce. Cree una clave DKIM en la configuración (Setup) de Salesforce y publique el par de CNAME que genera. Si Salesforce envía con el return-path de su organización, añada include:_spf.salesforce.com y configure el dominio de rebote — este es el único gran CRM donde el include de SPF suele hacer falta de verdad.
Mailchimp. Autentique su dominio y publique los CNAME de DKIM k2 / k3. La alineación de Mailchimp es solo por DKIM — ya no hay include de SPF que añadir, y añadir uno sacado de un tutorial antiguo solo malgasta consultas.
SendGrid. Complete la autenticación de dominio (“automated security”): tres CNAME que cubren tanto DKIM como el return-path en su propio subdominio. No hace falta include de SPF. De los 740.321 dominios cuyo SPF autoriza sendgrid.net, solo el 18,0% tiene DMARC con política de aplicación (datos a fecha de 2026-06-29) — la mayoría de los remitentes de SendGrid se quedan a un paso.
Zendesk y todo lo demás: mismo patrón. Busque la página de “autenticación de dominio” de la herramienta, publique sus CNAME de DKIM, y toque SPF solo si la herramienta documenta que usa su return-path.
¿Es SPF distinto para las empresas europeas?
No — SPF, DKIM y DMARC funcionan igual en todas partes. Lo que cambia en Europa es el contexto: quién pregunta, y qué han hecho ya sus vecinos.
Su ccTLD marca el listón local. Los ccTLD europeos publican SPF muy por encima de las tasas de .com, pero los dominios que rematan el trabajo — una política DMARC de aplicación encima — son minoría en todas partes:
| TLD | Adopción de SPF (de dominios calificados) | DMARC con aplicación (de dominios calificados) |
|---|---|---|
| .nl | 75,91% | 29,43% |
| .ie | 70,89% | 8,79% |
| .de | 64,67% | 21,38% |
| .dk | 50,42% | 19,88% |
| .com | 54,14% | 9,50% |
Datos a fecha de 2026-06-29. Francia: 13,65% con DMARC de aplicación; Italia: 5,24%.
El valor por defecto de su alojamiento europeo importa. 4.346.526 dominios autorizan los servidores de correo de IONOS en la UE (_spf-eu.ionos.com) en su SPF — y solo el 0,3% termina en -all estricto, con un 1,0% con DMARC en aplicación. Los 2.132.049 de OVH lo hacen mejor en rigor (43,7%) pero solo el 2,2% aplica DMARC (datos a fecha de 2026-06-29). Si nunca tocó su registro, usted está sobre esos valores por defecto.
Los reguladores ya lo nombran. El artículo 21(2)(j) de NIS2 exige a las entidades en su ámbito proteger sus comunicaciones, y el Reglamento de Ejecución (UE) 2024/2690 de la Comisión detalla medidas de seguridad de correo y de DNS. La autenticación del correo es la pieza concreta y comprobable — y, algo inusual en cumplimiento normativo, gratuita de arreglar.
Sobre la residencia de datos: el escáner y el censo de Defaults.Exposed se ejecutan en AWS eu-west-1, publicamos únicamente cifras agregadas, y un análisis comprueba solo el dominio que usted solicita.
Preguntas frecuentes
¿Mi verificador de SPF dice “pass” pero el panel de la herramienta dice que SPF falla — por qué? El verificador probó su registro; el receptor probó el dominio del Return-Path que la herramienta usó realmente, y luego DMARC lo comparó con su dominio From. Eso es un fallo de alineación, no un fallo del registro — se arregla con el DKIM de dominio propio del proveedor, no editando SPF.
¿Debería añadir sin más el include de SPF de cada herramienta que usamos? No. Cada include gasta parte del presupuesto de 10 consultas de SPF, de forma recursiva: 2.119.539 de los 138.927.207 dominios que publican SPF están en 9–10 consultas, y al menos 797.263 lo superan — su SPF devuelve PermError y no protege nada (datos a fecha de 2026-06-29).
¿El include arregla también DMARC? Solo si la herramienta envía con su return-path, de modo que SPF pasa y se alinea. Para la mayoría de las herramientas SaaS no es así — por eso el DKIM alineado, y no SPF, es la pata que hace que DMARC pase para el correo de SaaS.
¿Es esto una obligación legal en la UE? Para las entidades en el ámbito de NIS2, el artículo 21(2)(j) y el Reglamento de Ejecución (UE) 2024/2690 convierten la seguridad del correo en una obligación. Incluso fuera de ese ámbito, las aseguradoras y los cuestionarios de clientes lo preguntan cada vez más — y a fecha de 2026-06-29, ningún ccTLD de la UE consigue que ni siquiera un tercio de sus dominios tenga una política DMARC de aplicación (29,43% en .nl como máximo; 5,24% en .it).
Envíe el informe al propietario
Cuando los CNAME estén activos, vuelva a ejecutar el análisis y reenvíe el informe calificado al propietario del negocio o al cliente. Muestra, en lenguaje claro, qué estaba fallando, qué arregló usted y dónde está ahora el dominio — exactamente la prueba que necesitan para la renovación del ciberseguro o el cuestionario de seguridad del cliente, por escrito y no solo de palabra.
Compruebe su dominio gratis
Vea exactamente qué pata de SPF, DKIM y DMARC está fallando — de forma privada y solo para el propietario.
Compruebe su dominio → · Arreglar SPF → · SPF PermError: “too many DNS lookups” → · Cómo calificamos → · Solo datos agregados. Datos almacenados y procesados en la UE.