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
- 8 minutos de lectura
Waseem OsmanDMARC EnthusiastRegistro SPF a: podría autorizar más de lo que crees
Resumen del registro SPF a:
- El mecanismo
apuede autorizar infraestructura que no controlas, no solo la tuya. - El softfail más un registro SPF
aobsoleto oculta el riesgo de spoofing a menos que lo monitorices de forma activa. - Que SPF pase en la fuente equivocada no evita que DMARC también pase en ella.
Tu registro SPF puede autorizar el registro a de un tercero no verificado, y tu administrador de correo puede no enterarse hasta que un intento de spoofing llegue a tus clientes, partners o proveedores.
Eso no es un caso límite hipotético. Es un riesgo estructural en la evaluación SPF de remitentes autorizados, y afecta en particular a empresas con entornos híbridos, infraestructura multiinquilino y dominios cuya propiedad DNS ha cambiado con el tiempo.
Este artículo es una guía operativa para CISOs, administradores de correo y responsables de riesgo que necesitan auditar el riesgo del registro SPF a de forma sistemática, antes de que ocurra un fallo de entregabilidad o un incidente de spoofing.
Comprueba tu registro SPF para ver qué autoriza tu configuración actual.
Por qué son importantes los registros SPF a
SPF funciona publicando un registro TXT en el DNS que lista las fuentes de envío autorizadas. La mayoría de los equipos se centran en los mecanismos include e ip4.
Pocos prestan atención al mecanismo a, que indica a los servidores receptores que comprueben un registro SPF a y autoricen cualquier dirección IP que devuelva.
El mecanismo a es legítimo y útil. Permite a las organizaciones mapear un hostname a una dirección ip4. El problema no es el mecanismo en sí; es lo que ocurre cuando el registro SPF a al que referencia ya no apunta a infraestructura que controlas.
Supongamos que el registro SPF de un dominio incluye a:mail.partner-domain.example.com. Cuando se escribió ese registro, tu empresa controlaba ese subdominio. Desde entonces, se ha transferido a un tercero.
El registro sigue autorizando la dirección IP a la que resuelve el registro SPF a. Si el registro SPF a ahora apunta a una IP de una parte externa, has autorizado infraestructura no verificada para enviar como tu dominio.
La brecha de softfail del registro SPF a
Muchos registros SPF empresariales siguen usando ~all (softfail) en lugar de -all (hard fail). Softfail indica a los servidores receptores que los mensajes de fuentes no autorizadas deben marcarse, pero no necesariamente rechazarse. Combinado con un registro SPF a obsoleto o mal configurado, esto crea un escenario en el que:
- Un correo de una IP no verificada pasa SPF porque el registro
alo autoriza. - Un correo de un remitente legítimo falla SPF porque el registro
ase ha desviado.
Ningún resultado es visible sin monitorización activa. El primero representa un riesgo directo de spoofing y BEC que socava los esfuerzos de prevención del spoofing de correo.
El segundo crea un problema de entregabilidad que se manifiesta como fallos intermitentes de colocación en la bandeja de entrada. Es exactamente el tipo de fallo difícil de rastrear hasta una mala configuración DNS.
El enforcement de DMARC lo agrava. Si SPF pasa en la fuente equivocada, DMARC puede seguir pasando la alineación, lo que significa que tu política de enforcement no detecta el problema.
Pasos de auditoría del registro SPF a: identificar registros desalineados
Los siguientes pasos forman una auditoría estructurada del registro SPF a. Aplícalos a cada dominio que envía correo.
Paso 1: Extrae todos los mecanismos a de tus registros SPF
Para cada dominio, recupera el registro TXT SPF completo.
Documenta cada mecanismo a, incluidos los anidados dentro de referencias include. Las cadenas include anidadas son donde suelen esconderse los mecanismos a obsoletos.
Si tu registro SPF incluye remitentes de terceros, como plataformas de marketing, sistemas de RR. HH. o herramientas transaccionales, los registros SPF de esos proveedores pueden contener a su vez mecanismos a que resuelven a infraestructura sobre la que no tienes visibilidad.
Paso 2: Resuelve cada registro SPF a referenciado y verifica la propiedad
Para cada mecanismo a, resuelve el registro a actual.
Luego verifica:
- Si la IP devuelta pertenece a infraestructura que controla tu organización.
- Si la IP está asignada a un proveedor cloud que puede compartirse con otros inquilinos.
- Si la IP se ha reutilizado, transferido o ha quedado apuntando a un recurso temporal.
En entornos multiinquilino, este paso a menudo saca a la luz direcciones IP de antiguos proveedores. Son los escenarios en los que un solo registro SPF a mal configurado puede crear riesgo de autorización en varios dominios.
Paso 3: Cuenta tus consultas DNS
SPF impone un límite de 10 consultas DNS durante la evaluación. Cada mecanismo include, a, mx y exists que requiere una consulta DNS cuenta para ese límite.
Si tu registro supera las 10 consultas, los servidores receptores devuelven un PermError y SPF falla. Eso significa que tus mensajes pueden rechazarse de plano.
Cuenta las consultas en toda tu cadena SPF, incluidas las referencias include anidadas. Cada mecanismo a que apunta a una IP externa aumenta el recuento de consultas sin necesariamente mejorar la seguridad.
Validación segura antes del enforcement
Pasar a SPF -all (hard fail) o DMARC p=reject sin validar primero tu registro SPF a corre el riesgo de interrumpir flujos de correo críticos.
La secuencia de validación que reduce el riesgo del registro SPF a:
- Mapea todas las fuentes de envío antes de actualizar cualquier registro DNS. Usa los informes agregados DMARC para identificar cada IP que actualmente envía como tu dominio. Compara esas IPs con lo que tu registro SPF realmente autoriza. Las discrepancias indican remitentes no autorizados o un mecanismo
amal configurado. - Prueba los cambios del registro a en staging cuando sea posible. Si actualizas un registro SPF
acomo parte de una migración o baja, comprueba qué registros SPF lo referencian antes de hacer el cambio. Los procesos de gestión DNS empresariales deberían reconocer que los cambios en registrosapueden afectar a la seguridad y la entregabilidad del correo. - Pasa a
-allsolo después de que tus fuentes de envío estén mapeadas y autorizadas. Softfail no debería ser una configuración permanente. Una vez confirmado que cada remitente autorizado pasa SPF de forma consistente, el riesgo de pasar a hard fail es bajo. - Reaudita tras cualquier cambio de infraestructura. Las modificaciones del registro SPF
a, las altas de remitentes de terceros, las migraciones a la nube y la actividad de M&A crean condiciones en las que registros SPF previamente auditados se desalinean. Incorpora la verificación del registroaa tu proceso de gestión del cambio.
Cómo ayuda Sendmarc
Auditar el riesgo del registro SPF a de forma manual es viable para un solo dominio. No escala a docenas de dominios, varios departamentos y un ecosistema de proveedores que cambia cada trimestre.
Sendmarc ofrece visibilidad continua de quién envía realmente como tus dominios, incluidas las fuentes que tu registro SPF puede estar autorizando a través de registros a obsoletos o mal configurados.
Para equipos que se preparan para pasar de p=none a p=reject, la Plataforma DMARC de Sendmarc apoya un camino de enforcement estructurado: identificar remitentes no autorizados, validar los autorizados y pasar a enforcement sin conjeturas.
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.
