Verificador de SPF: seu registro SPF está funcionando?
E-mails caindo no spam, ou um serviço dizendo que seu SPF é inválido? Digite seu domínio abaixo. O verificador busca o registro SPF, segue cada include, conta as consultas DNS em relação ao limite de 10 e lista o que corrigir em linguagem simples.
Como um servidor receptor usa o seu registro SPF
Quando uma mensagem chega, o servidor receptor olha o domínio do remetente do envelope e busca o registro SPF desse domínio: um registro TXT que começa com v=spf1. Depois verifica se o endereço IP do servidor que acabou de se conectar está na lista. O resultado é pass, fail, softfail ou neutral, e o receptor o pondera com outros sinais para decidir se a mensagem vai para a caixa de entrada ou para a pasta de spam.
O SPF verifica o remetente do envelope, e não o endereço De (From) que as pessoas veem no aplicativo de e-mail. Fechar essa lacuna é papel do DMARC.
Os termos do SPF em resumo
| Termo | O que faz |
|---|---|
| ip4:192.0.2.0/24 | Permite um endereço ou faixa IPv4 |
| ip6:2001:db8::/32 | Permite um endereço ou faixa IPv6 |
| a | Permite os endereços dos registros A e AAAA do próprio domínio |
| mx | Permite os endereços dos servidores de e-mail do domínio |
| include:_spf.example.net | Permite também tudo o que o registro SPF desse domínio permite |
| exists:name | Permite quando uma consulta DNS do nome retorna um endereço |
| ptr | Obsoleto. Faz a correspondência por DNS reverso e não deve ser usado |
| all | Corresponde a tudo, por isso vem por último e define o resultado padrão |
Um qualificador antes de um termo define o resultado quando ele corresponde: + pass (o padrão), - fail, ~ softfail, ? neutral. Os finais mais usados são ~all, que marca remetentes não listados como suspeitos, e -all, que pede aos receptores que os rejeitem.
Por que o SPF quebra quando você adiciona mais um serviço
O SPF permite no máximo 10 termos que disparam uma consulta DNS durante a avaliação de um registro. include, a, mx, ptr e exists contam, e o modificador redirect também. ip4, ip6 e all não contam. As consultas dentro de um registro incluído entram no mesmo total.
É assim que um registro saudável estraga: você adiciona uma ferramenta de newsletter, um helpdesk, um CRM e um sistema de cobrança, cada um com seu próprio include, e alguns desses includes contêm outros includes. Passou de 10, o SPF retorna um erro permanente. Os receptores podem então tratar todas as mensagens como se o domínio não tivesse SPF algum, e ninguém avisa você.
- Remova os includes de serviços que você não usa mais.
- Substitua um include por faixas ip4 e ip6 quando os endereços do provedor forem estáveis.
- Nunca use ptr.
- Dê a cada serviço de envio o próprio subdomínio sempre que puder. Cada nome tem o seu próprio limite de 10.
- Se você converter includes em endereços (flattening), lembre-se de que os provedores mudam suas faixas, então um registro achatado precisa de atualizações regulares.
Uma forma segura de definir sua política SPF
- Publique exatamente um registro SPF por nome. Dois registros são um erro permanente.
- Comece com ~all enquanto confirma que todos os remetentes legítimos estão listados e passe para -all quando tiver certeza.
- Lembre-se de que o SPF não é herdado. Um subdomínio que envia e-mails precisa do próprio registro, e um subdomínio que nunca envia e-mails pode publicar v=spf1 -all.
- Combine o SPF com o DKIM e uma política DMARC. Cada um cobre as fraquezas dos outros.