{"id":29798,"date":"2020-12-04T08:17:29","date_gmt":"2020-12-04T08:17:29","guid":{"rendered":"https:\/\/easydmarc.com\/blog\/?p=29798"},"modified":"2023-06-09T14:07:53","modified_gmt":"2023-06-09T14:07:53","slug":"autenticacion-spf-spf-all-frente-a-all","status":"publish","type":"post","link":"https:\/\/easydmarc.com\/blog\/es\/autenticacion-spf-spf-all-frente-a-all\/","title":{"rendered":"Autenticaci\u00f3n SPF: SPF-all frente a ~all"},"content":{"rendered":"
\u00bfQu\u00e9 es SPF?<\/b> el marco de pol\u00edtica del remitente le permite al administrador de un dominio especificar qu\u00e9 direcciones IP pueden enviar correos en nombre de este; dicha autorizaci\u00f3n se publica como un registro .TXT en el proveedor del DNS (Cloudflare, GoDaddy, etc.). Es importante tener en cuenta que SPF comprueba la direcci\u00f3n 5321.MailFrom (tambi\u00e9n conocida como direcci\u00f3n de retorno, sobre de env\u00edo o direcci\u00f3n de rebote) para autorizar el env\u00edo de direcciones IP; cuando el servidor de correo del destinatario se adhiere a la <\/span>pol\u00edtica SPF<\/b> del dominio del remitente, ambos interact\u00faan en base a los lineamientos publicados en la pol\u00edtica SPF.<\/span><\/p>\n Desde hace un tiempo existe una disputa hist\u00f3rica relacionada con el uso de los <\/span>mecanismos SPF \u201chard fail\u201d o \u201csoft fail\u201d<\/b> desde que se iniciara el uso de los marcos de pol\u00edticas del remitente desde el a\u00f1o 2004.<\/span><\/p>\n En este art\u00edculo, vamos a discutir por qu\u00e9 deber\u00edas usar <\/span>SPF softfail vs hardfail (-all vs ~all)<\/b><\/p> El <\/span>registro SPF .TXT<\/b> comienza con el indicador de la <\/span>versi\u00f3n SPF<\/b> que est\u00e1 siendo usada seguida de todas las direcciones IP incluidas en la lista blanca, que est\u00e1n autorizadas para enviar correos a nombre de un dominio especifico, y termina con una etiqueta \u201call\u201d, aqu\u00ed te presentamos los dos escenarios posibles:<\/span><\/p>\n Las etiquetas anteriores indican qu\u00e9 pol\u00edtica debe aplicarse al correo cuando los ESPs (proveedores de buz\u00f3n como Google, Microsoft, Yahoo!, etc.) detectan que el correo ha sido enviado desde servidores o direcciones IP que no figuran en tu registro SPF; el uso de SPF hard fail o soft fail son los dos m\u00e9todos m\u00e1s aceptados, pero la preferencia general es \u201c~all\u201d.<\/span><\/p>\n Ahora que sabes que no deber\u00edas usar +all y ?all, podemos revisar un ejemplo del tipo de <\/span>registro SPF<\/b> antes de tocar el tema <\/span>SPF SoftFail vs HardFail<\/b>.<\/span><\/p>\n Ejemplo de registro SPF:<\/b><\/p>\n v=spf1 ip4:172.16.254.1 ip4:213.22.138.0\/24 ip6:2001:db8:0:1234:0:567:8:1 include:_spf.google.com -all<\/span><\/p>\n En este ejemplo se usa el <\/span>registro SPF hardfail vs softfail<\/b>, para descartar todos los correos que no pasen la prueba, incluidos los leg\u00edtimos. Antes de la adopci\u00f3n de DMARC (en el a\u00f1o 2012), solo SPF desempe\u00f1aba un papel importante en la autenticaci\u00f3n de mensajes de correo, a pesar de sus limitaciones, era el \u00fanico mecanismo de lucha contra los intentos de suplantaci\u00f3n de correo de las direcciones de retorno o MailFrom. Los ESPs aplicaron una serie de reglas basadas en las pol\u00edticas de registro de SPF tal como eran expresadas por los administradores (~all o -all), lo cual caus\u00f3 problemas con el bloqueo de correos leg\u00edtimos debido a m\u00faltiples errores de configuraci\u00f3n de SPF, lo que a su vez llev\u00f3 a la mayor\u00eda de los servicios de correos conocidos a usar SoftFail (~all) y Fail (-all) como m\u00e9todo para aceptar el ingreso de mensajes con una marca.<\/span><\/p>\nRegistro SPF: \u00bfc\u00f3mo luce?<\/b><\/h2>\n
\n
\n
\n<\/span><\/p>\n<\/p>\n
SPF -all vs ~all: \u00bfqu\u00e9 debo usar?<\/b><\/h2>\n