Soy responsable de un dominio que tiene un registro SPF recomendado por otros servicios que envían correo en nombre de este dominio.
Al configurar Mailchimp, me sorprendió no encontrar documentación sobre la configuración SPF recomendada por Mailchimp. Cuando me comuniqué con el soporte me dijeron que Mailchimp básicamente considera el SPF heredado, no ha usado SPF durante más de 6 meses y cree que tener el registro no ayuda ni obstaculiza. Incluso yendo tan lejos como para sugerir que borre nuestro registro SPF por completo.
No dudo que Mailchimp sepa infinitamente más que yo sobre la capacidad de entrega del correo electrónico. Pero me sorprende que Mailchimp no publique nada explicando esta decisión, especialmente teniendo en cuenta que todos los demás proveedores que envían correo electrónico en nuestro nombre siguen recomendando el uso de SPF, incluido G-Suite.
Entonces, ¿qué está pasando? ¿El SPF es inútil en 2020? ¿Debería preocuparme por no tener los servidores de Mailchimp en nuestro registro SPF y debería considerar eliminar el registro SPF por completo?
Respuesta1
Como @jornaneSeñala, Mailchimp utiliza su propio dominio comoremitente del sobre, lo que hace que el registro SPF del dominio del cliente sea irrelevante para su esquema de entrega. Esto hace que la firma DKIM sea indispensable para una alineación DMARC adecuada, ya que no habría alineación por parte del SPF.
Sin embargo, decir que SPF es heredado es una afirmación extraña considerando que tienen SPF configurado para su propio dominio mailchimp.com. A pesar de no estar documentados por ellos mismos, según el artículo de DMARCLY sobreCómo configurar SPF y DKIM para Mailchimp(actualizado el 9 de diciembre de 2020) el SPF correcto incluido para Mailchimp sería:
include:servers.mcsv.net
Este registro SPF todavía está vigente y supuestamente tiene las direcciones IP que usan:
"v=spf1 ip4:205.201.128.0/20 ip4:198.2.128.0/18 ip4:148.105.8.0/21 ?all"
Creo que esta afirmación podría provenir de la perspectiva sesgada que tiene la industria de entrega de correo electrónico sobre SPF, DKIM y DMARC. En su retórica, esas tecnologías tienen que ver con una mejor reputación o una entrega optimizada. Sólo los ven como herramientas para hacer llegar el mensaje a la bandeja de entrada, pero no como la otra cara de la moneda que impide que otros falsifiquen el correo de su dominio. Ese es casi siempre el caso cuando una empresa de este tipo intenta explicar los beneficios de esas tecnologías. ¡Pero esos no son los beneficios reales ni la razón por la que se inventaron en primer lugar!
Mailchimp podría haber llevado este pensamiento más allá: "si SPF no nos ayuda a entregar nuestro correo, debe ser inútil". En mi opinión, no tienen ni idea de si realmente hicieron tal afirmación. Este tipo de mentalidad es perjudicial, ya que podría incluso impedir que sus clientes avancen hacia una política DMARC más estricta. Esto se explica mejor por la observación de que Mailchimp está utilizando su propio dominio como remitente del sobre.
Respuesta2
Es un poco complicado debido a la historia del SPF, pero:
- MailChimp tiene razón técnicamente sobre el
SPFregistro(en lugar de proporcionar unTXTregistro con una política SPF). - Es casi seguro que no le están sugiriendo que deje de usar SPF por completo.
Las implementaciones originales de SPF buscaban TXTregistros DNS en el propio dominio que se ajustaran a un formato específico (comenzando v=spf1y conteniendo el resto de una política SPF válida). En 2005, la IANA asignó el tipo de registro de recursos 99 para un SPFregistro específico para reemplazarlo teóricamente y proporcionar una política SPF (con la ventaja teórica de que puede consultar un SPFregistro específicamente en lugar de tener que consultar todos TXTlos registros y luego analizarlos todos). para ver si hay una póliza válida).
Sin embargo, por motivos de compatibilidad, el uso real del SPFtipo de registro dedicado nunca fue muy elevado. Los operadores de red aún tenían que definir un TXTregistro con la política SPF para que las implementaciones heredadas de SPF aún funcionaran, y los implementadores tenían que apoyar la búsqueda de la política SPF en un TXTregistro para mantener la compatibilidad con las redes existentes, por lo que ninguna de las partes tenía ningún incentivo real para cambie exclusivamente al uso del SPFtipo de registro dedicado, especialmente porque la mayoría de los dominios no tienen grandes volúmenes de TXTregistros y, por lo tanto, analizar una política a partir de ellos es generalmente bastante rápido.
Como resultado de esa mala aceptación, el grupo de trabajo SPF decidió en 2014 dejar de admitir oficialmente el SPFtipo de registro dedicado porque en realidad no aportaba nada, no se usaba realmente y, en algunos casos, causaba confusión (como la confusión aquí).
Por lo tanto, laSPF registroDe hecho, está en desuso, pero proporciona un SPF.políticaen un TXTregistro sigue siendo muy recomendable, incluso si su dominio en realidad no maneja correo electrónico (en cuyo caso debe definir una política de v=spf1 -ALL).
Respuesta3
La forma en que MailChimp envía correos no es compatible con SPF, por lo que tiene sentido que lo desaprueben,en el contexto de que envíen en su nombre la forma en que lo hacen.
MailChimp quiere manejar los rebotes por usted, lo que requiere que establezcan la dirección de remitente del sobre en su propio dominio, lo que significa que el SPF debe verificarse con su dominio, no con el suyo. Por lo tanto, no tiene sentido que le pidan que los permita en su póliza SPF. Esta es también la razón por la que algunos clientes muestran "vía mailchimp" en el campo De.
SPF no está obsoleto, pero no es adecuado para listas de correo y casos similares. DKIM funciona en el encabezado De y está firmado criptográficamente por el remitente, por lo que es más resistente a los reenviadores y más fácil de delegar en terceros. Tiene más sentido que MailChimp se centre en eso.
Para sus propios servidores de correo saliente, debe mantener SPF, DKIM y DMARC (el tercero lo obtiene esencialmente gratis si hace bien los dos primeros)
Respuesta4
Además de las otras respuestas (en su mayoría correctas), hay otro punto a considerar con respecto al SPF.
Cuando utiliza servicios externos para enviar correo electrónico en su nombre, o tiene su correo electrónico configurado en un servicio en la nube y tiene SPF implementado, debe incluir esos registros SPF de servicios en el suyo.
La mayoría de esos servicios ahora utilizan grandes proveedores de nube y, por lo tanto, su propio registro SPF incluye bloques realmente enormes de IP: básicamente todos esos espacios de IP de proveedores gigantes.
Básicamente, eso significa que usted permite explícitamente que miles de millones de direcciones IP envíen correo electrónico en su nombre, y los spammers usan esas direcciones IP (ya sea enviando correo electrónico desde máquinas virtuales comprometidas en la nube, pirateando cuentas de correo electrónico M365 o generando máquinas virtuales temporales en esos servicios).
¡Así que terminas permitiendo explícitamente a los spammers enviar correos electrónicos en tu nombre!
Debido a esto, el SPF por sí solo es peor que ningún SPF.
Ahora es necesario utilizar DKIM y DMARC para contrarrestar este fenómeno.