O SPF PermError significa que seu registro SPF gera mais de 10 consultas DNS, o limite definido pela RFC 7208. Cada include, a, mx, ptr, exists e redirect conta, e cada include soma as consultas dentro dele. Corrija removendo includes sem uso, substituindo alguns por endereços ip4:/ip6: ou achatando o registro.
O receptor avalia o SPF em tempo real, então a especificação limita o trabalho de DNS a 10 consultas para evitar abuso e entrega lenta. Se ultrapassar, o resultado é PermError, tratado como falha que pode mandar seu e-mail legítimo para o spam ou rejeitá-lo sob DMARC.
Contam para o limite de 10: include, a, mx, ptr, exists, redirect e, recursivamente, tudo dentro de cada include. Não contam: os mecanismos ip4: e ip6: e o mecanismo all. Essa assimetria é a chave da solução.
1. Remova o que não usa mais. ESPs e ferramentas antigas no SPF são a causa mais comum. 2. Consolide. Alguns provedores publicam um include mais enxuto. 3. Troque includes por IPs. Se um serviço publica faixas de IP estáveis, troque include:servico.com por seus blocos ip4:: eles não custam consultas. 4. Achate como último recurso e só com monitoramento, pois um provedor que mude de IP quebra silenciosamente um registro achatado.
Confirme se existe exatamente um registro SPF e veja seus mecanismos:
$ dig TXT yourdomain.com +shortO verificador SPF acima expande cada inclusão e relata sua contagem real de pesquisas e quais incluem os maiores custos.
Verifique seu registro SPF agora
Abrir o verificador SPF gratuito →Não. Os mecanismos ip4: e ip6: custam zero consultas DNS, por isso trocar um include por suas faixas de IP é uma solução eficaz.
Funciona, mas é frágil: fixa os IPs atuais de um provedor no seu registro, então seu e-mail falha quando ele muda de IP. Se achatar, use um serviço que atualize o registro automaticamente e monitore-o.
Sim: publicar mais de um registro SPF é uma causa separada de PermError. Um domínio deve ter exatamente um.
