Asistencia técnicaSPF

Retos de gestión de SPF

By september 24, 2020april 5th, 2021No Comments

El mundo del correo electrónico era un lugar muy diferente en 1997 cuando la idea SPF comenzó a tomar forma. Pasó casi desapercibido cuando se mencionó públicamente por primera vez alrededor del año 2000, pero 20 años más tarde es una de las formas más extendidas de autenticación de correo electrónico en uso, junto con DKIM y DMARC.

Asegurar la exactitud de su registro en 2006 era un reto muy distinto al que se afronta hoy en día.

La exactitud de su registro SPF depende del grado de comprensión que usted tenga de su entorno de correo electrónico y de la visibilidad de este mismo. Para muchas organizaciones, este ecosistema consiste en una infraestructura gestionada directamente que es propiedad de o se encuentra en un entramado de servicios alojados que envían correos electrónicos en nombre de sus dominios. En los últimos años este entramado no ha hecho más que crecer, empujando rápidamente, y a veces rompiendo, los límites de SPF impuestos por su propia implementación, así como por el DNS. Jugar con estos límites son realidades que deben estar dirigidas a e integradas en los procesos de gestión de dominios de cualquier organización. En este artículo, nuestro Equipo de Despliegue habla principalmente de los desafíos comunes en cuanto al despliegue de SPF en el mundo moderno de la autenticación de correo electrónico.

Imaginemos por un momento que usted es dueño de un dominio solamente, junto con un entorno en línea híbrido, local/de intercambio, y alrededor de una docena de servicios alojados que envían correos electrónicos en nombre de ese dominio. La primera idea podría ser simplemente añadir todas las entradas relevantes al registro SPF de su dominio y darlo por terminado. Después de todo, están usando su dominio para enviar correo electrónico, así que el proceso debería ser sencillo. La realidad es que este proceso debería incluir la evaluación de cómo estos servicios están enviando correos electrónicos en su nombre, identificando qué desafíos relacionados con SPF está experimentando, y entendiendo las soluciones a cada uno de estos para establecer un plan de despliegue.

Es muy posible que se encuentre con uno de los siguientes problemas: o está sobrepasando el límite de 10 búsquedas de DNS,

o su registro es demasiado grande para caber en un solo registro TXT, siendo el primero lejos el más común. ¿Qué hacer al respecto? Bueno, hay algunas soluciones y ninguna es perfecta. Sin embargo, es necesario encontrar una solución, pero sigue siendo primordial comprender el problema mediante el conocimiento de la gestión de su entorno de correo electrónico. Esto le permitirá una mayor flexibilidad a la hora de tomar decisiones operativas para las prácticas de gestión de dominios de su organización.

Las soluciones más comunes para el tema del límite de de 10 búsquedas de DNS son las siguientes:

  • Aplanamiento del registro SPF
  • Evitar mecanismos de DNS innecesarios
  • Subdominios de flujos de correo electrónico determinados
  • Soluciones SPF dinámicas

Aplanamiento del registro SPF

El aplanamiento de un registro SPF probablemente sea uno de los enfoques más antiguos para mitigar el problema de 10 búsquedas DNS y puede ser efectivo de muchas maneras. ¿Quiere saber cómo? Utilice nuestra popular herramienta de inspección de SPF e ingrese su dominio para ver cómo funcionaría para usted.

El aplanamiento de SPF puede permitir el uso de un dominio específico mucho más de lo que normalmente es posible. Su implementación es relativamente simple y se basa mucho menos en el DNS que otras soluciones, ya que los principales mecanismos empleados aquí serían IPv4IPv6. El costo en su utilización radica principalmente en el gasto de tiempo, ya que requiere una revisión periódica de cada entrada, además de una supervisión constante y un registro sólido del lugar donde se originó el aplanamiento.

Evitar mecanismos de DNS innecesarios

Aunque esto puede parecer un consejo obvio, hay mucha mala orientación en Internet en cuanto a cuándo o si una organización debe añadir un proveedor o servicio específico a su registro de SPF. No olvidemos que un verificador realiza una comprobación del registro SPF con el dominio extraído de la dirección de correo electrónico (Mail From) del RFC 5321, o la identidad HELO/EHLO emitida por el cliente durante una conversación SMTP en caso de que el Mail From no sea válido. Esta dirección de correo electrónico (también conocida como ruta de retorno, sobre DE o dirección de rebote) no es la misma que el encabezado de la dirección de correo electrónico (De:) del RFC 5322, a la que a menudo también se le llama «Friendly From». Esta es la dirección de correo electrónico «de» que se muestra comúnmente en un cliente de correo electrónico. Estas dos direcciones a veces no coinciden, y tampoco es necesario.

Cuando se incorpora un nuevo servicio o proveedor, es importante entender cómo enviarán los correos electrónicos en nombre de sus dominios. Más precisamente, ¿qué dominio usarán como ruta de retorno? Si no utilizarán ninguno de sus dominios, entonces, desde una perspectiva de autenticación, no hay razón para añadirlos a su registro SPF. Puede ser difícil entender o ver cómo los servicios existentes están enviando correos electrónicos, y aquí es donde DMARC puede ayudar, ya que los informes de retorno contienen metadatos sobre qué identidad de dominio fue verificada como parte de la comprobación de SPF del receptor. ¡Mantenga sus registros limpios!

Subdominios de flujos de correo electrónico determinados

Aquí estamos hablando de crear un subdominio que será utilizado por uno que otro proveedor de servicios; por ejemplo, sales.example.org para todos los remitentes terceros relacionados con las ventas. Esto a veces es inevitable al desplegar DMARC, cuando por ejemplo se encuentra con un proveedor que no es compatible con DMARC, y ahí se le puede aislar en su propio subdominio donde tiene su propia política de DMARC.

Cuando un verificador realiza un control del registro SPF, sólo mira el dominio tal y como se extrae del Mail From de RFC 5321.

Esto significa que si un correo electrónico se envía usando info@sales.example.org como la dirección Mail From, el receptor buscará el registro SPF únicamente en el DNS de sales.example.org, y nunca en el dominio principal. Esto le da a usted un nuevo dominio para crear un registro SPF, una pizarra limpia. Aislar flujos de correo electrónico de esta manera también puede ayudar a mitigar el impacto de posible abuso solo para las cuentas de correo electrónico que existen en el subdominio. A su vez, también puede ayudar a limitar el impacto de abuso en la reputación de un dominio solo al subdominio, en lugar de afectar a todos los servicios si utilizara su identidad principal de dominio corporativo.

Dependiendo del alcance del subdominio, puede haber costos adicionales asociados con el despliegue, como la identificación de la necesidad de licencias adicionales, recursos web, etc. Establecer el alcance de sus necesidades le ayudará a determinar qué recursos necesita para el despliegue y cuáles serán los costos asociados. Además, esto se suma a la carga administrativa actual del equipo de gestión del dominio.

Soluciones SPF dinámicas

La idea de un registro SPF dinámico puede significar varias cosas, como aplanar dinámicamente un registro y luego publicar el resultado basado en una fuente de datos. También podría significar una gestión más compleja mediante el uso de macros. Estas soluciones pueden tener una implementación variada, pero normalmente todas presentan los mismos beneficios. En primer lugar, permiten un tipo de automatización y proporcionan mayor flexibilidad y escalabilidad. El objetivo es ahorrar tiempo de administración sin tener que preocuparse de cuántos remitentes están enviando en nombre de su dominio.

Pueden ser muy buenas soluciones, pero no son una panacea. Se necesitaría bastante tiempo de desarrollo interno para obtener una solución interna personalizada. En la práctica, las organizaciones buscarán un proveedor de servicios para esta funcionalidad, lo que puede ser costoso. Esto también puede tener como consecuencia que se priorice la opción de desplegar SPF primero, utilizando pocos, sino un solo dominio. Dado que muchos proveedores de servicios no admiten una ruta de retorno personalizada, es decir, una ruta de retorno que utilice su dominio en lugar del de ellos, estas soluciones no ayudarán y dependerán específicamente de DKIM para la autenticación en el momento de desplegar DMARC. En ciertas implementaciones, también puede haber una mayor dependencia del DNS con un único punto de fallo para todos los flujos de correo electrónico.

Para concluir

En última instancia, nada supera a una investigación sólida para determinar qué solución es la mejor para resolver su problema. Independientemente de cuál emplee, un fuerte proceso de gestión de SPF es la mejor práctica para asegurar el éxito de la implementación de autenticación de correo electrónico a largo plazo.

Si tiene alguna pregunta, visite nuestro sitio web y charle con uno de nuestros asesores de DMARC. Si aún no lo ha hecho, puede registrarse aquí para una prueba gratuita y permitirnos que le ayudemos a asegurar sus dominios de correo electrónico.