O registro SPF do Office365 tem muitas pesquisas

Por algumas razões administrativas totalmente ridículas, temos um domínio dividido com uma caixa de correio no Office365, o que exige que adicionemos include:outlook.comao nosso registro SPF. O problema é que somente essa regra exige nove pesquisas de DNS com o máximo de 10.

Sério, é horrível. Basta olhar para ele:

v=spf1
include:spf-a.outlook.com
include:spf-b.outlook.com
ip4:157.55.9.128/25
include:spfa.bigfish.com
include:spfb.bigfish.com
include:spfc.bigfish.com
include:spf-a.hotmail.com
include:_spf-ssg-b.microsoft.com
include:_spf-ssg-c.microsoft.com
~all

Dado que nós temos nosso próprio sistema de correio grande ish precisamos ter regras para a, mx, include:_spf1.mydomain.come include:_spf2.mydomain.comque nos coloca em pesquisas de 13 de DNS que causas PERMERRORs com validadores SPF rigorosos e validação completamente não confiáveis / imprevisível com não-rígidas / validadores mal implementadas .

É possível, de alguma maneira, eliminar três dessas include:regras do registro outlook.com inchado, mas ainda cobrir os servidores usados pelo O365?

Editar:

Os comentaristas mencionaram que devemos simplesmente usar o spf.protection.outlook.comregistro mais curto . Embora isso seja uma novidade para mim, e seja mais curto, é apenas um registro mais curto:

spf.protection.outlook.com
  include:spf-a.outlook.com
  include:spf-b.outlook.com
  include:spf-c.outlook.com
  include:spf.messaging.microsoft.com
    include:spfa.frontbridge.com
    include:spfb.frontbridge.com
    include:spfc.frontbridge.com

Editar²

Suponho que tecnicamente possamos reduzir isso:

v=spf1 a mx include:_spf1.mydomain.com include:_spf2.mydomain.com include:spf-a.outlook.com include:spf-b.outlook.com include:spf-c.outlook.com include:spfa.frontbridge.com include:spfb.frontbridge.com include:spfc.frontbridge.com ~all

mas os possíveis problemas que vejo com isso são:

Precisamos manter a par de todas as alterações nos pais spf.protection.outlook.come nos spf.messaging.microsoft.comregistros. Se alguma coisa for alterada ou [proibida a Deus], teremos que atualizar manualmente a nossa para refletir isso.
Com o nosso nome de domínio real, o comprimento do registro é de 260 caracteres, o que exigiria duas seqüências para o registro TXT, e sinceramente não confio que todos os clientes DNS e resolvedores de SPF aceitem corretamente um registro TXT com mais de 255 bytes .

email spf microsoft-office-365

— Sammitch
fonte

Você não pode apenas adicionar spf.protection.outlook.com para todo o Office365? technet.microsoft.com/en-us/library/hh852557.aspx

— Cold T

Por que o registro SPF do O365 não é o registro atual simples? include:spf.protection.outlook.com (curioso para ser honesto, nunca vi o que você tem a configuração ... se o portal dizer-lhe para colocar tudo isso?)

— TheCleaner

Toda a documentação que encontrei disse usar include:outlook.com, então spf.protection.outlook.comsão novidades para mim. O problema permanece, pois esse registro ainda requer 8 pesquisas e eu preciso reduzi-lo para 6 ou menos.

— 31513 Sammitch

Não se esqueça de contar as duas pesquisas de PTR em 'spfa.frontbridge.com'. De acordo com a RFC 7208, eles também contam para o limite de 10 pesquisas. :(

— Martijn Heemels

Respostas:

Em uma data recente, a Microsoft "corrigiu" esse problema se livrando de todos os sub-registros e usando 2 ou 3 registros "ptr":

$ dig TXT spf.protection.outlook.com
spf.protection.outlook.com. IN  TXT "v=spf1 ptr:protection.outlook.com ptr:o365filtering.com -all"

$ dig TXT spf.messaging.microsoft.com
spf.messaging.microsoft.com. IN TXT "v=spf1 ptr:protection.outlook.com ptr:messaging.microsoft.com ptr:o365filtering.com -all"

Aqui está o problema: embora isso ajude os clientes do Office 365 a evitar ficar abaixo do PermError "Muitas pesquisas" ... faz isso forçando todos os servidores de correio do mundo a fazer pesquisas de PTR (caras) para todos os endereços IP que se conectam a eles.

De acordo com a especificação SPF :

Se possível, evite usar esse mecanismo no seu registro SPF, pois resultará em um número maior de pesquisas de DNS caras.

— John Hart
fonte

@ChrisS - Também pensei nisso, no entanto, a especificação SPF afirma que o mecanismo "ptr:" deve ser verificado nos dois sentidos do DNS recíproco - o servidor de email de recebimento deve primeiro fazer um PTR no IP e depois um A o nome do host resultante e o IP devem estar listados no registro A. Portanto, não acho que seja uma falha de segurança, pelo menos não para implementar implementações de SPF.

— John Hart

Ah, bom encontrar lá. Eu não estava ciente da ressalva.

— Chris S

Também encontramos esse problema. A Microsoft está 'encorajando' você a usar o Office 365 exclusivamente para seu email, já que não há espaço para adicionar novos itens.

Nosso modo de contornar isso era duplo.

Primeiro, podemos analisar as pesquisas de DNS adicionando as outras entradas como entradas IPv4 explícitas. Isso nos permite adicionar vários IPs explícitos antes deinclude:outlook.com

Em segundo lugar, configuramos um subdomínio separado em nosso domínio principal para o material do Office 365. Dessa forma, os emails @ foo.company.com obtêm o SPF do Office 365 e os emails @ comapny.com obtêm nosso SPF normal. Não é perfeito, mas felizmente os lugares em que usamos o Office 365 podem usar endereços de email no subdomínio, e não no domínio base.

— Steve Shipway
fonte