Os registros SPF são legados?

Question

Sou responsável por um domínio que possui um registro SPF conforme recomendado por vários outros serviços que enviam mensagens em nome deste domínio.

Ao configurar o Mailchimp, fiquei surpreso ao não encontrar nenhuma documentação sobre a configuração SPF recomendada pelo Mailchimp. Quando entrei em contato com o suporte, fui informado que o Mailchimp basicamente considera o SPF legado, não usa o SPF há mais de 6 meses e acha que ter o registro não ajuda nem atrapalha. Chegando ao ponto de sugerir que eu exclua completamente nosso registro SPF.

Não duvido que Mailchimp saiba infinitamente mais sobre capacidade de entrega de e-mail do que eu. Mas acho surpreendente que o Mailchimp não publique nada explicando essa decisão, especialmente considerando que todos os outros provedores que enviam e-mails em nosso nome continuam recomendando o uso do SPF, incluindo o G-Suite.

Então, o que está acontecendo, o SPF é inútil em 2020, devo me preocupar em não ter os servidores do Mailchimp em nosso registro SPF e devo considerar a exclusão completa do registro SPF?

Answer 1

Como @jornaneaponta, o Mailchimp usa seu próprio domínio comoremetente do envelope, tornando o registro SPF do domínio do cliente irrelevante para seu esquema de entrega. Isso torna a assinatura DKIM indispensável para um alinhamento adequado do DMARC, pois não haveria alinhamento do lado SPF.

No entanto, dizer que o SPF é legado é uma afirmação estranha, considerando que eles têm o SPF configurado para seu próprio domínio mailchimp.com. Apesar de não documentado por si, de acordo com o artigo do DMARCLY sobreComo configurar SPF e DKIM para Mailchimp(atualizado em 9 de dezembro de 2020) o SPF correto incluído para Mailchimp seria:

include:servers.mcsv.net

Este registro SPF ainda está em vigor e supostamente contém os endereços IP que eles usam:

"v=spf1 ip4:205.201.128.0/20 ip4:198.2.128.0/18 ip4:148.105.8.0/21 ?all"

Acho que esta afirmação pode vir da perspectiva tendenciosa que a indústria de entrega de e-mail tem sobre SPF, DKIM e DMARC. Na sua retórica, essas tecnologias têm tudo a ver com melhor reputação ou entrega otimizada. Eles os veem apenas como ferramentas para enviar a mensagem para a caixa de entrada, mas não como o outro lado da moeda que impede que outras pessoas falsifiquem mensagens do seu domínio. Esse é quase sempre o caso quando tal empresa tenta explicar os benefícios dessas tecnologias. Mas esses não são os benefícios reais nem a razão pela qual foram inventados!

Mailchimp poderia ter levado esse pensamento adiante: “se o SPF não nos ajudar a entregar nossa correspondência, ela deve ser inútil”. Na minha opinião, eles não têm ideia se realmente fizeram tal afirmação. Este tipo de mentalidade é prejudicial, pois pode até impedir que os seus clientes adotem uma política DMARC mais rigorosa. Isso foi melhor explicado pela observação de que o Mailchimp está usando seu próprio domínio como remetente do envelope.

Answer 2

É um pouco complicado devido à história do FPS, mas:

• MailChimp está tecnicamente correto sobre oSPF registroem si (em vez de fornecer um TXTregistro com uma política SPF).
• É quase certo que eles não estão sugerindo que você pare completamente de usar o FPS.

---

As implementações originais do SPF procuravam TXTregistros DNS no próprio domínio ajustando-se a um formato específico (começando v=spf1e contendo o restante de uma política SPF válida). Em 2005, a IANA atribuiu o tipo de registro de recurso 99 para um SPFregistro específico para, teoricamente, substituí-lo por fornecer uma política SPF (com a vantagem teórica de que você pode consultar um SPFregistro especificamente, em vez de ter que consultar todos TXTos registros e depois analisar todos eles para ver se existe uma política válida).

No entanto, por razões de compatibilidade, a utilização real do SPFtipo de registo dedicado nunca foi muito elevada. Os operadores de rede ainda tiveram que definir um TXTregistro com a política SPF para que as implementações legadas do SPF ainda funcionassem, e os implementadores tiveram que apoiar a busca da política SPF em um TXTregistro para manter a compatibilidade com as redes existentes, de modo que nenhum dos lados tivesse qualquer incentivo real para mude exclusivamente para o uso do SPFtipo de registro dedicado, especialmente porque a maioria dos domínios não possui grandes volumes de TXTregistros e, portanto, analisar uma política desses geralmente é bastante rápido.

Como resultado dessa má aceitação, o grupo de trabalho do SPF decidiu em 2014 abandonar oficialmente o suporte para o SPFtipo de registro dedicado porque ele não estava realmente contribuindo com nada, não era realmente usado e, em alguns casos, causava confusão (como a confusão aqui).

Assim, oSPF registroestá realmente obsoleto, mas fornece um SPFpolíticaem um TXTregistro ainda é altamente recomendado, mesmo que seu domínio não administre e-mails (nesse caso, você deve definir uma política de v=spf1 -ALL).

Answer 3

A forma como o MailChimp envia correspondências não é compatível com SPF, então faz sentido para eles desativá-lo,no contexto de eles enviarem em seu nome da maneira que fazem.

MailChimp deseja lidar com devoluções para você, o que exige que eles definam o endereço Envelope From para seu próprio domínio, o que significa que o SPF deve ser verificado em relação ao domínio deles, não ao seu. Portanto, não faz sentido que eles peçam que você os permita em sua política de SPF. É também por isso que alguns clientes mostram “via mailchimp” no campo De.

O SPF não está obsoleto, mas não é adequado para listas de discussão e casos semelhantes. O DKIM funciona no cabeçalho From e é assinado criptograficamente pelo remetente, por isso é mais resistente aos encaminhadores e mais fácil de delegar a terceiros. Faz mais sentido que o MailChimp se concentre nisso.

Para seus próprios servidores de e-mail de saída, você deve manter SPF, DKIM e DMARC (o terceiro você obtém essencialmente de graça fazendo os dois primeiros corretamente)

Answer 4

Além das outras respostas (em sua maioria corretas), há outro ponto a considerar em relação ao FPS.

Quando você usa serviços externos para enviar e-mail em seu nome ou configura seu e-mail em um serviço de nuvem e tem o SPF instalado, você precisa incluir esses registros SPF de serviços em seus próprios.

A maioria desses serviços agora usa grandes provedores de nuvem e, portanto, seu próprio registro SPF inclui blocos realmente enormes de IP - basicamente todos esses espaços IP de provedores gigantes.

Isso significa basicamente que você permite explicitamente que bilhões de endereços IP enviem e-mails em seu nome, e os spammers usam esses endereços IP (seja enviando e-mails de VMs comprometidas na nuvem, invadindo contas de e-mail M365 ou gerando VMs temporárias nesses serviços).

Então você acaba permitindo explicitamente que spammers enviem e-mails em seu nome!

Devido a este FPS por si só é pior do que nenhum FPS.

É agora necessário utilizar DKIM e DMARC para contrariar este fenómeno.