SPF declara qué infraestructura puede enviar usando un dominio de envelope sender. Publicar otro registro SPF TXT para un segundo proveedor invalida el resultado en vez de sumar permisos.
Inventaría todas las fuentes legítimas y modifica una sola política.
Identifica el dominio que evalúa SPF
Inspecciona Return-Path en un mensaje o log. SPF evalúa ese dominio, que puede ser distinto del From visible.
Anota si WordPress usa el dominio web, un subdominio o un dominio de rebotes del proveedor. No edites SPF del dominio visible si el envelope sender está en otro lugar.
La alineación DMARC se comprueba por separado.
Localiza el registro autoritativo
Consulta DNS mediante varios resolvers y confirma nameservers activos. El panel del hosting no tiene efecto cuando Cloudflare u otro servicio es autoritativo.
Recopila todos los TXT que comienzan por v=spf1. Debe existir una única política para ese hostname. Guarda el valor y TTL actuales.
Comprueba comillas accidentales, espacios y fragmentos creados por el panel. Varias cadenas dentro de una respuesta TXT pueden ser válidas; varios registros SPF independientes no.
Inventaría los servicios legítimos
Enumera correo corporativo, WordPress, helpdesk, CRM, newsletters, facturas y relay del hosting que utilicen el mismo dominio. Confirma propiedad actual y documentación de cada proveedor.
No conserves includes obsoletos “por si acaso”: amplían confianza y consumen consultas DNS.
Separa marketing y transaccional en subdominios con finalidad propia cuando operativamente sea adecuado.
Fusiona mecanismos en una política
Añade el include, IP o mecanismo documentado antes del calificador all. Conserva la sintaxis y evita comillas inteligentes o saltos de un editor.
Una estructura simplificada:
v=spf1 include:provider-one.example include:provider-two.example -allSon placeholders; publica únicamente los valores reales de tus proveedores.
Controla el límite de consultas DNS
SPF limita los mecanismos que generan consultas. Includes anidados, redirect, a y mx pueden agotar el máximo aunque el texto sea corto.
Analiza la expansión completa. Elimina servicios sin uso antes de considerar flattening compatible, porque una lista fija de IP puede quedar obsoleta.
No añadas a o mx amplios si esos hosts no envían.
El límite se aplica durante la evaluación, incluyendo includes y redirects recursivos, no al número visible de palabras. Revisa cada rama hasta llegar a mecanismos de IP y detecta bucles o includes que devuelvan errores temporales. Un resultado permerror no se arregla cambiando -all por ~all.
Elige el calificador final
-all, ~all y ?all expresan políticas diferentes. No debilites el final para ocultar un error; incorpora correctamente el remitente y conserva la intención.
Coordina con el administrador si el dominio también soporta correo de empleados. Una reparación de WordPress no debe romper el correo corporativo.
Espera el TTL anterior y consulta al menos dos resolvers públicos antes de verificar.
Publica el cambio en una ventana con acceso al rollback. Si el panel divide automáticamente un TXT largo, verifica que DNS lo devuelva como una sola política lógica; si crea dos respuestas independientes, SPF seguirá inválido aunque el texto completo parezca correcto en la interfaz.
Verifica las dos fuentes y DMARC
Envía un mensaje identificado por cada proveedor después de propagar. Revisa SPF y el dominio autenticado. Después comprueba DKIM y alineación DMARC con From.
SPF pass puede no satisfacer DMARC si Return-Path no está alineado. Configura un dominio de rebotes propio o DKIM alineado cuando esté disponible.
Prueba también una fuente que no esté autorizada para confirmar que la política conserva el comportamiento esperado. Hazlo con una herramienta controlada, nunca falsificando envíos a terceros ni generando spam.
Prueba el formulario real, no solo el dashboard.
Mantén el registro
Documenta propietario y condición de eliminación de cada mecanismo. Revisa la política al retirar un proveedor, hosting o plataforma.
Monitoriza informes de autenticación y rebotes sin recopilar datos innecesarios. Conserva historial DNS y reversión.
Pide ayuda si se supera el límite, se desconoce la propiedad o varios sistemas comparten dominio. Comparte el registro público y cabeceras redactadas, nunca credenciales DNS o claves privadas.
Un ejemplo reproducible del segundo remitente sin cambiar DNS
El 24 de octubre de 2026 ejecutamos un ejercicio propio de selección de registros sin conexión. Utiliza respuestas TXT ficticias e IP reservadas para documentación. Comprueba selección y unión de cadenas, no propagación DNS, entrega de correo ni la evaluación SPF completa.
Caso A: dos registros TXT separados
"v=spf1 ip4:198.51.100.24 -all"
"v=spf1 ip4:203.0.113.44 -all"
Selección observada: permerror
Caso B: un registro TXT
"v=spf1 ip4:198.51.100.24 ip4:203.0.113.44 -all"
Selección observada: selected
Caso C: un registro TXT con dos cadenas
"v=spf1 ip4:198.51.100.24 " "ip4:203.0.113.44 -all"
Selección observada: selectedLa diferencia está en cuántos registros hay, no en cuántas cadenas entre comillas muestra el panel. En C se unen las cadenas del mismo registro; el espacio al final de la primera es intencionado. selected solo indica que el ejercicio encontró una política SPF. No equivale a SPF pass ni confirma autorización de un remitente real.
Para reproducir la distinción, inventaría cada respuesta TXT por separado y concatena únicamente sus propias cadenas. Contrasta el resultado con RFC 7208, apartados 3.2–3.3 y 4.5 —en inglés—. No publiques estas direcciones de ejemplo. La reparación real aún necesita dominio del remitente de sobre, instrucciones del proveedor, evaluación de consultas expandidas y un mensaje identificado de cada emisor.
Conserva una ficha antes y después por emisor: dominio de sobre, proveedor, resultado de autenticación, hora y destino controlado. Si el dominio también sirve al correo corporativo, solicita una valoración de SPF y entrega del formulario antes de modificar una política con otros emisores desconocidos.