Definición
Un registro SPF (Sender Policy Framework) es un recurso DNS de tipo TXT publicado en la zona DNS pública de un dominio que enumera las IPs, prefijos IPv6 y hostnames de servidores de correo autorizados a enviar email en nombre de ese dominio. Cuando un servidor de correo receptor acepta un mensaje entrante, consulta el DNS del remitente buscando el registro SPF y compara la IP de la conexión contra la política. Si la IP no está listada, el receptor puede marcar el mensaje como softfail, rechazarlo de plano o marcarlo para evaluación adicional, según el calificador fijado por el dueño del dominio.
SPF se formalizó por primera vez como estándar IETF en la RFC 4408 (2006) y luego se actualizó a la especificación autoritativa actual en la RFC 7208, publicada por el Internet Engineering Task Force (IETF) en abril de 2014. Es uno de los tres estándares complementarios de autenticación de email junto con DKIM (DomainKeys Identified Mail) y DMARC (Domain-based Message Authentication, Reporting, and Conformance).
Cómo funciona
El proceso de evaluación SPF involucra varios pasos secuenciales realizados por el motor SMTP del receptor durante la fase MAIL FROM del handshake.
El dueño del dominio publica un registro SPF TXT en DNS. Un registro típico sigue esta sintaxis: v=spf1 include:_spf.google.com ip4:203.0.113.5 ~all. Los componentes son: v=spf1 (identificador de versión), uno o más mecanismos (include, ip4, ip6, a, mx, exists) y un calificador final (+all, -all, ~all, ?all). El calificador -all significa hard fail: cualquier servidor no listado explícitamente no está autorizado. El ~all (softfail) deja pasar el mensaje pero anota la discrepancia, comúnmente usado en períodos de migración.
Cuando llega un mensaje, el MTA receptor extrae el dominio del envelope sender (la dirección MAIL FROM, también llamada RFC5321.MailFrom) y hace un lookup TXT por _spf.<dominio> o directo sobre la raíz. La librería SPF evalúa cada mecanismo en orden hasta que uno coincida o se alcance el límite de diez DNS lookups (el “SPF PermError” definido en la RFC 7208 sección 4.6.4). El resultado —Pass, Fail, SoftFail, Neutral, TempError o PermError— se inserta en el header Received-SPF del mensaje y se pasa al filtro de spam y al motor de política DMARC.
Es crítico notar que SPF autentica el envelope sender (MAIL FROM), no el header From visible en el cuerpo del mensaje. Esa distinción significa que SPF por sí solo no evita el spoofing del display name en clientes de correo, por lo cual el alineamiento DMARC —que exige que los resultados de SPF y/o DKIM coincidan con el dominio RFC5322.From— es necesario para protección completa.
Dónde aparece
Los registros SPF aparecen en cualquier contexto donde la entregabilidad de email y la reputación de remitente importen. La infraestructura transaccional de email operada por servicios como Amazon SES, SendGrid, Mailgun, Postmark y SparkPost exige que los dueños de dominio agreguen mecanismos include apuntando a la infraestructura del proveedor antes de que los mensajes pasen los chequeos de autenticación.
Las plataformas de concurso que envían correos de confirmación de voto —incluyendo Woobox, ShortStack y sistemas a medida usando Mailchimp Transactional (Mandrill)— dependen de que el dominio remitente tenga un SPF válido. Los proveedores de bandeja como Google (Gmail), Microsoft (Outlook / Exchange Online Protection) y Yahoo Mail evalúan SPF como input de sus algoritmos de entregabilidad. Un SPF faltante o mal configurado eleva sustancialmente la probabilidad de que los correos de confirmación se entreguen silenciosamente a spam o sean rechazados por completo, dejando votos sin confirmar.
Los paneles DNS de proveedores como Cloudflare, AWS Route 53, GoDaddy y Namecheap exponen edición de registros TXT SPF a través de sus interfaces. Herramientas de diagnóstico como MXToolbox SPF Lookup, Google Admin Toolbox y SPF Surveyor de DMARCIAN permiten inspeccionar y validar los registros publicados.
Ejemplos prácticos
Una plataforma de concurso envía correos de confirmación de voto desde [email protected]. El dominio votes.example.com tiene el SPF v=spf1 include:sendgrid.net -all. Cuando Gmail recibe un correo de confirmación, su servidor SMTP entrante consulta el DNS por el SPF de votes.example.com, expande el mecanismo include:sendgrid.net y verifica la IP conectante contra la lista autorizada de SendGrid. Si coincide, el resultado es Pass y el mensaje sigue al inbox. Si el dominio no tuviera SPF, el filtro de Gmail trataría el mensaje como no autenticado, reduciendo la probabilidad de inbox placement.
El concurso de un diario regional cambia su proveedor transaccional de Mailchimp a Amazon SES sin actualizar su SPF. Los correos de confirmación empiezan a fallar SPF en Microsoft Outlook y caen en bandeja masiva, dejando a los votantes fuera de la ventana de confirmación. El admin diagnostica con MXToolbox, agrega include:amazonses.com al registro y la entregabilidad se recupera dentro de la ventana de propagación DNS (típicamente 0 a 48 horas según los TTL).
Conceptos relacionados
SPF es uno de los pilares del stack de tres estándares de autenticación: ver DKIM para verificación de firma criptográfica y DMARC para la capa de política que actúa sobre los resultados de SPF y DKIM. El impacto operativo en concursos se describe en Voto con confirmación por correo, donde la entregabilidad del mensaje de confirmación es la dependencia operativa más crítica. BIMI (Brand Indicators for Message Identification), un estándar más reciente que construye sobre DMARC, permite a remitentes verificados mostrar el logo de la marca en proveedores compatibles, una señal de confianza emergente no cubierta aquí.
