PermError do Office365 SPF: muitas pesquisas de DNS

Question

Estamos migrando de uma plataforma de correspondência hospedada para o Office365 for Businesses. Tudo correu bem, exceto pelo registro SPF. No momento, temos v=spf1 a mx include:spf.mtasv.net -all como registro TXT, mas o Office365 também tem que permitir v=spf1 include:spf.protection.outlook.com -all . Então, eu fui em frente e os fundei em: v=spf1 a mx include:spf.mtasv.net include:spf.protection.outlook.com -all . Ao verificar este registro SPF no domínio de studentkickoff.be, isso resulta em PermError SPF Permanent Error: Too many DNS lookups .

A minha pergunta é a seguinte: Como resolvo este erro? Eu sei que posso substituir alguns registros com seu equivalente ip4 , mas ao fazer isso, o solucionador de problemas online do Office365 continuou reclamando que o registro não foi encontrado:

Obrigado antecipadamente!

    

Answer 1

Além de tudo o que já foi dito, vamos nos concentrar nisso:

My question is the following: How do I work around this error? I know I can replace some  
records with their ip4 equivalent, but when doing this, the online troubleshooter of  
Office365 kept complaining that the record was not found:

Recentemente encontrei o mesmo problema.
Embora esteja documentado que ele deve funcionar ( link ) nunca poderíamos obtê-lo para verificar com um registro diferente.
Não importa se era a:some.host.com ou ip4:127.0.0.1 , sempre reclamava que o registro SPF estava errado / faltando.
No final, alteramos o registro para v=spf1 include:spf.protection.outlook.com -all para tornar o assistente de verificação feliz e ajustamos novamente para o registro real.

    

Answer 2

Resposta retirada de SO aqui Autor: Swift . Adaptado para ajustar a questão. Além disso, leia aqui em geral Material SPF.

Começamos com:

v=spf1 a mx include:_spf.google.com include:servers.mcsv.net include:sendgrid.net ~all

Recebemos um total de 10 pesquisas antes de lançarmos o erro Too many DNS lookups :

  2 (Initial TXT & SPF Lookups)
  2 (a & mx Lookups)
  1 (_spf.google.com)
  1 (servers.mcsv.net)
 +1 (sendgrid.net)
 -----------------
  7 Lookups

Portanto, mesmo sem seguir os registros SPF incluídos, temos 7 pesquisas.

Agora, vamos mergulhar um nível mais profundo.

1. _spf.google.com

O registro do Google SPF é avaliado como:

v=spf1 include:_netblocks.google.com include:_netblocks6.google.com ?all

Cada um dos quais resolve os seguintes valores:

# _netblocks.google.com
v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:173.194.0.0/16 ?all

# _netblocks6.google.com
v=spf1 ip6:2607:f8b0:4000::/36 ip6:2a00:1450:4000::/36 ?all

Assim, o google nos fornece mais duas pesquisas, elevando o total para 9 pesquisas .

2. servers.mcsv.net

O Mailchimp é um pouco complicado porque adiciona 3 pesquisas adicionais:

v=spf1 include:spf1.mcsv.net include:spf2.mcsv.net include:spf.mandrillapp.com ?all

Eu imagino que, dependendo do que você está enviando através do Mailchimp, você pode remover um ou dois desses registros (mas você mesmo terá que avaliar isso).

De qualquer forma, aqueles resolvem o seguinte:

# spf1.mcsv.net
v=spf1 ip4:207.97.237.194/31 ip4:207.97.238.88/29 ip4:207.97.240.168/29 ip4:69.20.10.80/29 ip4:69.20.41.72/27 ip4:74.205.22.1/27 ip4:69.20.90.0/26 ?all

# spf2.mcsv.net
v=spf1 ip4:204.232.163.0/24 ip4:72.26.195.64/27 ip4:74.63.47.96/27 ip4:173.231.138.192/27 ip4:173.231.139.0/24 ip4:173.231.176.0/20 ip4:205.201.128.0/24 ?all

# spf.mandrillapp.com
v=spf1 ip4:205.201.136.0/24 ip4:205.201.137.0/24 ?all

Isso nos leva a um total de 12 pesquisas (que já ultrapassam dois limites).

2. sendgrid.net

O SendGrid acaba sendo o menor número de pesquisas adicionais para nós.

v=spf1 ip4:208.115.214.0/24 ip4:74.63.202.0/24 ip4:75.126.200.128/27 ip4:75.126.253.0/24 ip4:67.228.50.32/27 ip4:174.36.80.208/28 ip4:174.36.92.96/27 ip4:69.162.98.0/24 ip4:74.63.194.0/24 ip4:74.63.234.0/24 ip4:74.63.235.0/24 include:sendgrid.biz ~all

Portanto, a única pesquisa adicional aqui é sendgrid.biz , que é avaliada como:

v=spf1 ip4:208.115.235.0/24 ip4:74.63.231.0/24 ip4:74.63.247.0/24 ip4:74.63.236.0/24 ip4:208.115.239.0/24 ip4:173.193.132.0/24 ip4:173.193.133.0/24 ip4:208.117.48.0/20 ip4:50.31.32.0/19 ip4:198.37.144.0/20 ~all

Isso eleva nosso total para até 14 pesquisas.

Portanto, nosso total geral é de 14 pesquisas . Precisamos reduzir o número para 10. Eu delineei algumas opções abaixo, você pode precisar usar mais de uma delas para resolver o problema.

1. Inclua diretamente alguns dos registros spf redirecionados. Agora que sabemos para quais servidores os registros spf redirecionam, você pode cortar o intermediário e incluí-los diretamente. Observação: Se qualquer um dos serviços acabar alterando seus registros SPF, você terá que passar pelo processo de atualizar o seu manualmente.

2. Remova alguns dos serviços que você está usando. Não tenho certeza qual é o seu caso de uso para ter todos esses serviços, mas definitivamente há alguma sobreposição que você pode usar. Por exemplo, o SendGrid oferece suporte a (1) email de saída transacional, (2) e-mails de newsletter / marketing e (3) e-mails recebidos. Portanto, pode haver alguma redundância redutível.

3. Remova o registro MX se ele for redundante. Dependendo da sua configuração, a pesquisa do MX pode ser redundante.

Answer 3

Você pode apenas usar um serviço SPF Proxy como spfproxy.org. Então você não precisa achatar as entradas de DNS em endereços IP ou até mesmo mexer em subdomínios. Você acabou de configurar o SPF Proxy e ele fará todas as pesquisas no backend. É a única maneira que encontrei para resolver este problema elegantemente.

    

Answer 4

Posso ver isso, este é um ótimo motivo para criar subdomínios especificamente para envio por terceiros:

Se você tiver remetentes de terceiros diferentes lidando com coisas diferentes que podem ser inscritas, a configuração de um subdomínio separado pode ser uma ótima maneira de gerenciá-lo:

Os nomes dos subdomínios podem ser baseados no que está sendo enviado:

• NewsLetterName.Example.com para o boletim informativo enviado por meio de terceiros pode ter um registro específico para esse terceiro.
• Updates.Example.com para quando as "atualizações" foram inscritas.
• Support.Example.com para quando "Suporte" é fornecido por terceiros.

Ou os nomes de subdomínio podem ser baseados no remetente de terceiros:

• ccMail.Example.com para emails de contato constante
• mcMail.Example.com para emails do Chimp de e-mail
• zendeskMail.Example.com para e-mails do ZendDesk

Eu realmente gosto dessa ideia agora que eu mapeei isso! Eu vou tentar isso sozinho. Isso significará configurar endereços de e-mail adicionais para esses subdomínios, mas isso permitirá uma organização mais fácil dos e-mails.