“~ All” no meio de um registro SPF sinaliza o final do registro quando ele é analisado?

O formato de registro SPF da nossa empresa é o seguinte:

"v = spf1 incluem: _spf.google.com ~ all um mx ip4: XX0.0 / 23 inclui: spf.example.com? all"

Portanto, temos um "~ all" no meio do nosso registro SPF. No site openspf.com , eles dizem o seguinte sobre o mecanismo "todos":

Esse mecanismo sempre corresponde. Geralmente vai no final do registro SPF.

Portanto, eles não dizem que "todos" têm que ir no final do registro do SPF, mas que geralmente acontece no final.

Ultimamente, em nossa empresa, temos observado algumas falhas leves nos emails enviados pelos servidores listados em nosso registro SPF, mas nosso registro SPF passa por todas as ferramentas de validação encontradas até agora.

O que me pergunto é: esse "~ all" diretamente após a inclusão do Google Apps (_spf.google.com) faria com que a análise parasse e não reconhecesse as partes restantes do registro SPF? A aprovação versus falha suave dependeria de quem a está analisando e de sua implementação específica de como eles processam os registros SPF? Existe algum motivo para ter um mecanismo "tudo" que não esteja no final de um registro SPF?

E sim, eu sei que poderíamos mudar nosso registro SPF. Esta questão é mais sobre como esclarecer como tudo isso funciona e não necessariamente sobre como resolver nossa situação específica.

RFC 7208 § 5.1 é explícito sobre isso: depois que allaparece, tudo depois que DEVE ser ignorado.

Afinal, os mecanismos nunca serão testados. Os mecanismos listados depois de "todos" DEVEM ser ignorados. Qualquer modificador de "redirecionamento" ( Seção 6.1 ) DEVE ser ignorado quando houver um mecanismo "tudo" no registro, independentemente da ordem relativa dos termos.

A RFC obsoleta, a RFC 4408 , disse praticamente a mesma coisa; a versão mais recente do RFC simplesmente esclarece a intenção.

Afinal, os mecanismos nunca serão testados. Qualquer modificador de "redirecionamento" ( Seção 6.1 ) não tem efeito quando existe um mecanismo "todos".

Portanto, implementações em conformidade do SPF ignoram completamente tudo após o primeiro ~all. No entanto, isso não significa que toda implementação esteja em conformidade com as especificações. Em particular, isso provavelmente foi considerado digno de esclarecimento precisamente porque uma ou mais implementações não estavam em conformidade.

Não está totalmente claro por que uma ferramenta de validação online não captaria essa configuração incorreta, mas se você pretende que algo após o primeiro allseja usado, corrija o registro, pois as implementações adequadas o ignoram.

"v = spf1 incluem: _spf.google.com ~ all um mx ip4: XX0.0 / 23 inclui: spf.example.com? all"

diz em ordem:

"o email que passa o registro SPF _spf.google.comé válido para o nosso domínio"

"falha suave em todos os outros remetentes do nosso domínio"

"e-mails provenientes dos nossos registros A são válidos para o nosso domínio"

"os emails provenientes dos nossos registros MX são válidos para o nosso domínio"

"o email proveniente do intervalo de IP x.x.0.0/23é válido para o nosso domínio"

"o email que passa o registro SPF spf.example.comé válido para o nosso domínio"

"o email de todos os outros remetentes do nosso domínio não pode ser validado de uma maneira ou de outra"

De acordo com a sintaxe do registro:

Os mecanismos são avaliados em ordem. Se nenhum mecanismo ou modificador corresponder, o resultado padrão será "Neutro".

Portanto, para o seu, uma vez que ele atinja o "softfail para todos os outros", realmente é isso ... deve ignorar o restante dos mecanismos que você especificou.

Seu registro SPF deve ser o mais sucinto possível. Duvido muito que você tenha uma rede inteira / 23 que deva enviar e-mails para o seu domínio, nem todos os seus registros A. Talvez sim ... mas provavelmente não.

Um bom registro SPF limpo deve ser algo como:

"v = spf1 incluem: _spf.google.com incluem: spf.example.com mx -todos"

O que basicamente diria que _spf.google.com, spf.example.com e seus registros MX são os únicos remetentes válidos para o seu domínio ... todo o resto deve ser tratado como inválido.

Um verificador SPF adequadamente implementado entrará em curto-circuito em uma correspondência de mecanismo e a função check_host () retornará o valor do qualificador como resultado. Não tenho dados do "mundo real" para fornecer a respeito de saber se a maioria dos servidores de email segue ou não o RFC.

Fonte: RFC7208 (veja a página 17)