Generador gratuito de registros SPF

Un registro SPF (Sender Policy Framework) es una entrada DNS TXT que lista qué servidores y servicios están autorizados a enviar correo en nombre de tu dominio. Los proveedores de buzón verifican el registro en cada correo entrante; si el servidor de envío no está listado, la autenticación SPF falla. Sin SPF (o con un SPF roto), los correos suelen ser enrutados a spam o rechazados de plano. SPF también es exigido por los requisitos de remitentes masivos de Gmail y Yahoo a partir de 2024.

Como un registro DNS TXT en la raíz (apex) de tu dominio de envío; el host normalmente se ingresa como @ o simplemente el nombre del dominio (depende de la interfaz de tu proveedor de DNS). Por ejemplo, en example.com, el registro va en el host @ y el valor es la cadena TXT completa (incluyendo las comillas). Los subdominios usados para envío (por ejemplo, mail.example.com) necesitan sus propios registros SPF separados si envías desde ellos.

La RFC 7208 §4.6.4 limita el número de búsquedas DNS que los receptores deben realizar al evaluar tu registro SPF a 10. Cada include:, a, mx, exists y redirect cuenta como una búsqueda, e include también cuenta las búsquedas dentro del registro incluido (recursivamente). Cruza el límite y el receptor devuelve permerror, tratando tu dominio como si no tuviera SPF. Nuestra herramienta cuenta las búsquedas en tiempo real a medida que agregas remitentes.

El mecanismo all al final le dice a los receptores qué hacer con el correo de servidores que NO están en tu lista autorizada. ~all (softfail) acepta el correo pero lo marca como sospechoso; el predeterminado recomendado durante la transición. -all (fail) instruye a los receptores a rechazar el correo directamente; más estricto, mejor después de que confirmes que tu SPF está completo. ?all (neutral) trata el correo como si no hubiera política, raramente útil. Empieza con ~all, pasa a -all cuando tu SPF esté estable.

No. La RFC 7208 §3.2 prohíbe explícitamente varios registros v=spf1 en el mismo nombre DNS. Si un receptor encuentra dos, devuelve permerror y trata tu dominio como si no tuviera SPF en absoluto, el mismo resultado que no tener ninguno. Mezcla todos tus remitentes autorizados en un único registro v=spf1 en su lugar. Nuestra herramienta genera un único registro consolidado a partir de todos los remitentes seleccionados.

Algunos ESPs (HubSpot, ActiveCampaign, ConvertKit, Beehiiv, Substack) usan subdominios SPF de include por cliente, como 1234567.spf04.hubspotemail.net. Como la cadena exacta del host es diferente para cada cuenta, no podemos preconfigurarla en un preset universal. Agrega tu include específico del ESP manualmente en la sección "Agregar include personalizado" de la herramienta; cuenta para el presupuesto de 10 búsquedas de la misma forma que cualquier otro include.

Una sola cadena TXT está limitada a 255 caracteres, pero un registro TXT puede contener varias cadenas entre comillas que los receptores concatenan. La mayoría de los proveedores de DNS (Cloudflare, Route 53, Google Workspace, GoDaddy) dividen automáticamente las cadenas largas en pedazos; algunos requieren que las separes manualmente entre comillas. Si la interfaz de tu DNS rechaza una cadena larga, divídela en segmentos de ≤255 caracteres entre comillas, sin espacios ni caracteres extra. El contenido del registro debe seguir siendo un único registro v=spf1.

La propagación de DNS normalmente se completa en una hora para la mayoría de los receptores; algunos cachean hasta 24 horas dependiendo del TTL que configures en el registro. La herramienta vuelve a buscar el dominio vía DNS-over-HTTPS cada vez que verificas, así que puedes confirmar la propagación a medida que los receptores acceden al nuevo registro. Para cambios críticos, hazlos en una ventana de bajo tráfico y prueba con un correo real a un buzón que controles antes del próximo envío masivo.

SPF solo no es suficiente. SPF autentica el servidor de envío; DKIM autentica el contenido del mensaje con una firma criptográfica; DMARC le dice a los receptores qué hacer cuando cualquiera de los dos falla, y es lo que mueve el correo a spam o lo rechaza de forma fiable. Los tres trabajan juntos. Publica SPF, activa DKIM (en tu ESP) y luego publica DMARC con p=none para empezar, monitoreando los reportes antes de avanzar a quarantine o reject.

No. Cada búsqueda DNS se hace directamente desde tu navegador al endpoint público DNS-over-HTTPS de Google (dns.google/resolve). La herramienta no tiene backend; nada sobre tu dominio o configuración de remitente se envía a un servidor de InboxAlly. Los resultados son todos del lado del cliente: podrías correr la herramienta offline una vez que la página inicial carga, siempre que tu navegador pueda alcanzar dns.google.

Un SPF que pasa es una de tres señales (junto con la alineación de DKIM y DMARC) que los proveedores de buzón usan para decidir si tu correo es legítimo. Los dominios sin SPF, o con SPF roto (más de 10 búsquedas, varias políticas, sintaxis inválida), son tratados como sospechosos: mayor probabilidad de spam, tasas de entrega más bajas y desclasificación bajo el nuevo marco de remitentes masivos de Gmail/Yahoo. Publicar SPF válido (y mantenerlo bajo el límite de búsquedas) es una pequeña victoria que evita una gran cantidad de problemas de entregabilidad.