Verificador de SPF:
o seu registo está dentro do limite de 10 consultas?

Introduza o seu domínio acima. Procuramos os registos TXT, confirmamos que exatamente um começa por v=spf1 (dois é falha imediata — não se fundem, ambos morrem), e depois analisamos cada mecanismo segundo a RFC 7208: cada include é expandido recursivamente numa árvore, cada consulta DNS é contada face ao limite de 10, a política all final é avaliada, e cada intervalo de IP que o seu registo autoriza é somado numa única lista. Grátis, sem registo.

Ao avaliar o SPF, os destinatários executam no máximo 10 mecanismos que consultam o DNS por verificação (RFC 7208 §4.6.4). include, a, mx, ptr, exists e redirect contam todos, incluindo os que se escondem dentro dos includes dos seus fornecedores. Na consulta n.º 11, a avaliação é abortada com permerror. Nada é devolvido do seu lado; o DMARC passa simplesmente a tratar o seu domínio como não publicando SPF. A quebra chega aos poucos, uma subscrição de cada vez, e nunca se anuncia.

-all é o destino: rejeitar o que não é seu. ~all é o percurso: «marcar, não devolver». É a definição certa enquanto ainda está a descobrir remetentes — aquela ferramenta de faturação que ninguém mencionou. É também a mais segura se perder um e-mail legítimo lhe custar mais do que deixar passar um falsificado. Duas ressalvas: com o DMARC ativo, a diferença prática encolhe, porque o DMARC falha o correio não autorizado em qualquer dos casos. E um -all no fim de um registo que ultrapassa o limite de consultas é rigor colado a um cadáver — o permerror ganha sempre.

Não — e o modo de falha é implacável. A RFC 7208 diz que vários registos v=spf1 fazem a verificação devolver permerror: não é «o primeiro ganha», nem «fundem-se» — ambos ficam inválidos. Costuma acontecer de forma inocente: um plugin do site, o assistente de um ESP ou um segundo administrador «adiciona SPF» sem reparar no registo já existente. A correção é um minuto de trabalho: junte todos os mecanismos num único registo, elimine os restantes. Esta ferramenta conta os seus registos em primeiro lugar, antes de tudo o resto, exatamente por este motivo.

Termina o seu registo com «…e todos os outros também passam.» Qualquer IP na internet passa a ser um remetente autorizado do seu domínio: um spammer que falsifique o seu endereço recebe um SPF pass, e se a política de DMARC depender do alinhamento com o SPF, esse correio falsificado também pode passar no DMARC — a sua autenticação passa a garantir pelo atacante. É genuinamente pior do que não publicar SPF nenhum, porque «sem registo» deixa os destinatários desconfiados, enquanto «+all» os deixa confiantes. Aparece na prática como uma «correção» de entregabilidade mal orientada. Se esta ferramenta encontrar uma, não vai ser subtil a apontá-la.

Sozinho, não. O SPF valida o remetente do envelope (o endereço usado na conversa SMTP), não o From: que o seu leitor vê. Um falsificador pode passar no SPF do próprio domínio enquanto exibe o seu. Fechar essa lacuna é trabalho do DMARC: exige que o From visível esteja alinhado com o que o SPF ou o DKIM validaram. Também diz aos destinatários o que fazer quando não está. A pilha completa é SPF + DKIM + DMARC, e esta ferramenta garante que a parte do SPF está de pé, porque um permerror aqui compromete silenciosamente as outras duas.

Por ordem de dificuldade: remova o que não envia nada — a e mx são ganhos fáceis se o seu servidor web e o MX nunca enviarem correio de saída. O ptr pode sempre ser removido. Elimine fornecedores mortos — cada include deve corresponder a um serviço que ainda paga. Divida por subdomínio — deixe as newsletters serem enviadas como news.yourdomain.com, com o seu próprio registo e o seu próprio limite. Último recurso, achatamento: substituir includes pelos seus intervalos ip4/ip6 literais não custa qualquer consulta. Mas congela uma cópia das redes dos seus fornecedores — quando estes renumeram, o seu registo apodrece silenciosamente. Só achate com ferramentas ou monitorização que voltem a verificá-lo.