Defaults.Exposed › Relatórios

SPF ~all vs -all: Softfail ou Hardfail — O Que 139 Milhões de Registos Escolheram (2026)

Publicado 2026-07-03

Números a 2026-06-29 · metodologia v7. Dados agregados do censo em 261 milhões de domínios classificados. Todos os números são agregados — nunca publicamos o registo de uma empresa individual. Veja como classificamos.

Todo o registo SPF termina num mecanismo “all” — o veredicto sobre correio proveniente de qualquer lugar que não esteja na sua lista — e a internet escolheu esmagadoramente o suave: 55,8% dos 139 milhões de domínios que publicam SPF terminam em ~all (softfail), contra 39,3% que terminam em -all (hardfail). Um único caractere separa “rejeitar falsificações” de “provavelmente uma falsificação — entregue-a na mesma”. Qual é o certo para si depende de uma segunda definição que a maioria dos proprietários nunca configura.

O que é que ~all e -all realmente dizem a um recetor?

• -all (hardfail): “Rejeitar correio proveniente de qualquer outro lugar.” Um não firme.
• ~all (softfail): “Correio de outros lugares provavelmente não é legítimo — aceite-o, talvez sinalize-o.” Um encolher de ombros.
• ?all (neutro): “Sem opinião.” Escolhido por 3,0% dos publicadores; proteção apenas no nome.
• +all: “Qualquer pessoa pode enviar como eu.” Publicado por 36.014 domínios, e pior do que não ter registo nenhum — o problema do tapete de boas-vindas tem o seu próprio relatório.

Então ~all está errado? Só se estiver sozinho — e quase sempre está

O softfail tem um argumento moderno defensável: as diretrizes de remetentes da Google, e a maioria das práticas de entregabilidade que as acompanham, convergem para ~all combinado com uma política DMARC de aplicação (p=reject). Esta combinação protege tão bem como -all em todos os recetores que avaliam DMARC — o que agora inclui todos os principais fornecedores de caixas de correio — sem rejeitar duramente correio reencaminhado legítimo, a vítima clássica do -all. Nessa configuração, o encolher de ombros ganha dentes: o DMARC fornece o veredicto que o SPF recusou dar.

Mas a combinação é o ponto central, e eis o que o censo acrescenta que os guias de configuração não conseguem: dos 77.484.057 registos softfail na internet, apenas 7,1 milhões — cerca de 1 em 11 — têm uma política DMARC de aplicação por trás. Para os outros 70,4 milhões de domínios, ~all é exatamente o que parece. O seu registo identifica a falsificação e deixa-a passar.

Os mandatos de 2024 não resolveram isto?

Não — e a distinção importa mais do que a maioria da cobertura sugere. A Google e o Yahoo começaram a exigir autenticação dos remetentes em massa em fevereiro de 2024, seguidos pela Microsoft em maio de 2025: SPF ou DKIM que passe e esteja alinhado, mais um registo DMARC de no mínimo p=none. Os mandatos não chegam a exigir aplicação — um domínio com ~all, um registo p=none e DKIM alinhado cumpre totalmente, e permanece totalmente falsificável. Os mandatos normalizaram a papelada, não a proteção. Esse meio não aplicado — conforme, publicado, falsificável — é precisamente a lacuna que este censo mede, e é a maior população na segurança de email.

Então em que deve terminar o seu registo?

1. Envia correio e o reencaminhamento importa (newsletters, listas de distribuição, aliases): ~all com DMARC p=reject por trás — a combinação recomendada acima.
2. Envia correio a partir de uma configuração rigorosamente controlada: -all funciona e declara a política no próprio registo. Mapeie primeiro os seus remetentes — um final estrito num registo não mapeado quebra correio real, ou pior.
3. O domínio nunca envia: -all mais p=reject, hoje. Não existe nada legítimo para proteger, portanto não há nada para quebrar.

Qualquer que seja o final que escolher, a lição de uma linha do censo mantém-se: o qualificador só importa na medida em que algo o faz aplicar. Onde se encontra nessa escala é mensurável.

Perguntas frequentes

SPF ~all ou -all é melhor? Nenhum, universalmente. ~all com uma política DMARC de aplicação é o padrão que as diretrizes da Google recomendam — proteção equivalente nos recetores que avaliam DMARC sem quebrar correio reencaminhado. -all adequa-se a remetentes rigorosamente controlados. ~all sozinho — o estado de todos exceto 1 em 11 domínios softfail — é a opção fraca.

O que significa SPF softfail? ~all diz aos recetores que o correio de servidores não listados provavelmente é ilegítimo mas deve ainda assim ser aceite, normalmente com suspeita. Só se torna proteção real quando uma política DMARC age sobre a falha; veja SPF sem DMARC.

O hardfail -all vai quebrar o meu email reencaminhado? Pode: o reencaminhamento reenvia o seu correio a partir do servidor do reencaminhador, que o seu SPF não lista, e um hardfail convida à rejeição antes de o DKIM ou o DMARC pesarem. Esse risco é o motivo pelo qual existe a combinação ~all + p=reject.

A Google e a Microsoft exigem -all agora? Não. Os mandatos de remetentes em massa exigem autenticação alinhada e que passe, mais um registo DMARC de no mínimo p=none — sem aplicação, sem qualificador específico. A rejeição pela Google de correio em massa não conforme está ativa; a Microsoft tem colocado as falhas no lixo e caminha para a rejeição direta. Conformidade não é proteção.

Verifique em que termina o seu registo — e o que está por trás dele

Duas consultas dizem-lhe ambos, grátis, em 30 segundos. Se for um dos 70,4 milhões de encolheres de ombros não aplicados, a correção é um registo DNS, não uma compra.

Verifique o seu domínio → · Corrigir SPF → · Corrigir DMARC → · O modelo de maturidade SPF → · O mapa +all → · Apenas dados agregados. Dados armazenados e processados na UE.