Defaults.Exposed › Correções › Guides

O SPF a Falhar nas Suas Ferramentas SaaS? Porque Acontece e a Ordem de Correção — Edição Europa (2026)

Publicado 2026-07-08

Números a 2026-06-29 · metodologia v7. Dados agregados do censo de 261 milhões de domínios classificados. Veja como classificamos.

Quando uma ferramenta SaaS “falha o SPF”, o seu registo normalmente não é o problema: o correio está a falhar o alinhamento do DMARC, ou a sua cadeia de includes já ultrapassou o limite de 10 consultas de DNS do SPF. 2.119.539 de 138.927.207 domínios que publicam SPF estão em 9–10 consultas — a um include SaaS do precipício — segundo o censo do Defaults.Exposed de 261.086.232 domínios.

Abaixo: como distinguir qual dos dois problemas tem, depois a ordem de correção — verifique primeiro, encontre o domínio de onde a ferramenta realmente envia, mude o fornecedor para DKIM de domínio personalizado, e só adicione um include de SPF onde genuinamente ajudar — mais as especificidades para HubSpot, Salesforce, Mailchimp e SendGrid.

Porque é que o correio de uma ferramenta SaaS falha o SPF?

Três padrões cobrem quase todos os casos:

Dados a 2026-06-29.

A linha a negrito é onde a maioria das pessoas está. Adicionar linhas include: para cada ferramenta não resolve isso — e cada linha aproxima-o mais da segunda linha: pelo menos 797.263 domínios já ultrapassaram o limite de 10 consultas, e o seu SPF agora devolve um PermError que não protege nada. Números completos em o relatório de PermError do SPF.

Que domínio é que o SPF realmente verifica?

Não o que está no seu cabeçalho From. Os recetores avaliam o SPF contra o domínio do Return-Path (o RFC5321.MailFrom, também chamado endereço de devolução ou envelope-from) — o cabeçalho From que o seu destinatário vê não tem parte nenhuma na verificação de SPF em si.

Este facto único explica a maioria das “falhas de SPF do SaaS”. A sua plataforma de marketing envia com um Return-Path como [email protected]; o SPF é verificado contra fornecedor.com e passa perfeitamente. Depois o DMARC pergunta se esse domínio verificado pelo SPF corresponde ao seu domínio From. Não corresponde, portanto a verificação de SPF do DMARC falha e o seu painel diz “SPF a falhar”. Editar o seu próprio registo SPF não consegue corrigir isso — o seu registo nunca foi consultado.

Qual é a ordem de correção?

1. Execute primeiro a verificação gratuita. Diz-lhe de uma vez se o seu SPF está em falta, duplicado, acima do limite de consultas ou bem, e onde está o DMARC — antes de tocar no DNS.
2. Encontre o Return-Path que a ferramenta realmente usa. Envie-se um teste a partir da ferramenta e leia o cabeçalho Return-Path (e Authentication-Results) na mensagem em bruto. Isso diz-lhe em que linha da tabela acima está.
3. Ative o DKIM de domínio personalizado do fornecedor. Todas as ferramentas SaaS a sério oferecem “autenticação de domínio”: uns registos CNAME que lhe permitem assinar DKIM como o seu domínio. Essa assinatura alinha com o seu domínio From, portanto o DMARC passa via DKIM — de forma duradoura, e mesmo quando o correio é reencaminhado. Esta é a correção que dura.
4. Adicione o include de SPF do fornecedor só se ele usar o seu return-path — ativou o seu domínio de devolução personalizado, ou envia genuinamente com o seu domínio no envelope. Um include para um fornecedor que devolve via o seu próprio domínio não compra nada e gasta o seu orçamento de consultas.
5. Conte as suas consultas de DNS antes de guardar. O limite é 10 consultas resolvidas, os includes contam recursivamente, e 2.119.539 domínios já estão em 9–10 — o p99 do censo é 9. Perto do limite? Remova primeiro os includes de ferramentas que já não usa. Mudou de fornecedor de email há pouco? Verifique se sobrou um segundo registo — dois registos SPF equivalem a um PermError.
6. Volte a verificar e confirme. SPF a passar no domínio certo, DKIM alinhado, DMARC a passar. A referência completa está em como corrigir o SPF; passo a passo por fornecedor como SPF no GoDaddy e DMARC na IONOS cobrem os cliques nos painéis de DNS.

O que deve fazer para HubSpot, Salesforce, Mailchimp e SendGrid?

HubSpot. Ligue o seu domínio de envio nas definições do HubSpot e publique os dois CNAMEs de DKIM que emite (hs1-… / hs2-…). Isso alinha o DKIM com o seu domínio From. Não precisa de um include de SPF do HubSpot a menos que tenha configurado o HubSpot para usar o seu próprio domínio de devolução.

Salesforce. Crie uma chave DKIM no Salesforce Setup e publique o par de CNAME que gera. Se o Salesforce enviar com o return-path da sua organização, adicione include:_spf.salesforce.com e configure o domínio de devolução — este é o grande CRM em que o include de SPF costuma ser genuinamente necessário.

Mailchimp. Autentique o seu domínio e publique os CNAMEs de DKIM k2 / k3. O alinhamento do Mailchimp é só por DKIM — já não há include de SPF nenhum para adicionar, e adicionar um de um tutorial antigo só desperdiça consultas.

SendGrid. Complete a autenticação de domínio (“segurança automatizada”): três CNAMEs que tratam do DKIM e do return-path no seu próprio subdomínio. Sem necessidade de include de SPF. Dos 740.321 domínios cujo SPF autoriza o sendgrid.net, só 18,0% têm o DMARC aplicado (dados a 2026-06-29) — a maioria dos remetentes do SendGrid para um passo antes do fim.

Zendesk e tudo o resto: mesmo padrão. Encontre a página de “autenticação de domínio” da ferramenta, publique os seus CNAMEs de DKIM, e só toque no SPF se a ferramenta documentar que usa o seu return-path.

O SPF é diferente para empresas europeias?

Não — o SPF, o DKIM e o DMARC funcionam de forma idêntica em todo o lado. O que difere na Europa é o contexto: quem pergunta, e o que os seus vizinhos já fizeram.

O seu ccTLD define o padrão local. Os ccTLD europeus publicam SPF bem acima das taxas do .com, mas os domínios que terminam o trabalho — uma política DMARC aplicada por cima — são a minoria em todo o lado:

Dados a 2026-06-29. França: 13,65% com DMARC aplicado; Itália: 5,24%.

O padrão do seu alojamento europeu importa. 4.346.526 domínios autorizam os servidores de correio da IONOS na UE (_spf-eu.ionos.com) no seu SPF — e só 0,3% terminam em -all estrito, com 1,0% com DMARC aplicado. Os 2.132.049 da OVH saem-se melhor na severidade (43,7%) mas só 2,2% aplicam o DMARC (dados a 2026-06-29). Se nunca tocou no seu registo, está de pé nesses padrões.

Os reguladores agora nomeiam isto. O artigo 21.º, n.º 2, alínea j), da NIS2 exige que as entidades abrangidas protejam as suas comunicações, e o Regulamento de Execução (UE) 2024/2690 detalha as medidas de segurança de email e DNS. A autenticação de email é a parte concreta e verificável — e, invulgarmente para conformidade, gratuita de corrigir.

Sobre residência de dados: o scanner e o censo do Defaults.Exposed correm na AWS eu-west-1, publicamos apenas números agregados, e uma verificação só examina o domínio que perguntar.

Perguntas frequentes

O meu verificador de SPF diz “pass” mas o painel da ferramenta diz que o SPF está a falhar — porquê? O verificador testou o seu registo; o recetor testou o domínio do Return-Path que a ferramenta realmente usou, depois o DMARC comparou-o com o seu domínio From. Isso é uma falha de alinhamento, não uma falha de registo — corrigida com o DKIM de domínio personalizado do fornecedor, não com edições ao SPF.

Devo simplesmente adicionar o include de SPF para todas as ferramentas que usamos? Não. Cada include gasta parte do orçamento de 10 consultas do SPF, recursivamente: 2.119.539 dos 138.927.207 domínios que publicam SPF estão em 9–10 consultas, e pelo menos 797.263 estão acima — o seu SPF devolve PermError e não protege nada (dados a 2026-06-29).

O include também corrige o DMARC? Só se a ferramenta enviar com o seu return-path, para que o SPF passe e alinhe. Para a maioria das ferramentas SaaS não envia — é por isso que o DKIM alinhado, não o SPF, é a verificação que faz o DMARC passar para correio SaaS.

Isto é um requisito legal na UE? Para entidades no âmbito da NIS2, o artigo 21.º, n.º 2, alínea j), e o Regulamento de Execução (UE) 2024/2690 tornam a segurança do email uma obrigação. Mesmo fora do âmbito, as seguradoras e os questionários de clientes perguntam cada vez mais — e a 2026-06-29, nenhum ccTLD da UE leva sequer um terço dos seus domínios a uma política DMARC aplicada (29,43% no .nl na melhor das hipóteses; 5,24% no .it).

Envie o relatório ao proprietário

Assim que os CNAMEs estiverem em vigor, volte a executar a verificação e reencaminhe o relatório classificado ao dono do negócio ou cliente. Mostra, em linguagem simples, o que estava a falhar, o que corrigiu e onde o domínio está agora — exatamente a evidência de que precisam para a renovação do seguro ou o questionário de segurança de cliente, por escrito em vez de na sua palavra.

Verifique o seu domínio gratuitamente

Veja exatamente qual verificação de SPF, DKIM e DMARC está a falhar — em privado e só para o proprietário.

Verifique o seu domínio → · Corrigir o SPF → · SPF PermError: “demasiadas consultas de DNS” → · Como classificamos → · Apenas dados agregados. Dados armazenados e processados na UE.