O SPF Deixou de Funcionar Depois de Mudar de Fornecedor de Email — A Correção de Migração (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.

O SPF normalmente avaria-se depois de uma mudança de fornecedor de email porque o registo do novo fornecedor foi adicionado ao lado do antigo. Dois registos v=spf1 são um erro permanente — o SPF anula-se por completo. 1.013.416 domínios — cerca de um em 138 dos que tentam SPF — estão nesse estado, segundo o censo do Defaults.Exposed de 261 milhões de domínios. Junte-os num só.

A correção demora cerca de dez minutos: verifique o domínio para ver exatamente o que a migração deixou para trás, liste todos os registos SPF nos seus nameservers autoritativos, junte-os num único registo que inclua apenas o seu novo fornecedor, e volte a verificar com o dig. Este guia percorre cada passo, mais as verificações de DKIM e de nameserver que a maioria das migrações esquece.

Porque é que o SPF se avariou logo depois da migração?

Porque o guia de configuração do novo fornecedor disse “adicione este registo TXT” — e você fê-lo, ao lado do antigo. Isso é a única coisa que a norma SPF não permite. O RFC 7208 (§3.2, resultado de erro prescrito no §4.5) permite exatamente um registo v=spf1 por domínio; um recetor que encontre dois ou mais tem de devolver PermError em vez de adivinhar qual é o autoritativo. PermError significa que o SPF é nulo: não o registo antigo, não o novo, SPF nenhum.

E não fica por aí. O DMARC trata um PermError como uma falha na verificação de SPF, portanto o seu correio depende agora inteiramente do DKIM. Se o DKIM do novo fornecedor também ainda não estiver configurado — comum a meio de uma migração — está a enviar sem autenticação exatamente no momento em que mudou de infraestrutura, que é quando os recetores mais o escrutinam.

Este é o copiar-colar que anula a proteção quando muda de fornecedor, e não é raro: 1.013.416 domínios publicam dois ou mais registos SPF neste momento — cerca de um em 138 da população de 139 milhões que tenta SPF, segundo o censo do Defaults.Exposed de 261 milhões de domínios (dados a 2026-06-29). Os números completos sobre a armadilha dos dois registos têm o seu próprio relatório; esta página é a correção processual.

O que é que a migração deixou para trás?

Cinco resíduos causam quase todas as falhas de SPF pós-migração. Verifique-os por esta ordem:

O que ficou para trás	O que vê	A correção
O registo SPF antigo, ainda no DNS ao lado do novo (dois registos `v=spf1`)	Os verificadores reportam “multiple SPF records” ou PermError; o SPF deixa de funcionar por completo	Junte num único registo, elimine o resto — passos abaixo
O `include:` do fornecedor antigo dentro do seu único registo	O SPF funciona, mas está a desperdiçar consultas de DNS e os servidores do fornecedor antigo ainda podem enviar como você	Remova-o assim que o correio tiver drenado por completo do sistema antigo
O `include:` do novo fornecedor nunca adicionado	O correio do novo fornecedor falha o SPF nos recetores	Adicione-o ao único registo existente — nunca como um registo novo
Seletores DKIM não criados para o novo fornecedor	`dkim=fail` ou assinaturas do domínio predefinido do fornecedor; o DMARC não tem segunda verificação	Publique os novos seletores — passo 6 abaixo
Registo atualizado só nos nameservers antigos	Respostas diferentes consoante a quem pergunta; falhas intermitentes	Corrija a zona nos nameservers autoritativos; verifique ambos os conjuntos durante a transição

Como corrijo isto? A lista de verificação de migração

Execute primeiro a verificação gratuita em defaults.exposed. Lê o seu DNS real e diz-lhe se tem vários registos SPF, um include em falta, ou uma lacuna de DKIM — diagnostique antes de tocar em nada.
Liste todos os registos SPF nos nameservers autoritativos. dig +short NS oseudominio.com, depois dig +short TXT oseudominio.com @<nameserver> contra um deles. Conte as strings que começam por v=spf1. A única contagem segura é 1.
Junte tudo num único registo. Um registo, começando por v=spf1, contendo o include do seu novo fornecedor e qualquer outro remetente que ainda use (ferramenta de faturação, CRM, plataforma de newsletter), um único -all ou ~all terminal. Exemplo — Google Workspace antigo, Microsoft 365 novo, a meio da drenagem:
```
Antes:  "v=spf1 include:_spf.google.com ~all"
        "v=spf1 include:spf.protection.outlook.com -all"

Depois: "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
Mais tarde: "v=spf1 include:spf.protection.outlook.com -all"
```
Os valores dos fornecedores e as particularidades dos painéis de DNS estão nos guias de configuração para o Google Workspace e o Microsoft 365.
Elimine os registos a mais. Juntar sem eliminar não corrige nada — o PermError vem da contagem.
Mantenha o include do fornecedor antigo só enquanto o sistema antigo ainda envia — relatórios agendados, um conector de CRM antigo, uma caixa de correio esquecida. Assim que a drenagem terminar, remova-o: um include obsoleto deixa a infraestrutura antiga autorizada a enviar como você, e cada include custa consultas de DNS contra o teto rígido do SPF de 10 — pelo menos 797.263 domínios já anularam o SPF por ultrapassar esse teto (censo, 2026-06-29).
Configure o DKIM do novo fornecedor — e não elimine ainda os seletores antigos. Os seletores novos assinam correio novo; os seletores antigos têm de continuar publicados até toda a mensagem assinada com eles ter sido entregue e quaisquer reencaminhamentos assentarem. Passo a passo completo em DKIM a falhar depois de mudar de ferramentas.
Se também mudou de nameservers, verifique ambos. As migrações de DNS costumam andar a par das migrações de email. Consulte diretamente o conjunto de NS antigo e o novo (dig TXT oseudominio.com @old-ns e @new-ns) — até a delegação do registrador propagar por completo, alguns recetores ainda perguntam aos servidores antigos, portanto o registo corrigido tem de existir em qualquer conjunto que responda.
Volte a executar a verificação e confirme que o SPF mostra um único registo válido com um passe.

Que domínio é que o SPF realmente verifica?

Os recetores avaliam o SPF contra o domínio do Return-Path (RFC5321.MailFrom) — o endereço de devolução — não o cabeçalho From que os seus destinatários veem. Depois de uma migração isto importa duas vezes: o seu novo fornecedor pode usar o seu próprio domínio de devolução até configurar um personalizado, e o SPF a “passar” num domínio que não é seu não vai alinhar para o DMARC. A correção para isso é o DKIM do novo fornecedor, assinado com o seu domínio.

A migrar e a fazer rebranding ao mesmo tempo?

Mudou também o domínio, além do fornecedor? Trate-os como dois trabalhos. O domínio novo precisa da pilha completa — SPF, DKIM, DMARC — desde o primeiro dia; use a lista de verificação de email em domínio novo. O domínio antigo mantém-se autenticado enquanto o reencaminhamento ou o tráfego de respostas passar por ele, e é trancado explicitamente (não apenas abandonado) assim que for estacionado. Um domínio antigo com SPF residual e meio partido é um alvo de falsificação vestindo o seu nome anterior.

Perguntas frequentes

Posso manter dois registos SPF enquanto migro? Não. Não há período de graça na norma — dois registos v=spf1 são um PermError a partir do momento em que o segundo existe, e 1.013.416 domínios estão nesse estado à data do censo (2026-06-29). O padrão seguro para migração é um único registo com os includes dos dois fornecedores durante a sobreposição.

Quanto tempo devo manter o include do fornecedor antigo? Até nada mais enviar através do fornecedor antigo — normalmente a duração da sua janela de sobreposição, dias a algumas semanas. Vigie o Return-Path de tudo o que ainda chegar via o sistema antigo; quando esse tráfego parar, remova o include e volte a verificar a sua contagem de consultas.

Porque é que um verificador ainda mostra o meu registo antigo depois de o corrigir? A cache de DNS honra o TTL do registo, e se os seus nameservers mudaram, alguns resolvedores ainda consultam o conjunto antigo. Verifique diretamente nos nameservers autoritativos com dig TXT oseudominio.com @<ns> — se a resposta estiver correta ali, a correção está feita e as caches vão-se atualizar. Se estiver errada num conjunto de NS, veja ‘SPF record not found’ — as causas reais.

Preciso de mudar o DMARC quando mudo de fornecedor? Normalmente não o registo em si — nomeia a sua caixa de correio de relatórios e a política, não o seu fornecedor. Mas os resultados do seu DMARC dependem do SPF e do DKIM que acabou de migrar: espere uma quebra nos relatórios durante a transição, e confirme que ambas as verificações passam antes de apertar a política. Comece em corrigir o SPF se a verificação mostrar a verificação de SPF ainda a falhar.

Envie o relatório ao proprietário

Se está a fazer esta migração para um cliente, termine com evidência. Volte a executar a verificação gratuita assim que a junção estiver em vigor e reencaminhe o relatório classificado ao dono do negócio: SPF, DKIM e DMARC a passar no novo fornecedor, em linguagem simples, datado. É o artefacto que arquivam para a renovação do seguro cibernético e o próximo questionário de segurança de fornecedores — prova de que a migração deixou o domínio mais autenticado do que começou.

Verifique o seu domínio → · DKIM a falhar depois de mudar de ferramentas de email → · ‘SPF record not found’ — as causas reais → · Como classificamos → · Apenas dados agregados. Dados armazenados e processados na UE.