Por que o e-mail está sendo entregue normalmente, apesar de um "hardfail" do SPF?

Estou tentando descobrir por que o email falsificado está sendo entregue aos principais provedores de email (gmail.com, outlook.com), mesmo que o email esteja marcado com um SPF hardfail. O email também é entregue ao Microsoft Exchange, que está lançando um PermErrorpara o mesmo registro SPF.

Estou enviando email usando o domínio SOME_DOMAIN.com, que define um registro SPF quebrado. O email é transmitido a partir do meu próprio endereço IP, que não está listado explicitamente no registro SPF de SOME_DOMAIN.com. O registro SPF para SOME_DOMAIN.com possui as três propriedades a seguir, as duas primeiras são uma violação do SPF RFC-4408:

1. Requer mais de 10 consultas DNS para resolver todo o registro SPF, devido a include:.
2. Erro de sintaxe em um dos registros SPF, python-spf gera um erro de análise.
3. O registro SPF contém as regras ~alle -all, ambos dizendo que o conjunto de todos os endereços deve softfailehardfail

O email enviado para um endereço outlook.com representando admin@SOME_DOMAIN.com conterá o seguinte erro no cabeçalho SMTP do email entregue. Este email foi entregue normalmente na caixa de entrada do usuário :

Received-SPF: PermError (: domain of SOME_DOMAIN.com used an invalid SPF mechanism)

O Gmail também envia o email para a caixa de entrada do usuário, mas gera um erro SPF diferente:

spf=hardfail (google.com: domain of admin@SOME_DOMAIN.COM does not designate x.x.x.x as permitted sender) smtp.mail=admin@SOME_DOMAIN.COM

Então, o que está acontecendo aqui? Por que o email está sendo entregue apesar de um SPF hardfail? Ter um registro SPF quebrado significa que outros servidores SMTP desconsideram completamente o SPF? Ou há algo que estou perdendo aqui ...

O SPF é tão mal configurado por tantos sites que o recebimento de MTAs geralmente conta hardfailapenas como aconselhamento e apenas o fator em suas pontuações de detecção de spam. No final, cabe ao administrador do MTA a forma como as falhas do SPF serão tratadas.

As condições de erro do SPF não indicam nada sobre a política desejada. Como tal, eles não fornecem orientação para aceitar ou não a mensagem. É possível que a política pretendida seja +all. É normal aceitar correio neste caso. Parece que o Google está sendo indulgente com a falha deste domínio em cumprir com o padrão.

Mesmo as rejeições de política do SPF ( -all) não são confiáveis ​​ao validar endereços de remetentes. Há vários casos em que a rejeição de tal correspondência seria inadequada, incluindo:

• Correio enviado por mala direta contratada (essas pessoas são pagas por violar a política.);
• Correio enviado de formulários da web e outro sistema automatizado;
• Correio encaminhado por listas de correio ou outros mecanismos de encaminhamento; e
• Simplesmente incorreta configuração dos registros SPF (não é comum, mas não é rara o suficiente).

Eu corro um servidor bastante pequeno, onde posso adiar em caso de falhas graves. Isso me permite listar falhas legítimas. Se o remetente perceber que o e-mail não foi entregue, ele poderá corrigir sua configuração. Em alguns casos, tentarei entrar em contato com o relevante postmaster, mas muitos domínios não têm um postmasterendereço.

Os usuários que desejam impor uma política mais forte podem usar o DMARC, que ainda não é um padrão. É provável que as mensagens sejam entregues, mas podem ser colocadas em quarentena ou rejeitadas, conforme especificado nessa política. As mensagens que falham na política podem ser entregues na pasta de spam, em vez da caixa de entrada normal.

Falhas graves no SPF parecem confiáveis ​​para validar a identidade do servidor de envio. Pesquisei há pouco tempo e descobri que mesmo falhas leves no nome HELO são um motivo razoável para falhar ou adiar as mensagens recebidas.

Muitos servidores de email não possuem um registro SPF. Se o servidor de email não tiver um registro SPF, eu verifico no domínio pai um registro SPF. Isso não é padrão, mas é eficaz. Encorajo os administradores de email a garantir que haja um registro SPF para o IP dos servidores, conforme listado no registro PTR. Seu servidor também deve se identificar pelo nome retornado pelo registro PTR. Verifique se você tem um registro A correspondente para verificação reversa do DNS.