Puntos clave
- Un registro SPF indica a los servidores de correo receptores qué direcciones IP están autorizadas a enviar correos electrónicos en nombre de tu dominio.
- Para añadir una dirección IP, utiliza el mecanismo «ip4:» o «ip6:» dentro de tu registro TXT de SPF ya existente; nunca crees un segundo registro SPF. Un dominio solo puede tener uno.
- En el caso de los servicios de terceros (Google Workspace, Microsoft 365, Mailchimp, SendGrid, etc.), utiliza el mecanismo «include:» en lugar de direcciones IP sin formato. Se actualiza automáticamente.
- Tu registro SPF no puede superar las 10 consultas DNS. Se cuentan todos los mecanismos «include:», «a», «mx» y de redireccionamiento. Los mecanismos «ip4», «ip6» y «all» no se cuentan.
- Comprueba siempre tu registro SPF después de realizar cambios. Un solo error sintáctico puede impedir el envío de correos electrónicos de todo tu dominio sin que te des cuenta.
- Google, Yahoo y Microsoft exigen ahora la alineación con DMARC a los remitentes masivos. Si solo dispones de SPF, no cumples plenamente con los requisitos para 2026.
Para añadir una dirección IP a tu registro SPF, edita el registro TXT SPF existente de tu dominio en el DNS e inserta un mecanismo «ip4:» (o «ip6:») antes del mecanismo «all». Por ejemplo:
v=spf1 ip4:192.0.2.1 include:_spf.google.com -all
Importante: NO crees un segundo registro SPF. Debes editar el que ya tienes y, antes de añadir una IP sin formato, comprueba si tu servicio de envío proporciona un valor «include:», que suele ser la mejor opción a largo plazo.
Esta guía te acompaña a lo largo de todo el proceso, desde cómo localizar tu registro actual y elegir entre «ip4» e «include», hasta cómo editar tu configuración de DNS en los proveedores más habituales, validar el resultado y evitar los errores que, sin que nos demos cuenta, provocan fallos en el correo electrónico de miles de dominios cada año.
¿Qué es un registro SPF y por qué es importante en 2026?
El SPF (Sender Policy Framework) es un registro TXT del DNS que enumera las direcciones IP y los servicios autorizados para enviar correo electrónico desde tu dominio. Si la IP de un servidor no figura en la lista, los servidores de correo receptores pueden rechazar el mensaje o marcarlo como sospechoso.
Google comenzó a aplicar los requisitos de autenticación para los remitentes masivos en febrero de 2024, exigiendo SPF o DKIM más DMARC a cualquiera que envíe más de 5.000 mensajes al día.
A partir de noviembre de 2025, los correos electrónicos que no cumplan los requisitos se enfrentarán a rechazos permanentes, no a aplazamientos temporales, sino a rebotes definitivos. Yahoo estableció requisitos idénticos con el mismo calendario. Microsoft siguió sus pasos en mayo de 2025, rechazando directamente los correos masivos no autenticados con errores 550.
Sin un registro SPF correcto, tu dominio queda expuesto a la suplantación de identidad e incluso tus correos electrónicos legítimos podrían ser rechazados por Gmail, Yahoo y Outlook. Si tu registro SPF no funciona correctamente, tus correos dejarán de llegar sin que se te avise. El envío fallará de forma silenciosa en el extremo receptor, y te darás cuenta cuando un cliente o un compañero te diga que nunca recibió tu mensaje.
Explicación de la sintaxis de los registros SPF (con ejemplos)
Antes de añadir nada a tu registro, debes comprender la función de cada parte. A continuación te mostramos la estructura de un registro SPF típico:
v=spf1 ip4:192.0.2.1 ip4:203.0.113.0/24 include:_spf.google.com -all
| Componente | Qué hace |
|---|---|
| v=spf1 | Etiqueta de versión. Obligatoria. Debe aparecer en primer lugar. |
| IPv4: 192.0.2.1 | Autoriza una única dirección IPv4. No consume una consulta DNS. |
| IPv4: 203.0.113.0/24 | Autoriza un rango CIDR (256 direcciones IP). No consume una consulta DNS. |
| ip6:2001:db8::1 | Autoriza una dirección IPv6. No consume una consulta DNS. |
| incluir:_spf.google.com | Se redirige al registro SPF de otro dominio. Requiere al menos una consulta DNS. |
| a | Autoriza las direcciones IP del registro A del dominio. Consume 1 consulta. |
| mx | Autoriza las direcciones IP de los servidores MX del dominio. Consume 1 consulta. |
| -todos | Fallo grave. Rechaza todo lo que no figure en la lista anterior. |
| ~todos | Fallo leve. Marcar el correo electrónico no autorizado, pero no rechazarlo. |
A continuación se presentan tres ejemplos reales que abarcan distintos niveles de complejidad:
Simple (un solo servidor de correo):
v=spf1 ip4:198.51.100.25 -all
PYME típica (Microsoft 365 + una herramienta de marketing):
v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net -all
Empresa compleja (múltiples servicios):
v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:spf.brevo.com -all
| Regla fundamental: Un dominio solo puede tener UN registro SPF. Si ya tienes uno, DEBES editarlo. No añadas un segundo registro TXT que comience por v=spf1. Dos registros SPF en el mismo dominio provocarán un PermError y anularán TODA la autenticación de correo electrónico. |
¿Necesitas crear un registro desde cero?
Usar el generador gratuito de registros SPF de PowerDmarc para crear al instante un registro sintácticamente correcto.
Cómo añadir una dirección IP a tu registro SPF (paso a paso)
Añadir una dirección IP a tu registro SPF es una de las formas más directas de autorizar una fuente de envío. Suele ser necesario cuando se utiliza un servidor dedicado, un sistema de correo electrónico transaccional o cualquier infraestructura que controles.
Aunque el cambio en sí es sencillo, la precisión es fundamental, ya que los datos incorrectos o los problemas de formato pueden afectar a la autenticación y a la capacidad de entrega. Los pasos que se indican a continuación te guían a lo largo del proceso para añadir correctamente una dirección IP a tu registro SPF, sin alterar tu configuración actual.
Paso 1: Busca tu registro SPF actual
Muchos dominios ya cuentan con un registro SPF de una configuración anterior. Si creas uno nuevo sin comprobarlo, acabarás teniendo dos y eso lo estropeará todo.
Puedes consultar tu historial actual de dos maneras.
Uso la herramienta gratuita de verificación de SPF de PowerDMARC para obtener un resultado visual al instante o ejecuta una consulta desde la línea de comandos:
nslookup -type=TXT tu-dominio.com
buscar TXT tudominio.com

Descubre cómo comprobar al instante tu registro SPF e identificar problemas de configuración que podrían afectar a la entrega del correo electrónico
Busca un registro TXT que empiece por v=spf1. Si encuentras uno, ese es tu registro SPF, y lo editarás en el paso 3. Si ves dos registros que empiezan ambos por v=spf1, ya tienes un problema; fúndelos en uno solo antes de hacer nada más.
Paso 2: Identifica la dirección IP o el valor «Include:» que debes añadir
Hay dos posibilidades, y la elección correcta depende de lo que estés autorizando:
Escenario A: Estás añadiendo una dirección IP específica. Esto se aplica cuando ejecutas tu propio servidor de correo en una IP estática o cuando dispones de una IP de envío dedicada que controlas. Necesitas la dirección IPv4 o IPv6 exacta del servidor.
Escenario B: Estás autorizando un servicio de terceros. Esto se aplica a servicios como Mailchimp, SendGrid, HubSpot, Google Workspace o Microsoft 365. En este caso, necesitas el valor «include:» que figura en la documentación de ese servicio, no sus direcciones IP.
Antes de añadir una dirección IP sin formato, lee la sección siguiente sobre «ip4» frente a «include». Para la mayoría de los servicios de terceros, «include:» es la mejor opción a largo plazo.
Paso 3: Edita tu registro SPF en el DNS
Inicia sesión en tu proveedor de DNS (tu registrador de dominios o proveedor de alojamiento web), busca los registros TXT de tu dominio y edita el registro SPF existente. Añade el nuevo mecanismo «ip4:» o «include:» ANTES del mecanismo «all».
A continuación te explicamos cómo hacerlo con los proveedores más habituales:
- Cloudflare: Ve a DNS → Registros. Busca el registro TXT existente para tu dominio (@ o raíz) que empiece por v=spf1. Haz clic en Editar. Añade el nuevo mecanismo antes de la etiqueta all. Haz clic en Guardar.
- GoDaddy: Ve a Mis productos → DNS → Registros DNS. Busca el registro TXT que contenga v=spf1. Haz clic en Editar. Modifica el campo Valor para incluir el nuevo mecanismo antes de todo. Guarda los cambios.
- Namecheap: Ve a Lista de dominios → Administrar → DNS avanzado. En Registros TXT, busca la entrada SPF. Edítala para añadir el nuevo mecanismo. Guarda los cambios.
- AWS Route 53: Abre Zonas alojadas → selecciona tu dominio → busca el registro TXT con v=spf1. Haz clic en Editar. Actualiza el valor (mantén las comillas que lo rodean). Guarda.
- cPanel: Vaya a Entregabilidad del correo electrónico → haga clic en Administrar junto a su dominio → desplácese hasta Registro SPF sugerido → haga clic en Personalizar. Añada la nueva IP en la sección Dirección IP. Haga clic en Instalar.
| Consejo de experto: Reduce el TTL a 300 segundos (5 minutos) ANTES de realizar cambios en el SPF. Esto acelera la propagación del DNS y te permite corregir errores más rápidamente. Espera a que caduque primero el TTL anterior y, a continuación, realiza el cambio. Restablece el TTL a su valor normal después de confirmar que el registro funciona. |
Paso 4: Valida tu registro SPF actualizado
Un simple espacio de más, un punto y coma que falte o un registro duplicado pueden provocar, sin que te des cuenta, fallos en el correo electrónico de todo tu dominio. La validación tarda 30 segundos y te ahorra horas de resolución de problemas.
Revisa esta lista de comprobación cada vez que cambies el SPF:
- Comprueba tu dominio con una herramienta de verificación de SPF y asegúrate de que el registro se interpreta correctamente.
- Comprueba que solo aparece UN registro SPF (y no dos registros TXT que empiecen por v=spf1).
- Comprueba el número total de consultas DNS. Debe ser igual o inferior a 10.
- Comprueba que todo el mecanismo se encuentre en el extremo final del registro.
- Envía un correo electrónico de prueba a una cuenta de Gmail o Yahoo, abre el mensaje, consulta los encabezados originales y busca «spf=pass».
Para realizar una auditoría de seguridad completa que vaya más allá del SPF, analiza tu dominio con el analizador de dominios de PowerDMARC. Comprueba el SPF, el DKIM, el DMARC, el MTA-STS y el BIMI de una sola vez.
Paso 5: Supervisar los resultados de la autenticación SPF a lo largo del tiempo
Añadir la dirección IP es el primer paso. Comprobar si realmente funciona y detectar si se produce algún fallo más adelante es el segundo paso.
Los informes agregados de DMARC son la principal forma de obtener una visión continua de las tasas de superación o fracaso de SPF por fuente de envío. Sin supervisión, se está actuando a ciegas. Muchos administradores solo se dan cuenta de que un registro SPF está dañado cuando los clientes empiezan a marcar correos electrónicos legítimos como spam o cuando una herramienta de facturación lleva semanas enviando mensajes desde una IP no autorizada sin que nadie se haya percatado.
| ¿Quieres tener un control constante de todas las direcciones IP que envían correos electrónicos desde tu dominio?
El panel de informes DMARC de PowerDMARC muestra las tasas de aprobación/rechazo de SPF por fuente en todos tus dominios, en paneles fáciles de leer, no en formato XML sin procesar. Empieza tu prueba gratuita de 15 días → powerdmarc.com/free-dmarc-trial/ |
ip4 frente a include: ¿cuál deberías usar? (Guía para tomar una decisión)
Cuándo utilizar IPv4 (direcciones IP sin formato):
- Tienes tu propio servidor de correo en una dirección IP estática que controlas.
- Dispones de una IP de envío dedicada de un proveedor de servicios de correo electrónico (ESP) de tu propiedad (no compartida).
- Estás autorizando un relé SMTP local con una dirección fija.
La regla: utiliza ip4: solo cuando TÚ controles la IP y esta no vaya a cambiar.
Cuándo utilizar «include:» (SPF delegado):
- Estás autorizando cualquier servicio SaaS de terceros, como Google Workspace, Microsoft 365, Mailchimp, SendGrid, HubSpot, Salesforce, Zendesk o cualquier herramienta de correo electrónico basada en la nube.
- El servicio utiliza direcciones IP compartidas o rotativas.
- El servicio publica su propio registro SPF, del que se encarga de mantenerlo.
Por qué incluirlo: casi siempre es mejor para los servicios de terceros:
Los servicios en la nube cambian las direcciones IP con regularidad. Si introduces sus direcciones IP actuales de forma estática con «ip4:», tu registro SPF quedará obsoleto cuando migren la infraestructura y tu correo electrónico dejará de funcionar sin previo aviso.
El mecanismo «include:» remite al registro SPF del propio servicio, que se mantiene de forma dinámica. Cuando actualizan sus direcciones IP, tu SPF refleja automáticamente los cambios sin que tengas que hacer nada por tu parte.
[Imagen: Diagrama de flujo de árbol de decisión — «¿Es este un servidor o una dirección IP de tu propiedad y bajo tu control?» → SÍ → Utiliza IPv4 / NO → «¿El servicio proporciona un valor "include"?» → SÍ → Utiliza "include" (preferible) / NO → Utiliza IPv4 + configura un recordatorio de revisión trimestral]
[Texto alternativo: Diagrama de flujo que muestra cuándo utilizar el mecanismo «ip4» frente al mecanismo «include» en los registros SPF]
Para obtener más información sobre la sintaxis de «include» y las prácticas recomendadas, consulta la guía completa sobre «include» en SPF.
Valores comunes de SPF de terceros (tabla de referencia rápida)
Esta tabla evita tener que buscar por separado la documentación SPF de cada servicio. Añádela a tus favoritos para la próxima vez que el departamento de marketing contrate una nueva herramienta.
| Servicio de correo electrónico | Valor de inclusión del SPF | Notas |
|---|---|---|
| Espacio de trabajo de Google | incluir:_spf.google.com | Abarca todo el envío de Google Workspace |
| Microsoft 365 | incluir:spf.protection.outlook.com | Estándar para todos los inquilinos de M365 |
| Mailchimp | incluir:servers.mcsv.net | La versión estándar de Mailchimp incluye |
| SendGrid | incluir:sendgrid.net | Abarca todos los envíos de SendGrid |
| Salesforce | incluyen:_spf.salesforce.com | Abarca los envíos de correo electrónico de Salesforce |
| Zendesk | incluyen: mail.zendesk.com | Correo electrónico de asistencia de Zendesk |
| Freshdesk | incluye: email.freshdesk.com | Correo electrónico de asistencia de Freshdesk |
| Amazon SES | incluye:amazonses.com | Abarca el envío de SES |
| Brevo | incluir:spf.brevo.com | Actualizado desde Sendinblue |
| Zoho Mail | incluye:zoho.com | Incluye Zoho Mail |
| Matasellos | incluir:spf.mtasv.net | Para el correo electrónico transaccional de Postmark |
| Klaviyo | incluir:spf.klaviyo.com | Para el marketing por correo electrónico de Klaviyo |
Tabla: Referencia rápida de los valores de SPF para los servicios de correo electrónico más habituales. Comprueba siempre el valor actual en la documentación oficial de cada servicio, ya que los proveedores los actualizan de vez en cuando.
Importante: Cada inclusión cuenta como al menos una consulta DNS, y muchos registros SPF de terceros contienen inclusiones anidadas que añaden más. Si utilizas cinco o más servicios, es probable que te estés acercando al límite de 10 consultas. Consulta la siguiente sección para saber cómo gestionar esto.
El límite de 10 consultas DNS y qué hacer cuando se alcanza
La RFC 7208 limita la evaluación del SPF a 10 mecanismos de consulta DNS. Los mecanismos que se tienen en cuenta son: include, a, mx, redirect y exists. Los mecanismos que NO se tienen en cuenta son: ip4, ip6 y all. Estos se evalúan localmente sin necesidad de realizar una consulta DNS.
Cuando tu registro supera las 10 consultas, SPF devuelve un PermError. Muchos servidores receptores interpretan un PermError como un fallo de SPF. La capacidad de entrega de tu correo electrónico disminuye y no recibes ninguna notificación de que esto ha ocurrido.
También existe una restricción menos conocida: el límite de dos consultas sin respuesta. Si más de dos consultas DNS devuelven NXDOMAIN (dominio no encontrado) durante la evaluación del SPF, este también falla.
Aquí tienes tres formas de solucionarlo, ordenadas por orden de practicidad:
Opción 1: Retirar los mecanismos que no se utilizan
Empieza por realizar una auditoría. Elimina las declaraciones «include:» correspondientes a los servicios que ya no utilices. Elimina los registros A y MX si no envías correo electrónico desde las direcciones IP asociadas a los registros A o MX de tu dominio. Esta es la solución más rápida y, a menudo, libera de inmediato entre 2 y 3 consultas.
Opción 2: Aplanamiento manual del SPF
Resuelve los mecanismos de inclusión hasta llegar a sus direcciones IP subyacentes y codifícalas directamente como entradas IPv4. De este modo, se eliminan las consultas de DNS que habrían consumido esas inclusiones.
Esto supone una carga de mantenimiento constante. Los proveedores de correo electrónico modifican o amplían sus rangos de IP sin avisarte. Cuando lo hacen, tu registro simplificado queda desactualizado y los correos legítimos empiezan a fallar. La simplificación manual del SPF es como cortar el césped. Funciona, pero hay que volver a hacerlo cada pocas semanas.
Opción 3: Macros SPF o aplanamiento automático
El enfoque moderno utiliza macros SPF (definidas en el RFC 7208, apartado 7), que se expanden dinámicamente en el momento de la evaluación para mantener el registro por debajo del límite de consultas sin necesidad de realizar un mantenimiento manual de las direcciones IP.
Las herramientas de simplificación automática se encargan de esto de forma continua, volviendo a resolver las direcciones IP de los proveedores según un calendario y actualizando tu registro publicado.
| ¿Has alcanzado el límite de 10 búsquedas?
PowerSPF utiliza macros SPF para mantener tu registro por debajo del límite de consultas de forma permanente y automática. Sin necesidad de aplanamiento manual, sin direcciones IP obsoletas y sin mantenimiento. PowerDMARC también admite el aplanamiento SPF tradicional para configuraciones más sencillas. Empieza tu prueba gratuita de 15 días |
El SPF por sí solo no basta: por qué DKIM y DMARC completan el panorama
El SPF comprueba si la dirección IP del remitente del sobre (MAIL FROM) figura en tu lista de direcciones autorizadas. Funciona cuando el correo electrónico viaja directamente del remitente al destinatario, pero cuando se reenvía —ya sea a través de listas de correo, reglas de reenvío automático, buzones compartidos o cualquier servidor de retransmisión—, la dirección IP de envío cambia. El SPF deja de funcionar, ya que la dirección IP del servidor de reenvío no figura en tu registro SPF, y no debería figurar.
DKIM (DomainKeys Identified Mail) funciona de manera diferente. Adjunta una firma criptográfica al cuerpo del correo electrónico. Esa firma acompaña al mensaje independientemente del servidor que lo reenvíe. DKIM se mantiene intacto tras el reenvío, pero SPF no.
DMARC (Autenticación, Notificación y Conformidad de Mensajes Basadas en Dominios) los integra. Basta con que SPF o DKIM (uno de los dos) sea válido y coincida con tu dominio de remitente para que el mensaje supere la verificación DMARC.
En la práctica, DKIM es el mecanismo de verificación más fiable, ya que no se ve afectado por el reenvío.
Por eso es importante contar con ambas cosas:
- Google exige el uso de SPF o DKIM para todos los remitentes, además de DMARC para los remitentes masivos (más de 5.000 mensajes al día). A partir de noviembre de 2025, los mensajes que no cumplan estos requisitos serán rechazados de forma permanente.
- Microsoft comenzó a rechazar los correos electrónicos masivos no autenticados en mayo de 2025.
- Yahoo aplica los mismos requisitos y sigue el mismo calendario que Google.
Si SPF es tu único mecanismo de autenticación, tu dominio sigue siendo vulnerable a la suplantación de identidad en cualquier ruta de reenvío de correo electrónico y no cumples plenamente con los requisitos de los proveedores de correo electrónico para 2026.
Qué hacer a continuación:
- Configura DKIM para todos los servicios que envían correos electrónicos desde tu dominio.
- Publica un registro DMARC (empieza con p=none para realizar un seguimiento y, posteriormente, pasa a p=reject).
- Supervisa los informes agregados de DMARC para ver qué fuentes superan o no las verificaciones de SPF y DKIM.
| ¿Estás listo para conocer todos los detalles sobre la autenticación de tu correo electrónico?
PowerDMARC supervisa DMARC, SPF y DKIM en todos tus dominios mediante paneles de control claros que muestran exactamente qué mensajes se aceptan, cuáles se rechazan y por qué. |
Registros SPF para dominios que no envían correo electrónico
Si tienes dominios aparcados, inactivos o que solo se utilizan para sitios web, estos siguen necesitando protección SPF. Los atacantes suplantan activamente los dominios no utilizados precisamente porque a menudo se dejan desprotegidos.
La solución es sencilla. Publica este registro SPF:
v=spf1 -todos
Esto indica a los servidores receptores que nadie está autorizado a enviar correos electrónicos desde este dominio. Cualquier mensaje que afirme proceder de él debe ser rechazado.
Para garantizar la máxima protección, publica también un registro DMARC con una política de rechazo:
v=DMARC1; p=rechazar; rua=mailto:[email protected]
Esta combinación impide la suplantación de identidad en todos los dominios que poseas, independientemente de si envían correo electrónico o no.
Errores habituales con el protector solar y cómo evitarlos
Los errores de sintaxis en SPF son muy frecuentes, y lo peor es que no dan ningún aviso. A continuación, te presentamos los ocho errores más comunes, qué ocurre cuando los cometes y cómo solucionarlos:
| Error | ¿Qué pasa? | Cómo solucionarlo |
|---|---|---|
| Dos registros SPF en un dominio | PermError. Fallo de SPF en TODOS los correos electrónicos | Combinar ambos registros en un único registro TXT |
| Falta «v=spf1» al principio | El registro se ignora por completo | Asegúrate de que el registro comience exactamente con «v=spf1» |
| Mecanismos instalados al final | Todo lo que venga después de «-all» o «~all» se ignora | Mueve todo al final del registro |
| Más de 10 consultas DNS | PermError. El SPF falla sin mostrar ningún mensaje | Elimina las inclusiones que no se utilicen, aplana el código o utiliza macros SPF |
| Usar +all | Autoriza a todo Internet a enviar mensajes como si fuera tu dominio | Cambia inmediatamente a -all o ~all |
| Espacios o errores tipográficos en las direcciones IP | El mecanismo no es válido; puede provocar un PermError | Comprueba bien todas las direcciones IP; utiliza una herramienta generadora de SPF |
| Incluido el mecanismo ptr, que ha quedado obsoleto | El RFC 7208 desaconseja el uso de «ptr»; algunos receptores lo ignoran | Sustituye por «ip4:» o incluye: |
| Direcciones IP obsoletas de servidores fuera de servicio | Podría ser reasignado. Posible riesgo para la seguridad | Revisar el SPF cada trimestre; eliminar las direcciones IP que ya no se utilizan |
Tabla: Los errores más comunes en los registros SPF, sus consecuencias y cómo solucionarlos.
Si quieres profundizar en la resolución de errores de validación de SPF, consulta nuestra guía sobre los errores de validación de SPF y cómo solucionarlos.
Conclusión
Añadir una dirección IP a tu registro SPF es una modificación sencilla del DNS, pero para hacerlo correctamente es necesario comprender la sintaxis, elegir entre «ip4:» e «include:», no superar el límite de 10 consultas DNS y validar el resultado después de cada cambio.
SPF es uno de los componentes de una pila completa de autenticación de correo electrónico. En 2026, con Google, Yahoo y Microsoft aplicando activamente los requisitos de autenticación de remitentes, el SPF por sí solo no es suficiente. DKIM y DMARC son igualmente esenciales para una protección y un cumplimiento totales.
A medida que tu organización incorpore más servicios de envío, tu registro SPF irá creciendo. La gestión manual no es escalable y un solo error puede impedir, sin que te des cuenta, la entrega de correos electrónicos en todo tu dominio. La gestión automatizada del SPF ya no es un lujo. Es una cuestión de buenas prácticas operativas.
Deja de gestionar los registros SPF manualmente. PowerDMARC te ofrece la simplificación automatizada de SPF (PowerSPF), la supervisión de DMARC, la gestión de DKIM y la generación de informes claros para todos tus dominios, todo ello en una sola plataforma. Empieza tu prueba gratuita de 15 días
Preguntas frecuentes
1) ¿Puedo tener dos registros SPF en el mismo dominio?
No. La RFC 7208 exige exactamente un registro TXT de SPF por dominio. Si un dominio tiene dos registros que comienzan por «v=spf1», los servidores receptores devuelven un PermError y consideran que el SPF ha fallado para todos los mensajes. Si necesitas autorizar fuentes adicionales, edita el registro existente para añadirlas; no crees uno nuevo.
2) ¿Cuál es la diferencia entre -all y ~all?
-all es un fallo duro: indica a los servidores receptores que rechacen los correos electrónicos procedentes de direcciones IP no autorizadas. ~all es un fallo blando: marca los correos electrónicos no autorizados, pero no obliga a rechazarlos. En la práctica, cuando se aplica DMARC con p=quarantine o p=reject, la diferencia es mínima, ya que la política DMARC prevalece sobre el calificador SPF. Si tienes DMARC en modo de aplicación, cualquiera de las dos opciones funciona. Si aún no tienes DMARC, -all ofrece una protección mayor.
3) ¿Cuántas direcciones IP puedo añadir a un registro SPF?
No existe un límite estricto en cuanto al número de mecanismos «ip4:» o «ip6:». Estos no se tienen en cuenta a la hora de calcular el límite de 10 consultas DNS. Sin embargo, el registro SPF completo debe ajustarse a las restricciones de tamaño de los registros TXT del DNS (255 caracteres por cadena, con varias cadenas concatenadas hasta un máximo de aproximadamente 4.096 caracteres). Para listas de IP extensas, utilice la notación CIDR (por ejemplo, ip4:192.0.2.0/24) para abarcar rangos de forma eficiente.
4) ¿Cuánto tiempo tardan en surtir efecto los cambios en el FPS?
Depende del TTL (Time to Live) de tu registro DNS. Si tu TTL es de 3600 (1 hora), la mayoría de los servidores de resolución detectarán el cambio en el plazo de 1 hora. Para acelerar el proceso: reduce tu TTL a 300 (5 minutos) antes de realizar los cambios, espera a que expire el periodo del TTL anterior y, a continuación, realiza la modificación. Esto reduce considerablemente el tiempo de propagación.
5) ¿Cómo puedo saber qué direcciones IP están enviando correos electrónicos desde mi dominio en este momento?
El método más fiable es la generación de informes DMARC. Cuando publicas un registro DMARC con la etiqueta «rua», los servidores receptores envían informes diarios agregados en los que se enumeran todas las direcciones IP que han intentado enviar correo electrónico desde tu dominio, junto con los resultados de superación o fallo de las verificaciones SPF y DKIM. Sin DMARC, solo puedes hacer conjeturas. PowerDMARC procesa estos informes y los presenta en paneles de control claros y fáciles de entender, para que puedas ver exactamente quién está enviando mensajes desde tu dominio.
6) ¿Se tienen en cuenta los mecanismos IPv4 e IPv6 a la hora de calcular el límite de 10 consultas DNS?
No. Solo cuentan para el límite los mecanismos que requieren una consulta DNS: include, a, mx, redirect y exists. Los mecanismos ip4, ip6 y all se evalúan localmente y no consumen consultas DNS.
- Cómo añadir una dirección IP a tu registro SPF (guía paso a paso) - 11 de mayo de 2026
- Registro SPF de Avanan: cómo configurar, corregir y optimizar tu SPF para Check Point Harmony Email - 7 de mayo de 2026
- Registro SPF de DNS: cómo funciona y cómo configurarlo - 6 de mayo de 2026


