Soluções alternativas para o limite máximo de termos interativos de DNS excedido no registro SPF?

Como provedor de hospedagem, enviamos e-mails em nome de nossos clientes, para ajudá-los a configurar registros de e-mail DKIM e SPF em seu DNS para obter a entrega de e-mails correta. Nós os aconselhamos a usar o http://mail-tester.com para testar se eles não perderam nada, e eu gosto muito dessa ferramenta.

Um problema que encontramos algumas vezes, e não tenho certeza, é o "limite" de DNS no registro SPF com base no nome de domínio. Então, se você tem isso:

v=spf1 a include:aspmx.googlemail.com include:campaignmonitor.com include:authsmtp.com include:mail.zendesk.com include:salesforce.com include:_hostedspf.discourse.org ~all

Você terá

example.com ... campaignmonitor.com: Maximum DNS-interactive term limit (10) exceeded

Igual a:

Eu tenho algumas perguntas sobre isso.

1. Eu conto seis nomes de domínio aqui, não 10, então por que ele está atingindo "dez" solicitações de DNS aqui? Respondeu aqui

2. Esse termo interativo de 10 DNS limita um aviso ou um erro real ? por exemplo, devemos nos importar? Está incomodando um pouco nossos clientes e eles nos enviam um email para suporte. Respondeu aqui

3. Esse termo interativo de 10 DNS limita um problema real na web de hoje? Como você pode ver, esse cliente tem muitos serviços enviando email para eles e todos são legítimos. Talvez esse limite de DNS tenha sido definido no ano de 2000 quando delegar serviços de email como esse não era comum?

Sim, podemos fazer com que nossos clientes alterem a inclusão para IPs no registro SPF, mas isso nos impede de alterar os IPs, mas um monte de coisas dos clientes será interrompido. Realmente não quero fazer isso ..

Quais soluções alternativas existem para isso?

1. Principalmente já respondidas, observe que a inclusão do Google está incorreta . Você deseja usar _spf.google.comou sofrer uma penalidade pelo redirecionamento:

   ○ → host -t txt aspmx.googlemail.com
   aspmx.googlemail.com descriptive text "v=spf1 redirect=_spf.google.com"
   
   ○ → host -t txt _spf.google.com
   _spf.google.com descriptive text "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
   

Essa pesquisa consumirá 5/10 por si só - 4/10 ainda é uma porcaria, mas 20% menos.

2. Ele interromperá o processamento e retornará um erro permanente - cabe ao mecanismo que usa o SPF decidir como deseja tratar um erro permanente.

3. Sim - sem os limites de processamento, os mecanismos SPF poderiam ser usados ​​como um amplificador de DoS contra terceiros ou terceiros.

Como solução alternativa, os emails podem vir de um subdomínio da propriedade principal - community.largecorporation.compor exemplo.

1. Supondo que as redundâncias (como várias referências _spf.google.come os registros a que se refere) sejam contadas apenas uma vez, conto 17 pesquisas a partir do ponto em que você já consultou o registro inicial. (Ver abaixo.)

2. Ele se recusa a procurar todos os registros necessários para avaliar seu registro SPF porque seria "muito trabalho". Presumivelmente, isso significa que ele tratará seu domínio como se não tivesse registro SPF (ou possivelmente o rejeite). A especificação diz que isso resulta em permerror , o que deixa bastante aberto para o destinatário decidir o que fazer .

3. Eu acho que o abuso tem aumentado e não diminuído, geralmente. Esse limite parece ter como objetivo impedir domínios de remetentes abusivos que, de outra forma, podem sobrecarregar o destinatário com enormes cadeias de SPF, potencialmente levando ao DoS.

Acho que, embora a terceirização de email seja comum, não é tão comum terceirizar email para seis provedores diferentes. Você precisará otimizar o registro SPF de alguma forma.
(Por um lado, a referência a aspmx.googlemail.comparece um desperdício, pois ela é redirecionada imediatamente para um nome diferente.)

<lookup of example.com A>                   #1
$ dig aspmx.googlemail.com TXT +short       #2
"v=spf1 redirect=_spf.google.com"
$ dig _spf.google.com TXT +short            #3
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
$ dig _netblocks.google.com TXT +short      #4
"v=spf1 ip4:64.18.0.0/20 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:173.194.0.0/16 ip4:207.126.144.0/20 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"
$ dig _netblocks2.google.com TXT +short     #5
"v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"
$ dig _netblocks3.google.com TXT +short     #6
"v=spf1 ~all"
$ dig campaignmonitor.com TXT +short        #7
"google-site-verification=HcHoB67Mph6vl5_x4gK5MN9YwN5gMgfZYdNmsP07tIg"
"v=spf1 mx ptr ip4:23.253.29.45/29 ip4:203.65.192.250 include:cmail1.com include:_spf.google.com include:stspg-customer.com ~all"
$ dig cmail1.com TXT +short                 #8
"google-site-verification=HSJ8sL4AxQo0YHHNk9RwDqs0p3lJPGmc1nCrSsmous8"
"mailru-verification: 95d4c6eb0645b43c"
"v=spf1 ip4:103.28.42.0/24 ip4:146.88.28.0/24 ip4:163.47.180.0/22 ip4:203.55.21.0/24 ip4:204.75.142.0/24 ~all"
$ dig stspg-customer.com TXT +short         #9
"v=spf1 ip4:166.78.68.221 ip4:166.78.69.146 ip4:23.253.182.103 ip4:192.237.159.42 ip4:192.237.159.43 ip4:167.89.46.159 ip4:167.89.64.9 ip4:167.89.65.0 ip4:167.89.65.100 ip4:167.89.65.53 -all"
$ dig authsmtp.com TXT +short               #10
"v=spf1 include:spf-a.authsmtp.com include:spf-b.authsmtp.com ~all"
"google-site-verification=skc1TleK4GylDiNZUayfvWWgqZIxmmiRj4KgXlCgB8E"
$ dig spf-a.authsmtp.com TXT +short         #11
"v=spf1 ip4:62.13.128.0/24 ip4:62.13.129.128/25 ip4:62.13.136.0/22 ip4:62.13.140.0/22 ip4:62.13.144.0/22 ip4:62.13.148.0/23 ip4:62.13.150.0/23 ip4:62.13.152.0/23 ~all"
$ dig spf-b.authsmtp.com TXT +short         #12
"v=spf1 ip4:72.52.72.32/28 ip4:64.49.192.16/29 ip4:209.61.188.242 ip4:64.49.192.24 ip4:64.49.192.25 ip4:64.49.210.64/29 ip4:64.49.210.72/30 ip4:64.49.210.76 ip4:64.49.210.77 ip4:64.49.210.78 ~all"
$ dig mail.zendesk.com TXT +short           #13
"v=spf1 ip4:192.161.144.0/20 ip4:185.12.80.0/22 ip4:96.46.150.192/27 ip4:174.137.46.0/24 ~all"
$ dig salesforce.com TXT +short             #14
"adobe-idp-site-verification=898b7dda-16a9-41b7-9b84-22350b35b562"
"MS=749862C9F42827A017A6EA2D147C7E96B3006061"
"MS=ms68630177"
"v=spf1 include:_spf.google.com include:_spfblock.salesforce.com include:_qa.salesforce.com ip4:136.146.208.16/28 ip4:136.146.210.16/28 ip4:136.146.208.240/28 ip4:136.146.210.240/28 ip4:85.222.130.224/28 ip4:136.147.62.224/28 ip4:136.147.46.224/28 mx ~all"
$ dig _spfblock.salesforce.com TXT +short   #15
"v=spf1 ip4:96.43.144.0/20 ip4:182.50.76.0/22 ip4:202.129.242.0/23 ip4:204.14.232.0/21 ip4:62.17.146.128/26 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:68.232.207.20 ip4:207.67.38.45 ip4:198.245.81.1 ip4:198.245.95.4/30 ip4:136.146.128.64/27  ~all"
$ dig _qa.salesforce.com TXT +short         #16
"v=spf1 ip4:199.122.122.176/28 ip4:199.122.121.112/28 ip4:199.122.122.240/28 ip4:66.231.95.0/29 ~all"
$ dig _hostedspf.discourse.org TXT +short   #17
"v=spf1 ip4:64.71.148.0/29 ip6:2001:470:1:3c2::/64 -all"

Como a resposta aceita a uma das perguntas vinculadas deixa claro, muitas das ferramentas subjacentes aos sistemas UNIX realmente impõem esse limite (embora nem todas exatamente da mesma maneira), portanto, qualquer implementação do SPF que as use - que é quase toda no UNIX - aplicará esses limites também. Os sistemas Windows são uma lei em si mesmos, e eu não posso lançar nenhuma luz sobre eles.

A solução alternativa é ter um trabalho cron que avalie sua cadeia de registros SPF terceirizados, expresse todos eles como blocos de rede ipv4 e ipv6 e faça isso em seu registro. Não esqueça o -all.

No seu caso, você deseja que os clientes possam publicar um registro SPF que eles não precisam manter. Uma possibilidade seria fazer com que cada cliente publicasse um registro que contenha redirect=spf.client1.jeffs-company.examplee você faça o trabalho de manter a lista de netblocks em jeffs-company.example.

Talvez esse limite de DNS tenha sido definido no ano de 2000 quando delegar serviços de email como esse não era comum?

O limite dificulta a terceirização do seu email para seis ou sete grandes operações; mas, sem dúvida, se você estiver fazendo isso, para todos os fins práticos, perdeu o controle de seu email de qualquer maneira.

Em algum lugar, algum dia, algum programador sub-subcontratado cuja existência você desconhecia completamente e sobre quem você não tem controle, perderia um ponto-e-vírgula, e uma tonelada de e-mails falsos serão enviados com seu imprimatur SPF diretamente sobre ele. O controle total do seu e-mail requer controle total da sua infraestrutura de e-mail e, na minha opinião, é totalmente inconsistente com tanta terceirização.