¿Por qué los administradores utilizan principalmente +ajunto +mxen los registros SPF? Este es el ejemplo:
@ 10800 IN TXT "v=spf1 +a +mx -all"
¿No es suficiente usar solo +mxparámetros, por ejemplo:
@ 10800 IN TXT "v=spf1 +mx -all"
Pensé que la tarea del registro MX es enviar correo electrónico y no la del registro A. ¿Alguien puede explicar el escenario por qué alguien lo usaría +aentonces?
Respuesta1
Francamente porque han copiado la configuración de algún tutorial o configuración de ejemplo sin conocer los principios básicos del SPF. A veces se desea que, por ejemplo, tanto un servidor web ena como entranteintercambios de correo mxTambién se utilizan para enviar correo, pero no siempre.
Es mejor favorecer mecanismos con menos consultas DNS adicionales: ip4/ ip6una ay aotra vez mx(RFC 7208, 10.1.1) E incluso si, para facilitar la administración (10.1.2), ase elige el mecanismo, no siempre es a mxo a, pero por ejemplo a:relay.example.com.
Respuesta2
La tarea de los anfitriones enumerados en los MXregistros esrecibircorreo electrónico, no necesariamente aentregarcorreo electrónico.
Es completamente válido (y bastante común, particularmente para operaciones más grandes) tener una configuración asimétrica donde los hosts que manejan el correo electrónico entrante y saliente no son los mismos.
Es decir, no hay garantía de que mx(aka +mx) o a(aka +a) en SPF sean relevantes para especificar qué hosts se espera queentregarcorreo electrónico.
Como ejemplo, si no ejecuta sus propios servidores de correo, tal vez algo así v=spf1 include:spf.majoremailserviceprovider.example -allsería más relevante.
Para abordar directamente la pregunta sobre por qué la a mxcombinación en particular parece estar sobrerrepresentada en los registros SPF, supongo que esta situación se reduce a que demasiados administradores agregan registros SPF sin comprender los conceptos del SPF lo suficientemente bien como para juzgar qué incluir en su política. , en lugar de simplemente copiar y pegar algunos ejemplos construidos arbitrariamente.
Respuesta3
Estoy de acuerdo con las otras respuestas, que +a +mxprobablemente sea un antiidioma culto a la carga.
Con respecto a cuándo usaría +a, el documento RFC responde esto ensección 10.1.2:
La publicación de registros SPF para hosts individuales también es una buena práctica. El nombre de host generalmente es la identidad utilizada en el comando 5321.HELO/.EHLO. En el caso de mensajes con un 5321.MailFrom nulo, este se utiliza como dominio para las comprobaciones de SPF 5321.MailFrom, además de utilizarse en las comprobaciones de SPF basadas en 5321.HELO/.EHLO. El registro SPF estándar para un host individual que participa en el procesamiento de correo es:
relay.example.com. IN TXT "v=spf1 a -all"
Por ejemplo, publico un registro de este tipo para mi servidor de correo mail.mydomain.org, en beneficio de los verificadores que verifican primero la identidad de HELO. (Por supuesto, también publico el v=spf1 mx -allregistro habitual en el mydomain.orgpropio dominio de correo).
Respuesta4
Podría ser una ventaja en cuanto a duración, aunque es muy poco probable que ésta sea la verdadera motivación.
Tenga en cuenta que el registro TXT puede aumentar de tamaño hasta el punto de que un solo paquete UDP sea demasiado pequeño. Entonces, la solicitud se envía nuevamente en TCP y la respuesta son múltiples paquetes TCP y el tiempo de configuración del protocolo de enlace asociado.
Mediante un uso cuidadoso de las solicitudes A y MX, se podrían obtener dos respuestas UDP de ~1500 bytes para el registro SPF, una para el A y otra para el MX, así como los ~1400 bytes restantes para todos los registros TXT.
Esto supone que tiene suficientes "cosas" autorizadas en su registro SPF para superar los 3000 bytes. Las inclusiones también pueden solucionar las restricciones de longitud, pero no estoy seguro de si cada una sería una solicitud UDP separada o una única sesión de solicitud TCP.