Por que os administradores usam principalmente +aos +mxregistros SPF? Este é o exemplo:
@ 10800 IN TXT "v=spf1 +a +mx -all"
Não é suficiente usar apenas +mxparâmetros, por exemplo:
@ 10800 IN TXT "v=spf1 +mx -all"
Achei que a tarefa do registro MX era enviar e-mail e não um registro. Alguém pode explicar o cenário por que alguém usaria +aentão?
Responder1
Francamente porque copiaram a configuração de algum tutorial ou exemplo de configuração sem conhecer os princípios básicos do SPF. Às vezes é desejado que, por exemplo, um servidor web de entrada ae de entradatrocas de correio mxtambém são usados para enviar correspondência, mas nem sempre.
É melhor favorecer mecanismos com menos consultas DNS adicionais : ip4/ ip6repetidamente (aamxRFC 7208, 10.1.1) E mesmo que, para facilitar a administração (10.1.2), ao mecanismo é escolhido, nem sempre é a mxou a, mas por exemplo a:relay.example.com.
Responder2
A tarefa dos hosts listados nos MXregistros érecebere-mail, não necessariamente paraentregare-mail.
É totalmente válido (e bastante comum, especialmente para operações maiores) ter uma configuração assimétrica onde os hosts que lidam com e-mails recebidos e enviados não são os mesmos.
Ou seja, não há garantia de que mx(aka +mx) ou a(aka +a) no SPF seja relevante para especificar quais hosts devem serentregare-mail.
Por exemplo, se você não administra seus próprios servidores de e-mail, talvez algo como v=spf1 include:spf.majoremailserviceprovider.example -allseja mais relevante.
Para abordar diretamente a questão sobre por que a a mxcombinação em particular parece estar super-representada nos registros SPF, meu palpite é que esta situação se resume a muitos administradores adicionando registros SPF sem compreender os conceitos SPF bem o suficiente para julgar o que colocar em sua política , em vez disso, basta copiar e colar alguns exemplos construídos arbitrariamente.
Responder3
Concordo com as outras respostas que +a +mxprovavelmente é um anti-idioma culto à carga.
Em relação a quando você usaria +a, o documento RFC responde isso emseção 10.1.2:
Publicar registros SPF para hosts individuais também é uma prática recomendada. O nome do host geralmente é a identidade usada no comando 5321.HELO/.EHLO. No caso de mensagens com 5321.MailFrom nulo, este é utilizado como domínio para verificações SPF 5321.MailFrom, além de ser utilizado em verificações SPF baseadas em 5321.HELO/.EHLO. O registro SPF padrão para um host individual envolvido no processamento de correspondência é:
relay.example.com. IN TXT "v=spf1 a -all"
Por exemplo, eu publico esse registro para meu servidor de e-mail mail.mydomain.org, para benefício dos verificadores que verificam primeiro a identidade do HELO. (É claro que também publico o v=spf1 mx -allregistro habitual no mydomain.orgpróprio domínio de correio.)
Responder4
Poderia ser uma vantagem em termos de comprimento - embora seja muito improvável que esta seja a verdadeira motivação.
Considere que o registro TXT pode aumentar de tamanho a ponto de um único pacote UDP ser muito pequeno. Portanto, a solicitação é enviada novamente em TCP e a resposta são vários pacotes TCP e o tempo de configuração do handshake associado.
Pelo uso cuidadoso das solicitações A e MX, pode-se obter duas respostas UDP de ~1.500 bytes para o registro SPF, uma para A e outra para MX, bem como os ~1.400 bytes restantes para todos os registros TXT.
Isso pressupõe que você tenha "coisas" autorizadas suficientes em seu registro SPF para exceder 3.000 bytes. As inclusões também podem contornar restrições de comprimento, mas não sei se cada uma delas seria uma solicitação UDP separada ou uma única sessão de solicitação TCP.