Tu correo ha rebotado. No ha acabado en spam: el servidor lo ha rechazado. Ha devuelto 550 5.7.26 o 550 5.7.515, y el mensaje no ha llegado a su destino. Una posible causa es que tu dominio no tenga un registro SPF para el correo electrónico válido o que el existente tenga errores de estructura. Estos códigos, por sí solos, no demuestran que SPF sea la única causa.
Desde febrero de 2024, Google y Yahoo aplican requisitos de autenticación que varían según la categoría y el volumen del remitente. Una configuración SPF incorrecta puede provocar rechazos o perjudicar la entrega. Conviene revisarla en cualquier dominio de correo empresarial, incluido el tuyo.
Google:
550 5.7.26- No se acepta correo sin autenticarMicrosoft:
550 5.7.515- Identidad del remitente no autenticada
Esta guía va directamente a la configuración. Encontrarás ejemplos para tu entorno, problemas que pasan desapercibidos incluso en registros aparentemente correctos y una prueba para comprobar la autenticación en un envío real. SPF es una pieza de un conjunto de tres: para entender cómo encaja con DKIM y DMARC, consulta los fundamentos de seguridad del correo empresarial.
¿Qué es un registro SPF para el correo electrónico?
Un registro SPF es una entrada TXT del DNS que indica qué servidores pueden enviar correo usando el dominio del sobre SMTP. Cuando llega un mensaje a Gmail o Outlook, el servidor receptor consulta el DNS y compara la IP de envío con las autorizaciones del registro. El resultado puede ser pass, fail u otro estado SPF; la decisión de aceptar, rechazar o filtrar el mensaje depende de la política del receptor.
SPF se evalúa en el sobre SMTP, contra el dominio de MAIL FROM, no contra la dirección «De» que ve el destinatario. El TXT se publica en ese dominio, que puede ser la raíz (@) o un subdominio utilizado para el sobre. Si quieres entender cómo encajan las distintas entradas DNS, la guía para configurar el correo en tu dominio explica todo el proceso desde cero.
La regla de un único registro
RFC 7208, la especificación de SPF, permite un único registro TXT que empiece por v=spf1 en cada dominio evaluado. Si el receptor encuentra dos registros SPF en ese dominio, devuelve PermError. SPF no puede evaluarse correctamente mientras siga el duplicado, aunque eso no implica necesariamente el rechazo de todos los mensajes.
Es un error habitual al añadir un proveedor a un dominio que ya utiliza Google Workspace u otro servicio: alguien crea un segundo registro en vez de modificar el existente.
Comprueba lo que tiene tu dominio antes de cambiar nada:
dig +short txt yourdomain.comCuenta las líneas que empiezan por v=spf1. Si hay dos, la evaluación devolverá PermError. Resuelve primero ese duplicado.
| Situación | Resultado |
|---|---|
| Un registro SPF con sintaxis correcta | Puede autenticar las IP autorizadas ✓ |
| Dos registros SPF en el mismo dominio | PermError: SPF no se evalúa correctamente ✗ |
| Ningún registro SPF en el dominio | SPF ausente; puede incumplir los requisitos del receptor ✗ |
Incorrecto: dos registros provocan PermError al evaluar ese dominio:
v=spf1 include:_spf.google.com -all
v=spf1 include:spf.trekmail.net -allCorrecto: ambos se combinan en un único registro SPF:
v=spf1 include:_spf.google.com include:spf.trekmail.net -allTu registro SPF: la configuración mínima
El contenido exacto depende de los servidores que realmente envían tu correo. Autoriza solo los que utilizas. Cada include: adicional consume presupuesto de evaluación e incorpora rangos de IP que no controlas.
Escenario A: SMTP gestionado de TrekMail (planes Starter y Agency)
Si tu plan de pago de TrekMail incluye entrega gestionada y este es el único servicio que envía para el dominio del sobre, esta línea puede cubrirlo. Confirma primero todos los remitentes:
v=spf1 include:spf.trekmail.net -allEscenario B: plan gratuito de TrekMail (SMTP propio)
Si el plan Nano ofrece conexión a tu propio proveedor SMTP, como Amazon SES, SendGrid o Mailgun, autoriza las IP de ese proveedor, no las de TrekMail:
v=spf1 include:amazonses.com -allSustituye include:amazonses.com por lo que indique la documentación de tu proveedor para tu configuración. No autorices rangos de IP que no utilizas.
Escenario C: configuración híbrida - TrekMail + Google Workspace
¿Estás migrando desde Google o mantienes ambos servicios durante la transición? Si ambos envían usando el mismo dominio del sobre, combínalos en un registro:
v=spf1 include:spf.trekmail.net include:_spf.google.com -allComponentes del registro
| Componente | Función |
|---|---|
v=spf1 | Identificador de versión. Debe aparecer primero. |
include: | Delega la autorización en la política SPF de un proveedor externo. |
-all | Hard fail: declara no autorizados los remitentes no coincidentes. Úsalo tras completar el inventario, valorando la transición desde ~all. |
~all (soft fail) señala que un remitente probablemente no está autorizado; no garantiza que el mensaje se entregue. -all expresa una política más estricta, pero tampoco obliga al receptor a rechazar. Antes de usarlo en producción, comprueba que todos los servicios legítimos estén incluidos. Durante una configuración nueva o una transición, ~all puede ser una opción temporal.
El límite de 10 términos con consultas DNS
La especificación SPF (RFC 7208) limita a 10 los términos que provocan consultas DNS durante la evaluación, no todas las consultas DNS individuales. Cuentan include:, a, mx y el modificador redirect, incluidos los términos evaluados en las políticas referenciadas. ip4: e ip6: no cuentan. Si la evaluación supera 10, el receptor devuelve PermError.
Es fácil pasarlo por alto. Tu registro puede superar una comprobación de sintaxis porque su estructura es válida. Pero cuando el receptor recorre las referencias anidadas y el total de términos evaluados supera 10, SPF devuelve un error.
Qué cuenta para el límite:
include:(y los términos anidados que se evalúen)a,mx,redirect
Qué no cuenta:
ip4:eip6:: las entradas de IP directas no necesitan esa cadena de consultasall
Comprueba el registro antes de publicarlo y analiza también sus referencias:
dig +short txt yourdomain.comSi tienes una cadena larga de referencias anidadas, puedes aplanar el registro sustituyendo include: por entradas ip4: directas, siempre que mantengas actualizados los rangos cuando cambien. Otra opción es repartir los envíos entre subdominios del sobre, cada uno con su propio presupuesto.
Cómo validar tu registro SPF
No te fíes solo de los indicadores verdes del panel DNS: una sintaxis válida no demuestra que la entrega funcione. Comprueba SPF con un envío SMTP real. Así verás la evaluación que hizo Gmail para ese mensaje, aunque un resultado positivo no garantice la bandeja de entrada.
- Envía un correo desde tu dominio a una cuenta de Gmail que controles.
- Abre el mensaje en Gmail.
- Haz clic en el menú de tres puntos → Mostrar original.
- Busca
Authentication-Results.
Ejemplo de un resultado positivo:
spf=pass (google.com: domain of team@yourdomain.com designates 192.0.2.1 as permitted sender)| Resultado | Significado | Corrección |
|---|---|---|
spf=softfail | La IP no coincide con una autorización y se aplica ~all | Si es legítima, autorízala; cambiar a -all no la autoriza |
spf=fail | La IP no está autorizada y se aplica -all | Añade la IP de envío si es legítima |
spf=permerror | Error de sintaxis, duplicados o más de 10 términos con consultas | Corrige primero la estructura |
spf=none | No se encontró SPF en el dominio evaluado | Publica el TXT en ese dominio, en @ si es la raíz |
permerror indica que no se pudo evaluar correctamente la política SPF, no simplemente que una IP no esté autorizada. Revisa duplicados, términos con consultas y sintaxis antes de modificar las autorizaciones.
Errores SPF habituales
Muchos fallos de SPF se deben a cinco errores. Algunos se corrigen en menos de 10 minutos, aunque la propagación DNS y la comprobación pueden tardar más.
| Error | Consecuencia |
|---|---|
Usar +all | Autoriza a cualquier IP a enviar usando el dominio del sobre. No lo uses. |
Usar el mecanismo ptr | La especificación desaconseja su uso; es lento y poco fiable. |
| Errata en el dominio incluido | include:google.com no sustituye al valor documentado include:_spf.google.com. |
| Espacio después de los dos puntos | ip4: 1.2.3.4 no es válido. Debe ser ip4:1.2.3.4, sin espacio. |
Usar ~all en producción sin revisarlo | Soft fail no garantiza entrega ni rechazo. Valora -all tras inventariar los remitentes. |
Las erratas son especialmente molestas porque una comprobación de sintaxis puede no detectar que el dominio referenciado carece de una política SPF válida. Consulta siempre la documentación del proveedor para obtener el valor exacto.
Gestionar SPF en varios dominios
Configurar SPF en un dominio puede ser una tarea de 10 minutos. Mantenerlo en 50 dominios de clientes exige seguimiento continuo. Cada nueva herramienta de marketing puede dejar incompleta la autenticación, y quizá no lo descubras hasta que el cliente pregunte por los rebotes.
Para agencias y proveedores de servicios gestionados, la estandarización ayuda. Si están disponibles en tu plan, el panel multidominio y el asistente SPF/DKIM/DMARC de TrekMail facilitan una configuración coherente. Los planes de pago anunciados desde $3.50/mes pueden incluir entrega SMTP gestionada; comprueba los precios y prestaciones vigentes. Con el plan Nano, si ofrece SMTP propio, utilizas tu proveedor y gestionas su reputación IP según sus condiciones, algo útil si ya tienes cuentas de SES o Mailgun preparadas para enviar.
Una plantilla común puede reducir el trabajo al migrar clientes a TrekMail, siempre que adaptes las autorizaciones a los remitentes reales de cada dominio. Para organizar el correo a escala, consulta la gestión del correo de clientes para agencias. Si empiezas desde cero, la guía para crear correo con tu dominio explica el proceso completo.
Registro SPF: lista de comprobación antes de publicar
Antes de publicar, revisa esta lista en orden:
- Comprueba los registros existentes:
dig +short txt yourdomain.com, una sola líneav=spf1. - Identifica todos los servicios que envían usando tu dominio del sobre: correo transaccional, marketing y herramientas de soporte.
- Escribe un único registro que los cubra. Combina, no dupliques.
- Usa
-alltras completar el inventario; revisa el uso de~ally evita+all. - Cuenta los términos que requieren DNS y deja margen por debajo de 10.
- Publica el TXT en el dominio del sobre, en
@si es la raíz. - Envía una prueba a Gmail y consulta Mostrar original para verificar
spf=pass.
Las directrices de Google para remitentes distinguen entre categorías de remitentes; los remitentes masivos deben configurar SPF, DKIM y DMARC. SPF es un primer paso. DKIM y DMARC completan la autenticación, pero ni siquiera un resultado positivo en los tres garantiza la bandeja de entrada.
Después de configurar SPF, revísalo cuando cambies de proveedor o este actualice sus requisitos. Un registro incorrecto puede provocar problemas de autenticación y rebotes. Prueba TrekMail gratis si el plan Nano sigue disponible sin tarjeta. Los planes anunciados desde $3.50/mes y la prueba gratuita de 14 días están sujetos a las condiciones vigentes.
