Si eres dueño de un dominio que envía correos electrónicos, lo más probable es que tengas una configuración preestablecida para tu registro SPF por parte de tu servicio de hosting. Entonces ¿por qué es necesario optimizar tu registro SPF?
El registro que tienes en uso contiene mecanismos A, IP4 o IP6 o también MX si tienes un servicio de hosting exclusivo. Si usas un hosting compartido los únicos mecanismos que se manejan para tus correos son MX e INCLUDE.
Ese registro SPF preestablecido se asegura de que los correos que sean enviados de tu sitio web o desde tu máquina VPS, en tu servicio de hosting estén autenticados.
En realidad, mucha gente usa una amplia variedad de servicios de terceros para enviar correos desde su dominio (por ejemplo, CRM o servicios de correo en la nube tales como G Suite y Microsoft 365) es por esto que los registros preestablecidos requieren ciertas modificaciones para cubrir los servidores usados por los servicios de terceros para enviar sus correos y que estos puedan ser autenticados también.
- Crear o modificar un registro SPF existente
- Validar un registro SPF con sintaxis y limitaciones correctas
- Optimizar el registro SPF
Crear un registro SPF nuevo o modificar uno existente
Puedes crear un nuevo registro SPF o modificar uno existente, sigue una de las siguientes opciones que se presentan a continuación:
Usa el generador de registros SPF de EasyDMARC, para crear o actualizar un registro SPF nuevo. Esta herramienta genera registros con la sintaxis apropiada y al mismo tiempo resalta los problemas existentes en los mecanismos que están en uso, si estos son detectados durante el proceso de validación de registros.
También puedes usar la herramienta EasyDMARC para la validación de registros SPF, si estás familiarizado con la sintaxis de los registros y si prefieres trabajar con un registro desde cero. Dicha herramienta válida la redacción inicial del registro y te muestra la extensión de este mientras resalta los potenciales problemas que pudiese presentar.
Validación de un registro SPF con sintaxis y limitaciones correctas
Existen múltiples retos que puedes enfrentar al querer mantener un registro SPF funcional de forma eficiente. Muchos de ellos no están a la vista o son difíciles de notar. La mayoría de estos problemas tienen que ver con la sintaxis del registro y las limitaciones o restricciones que estos heredan del momento en el que los registros SPF se convirtieron en la norma en el año 2006.
Aquí tienes una lista de los casos más comunes a los que puedes enfrentarte:
1. Uso de mecanismo PTR
Los mecanismos PTR le solicitan a los DNS realizar una mapeado en reverso para enviar una dirección IP y luego poder hacer la búsqueda del DNS con los nombres de los servicios de hosting que verifican si él envió de la IP está incluido entre las direcciones IP solicitadas. En los casos en los que la dirección IP consigue múltiples registros de tu servicio de hosting, este inicia el proceso de búsqueda de varios DNS y puede llegar al límite de 10 intentos que se describe posteriormente en esta guía o como se muestra aquí. No es entonces posible validar los mecanismos PTR durante un chequeo de registro SPF ya que el proceso es dinámico y depende del envío de una IP, por lo que solo te mostrará una advertencia de que su uso no se recomienda.
2. Usar un CDN como proxy para un dominio de DNS
Si tu dominio está protegido por un CDN como Cloudflare por ejemplo, y los registros DNS A / AAAA están enlazados con un proxy, estos registros serán resueltos por la IP localizada en el proxy y no por la IP actual de la dirección del servicio de hosting que envía tus correos. En estos casos, tienes que reemplazar los mecanismos A con los mecanismos IP4 o IP6. También debes especificar la dirección IP de envío que será actualmente utilizada por el servidor.
3. Límite de 10 búsquedas del DNS
La búsqueda de registros SPF por parte del DNS es el problema más común que enfrentan muchos usuarios. Esto sucede cuando se añaden fuentes adicionales de correos electrónicos a un registro SPF. El protocolo RFC7208 se activa para evitar tiempos de carga excesivos del DNS colocado un número de intentos de búsqueda que no exceda de 10. Cada uno de los mecanismos MX o INCLUDE, así como los modificadores para redireccionar le indican al servidor del servicio de correo que debe realizar una búsqueda del DNS o resolver las búsquedas de las direcciones IP. Si el registro SPF que resuelve el mecanismo de inclusión contiene un mecanismo de inclusión adicional, entonces el conteo de búsquedas del DNS se incrementa en una unidad cada vez. No es fácil llevar cuenta de la cantidad de búsquedas e identificar el límite de excesos si no utilizamos una herramienta de monitoreo de búsqueda de DNS.
Los registros SPF se leen de izquierda a derecha, por lo que el mecanismo o modificador debe estar localizado o alineado con la décima búsqueda, de otra forma ignorará los correos que vengan directamente de la fuente, incluso si esta es definida en estos mecanismos que son ignorados, por lo que la autenticación SPF fallará con un mensaje de “error permanente” como resultado.
4. Dos búsquedas vacías
Este caso ya es mencionado en la misma sección RFC7208 que define la limitación de búsqueda del DNS a 10 intentos. Si un mecanismo A, MX o INCLUDE en cualquier registro SPF puede enlazarse con el servicio de hospedaje, pero ofrece una respuesta vacía (por ejemplo: include:existing-domain-with-no-spf.com) o si sencillamente no consigue el servicio de hosting (por ejemplo: a:non-exising-domain.com) entonces nos referiremos a este problema como búsquedas vacías. La recomendación inicial es detener el proceso de búsqueda del registro SPF una vez que las búsquedas vacías lleguen a dos. Si excedes este límite recibirás un mensaje de “error permanente”
5. Búsquedas recursivas
Las búsquedas recursivas son bastante complejas de detectar, especialmente cuando una incluye mecanismos que contienen otros mecanismos de forma directa o indirecta, ya que este solo crea un ciclo infinito de búsquedas que cubre el tope de 10 búsquedas del DNS en muy poco tiempo. Aquí puedes ver dos ejemplos de este tipo de registros:
example.com TXT v=spf1 include:example.com ~all
o también:
sub1.example.com TXT v=spf1 include:sub2example.com include:sub3.example.com ~all
sub3.example.com TXT v=spf1 include:sub1.example.com ~all
6. Uso de símbolos para espacios en blanco
Si tipeas accidentalmente un espacio en blanco adicional en el nombre del mecanismo o en el nombre del dominio (por ejemplo: e.g. inclu de:_spf.google.com o a:so mecrm.com o ip 4:12.3 4.56.78) el resto del hilo de reconocimiento será ignorado por las fuentes de origen, ya que creará un listado para elementos maliciosos y tus correos caerán en esa categoría incluso después de chequear tu registro SPF. Un espacio en blanco en el nombre del servicio de hospedaje y la inclusión de los mecanismos A e INCLUDE serán tratados como una búsqueda vacía.
7. Existencia de más de un registro SPF
Debes asegurarte que solo tengas un registro en formato .TXT en el dominio de tu DNS. Este debe iniciar su sintaxis de esta forma: “v=spf1“ si tienes más de un registro con esa misma sintaxis te dará resultados erróneos cuando tu dominio intente ser localizado por un proveedor de correos y todos tus chequeos SPF arrojarán reportes de fallos.
8. Extensión del registro SPF
Un hilo simple de un registro .TXT debe tener una extensión máxima de 255 bytes, aunque de acuerdo a la normativa RFC7208, múltiples hilos de data con una extensión de 255 bytes cada uno pueden ser comprimidos en un solo registro. Si necesitas un registro SPF más extenso puedes hacerlo de esta manera: TXT “v=spf1 …. Primer hilo-” “Segundo hilo…” será analizado como TXT “v=spf1 …. Primer hilo, segundo hilo…”
También necesitas asegurarte que la zona de dominio de hosting de tu proveedor de DNS sea compatible con registros .TXT y que no sean mayores a 255 bytes. Si no puedes obtener este beneficio con tu proveedor actual, deberás considerar mover la zona de tu dominio DNS a un sistema alternativo que respalde registros extensos, como, por ejemplo: e.g. Cloudflare.Besides.
Aclarado este punto, también existe otra limitación específica al tipo de formato .TXT que se usa para los registros SPF. Se recomienda que se mantenga el tamaño del registro lo suficientemente pequeño para que la búsqueda del DNS no ocupe un espacio mayor a 512 bytes. Si este proceso no se maneja de esta forma, existe la posibilidad de que se exceda el tamaño límite para los paquetes UDP que están definidos en los protocolos del DNS. Esta limitación ya fue revisada en la norma RFC6891 por lo que al mantener tus registros menores a 512 bytes aún, se debería eliminar los casos de remitentes antiguos sin configuración en su DNS de acuerdo a lo estipulado en RFC6891, por lo que cualquier intento de validación de un correo con un registro SPF muy extenso fallara completamente.
De hecho la solicitud de DNS una vez que ejecutada la lectura del registro SPF, retorna el registro SPF junto a todos los registros en formato .TXT, tal como lo hacen todos los sitios web de Google, Microsoft 365 entre otros sistemas de verificación; es importante que recuerdes llevar cuenta de estos y calcular el tamaño que queda para implementar un registro SPF apropiado (512 – DNS hostname – todas las otras longitudes de los demás registros .TXT) Puedes usar el comando “dig example.com txt” en Linux o la herramienta de interfaz Dig Web en línea para revisar cuándo registros .TXT necesitas, y calcular de tamaño adecuado para tus registro SPF. A continuación, puedes observar un ejemplo de un dominio con múltiples registros .TXT:
Los casos que hemos descritos pueden ser detectados y analizados por nuestra herramienta EasyDMARC para buscar registros SPF tal como puedes ver en la siguiente captura de pantalla:
Cómo optimizar un registro SPF
A continuación, vamos a describirte los pasos que pueden asistirte en la optimización de tus registros SPF:
1. Cambia el orden de las fuentes
Los registros SPF se leen de izquierda a derecha, así que es necesario colocar las fuentes de correos más importantes al inicio del registro.
2. Limpia el registro de fuentes duplicadas
Algunas veces es necesario liberar espacio en tus registros SPF retirando las fuentes duplicadas y añadiendo nuevas fuentes. Esto se hace mucho más necesario cuándo estás a punto de alcanzar los 10 intentos de búsqueda de tus DNS. Usa la herramienta EasyDMARC para buscar registros SPF para detectar estas fuentes duplicadas en tus registros SPF y en todo tu organigrama.
3. Deshazte de fuentes obsoletas
Al momento de analizar reportes DMARC deja pasar un tiempo determinado (un mes o dos desde el momento que empiezan a generarse) y podrás detectar ciertas fuentes añadidas a tus registros SPF que no envían correos durante este periodo especifico. Asegúrate que las fuentes están asociadas a los sistemas usados por tu compañía y muévelos si ya no están siendo utilizados.
4. Reduce el número de mecanismos INCLUDE
Cada mecanismo INCLUDE ocupa una búsqueda de tu DNS. Si el mecanismo INCLUDE no contiene mecanismos IP4 e IP6, pero incluye otros mecanismos INCLUDE que siguen ocupando tu DNS, debes reemplazarlos con IP4 o IP6.
Este paso es medianamente complejo, especialmente cuando INCLUDE está manejando servicios de correos de terceros. Puede que no sea posible analizar el cumplimiento de tu registro SPF porque nunca podrás saber realmente si tu ESP decide enviar un correo a través de otra dirección IP mientras actualiza su propio registro SPF. Además de que se hace aún necesario mantener el límite de tus registros a un tamaño no mayor a 512 bytes.
5. Evita usar mecanismos MX y A
Los mecanismos MX ocupan una búsqueda de DNS completa y puede ocupar fácilmente el límite de 10 búsquedas. Este mecanismo también activa la búsqueda de DNS para servicios de hosting indicados en tus registros MX. Estas búsquedas no cuentan de forma directa para el conteo de DNS estipulado en tu registro SPF, pero incrementa la latencia del envío de cada uno de tus correos.
Es mucho más razonable usar mecanismos IP4 e IP6 en su lugar e incluir los rangos de tus envíos de correo usando mecanismos MX para ahorrar tiempo en las respuestas del DNS.
Lo mismo aplica para el uso de mecanismos A
6. Remueve las fuentes no alineadas con tus remitentes y dominio
Como ya debes saber, los chequeos SPF se llevan a cabo en paralelo a tu dominio través de una dirección de correo como ruta de retorno (smtp.mailfrom) o a través de un dominio smtp.helo cuando smtp.mailfrom se encuentra vacío. Lo más usual es que el dominio en forma de encabezado y la ruta de regreso tengan la misma dirección. En Gmail puedes ver el encabezado como un campo específico y la ruta de retorno estipulada de la siguiente forma: “Return-path / smtp.helo”
Puedes ver el ejemplo que mostramos a continuación:
Encabezado de: VMWare <[email protected]>
Ruta de retorno: [email protected]
Algunos proveedores de servicios usan sus propios dominios como rutas de retorno cómo puedes ver a continuación:
Encabezado de: Booked Scheduler <[email protected]>
Ruta de retorno: bounce-mc.us19_134631002.4790858-956d20b353@mail249.suw12.mcsv.net
Las guías de configuración para muchos proveedores de servicios que no cumplen con los requerimientos de tu registro SPF pueden recomendar, o exigir que incluyas sus registros SPF a los hilos de tu dominio. Obviamente esto es el resultado de tener poco conocimiento acerca de cómo funciona la verificación SPF. Esta es una lista (incompleta) de todos los proveedores de servicios de correo que usan sus propios dominios como rutas de retorno: Active Campaign, Aweber, Mailchimp, Marketo, y Salesforce.
Como ya mencionamos anteriormente, los servidores de tus destinatarios pueden llevar a cabo un chequeo de los registros SPF de los dominios mencionados en las rutas de retorno, y no en lo que está definido en el encabezado de la dirección de correo. No hay necesidad de añadir el registro SPF de un proveedor externo al SPF de tu dominio ya que ocupa espacio valioso y activa búsquedas innecesarias de DNS.
7. Mueve partes de la fuente a los subdominios
Si estás usando múltiples mecanismos INCLUDE, las 10 búsquedas de DNS se verán agotadas, por lo que se hace necesario reconfigurar algunas fuentes de correos electrónicos para enviarlas a los subdominios y no al dominio base (puedes ver un ejemplo con VMWare descrito en el punto 6) posteriormente puedes mover estas fuentes con INCLUDE al hilo de un nuevo registro SPF creado para el subdominio.
8. Usa la herramienta EasyDMARC EasySPF para generar un registro SPF dinámico e inteligente
La sugerencia final es usar la herramienta EasyDMARC para el manejo de registros SPF. EasySPF sirve perfecto si no quieres considerar las 7 recomendaciones previas ya sea por que consumen mucho de tiempo en términos de optimización y necesitas chequear constantemente los servicios de terceros y sus propios registros SPF (aplicable solo si usas el consejo número 4 de nuestra lista) La herramienta no requiere mayor intervención de tu parte más allá de activar su uso para reemplazar tu registro SPF viejo y diseñar un registro personalizado e inteligente.
