v=spf1Versión
Indica que es un registro SPF versión 1. Obligatorio al inicio.
Sender Policy Framework
Sender Policy Framework es el registro DNS que le dice a los servidores receptores qué IPs y servidores tienen permiso para enviar mail con tu dominio en el remitente. Sin SPF bien configurado, tus campañas terminan en spam o son rechazadas.
SPF (Sender Policy Framework) es un estándar abierto definido en RFC 7208. Funciona como una lista blanca: vos publicás en el DNS de tu dominio qué servidores están autorizados a enviar mail en tu nombre.
Cuando Gmail, Outlook o cualquier servidor receptor recibe un mail con remitente "@tudominio.com", consulta el registro SPF del dominio. Si la IP del servidor que envía está en la lista, el mail pasa la verificación SPF. Si no, lo trata como sospechoso.
Sin SPF, cualquiera puede falsificar tu remitente (spoofing). Con SPF mal configurado, tus mails legítimos caen en spam.
Ejemplo real
v=spf1 include:_spf.arrobamail.com ~all
v=spf1Versión
Indica que es un registro SPF versión 1. Obligatorio al inicio.
include:_spf.arrobamail.comMecanismo include
Importa los servidores autorizados de arrobaMail. Podés tener varios includes (uno por proveedor que envía en tu nombre).
~allPolítica
~all = softfail (marcar como sospechoso). -all = hardfail (rechazar). ?all = neutral. Empezá con ~all y subí a -all cuando estés seguro.
Pasos en orden. Saltar uno suele derivar en problemas que tardan días en diagnosticar.
Listá cada herramienta que envía email con tu dominio: plataforma de marketing (arrobaMail), Google Workspace, Microsoft 365, CRM, sistema de tickets, transaccionales, etc.
Tip: Si te olvidás de una, sus mails fallarán SPF.
Cada plataforma publica su include. El de arrobaMail es include:_spf.arrobamail.com. Google es include:_spf.google.com. Outlook es include:spf.protection.outlook.com.
Tu dominio debe tener un solo registro SPF (no múltiples). Combinás todos los includes en una sola línea: v=spf1 include:_spf.arrobamail.com include:_spf.google.com ~all.
Tip: Tener dos registros SPF es un error muy común que invalida la autenticación.
En tu proveedor de DNS (Cloudflare, GoDaddy, Route53, etc.) creá un registro TXT con Name = @ (o tu dominio raíz) y Value = el string SPF que armaste.
La propagación puede tardar de minutos a 24 hs. Usá las herramientas de verificación del paso siguiente para confirmar que está activo y sin errores.
Si publicás dos TXT con v=spf1, los receptores los descartan ambos como inválidos.
Cómo arreglarlo: Unificá en un solo registro con todos los includes necesarios.
SPF tiene un límite duro de 10 lookups (cada include cuenta como uno o más). Pasarse causa permerror.
Cómo arreglarlo: Auditá tus includes y remové proveedores que ya no usás. Si seguís sobre 10, usá flattening manual o herramientas de SPF flattener.
Un registro sin ~all o -all queda implícito como ?all (neutral) y deja la puerta abierta a spoofing.
Cómo arreglarlo: Siempre cerrá con ~all (modo seguro inicial) y subí a -all cuando confirmes que todos tus envíos pasan.
Si saltás directo a -all con includes incompletos, tus mails legítimos serán rechazados sin chance de revisión.
Cómo arreglarlo: Empezá con ~all, monitoreá los reportes de DMARC unas semanas, recién después subí a -all.
Tres maneras de verificar — desde tu terminal o desde herramientas online. Si todas devuelven OK, ya está.
Linux/Mac terminal
dig TXT tudominio.com +short
Devuelve el string SPF si está publicado.
Windows PowerShell
Resolve-DnsName -Type TXT tudominio.com
Lista los registros TXT incluyendo el SPF.
Online
mxtoolbox.com/spf.aspx
Análisis completo con detección de errores y advertencias.
Cómo lo hace arrobaMail
En arrobaMail asistimos la configuración de SPF paso a paso desde el panel: te damos el include exacto, validamos la sintaxis del registro que querés publicar y monitoreamos la verificación una vez activo.
No. Solo se permite un registro SPF (un solo TXT con v=spf1) por dominio. Tener dos invalida la autenticación. Lo que sí podés tener es múltiples includes dentro de ese único registro.
No automáticamente. Cada subdominio puede tener su propio SPF. Si no lo tenés, hereda comportamientos según el receptor — algunos consideran el SPF del root, otros lo tratan como sin política. Lo más seguro es publicar SPF también en subdominios desde los que enviás.
Depende del TTL de tu DNS. En la mayoría de los proveedores está entre 5 minutos y 4 horas. En casos extremos hasta 24-48 hs. Cloudflare suele propagar en menos de 5 min.
Si tenés ~all, los receptores la marcan como sospechosa (puede caer en spam). Si tenés -all, la rechazan directamente. Por eso es clave que listes todos los servicios legítimos antes de subir a -all.
No. Son complementarios. SPF autentica el servidor de envío. DKIM autentica el contenido del mensaje con firma criptográfica. DMARC combina ambos y aplica una política. Lo ideal es tener los tres.
DomainKeys Identified Mail
Firma criptográfica que prueba autenticidad e integridad del mensaje.
Leer guíaDomain-based Message Authentication
Política y reportes sobre lo que pasa cuando SPF o DKIM fallan.
Leer guíaCalentamiento de dominio e IP
Aumento gradual del volumen para construir reputación buena.
Leer guíaPlan Gratuito, generaciones de IA incluidas, sin tarjeta de crédito y soporte real en español.