Puestos

¿Por qué falla la autenticación SPF? ¿Cómo solucionar el fallo de SPF?

¿Ha visto alguna vez que un correo electrónico falle el SPF? Si lo has hecho, te voy a decir exactamente por qué falla la autenticación SPF. Sender Policy Framework, o SPF, es uno de los estándares de verificación de correo electrónico que todos hemos utilizado durante años para detener el spam. Incluso si no eres consciente de ello, apuesto a que si comprobara la configuración de tu cuenta de inicio de sesión en Facebook, probablemente mostraría que has optado por el "correo electrónico sólo de amigos". Eso es efectivamente lo mismo que el SPF.

¿Qué es la autenticación SPF?

SPF es un protocolo de autenticación de correo electrónico que se utiliza para verificar que el remitente del correo electrónico coincide con su nombre de dominio en el campo De: del mensaje. El MTA remitente utilizará DNS para consultar una lista preconfigurada de servidores SPF para comprobar si la IP remitente está autorizada a enviar correo electrónico para ese dominio. Puede haber incoherencias en el modo en que se configuran los registros SPF, lo que es fundamental para comprender por qué los correos electrónicos pueden fallar en la verificación SPF, y qué papel puede desempeñar usted para garantizar que no se produzcan problemas en sus propios esfuerzos de marketing por correo electrónico o cuando envíe cupones de marketing por correo electrónico para captar clientes.

Por qué falla la autenticación SPF : Ninguno, Neutral, Hardfail, Softfail, TempError y PermError

Los fallos de autentificación SPF pueden ocurrir por las siguientes razones:

  • El MTA receptor no encuentra un registro SPF publicado en su DNS
  • Tiene varios registros SPF publicados en su DNS para el mismo dominio
  • Sus ESPs han cambiado o añadido a sus direcciones IP que no han sido actualizadas en su registro SPF
  • Si supera el límite de 10 búsquedas de DNS para SPF
  • Si supera el límite de búsqueda de vacíos permitido de 2
  • La longitud de su registro SPF aplanado supera el límite de 255 caracteres SPF

Los casos anteriores son varios de los motivos por los que falla la autenticación SPF. Puede supervisar sus dominios con nuestro analizador DMARC para obtener informes sobre los fallos de autenticación SPF. Cuando tiene activados los informes DMARC, el MTA receptor devuelve cualquiera de los siguientes resultados de fallo de autenticación SPF para el correo electrónico, dependiendo del motivo por el que su correo electrónico falló SPF. Vamos a conocerlos mejor:

Tipos de calificadores de fallo SPF

Los siguientes son tipos de calificadores de fallo SPF, cada uno de los cuales se añade como prefijo antes del mecanismo de fallo SPF:

"+" "Aprobado"
"-" "Fallo"
"~" "Softfail"
"?" "Neutral"

¿Qué importancia tienen? Bueno, en una situación en la que su correo electrónico falle el SPF, puede elegir el grado de rigor con el que desea que los receptores lo manejen. Puede especificar un calificador para "pasar" los mensajes que fallan la comprobación (entregarlos), "Fallar" la entrega, o tomar un punto de vista "Neutral" (no hacer nada).

Caso 1: Se devuelve el resultado SPF None

En el primer caso, si el servidor de correo electrónico receptor realiza una búsqueda de DNS y no puede encontrar el nombre de dominio en el DNS, se devuelve un resultado de ninguno. También se devuelve ninguno en caso de que no se encuentre ningún registro SPF en el DNS del remitente, lo que implica que el remitente no tiene configurada la autenticación SPF para este dominio. En este caso la autenticación SPF para sus correos electrónicos falla.

Genere ahora su registro SPF sin errores con nuestra herramienta gratuita generadora de registros SPF para evitarlo.

Caso 2: Se devuelve el resultado neutro del FPS

Al configurar el SPF para su dominio, si ha puesto un mecanismo ?all a su registro SPF, esto significa que, independientemente de lo que concluyan las comprobaciones de autenticación SPF para sus correos electrónicos salientes, el MTA receptor devuelve un resultado neutral. Esto sucede porque cuando tiene su SPF en modo neutral, no está especificando las direcciones IP que están autorizadas a enviar correos electrónicos en su nombre y permitiendo que las direcciones IP no autorizadas también los envíen.

Caso 3: Resultado del SPF Softfail

Al igual que el SPF neutro, el SPF softfail se identifica por el mecanismo ~all, que implica que el MTA receptor aceptaría el correo y lo entregaría en la bandeja de entrada del destinatario, pero se marcaría como spam, en caso de que la dirección IP no figure en el registro SPF que se encuentra en el DNS, lo que puede ser una razón por la que la autenticación SPF falle para su correo electrónico. A continuación se muestra un ejemplo de SPF softfail:

 v=spf1 include:spf.google.com ~all

Caso 4: Resultado del SPF Hardfail

SPF hardfail, también conocido como SPF fail es cuando los MTAs receptores descartan los correos electrónicos originados por cualquier fuente de envío que no esté listada en su registro SPF. Le recomendamos que configure el hardfail SPF en su registro SPF, si desea obtener protección contra la suplantación de dominio y el spoofing de correo electrónico. A continuación se muestra un ejemplo de SPF hardfail:

v=spf1 include:spf.google.com -all

Caso 5: SPF TempError (Error temporal del SPF)

Una de las razones muy comunes y a menudo inofensivas por las que falla la autenticación SPF es el SPF TempError (error temporal) que se produce debido a un error de DNS, como un tiempo de espera de DNS, mientras el MTA receptor realiza una comprobación de autenticación SPF. Por lo tanto, como su nombre indica, suele ser un error provisional que devuelve un código de estado 4xx que puede causar un fallo temporal de SPF, pero que da un resultado de aprobación de SPF cuando se vuelve a intentar más tarde.

Caso 6: SPF PermError (error permanente del SPF)

Otro resultado común al que se enfrentan los errores de dominio es el SPF PermError. Por ello, la autenticación SPF falla en la mayoría de los casos. Esto ocurre cuando su registro SPF es invalidado por el MTA receptor. Hay muchas razones por las que el SPF puede romperse y ser invalidado por el MTA al realizar las búsquedas de DNS:

  • Superar el límite de 10 búsquedas de SPF
  • Sintaxis incorrecta del registro SPF
  • Más de un registro SPF para el mismo dominio
  • Exceder el límite de longitud del registro SPF de 255 caracteres
  • Si su registro SPF no está actualizado con los cambios realizados por sus ESPs

Nota: Cuando un MTA realiza una comprobación SPF en un correo electrónico, consulta el DNS o realiza una búsqueda de DNS para comprobar la autenticidad del origen del correo electrónico. Idealmente, en el SPF se permite un máximo de 10 búsquedas de DNS, si se sobrepasa, el SPF fallará y devolverá un resultado PermError.

¿Cómo puede el aplanamiento dinámico del SPF resolver el SPF PermError?

A diferencia de los otros errores SPF, el SPF PermError es mucho más difícil y complicado de resolver. PowerSPF le ayuda a mitigarlo fácilmente con la ayuda del aplanamiento automático del SPF. Le ayuda:

  • Manténgase por debajo del límite duro del FPS
  • Optimice instantáneamente su registro SPF
  • Aplanar su registro a una sola declaración de inclusión
  • Asegúrese de que su registro SPF se actualiza siempre con los cambios realizados por sus ESP

¿Quiere comprobar si tiene configurado correctamente el SPF para su dominio? Pruebe hoy mismo nuestra herramienta gratuita de búsqueda de registros SP F.

/por

La diferencia entre SPF -all y SPF ~all | SPF -all vs ~all

El SPF existe en el DNS de su dominio como un registro TXT con un montón de mecanismos y modificadores que representan instrucciones específicas. El mecanismo SPF all está presente en el extremo derecho de un registro SPF, precedido por "-" o "~". Veamos cuál es la diferencia entre los mecanismos SPF -all y ~all para determinar cuándo debe configurarlos.

SPF -todos vs ~todos

Ambos mecanismos SPF -all y ~all significan "NO PASA" para la autenticación SPF. En los últimos tiempos, para la mayoría de los proveedores de servicios de correo electrónico, no hay diferencia entre el mecanismo -all y ~all, y se devuelve el mismo resultado. Sin embargo, este no era el caso hace unos años.

¿Cómo funcionaba el mecanismo SPF all (Softfail vs Fail) antes de DMARC?

El DMARC se creó mucho tiempo después de que el SPF ya estuviera en el mercado como protocolo estándar de autenticación del correo electrónico. En ese momento el mecanismo SPF -all softfail funcionaba de la siguiente manera: 

Supongamos que su registro SPF fuera 

v=spf1 include:spf.domain.com ~all (donde ~all significa SPF Softfail)

El servidor de correo electrónico del receptor habría realizado una búsqueda de DNS para consultar el registro SPF del remitente. Si el dominio de la ruta de retorno del correo electrónico no figuraba en el registro del remitente, el servidor receptor habría devuelto un resultado SPF "NO PASA", pero habría entregado el correo electrónico a la bandeja de entrada del receptor.

Ahora supongamos que su registro SPF fuera: 

v=spf1 include:spf.dominio.com -all (donde -all significa Fallo SPF)

El servidor de correo electrónico del receptor habría realizado una búsqueda de DNS para consultar el registro SPF del remitente. Si el dominio de la ruta de retorno del correo electrónico no figuraba en el registro del remitente, el servidor receptor habría devuelto un resultado SPF "NO PASA", pero en este caso, el correo electrónico habría sido rechazado y no se habría entregado a la bandeja de entrada del receptor.

Más información sobre la historia de Sender Policy Framework. 

¿Cómo manejan ahora los proveedores de servicios de correo electrónico el mecanismo SPF -all vs ~all?

Mientras que en la actualidad es libre de utilizar SPF -all o ~all para la mayoría de los proveedores de buzones de correo sin tener que preocuparse por los fallos de entrega de los correos legítimos, puede surgir una situación en la que un servidor rechace su correo electrónico en caso del atributo -all.

Para estar más seguro, puede evitar el uso del mecanismo SPF hard fail -all mientras crea su registro SPF. Así es como se hace:

  • Abra el programa PowerDMARC generador de registros SPF para empezar a crear un registro de forma gratuita
  • Después de incluir las direcciones IP y los dominios de sus remitentes de correo electrónico, desplácese hasta la última sección designada para indicar al servidor de correo electrónico lo estricto que debe ser al verificar sus correos electrónicos
  • Elija la opción "Soft-fail" antes de pulsar el botón "Generar registro SPF"

¿Qué recomendamos? SPF -todos o SPF ~todos

Los problemas de entrega de correo electrónico relacionados con el mecanismo SPF -all pueden ocurrir en muy raras ocasiones. No es un problema recurrente con el que se encuentre a menudo. Para asegurarse de que nunca se encuentre con este problema, puede seguir los siguientes pasos:

  • Configurar DMARC para sus correos electrónicos y active los informes DMARC
  • Establezca su política de DMARC en la supervisión e inspeccione detenidamente los resultados de la autenticación SPF para detectar cualquier incoherencia en la capacidad de entrega del correo electrónico
  • Si todo está bien, puede utilizar el mecanismo -all en su registro SPF. Recomendamos utilizar el atributo hard fail ya que afirma que está seguro de la autenticidad de sus correos electrónicos, lo que puede impulsar la reputación de su dominio

Si no está seguro de utilizar el SPF -all, puede seguir estos pasos:

  • Configurar un registro SPF utilizando el mecanismo ~all
  • Configurar DMARC para sus correos electrónicos y activar los informes DMARC
  • Establezca su política DMARC para rechazar

Solución de otros errores de SPF

Al utilizar herramientas en línea, es posible que a menudo se encuentre con el mensaje "No se ha encontrado ningún registro SPF"que es un estado de error común que surge de un resultado nulo devuelto cuando un servidor buscó el registro SPF de su dominio. Hemos cubierto un artículo en detalle hablando de este problema y ayudando a los usuarios a resolverlo. Haga clic en el texto enlazado para saber más.

Si tiene DMARC en su dominio además de SPF, los servidores de correo electrónico comprobarán la política DMARC de su dominio para establecer cómo quiere que se traten los correos electrónicos que no se autentiquen. Esta política de DMARC determinará si sus correos electrónicos se entregan, se ponen en cuarentena o se rechazan. 

El rechazo de DMARC ayuda a proteger su dominio contra una variedad de ataques de suplantación de identidad como el spoofing, el phishing y el ransomware.

/por

¿Cómo arreglar el problema de "SPF Softfail Domain Does Not Designate IP as Permitted Sender"?

Si su empresa utiliza sus propios dominios y correos de gestión de dominios, hay muchas posibilidades de que se encuentren con problemas de correo electrónico, y se hayan topado con el error "SPF Softfail Domain Does Not Designate IP as Permitted Sender". Es crucial que las empresas designen correctamente las direcciones IP utilizadas para enviar correos electrónicos en su nombre como remitente permitido en el registro SPF.

¿Qué es el FPS?

SPF o Sender Policy Framework es un estándar de autenticación de correo electrónico que protege a las organizaciones contra la suplantación de identidad. Un atacante puede utilizar el dominio y la marca de una empresa para enviar mensajes falsos a sus clientes. Estos correos electrónicos de suplantación de identidad parecen lo suficientemente auténticos como para convencer a los clientes y hacerles caer en una estafa en Internet en nombre de la empresa. Esto perjudicará la credibilidad de la marca de una empresa y dañará su imagen pública. El SPF se puede imaginar como una lista de seguridad de los dominios de confianza de una empresa desde donde se puede originar una comunicación auténtica.

¿Cómo comprobar si su dominio es un remitente permitido?

El primer paso para resolver el error "SPF Softfail Domain Does Not Designate IP as Permitted Sender" es comprobar su autoridad de remitente. Para ello:

Paso 1: Inicie sesión en la cuenta de correo electrónico del dominio de la empresa, digamos, [email protected]

Paso 2: Envíe un correo electrónico a otra cuenta de correo electrónico a la que tenga acceso; puede ser a un dominio externo como Gmail, Yahoo, Hotmail u otros.

Paso 3: Inicie sesión en la cuenta de correo electrónico donde envió el primer correo, y luego vea las cabeceras de este correo. Estará marcado como "Mostrar original".

Entonces, verá algo similar a esto. Observe el mensaje de SPF Softfail.

-Mensaje original -

X-Recibido: ...

Sat, 13 March, 2022 11:01:19 IST

Return-Path: [email protected]

Recibido: de mymy2.spfrecords.com (mymy2.spfrecords.com [60.130.71.223])

por mx.google.com con ESMTPS id 

*id*

Para [email protected]

SPF recibido: softfail (google.com: el dominio de transición [email protected] no designa 60.130.71.223 como remitente permitido) client-ip=60.130.71.223; 

Resultados de la autenticación: mx.google.com;

Spf = softfail (google.com: el dominio de transición [email protected] no designa 60.130.71.223 como remitente permitido) client-ip=60.130.71.223; 

*final del mensaje de cabecera

Nota: Si observa "Received-SPF: pass" en la cabecera, entonces el dominio que está utilizando para enviar los correos está autenticado y ya está añadido a su registro SPF, y no tiene nada de qué preocuparse. Sin embargo, como se muestra arriba, hay un problema de softfail. Ahora veremos cómo resolverlo.

¿Qué significa "SPF Softfail Domain Does Not Designate IP as Permitted Sender"?

Su remitente de correo electrónico tiene una IP de host que se parece a esto:

30.10.323.005

Si esta dirección IP del dominio remitente no está incluida en el registro SPF de su dominio, el servidor receptor de correo electrónico no identifica la IP designada como remitente permitido. El servidor interpreta automáticamente que el mensaje proviene de una fuente no autorizada. Esta es una posible razón por la que el SPF falló para el mensaje. Se produce una alta probabilidad de fallo de DMARC si el sistema de autenticación de correo electrónico depende únicamente de SPF para la verificación de la fuente (y no de DKIM). 

En estas circunstancias, si su política de protocolo está configurada para rechazar, su mensaje nunca se entregará. Por lo tanto, el propietario del dominio debe tomar medidas rápidas y procesables para solucionar el problema "SPF Softfail Domain Does Not Designate IP as Permitted Sender".

¿Cómo incluir una IP como remitente permitido para el SPF?

La solución para esto puede dividirse en los siguientes pasos: 

1. Cree una lista de fuentes de envío para su dominio. Puede utilizar una lista de direcciones de correo electrónico basada en su dominio, así como fuentes de envío de terceros para las transacciones de correo electrónico.

2. Ahora, identifique las IPs del host de estas fuentes de envío 

¿Cómo encontrar las direcciones IP vinculadas a sus fuentes de envío de correo electrónico?

Es muy fácil. Para encontrar la dirección IP de su fuente de envío, abra el correo electrónico y vea su encabezado completo. Para ello, haz clic en los tres puntos de la esquina superior derecha de tu correo electrónico para ver el menú desplegable y selecciona "Mostrar el original".

En el mensaje original, desplácese hacia abajo hasta la sección Recibido podrá ver la dirección IP del remitente original, como se muestra a continuación:

3. Utilice nuestro Generador de registros SPF para generar un registro SPF gratuito para su dominio.

  • En el generador de registros, añada todas las direcciones IP que desee que se autentifiquen para enviar correos electrónicos y comunicaciones en nombre de la empresa.
  • Añada cualquier servidor de terceros o servicios de entrega externos como fuente de envío autorizada para su dominio. De esta manera, cualquier correo enviado a través de servidores de terceros también pasará la autenticación SPF.

4. Una vez que haya utilizado el generador de registros SPF para generar el registro SPF de su dominio con todos los dominios y direcciones IP de confianza añadidos, lo único que queda por hacer es implementar el SPF publicándolo en sus DNS. A continuación le explicamos cómo puede conseguirlo:

  • Acceda a su consola de gestión de DNS
  • A continuación, navegue hasta el dominio elegido (el dominio para el que está intentando añadir/modificar el registro SPF)
  • Especifique el tipo de recurso como "TXT
  • Especifique el nombre de host como "_spf"
  • Pegue el valor de su registro SPF generado 
  • Guarde los cambios para configurar el SPF para su dominio

Nota: Los nombres o cabeceras anteriores pueden variar en función de la consola de gestión de DNS que utilice su empresa.

De este modo, los propietarios de los dominios pueden asegurarse de que todas sus direcciones IP de confianza y los dominios que puedan utilizar para enviar comunicaciones en nombre de la empresa se añaden al servidor, y no se producirá un error similar en el que el dominio SPF Softfail no designe la IP como remitente permitido. 

¿Cómo utilizar eficazmente la norma SPF?

La única manera de consolidar la tecnología SPF de una empresa es incorporarla con DMARC. Estas son las ventajas de hacerlo,

1. DMARC = SPF + DKIM

Los protocolos de autenticación de correo electrónico como DMARC se configuran añadiendo un registro TXT a su DNS. Además de configurar una política para los correos electrónicos de su dominio, también puede aprovechar DMARC para habilitar un mecanismo de informes que le envíe una gran cantidad de información sobre sus dominios, proveedores y fuentes de correo electrónico.

DMARC puede ayudarle a utilizar las tecnologías SPF (Sender Policy Framework) y DKIM (DomainKeys Identified Mail) en conjunto para dar a su dominio una protección aún mejor contra la suplantación.

Nota: Esto se recomienda, pero no es obligatorio. DMARC puede funcionar con la alineación de identificadores SPF o DKIM.

2. Informes y comentarios con PowerDMARC

Ni el SPF ni el DKIM proporcionan al propietario del dominio información sobre los correos electrónicos que fallan en la autenticación. DMARC le envía informes detallados directamente, que la plataforma PowerDMARC convierte en gráficos y tablas fáciles de leer.

3. Controlar lo que ocurre con los correos electrónicos no autentificados 

DMARC le permite a usted, el propietario del dominio, decidir si un correo electrónico que falla la validación va a la bandeja de entrada, al correo no deseado o es rechazado. Con PowerDMARC, todo lo que tiene que hacer es pulsar un botón para establecer su política DMARC, y es así de fácil.

Los remitentes no autorizados pueden ser una peligrosa amenaza para la seguridad de sus clientes y para la imagen y el valor de la marca de su empresa. Proteja a sus clientes de la suplantación de identidad y de las estafas incorporando DMARC en su empresa, y sólo permita que les lleguen correos de remitentes autentificados.

/por