Errores comunes que se deben evitar al configurar los ajustes de SPF
por
Tiempo de lectura: 4 min
SPF es importante para mejorar la tasa de entrega de correo electrónico y proteger su dominio de phishing y spam de phishing y spam. Sin embargo, la configuración de SPF es complicada y puede equivocarse al configurarla. Corregir y evitar estos errores comunes garantiza que no se produzcan falsos positivos y que DMARC correctamente a su dominio de envío de correo electrónico.
7 errores comunes que hay que evitar al configurar los ajustes SPF
Algunos mecanismos DNS se utilizan para indicar las IP de los sistemas autorizados a enviar correos electrónicos con una dirección de ruta de retorno de correo electrónico. Pero su uso incorrecto provoca errores como - exceder el tamaño del registro SPF, más de 10 búsquedas DNS, más de 2 búsquedas DNS no resueltas, etc.
Hemos enumerado los errores SPF más comunes para ayudarle a evitarlos cuando configure los ajustes SPF.
Error 1: Múltiples registros SPF
Debe haber una entrada SPF por dominio, de lo contrario los servidores receptores rechazarán ambas. Elimina las entradas SPF que no estén en uso, por ejemplo, servicios obsoletos con entradas SPF activas.
Puede resolver este error de configuración SPF fusionando dos o más registros en uno. Digamos que un dominio de usuario tiene un registro SPF e incluye una entrada SPF de Elastic Email pero no pasa las comprobaciones de verificación. La posible razón de esto es tener 2 registros presentes en el dominio.
v=spf1 a mx include:_sampledomain1.com include:_spf.elasticemail.com ~all
v=spf1 a mx include:_sampledomain2.com ~all
Puedes resolverlo fusionándolos en un único registro como:
v=spf1 a mx include:_sampledomain1.com include:_sampledomain2.com include:_spf.elasticemail.com ~all
Error 2: Demasiadas búsquedas DNS
Hay un límite de 10 búsquedas "include", lo que significa que no puedes generar más de 10 referencias a otros dominios. Cada aparición de los parámetros "include", "a", "mx", "ptr", "exists" y "redirect" genera una búsqueda. Además, si un dominio al que se hace referencia en un parámetro 'includecontiene otro parámetro, también se tendrá en cuenta para el límite de 10 búsquedas. Por lo tanto, superar el límite de búsquedas es uno de los errores más comunes que se producen al configurar los ajustes de SPF.
Puede solucionarlo eliminando 'incluyey las referencias a dominios inactivos.
Error 3: Permisividad todo Mecanismo
Un registro SPF se interpreta de izquierda a derecha, y el carácter 'todos' coincidirá con el mecanismo 'todos que no coincidan con los mecanismos anteriores. Se recomienda colocar el mecanismo 'all al final de su registro SPF, y utilizarlo con el prefijo ~ (softfail) o - (fail). Cuando no se establece ningún prefijo, se utiliza el + (pass) por defecto.
Error 4: El uso de la función ptr Mecanismo
El SPF 'ptr se utiliza para la búsqueda DNS inversa que devuelve el nombre de host a su dirección IP correspondiente. Esta información es útil sobre todo para las marcas B2B. Pero este mecanismo tiene problemas de fiabilidad y supone una carga para los servidores DNS inversos y los sistemas de correo electrónico conectados a ellos.
Por eso RFC7208 desaconseja el uso de la extensión 'ptr . En la mayoría de los casos, puede sustituirlo por el mecanismo 'a' .
Error 5: El uso de mx Mecanismo
Utilice mx con nombres de dominio y no con nombres de servidores de correo. Indicando mx:mailserver.ejemplo.com se considera incorrecto a menos que realmente necesite la validación SPF para buscar todos los hosts que aceptan correo para el dominio "mailserver.sample.com". En la mayoría de los casos, no habrá tales hosts, ya que "mailserver.sample.com" es en sí mismo un host y no un dominio.
No se encontrará con esto como un error de sintaxis, pero no coincidirá simplemente con nada.
La forma correcta de validar contra el registro MX para 'sample.com' es mx:ejemplo.com. Cuando tenga que definir el nombre de host o la dirección IP de un determinado servidor de correo, se debe utilizar a:mailserver.sample.com o ip4:x.x.x.x
Error 6: Crear un registro SPF sin la investigación adecuada
Esto es especialmente para los ISP. No crees registros con información a medias sobre el dominio, su propietario y la marca a la que pertenece. Investiga qué servidor de correo electrónico utilizan, de lo contrario podrías acabar bloqueando su ruta de entrega de correo saliente desde el servidor de correo de su oficina.
Error 7: Errores tipográficos
Evite cometer errores comunes al configurar los ajustes SPF comprobando dos veces el registro SPF en busca de errores tipográficos. Puede que escriba "inlcude" en lugar de "include". Esto puede invalidar todo el registro.
Error 8: No publicar registros SPF para los nombres HELO utilizados por sus servidores de correo electrónico
Verifying HELO or EHLO names is encouraged by the SPF RFC. HELO or its developed version EHLO is used when Mail from is <> despite the recipient’s failure in doing 100% HELO checking.
La publicación de un protocolo HELO incluye la generación de un registro SPF correspondiente al FQDN HELO utilizado por su servidor de correo. Por ejemplo mailserver.sample1.com
En general, debería ser una regla SPF completamente distinta de la que comprueba la dirección From de su dominio vinculada a "sample1.com".
Error 9: El contenido del registro TXT no se muestra con comillas dobles
El contenido de un registro DNS TXT siempre va entre comillas dobles ("-"), pero nunca deben formar parte del contenido real del registro DNS. Estas comillas son sólo para fines de visualización, ya que ayudan a separar el inicio y el final del contenido de un registro TXT.
Un registro SPF debe comenzar por v=spf1 pero si empieza por "v=spf1no será reconocido en absoluto.
¿Sigue siendo un problema?
Cada alteración en la configuración SPF requiere algún tiempo para propagarse a través de Internet. Puede tardar hasta 72 horas. Pero si sigue teniendo problemas, utilice nuestro comprobador de registros SPF o póngase en contacto con nuestro equipo de expertos en [email protected].
Experto en seguridad de dominios y correo electrónico de PowerDMARC
Ahona es la Directora de Marketing de PowerDMARC, con más de 5 años de experiencia escribiendo sobre temas de ciberseguridad, especializada en seguridad de dominios y correo electrónico. Ahona tiene un posgrado en Periodismo y Comunicaciones, consolidando su carrera en el sector de la seguridad desde 2019.
Últimas publicaciones de Ahona Rudra (ver todas)
- PowerDMARC nombrado líder G2 en software DMARC por cuarta vez en 2024 - 6 de diciembre de 2024
- Falsificación de datos y suplantación de identidad por correo electrónico en la enseñanza superior - 29 de noviembre de 2024
- Qué es el reenvío de DNS y sus 5 principales ventajas - 24 de noviembre de 2024
