El registro de Office365 SPF tiene demasiadas búsquedas

Por algunas razones administrativas completamente ridículas, tenemos un dominio dividido con un buzón en Office365 que requiere que agreguemos include:outlook.coma nuestro registro SPF. El problema con esto es que esa regla sola requiere nueve búsquedas DNS del máximo de 10.

En serio, es horrible. Solo míralo:

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 tenemos nuestro propio sistema de correo de gran ish tenemos que tener reglas para a, mx, include:_spf1.mydomain.com, y include:_spf2.mydomain.comque nos sitúa en las búsquedas de 13 DNS que causa PERMERRORs con estrictas validadores SPF, y la validación completamente fiable / impredecible con no estrictas validadores / mal implementadas .

¿Es posible eliminar de alguna manera 3 de esas include:reglas del registro hinchado de outlook.com, pero aún así cubrir los servidores utilizados por O365?

Editar:

Los comentaristas han mencionado que simplemente deberíamos usar el spf.protection.outlook.comregistro más corto . Si bien eso es nuevo para mí, y es más corto, solo es un registro más corto:

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²

Supongo que técnicamente podemos reducir esto a:

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

pero los posibles problemas que veo con esto son:

Necesitamos estar al tanto de cualquier cambio en el padre spf.protection.outlook.comy los spf.messaging.microsoft.comregistros. Si se cambia algo o se agrega [Dios no lo permita], tendríamos que actualizar el nuestro manualmente para reflejarlo.
Con nuestro nombre de dominio real, la longitud del registro es de 260 caracteres, lo que requeriría 2 cadenas para el registro TXT, y sinceramente, no confío en que todos los clientes DNS y solucionadores SPF acepten correctamente un registro TXT de más de 255 bytes .

email spf microsoft-office-365

— Sammitch
fuente

¿No puede simplemente agregar spf.protection.outlook.com para todo Office365? technet.microsoft.com/en-us/library/hh852557.aspx

— Cold T

¿Por qué el registro SPF para O365 no es el actual simple? include:spf.protection.outlook.com (Curioso para ser sincero, nunca he visto lo que has configurado ... ¿el portal te dijo que

— pusieras

Toda la documentación que encontré decía que debía usarla include:outlook.com, así que spf.protection.outlook.comes una novedad para mí. Sin embargo, el problema persiste, ya que ese registro todavía requiere 8 búsquedas, y necesito reducirlo a 6 o menos.

— Sammitch

No olvide contar las dos búsquedas PTR en 'spfa.frontbridge.com'. De acuerdo con RFC 7208, también cuentan para el límite de 10 búsquedas. :(

— Martijn Heemels

Respuestas:

A partir de una fecha reciente, Microsoft ha "solucionado" este problema eliminando todos los sub-registros y utilizando 2 o 3 registros "ptr" en su lugar:

$ 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"

Este es el problema: si bien esto ayudará a los clientes de Office 365 a evitar mantenerse por debajo del PermError "Demasiadas búsquedas" ... lo hace obligando a todos los servidores de correo del mundo a realizar búsquedas PTR (caras) para cada dirección IP que se conecta a ellas.

Por la especificación SPF :

Si es posible, debe evitar usar este mecanismo en su registro SPF, ya que dará como resultado una mayor cantidad de costosas búsquedas de DNS.

— John Hart
fuente

@ChrisS: también pensé en eso, sin embargo, la especificación SPF establece que el mecanismo "ptr:" debe verificarse en ambos sentidos para el DNS recíproco: el servidor de correo receptor primero debe hacer un PTR en la IP y luego hacer una A en el nombre de host resultante y la IP deben aparecer en el registro A. Así que no creo que sea un agujero de seguridad, al menos no para las implementaciones de SPF conformes.

— John Hart

Ah, buen hallazgo allí. No estaba al tanto de la advertencia.

— Chris S

También hemos encontrado este problema. Microsoft lo 'anima' a usar Office 365 exclusivamente para su correo electrónico, ya que no hay espacio para agregar nuevos elementos.

La forma en que lo rodeamos fue doble.

Primero, podemos reducir las búsquedas de DNS agregando las otras entradas como entradas explícitas de IPv4. Esto nos permite agregar una cantidad de IP explícitas antes deinclude:outlook.com

En segundo lugar, configuramos un subdominio separado en nuestro dominio principal para las cosas de Office 365. De esta manera, los correos electrónicos @ foo.company.com obtienen el SPF de Office 365, y los correos electrónicos @ comapny.com obtienen nuestro SPF normal. No es perfecto, pero afortunadamente los lugares donde hemos usado Office 365 pueden usar direcciones de correo electrónico dentro del subdominio en lugar del dominio base.

— Steve Shipway
fuente