Herramienta gratuitaSin registro
Consulta DNS
Use la herramienta de consulta DNS de Sendmarc para analizar al instante los registros de un dominio, verificar su configuración y detectar problemas de DNS.
Artículo de blog
- 7 minutos de lectura
Waseem OsmanEspecialista en DMARCEstructura del registro SPF: las decisiones de arquitectura que importan
Resumen de la estructura del registro SPF:
- La estructura del registro SPF determina el recuento de consultas DNS, la alineación DMARC y la auditabilidad
- El RFC 7208 limita la evaluación SPF a 10 consultas, contando cada mecanismo include, a, mx y exists
- El aplanamiento IP elimina la profundidad de consulta, pero se rompe cuando cambian los rangos IP del proveedor
- ~all frente a -all importa más antes de que DMARC llegue a enforcement
Un solo calificador SPF mal colocado puede romper tu registro.
La sintaxis SPF parece asequible. Un registro TXT, un puñado de mecanismos y un calificador SPF. Pero las decisiones estructurales al crear un registro SPF tienen consecuencias que van mucho más allá de la configuración inicial. Tu recuento de consultas DNS, la alineación DMARC y la auditabilidad de tu registro SPF dependen de su estructura.
Esta guía está pensada para administradores de correo, CISO y operadores de MSP. Se centra en el razonamiento de diseño y operativo detrás de las elecciones de estructura del registro SPF – las decisiones que determinan si esa estructura se sostiene a escala.
La Plataforma de gestión de DMARC de Sendmarc te da visibilidad sobre la estructura de tu registro SPF y tus fuentes de envío, para que las decisiones de configuración se tomen con contexto completo en lugar de a ciegas.
Por qué la estructura del registro SPF es una decisión de arquitectura
La mayoría de las guías SPF se quedan en la sintaxis y omiten las decisiones estructurales que determinan si un registro se sostiene a escala. Acertar con los mecanismos, publicar el registro y seguir adelante. Ese enfoque funciona para un solo dominio con dos o tres fuentes de envío. Falla en cualquier otro escenario.
Los entornos empresariales suelen ejecutar varios sistemas de envío: un servidor principal, un CRM, una plataforma de marketing, un servicio transaccional y un sistema financiero. Añade infraestructura regional y las decisiones sobre la estructura del registro SPF se convierten en un problema.
La estructura del registro SPF determina:
- Cuántas consultas DNS dispara en la evaluación y cuán cerca queda el registro del límite de consultas DNS
- Si los rangos IP aplanados introducen deriva cuando cambia la infraestructura del proveedor
- Si las cadenas include son auditables
Estas son decisiones de arquitectura SPF. Tratarlas como sintaxis es donde empieza el riesgo operativo.
El límite de consultas DNS: la restricción que moldea la estructura del registro SPF
El RFC 7208 limita la evaluación SPF a 10 consultas DNS. Ese límite incluye cada mecanismo include, a, mx y exists de la cadena.
Para una configuración ligera de una sola plataforma, el límite de consultas DNS es generoso. Para una empresa con cinco o seis remitentes SaaS, cada uno con su propia cadena include, es fácil superarlo.
Supongamos que configuras un registro SPF para una organización de tamaño medio:
| Host | Type | Value |
|---|---|---|
| @ | TXT | v=spf1 include:_spf.google.com include:sendgrid.net include:spf.protection.outlook.com include:servers.mcsv.net include:_spf.salesforce.com include:spf.mandrillapp.com ~all |
Parece razonable. Seis referencias include, todas de remitentes legítimos. Pero cada include apunta a un registro que a su vez contiene una o más consultas. Para cuando un servidor receptor resuelve esta cadena, es probable que hayas superado el límite de consultas DNS, lo que significa que SPF devuelve un PermError.
La solución no es quitar remitentes. La solución es reestructurar la estructura del registro SPF para controlar la profundidad de consulta.
Opción 1: aplanamiento IP
Sustituye las referencias include por los rangos IP resueltos:
| Host | Type | Value |
|---|---|---|
| @ | TXT | v=spf1 ip4:74.125.0.0/16 ip4:209.85.128.0/17 ip4:149.72.0.0/16 ip4:167.89.0.0/16 ~all |
Los mecanismos ip4 e ip6 no cuentan para el límite de consultas DNS, así que el aplanamiento SPF elimina por completo la profundidad de consulta.
Esta elección de estructura del registro SPF conlleva una compensación: cuando un proveedor rota o amplía su rango IP, algo que hacen Google, Salesforce y los principales ESP, tu registro aplanado deja de ser preciso. La autenticación SPF puede fallar para correos legítimos hasta que actualices el registro manualmente.
Opción 2: macros SPF
Los MSP y las empresas que gestionan varios dominios desde una infraestructura compartida pueden usar macros para construir registros SPF de forma dinámica. La macro %{d} se resuelve al dominio de envío.
La decisión del calificador SPF -all frente a ~all
El calificador SPF al final de un registro SPF determina qué ocurre cuando una fuente no está listada. -all devuelve un fail; ~all devuelve un softfail. Ningún calificador SPF es universalmente correcto.
Para las empresas con una política DMARC de p=reject o p=quarantine, el efecto del calificador SPF ~all frente a -all es mínimo. La política DMARC tiene prioridad.
En entornos que aún están construyendo su inventario de remitentes, ~all es el calificador SPF de partida adecuado. Evita bloquear mensajes de remitentes aún no identificados, mientras los informes DMARC sacan a la luz esas fuentes para su remediación. Una vez completo el inventario de remitentes y DMARC en enforcement, endurecer a -all es la opción operativamente sólida.
Errores habituales en la estructura del registro SPF
- Mecanismos duplicados: Listar la misma referencia include más de una vez malgasta el presupuesto de consultas y señala una mala higiene del registro en las auditorías.
- Calificador all ausente: Un registro sin un calificador all final por defecto es neutral, lo que equivale funcionalmente a no tener política SPF.
- Sin proceso de gestión del cambio: Las actualizaciones del registro SPF son cambios de DNS. En entornos con ventanas de cambio estrictas, una actualización SPF no documentada (a menudo hecha por un equipo de marketing o de onboarding) puede romper la autenticación de otros remitentes.
Cómo ayuda Sendmarc
Gestionar la estructura del registro SPF en múltiples dominios y proveedores de envío es una tarea operativa continua. Los entornos distribuidos dificultan ver cada fuente de envío en un solo lugar, y los equipos de seguridad y TI, ya al límite, no tienen capacidad para rastrear cadenas de consultas.
Sendmarc ofrece visibilidad continua de tu registro SPF, sacando a la luz remitentes desconocidos o no autorizados que aparecen en los datos agregados de DMARC antes de que se conviertan en un problema de cumplimiento o de entregabilidad.
La gestión DMARC de Sendmarc amplía esta visibilidad más allá de SPF hacia la autenticación DKIM y DMARC, con monitorización continua e informes centralizados en todos los dominios que gestionas.
Recibe las últimas actualizaciones de seguridad de correo electrónico en tu bandeja de entrada cada mes
¿Tu dominio está protegido?
Obtén la puntuación de seguridad de tu dominio en segundos.
Consulta tus calificaciones de suplantación, privacidad y marca.
Si corres riesgo de suplantación de identidad, uno de nuestros expertos se pondrá en contacto para ayudarte.
