O que é um registro SPF e como ler um?

O que um registro SPF realmente contém?

O SPF (Sender Policy Framework) é definido na RFC 7208 como um único registro TXT de DNS publicado no próprio nome do domínio, não em um subdomínio. Todo registro válido começa com a tag de versão v=spf1, seguida por uma lista de mecanismos separados por espaço, cada um verificando se o servidor que está tentando enviar o e-mail corresponde ou não, avaliados da esquerda para a direita até que um deles corresponda.

Um domínio deve publicar no máximo um registro SPF. A RFC 7208 trata vários registros TXT com v=spf1 no mesmo nome como um erro (um PermError) em vez de combiná-los, então um domínio que usa vários provedores de e-mail precisa de um único registro que liste ou inclua todos eles, nunca vários registros separados.

O que significam os mecanismos e os qualificadores?

Cada mecanismo pode carregar um de quatro qualificadores, colocado diretamente na frente dele, e a RFC 7208, seção 5, os define assim:

• + (pass) - o padrão quando nenhum qualificador é escrito; o servidor remetente está autorizado.
• - (fail) - o servidor remetente está explicitamente não autorizado; um receptor rigoroso pode rejeitar a mensagem.
• ~ (softfail) - o remetente provavelmente não está autorizado, mas o registro não está pedindo uma rejeição direta; usado com frequência durante a implantação gradual de uma política.
• ? (neutral) - nenhuma afirmação em um sentido ou outro.

Os próprios mecanismos cobrem as formas comuns pelas quais um domínio autoriza remetentes:

• a - corresponde se o endereço IP do servidor que está conectando é um dos registros A ou AAAA do próprio domínio.
• mx - corresponde se o IP que está conectando pertence a um dos próprios hosts MX do domínio.
• ip4 / ip6 - corresponde a um endereço exato ou faixa CIDR, por exemplo ip4:203.0.113.0/24.
• include - avalia o registro SPF de outro domínio e só conta como correspondência se essa consulta retornar pass; é assim que um domínio autoriza um remetente terceirizado, como uma plataforma de e-mail, sem copiar as faixas de IP dela manualmente.
• all - corresponde a tudo, e por convenção fica por último como a regra geral para qualquer remetente que os mecanismos anteriores ainda não tenham correspondido.

O que é o limite de 10 consultas DNS, e como ele é ultrapassado?

A avaliação de SPF não pode rodar indefinidamente. A RFC 7208, seção 4.6.4, exige que as implementações de SPF limitem o total desses termos a 10 durante a avaliação, contando cada mecanismo include, a, mx, ptr e exists, além do modificador redirect, como uma consulta cada. Mecanismos que não precisam de consulta DNS para serem testados, como ip4, ip6 e all, não entram na contagem. Ultrapassar o limite encerra a avaliação em um PermError, que a maioria dos receptores trata como se o SPF não desse nenhuma resposta utilizável para aquela mensagem.

O limite é fácil de ultrapassar sem perceber porque o include é recursivo: cada serviço terceirizado que um domínio adiciona, um para a ferramenta de marketing por e-mail, um para o helpdesk, um para o CRM, pode por sua vez incluir outros domínios, e cada camada conta para o mesmo total compartilhado de 10. Três ou quatro entradas include típicas, cada uma trazendo seus próprios includes aninhados, já podem chegar perto do limite mesmo que o registro do próprio domínio pareça curto. Um registro como v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org mx -all parece ter três consultas à primeira vista, mas, se qualquer um desses domínios incluídos incluir por sua vez mais dois ou três provedores por baixo, o total real sobe bem além do que o comprimento da linha do registro sugere. A única forma de saber a contagem real é resolver cada include da cadeia e somar, não contar os mecanismos visíveis no registro de nível superior.

Por que +all é perigoso?

Terminar um registro com +all (ou deixar o qualificador de fora, já que + é o padrão) significa que o registro autoriza explicitamente qualquer remetente que exista, já que all sempre corresponde. Isso não reforça nada; faz o SPF passar para literalmente qualquer um que alegue enviar como aquele domínio, o que anula todo o propósito de publicar o registro. Um registro pensado para proteger um domínio deve terminar em -all assim que todo remetente legítimo estiver contabilizado, ou em ~all enquanto ainda se confirma que a lista está completa, nunca em +all.

Alguns registros SPF são publicados assim por engano, e não de propósito, copiados de um tutorial antigo ou deixados de uma fase de teste que nunca foi concluída, e um domínio com +all em produção não tem nenhuma proteção real do SPF, mesmo que o registro exista e valide tecnicamente. Verificar o último mecanismo de um registro é a primeira coisa a conferir ao revisar o SPF, antes de se preocupar com qualquer outra parte do registro.

Um exemplo completo

v=spf1 ip4:203.0.113.10 include:_spf.google.com mx -all

Esse registro autoriza um endereço IP específico, delega ao próprio registro SPF do Google para qualquer servidor que o Google Workspace use para enviar em nome do domínio, autoriza os próprios hosts MX do domínio e falha explicitamente tudo o mais. Ele usa duas das dez consultas disponíveis: uma para o include e uma para o mecanismo mx.

Por que o SPF sozinho falha no encaminhamento?

O SPF verifica o endereço IP do servidor que está fazendo a conexão contra o domínio no remetente de envelope (o endereço MAIL FROM, diferente do cabeçalho visível From: que uma pessoa lê). O encaminhamento simples retransmite a mensagem a partir de um servidor diferente daquele que a enviou originalmente, então o IP que está conectando não corresponde mais ao registro SPF do domínio original, e a verificação falha no destinatário final mesmo que a mensagem em si seja legítima. Esse é um dos motivos pelos quais o SPF não é a solução completa: o DKIM, uma verificação baseada em assinatura que viaja junto com o conteúdo da mensagem, não depende de qual servidor retransmite o e-mail. O SPF também não tem nenhuma relação com qual servidor de e-mail realmente recebe o e-mail que chega a um domínio, essa é a função do registro MX.

Perguntas frequentes

Um domínio pode ter mais de um registro SPF?

Não. A RFC 7208 trata dois ou mais registros TXT com v=spf1 no mesmo nome como um erro. Combine todo remetente autorizado em um único registro.

O SPF verifica o endereço que uma pessoa vê na caixa de entrada?

Não. O SPF avalia o remetente de envelope usado durante a transação SMTP, não o cabeçalho visível From:. Conectar essas duas coisas é o que o alinhamento do DMARC faz, coberto mais adiante nesta seção.

O que faz o modificador redirect?

Ele substitui toda a avaliação pelo registro SPF de outro domínio, em vez de adicionar ao registro atual como o include faz. É usado quando a política de um domínio deve ser, na íntegra, a política de outro domínio.

Como verifico quantas consultas meu registro usa?

Resolva o registro e conte os termos include, a, mx, ptr e exists, depois verifique da mesma forma qualquer domínio citado em um include, já que as consultas dele também contam. A ferramenta de consulta MX é útil junto com isso para confirmar quais hosts o mecanismo mx de um domínio traria.

O SPF sozinho é suficiente para impedir e-mails forjados?

Não por si só. Ele só diz quais servidores podem enviar em nome de um domínio; não diz nada sobre o nome de remetente visível que um destinatário lê, e não sobrevive a um encaminhamento simples. O DKIM e o DMARC, cobertos nos dois próximos guias, fecham essas lacunas.