DKIM a falhar depois de mudar de ferramenta de email: o guia de migração de CNAMEs e seletores (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 DKIM parte-se depois de uma mudança de ferramenta por duas razões mecânicas: o seu painel de DNS estropiou os alvos de CNAME da nova ferramenta — normalmente acrescentando a sua própria zona — ou os seletores da ferramenta antiga foram removidos antes de o correio dela escoar. Só 3,87% dos domínios — 10.092.481 — completam a tríade SPF+DKIM+DMARC, segundo o censo do Defaults.Exposed de 261.086.232 domínios classificados.

A ordem da correção: verifique o domínio, depois confira o alvo guardado de cada novo CNAME com dig — um alvo terminado no nome do seu próprio domínio é a prova do crime. Repare os registos nos nameservers autoritativos, confirme que a nova ferramenta assina e passa antes de encaminhar correio real por ela, e mantenha os seletores da ferramenta antiga publicados até o tráfego dela escoar.

Porque é que o DKIM se partiu quando mudou de ferramenta?

Nada no DKIM em si mudou — os seus seletores mudaram. A ferramenta antiga assinava com os seletores dela; a nova assina com outros, normalmente delegados através de dois ou três registos CNAME adicionados durante a ativação. Quatro armadilhas explicam quase todas as falhas de DKIM pós-migração:

O seu painel de DNS acrescentou a sua zona ao alvo do CNAME. Muitos painéis tratam qualquer hostname colado como relativo e guardam silenciosamente target.provider.com.yourdomain.com em vez de target.provider.com. O registo existe, o painel mostra um visto verde, e não resolve para nada.
Confusão com o ponto final. Alguns painéis exigem um ponto final (target.provider.com.) para significar “absoluto — não acrescentes a minha zona”; outros rejeitam o ponto como inválido e tratam eles próprios da questão. O mesmo valor colado está certo num painel e estropiado no seguinte.
Os seletores da ferramenta antiga foram apagados no dia da mudança. O correio que a ferramenta antiga já assinou fica em filas de reenvio e percursos de reencaminhamento durante dias; remover os seletores dela — ou fechar a conta antiga, o que mata os CNAMEs delegados — parte esse correio retroativamente.
Verificou nos nameservers errados. Se a migração incluiu uma mudança de nameservers, os registos corrigidos podem existir num conjunto de NS enquanto os recetores ainda consultam o outro.

Só 51,84% dos 261 milhões de domínios do censo apresentam uma chave DKIM detetável no momento da verificação (dados a 2026-06-29).

A mesma migração costuma deixar também destroços no SPF — 1.013.416 domínios, cerca de 1 em cada 138 dos que tentam o SPF, têm dois registos v=spf1, o sinal clássico de que uma mudança de fornecedor adicionou um registo em vez de fundir um. Esse lado da mudança tem o seu próprio guia: o SPF deixou de funcionar depois de mudar de fornecedor de email.

Como deteto um registo CNAME estropiado?

Não confie no painel — pergunte ao DNS o que realmente guardou. Consulte o alvo do CNAME de cada seletor que a nova ferramenta lhe deu. Um exemplo ilustrativo, imitando um seletor delegado ao estilo SendGrid (a forma do alvo do seu fornecedor será diferente):

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.yourdomain.com.

O fornecedor pediu s1.domainkey.u1234567.wl123.sendgrid.net — mas o alvo guardado termina em .yourdomain.com. O painel acrescentou a zona; esse nome não resolve para nada, portanto os recetores não encontram chave nenhuma. A versão saudável:

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.

(Um único ponto final na saída do dig é normal — marca um nome totalmente qualificado.) Se o alvo estiver certo, siga-o um salto: dig TXT s1._domainkey.yourdomain.com +short deve devolver a chave do fornecedor. Resposta vazia com um CNAME correto significa que o problema está do lado do fornecedor da delegação — conclua o passo de verificação deles, ou veja DKIM “no key for signature” para o diagnóstico ao nível do seletor.

O runbook da migração: antes, durante, depois

A falha normalmente não está nos registos — está na ordem. As migrações de DKIM correm mal na transição porque a verificação acontece depois da mudança, quando o correio real já está a falhar.

Fase	O que fazer	Condição antes de avançar
Antes da mudança	Adicione os CNAMEs de DKIM da nova ferramenta (e os registos do domínio de bounce), depois prove-os: faça `dig` ao alvo guardado de cada CNAME a partir de fora da sua rede, conclua o passo de verificação da própria ferramenta e envie um teste através da nova ferramenta para uma caixa de correio que controle	A mensagem de teste mostra `dkim=pass` com `d=` = o seu domínio — nunca encaminhe correio real por uma ferramenta não verificada
Dia da mudança	Mova o tráfego real para a nova ferramenta. Não toque em nada da ferramenta antiga: deixe os seletores, os CNAMEs e a conta vivos	O correio da nova ferramenta passa nos recetores reais; a antiga continua a passar para o que ainda flui por ela
Depois do escoamento	Acompanhe os relatórios agregados DMARC até os seletores da ferramenta antiga deixarem de aparecer (as filas de reenvio e os reencaminhamentos correm durante dias — conte com uma semana ou mais), depois retire os registos e a conta	Seletores antigos ausentes dos relatórios ≥ 7 dias antes da remoção

A linha a negrito é onde as migrações se salvam ou se perdem: todas as verificações nela podem ser feitas dias antes da transição, com risco zero para o correio em produção. A mecânica de retirada de seletores — incluindo porque é que republicar com um p= vazio é melhor do que apagar — está coberta no runbook de rotação; esta tabela é sobre sequenciar a mudança de ferramenta em si.

Como corrijo o DKIM depois da mudança?

Execute a verificação gratuita em defaults.exposed antes de tocar no DNS. Lê os seus registos em produção e mostra o que os recetores realmente veem — incluindo alvos de CNAME que ficaram com a zona acrescentada e seletores que não resolvem.
Liste os registos DKIM que a nova ferramenta espera. A partir da consola de administração dela — para fornecedores de caixas de correio, os guias de configuração do Google Workspace e do Microsoft 365 mostram onde; as ferramentas de newsletters e CRM listam os seus CNAMEs em autenticação de domínio (veja emails de Mailchimp/Brevo/Klaviyo a falhar o DMARC).
Verifique o valor guardado de cada registo com dig CNAME <name> +short e compare-o carácter a carácter com o que a ferramenta pediu. Um alvo terminado no seu próprio domínio = zona acrescentada; volte a introduzi-lo e, se o painel continuar a acrescentar, adicione o ponto final (ou remova-o, se o painel rejeitar pontos).
Verifique nos nameservers autoritativos. dig +short NS yourdomain.com, depois repita as verificações de CNAME @<esse nameserver>. Se a migração mudou de nameservers, verifique ambos os conjuntos — os recetores podem ainda consultar o antigo até a delegação propagar.
Volte a correr a verificação da ferramenta e envie uma mensagem de teste. O cabeçalho Authentication-Results deve mostrar dkim=pass com d= igual ao seu domínio — um resultado positivo no domínio por omissão da ferramenta não alinha para o DMARC.
Deixe os seletores da ferramenta antiga publicados até o correio dela escoar, depois retire-os deliberadamente. Volte então a verificar, e trabalhe o que mais for assinalado na página corrigir o DKIM.

Perguntas frequentes

Preciso ou não do ponto final no meu CNAME de DKIM? Depende inteiramente do painel. O ponto significa “nome absoluto — não acrescentes a minha zona”; alguns painéis exigem-no, alguns adicionam-no por si, alguns rejeitam-no. O único teste que conta é a saída de dig CNAME <selector>._domainkey.yourdomain.com +short depois de guardar: se o alvo terminar no seu próprio domínio, o painel acrescentou a zona e você precisa do ponto (ou de um formato de introdução diferente).

Posso apagar os registos DKIM da ferramenta antiga no dia da mudança? Não. O correio que a ferramenta antiga assinou ainda está em filas de reenvio e percursos de reencaminhamento, e apagar a chave para que ele aponta parte essas mensagens retroativamente. Mantenha os seletores antigos vivos até deixarem de aparecer nos seus relatórios agregados DMARC — uma semana ou mais — e também não feche a conta antiga antes disso.

O meu painel de DNS e a nova ferramenta dizem ambos “verificado”, mas os recetores continuam a falhar o DKIM. Como? Dois casos comuns: a ferramenta verificou contra uma consulta em cache enquanto os nameservers autoritativos servem outra coisa (consulte-os diretamente com dig @<ns>), ou o DKIM passa mas no domínio de assinatura por omissão da ferramenta em vez do seu, e o DMARC continua a falhar o alinhamento. A verificação distingue os dois.

Os registos DKIM das duas ferramentas podem coexistir durante a sobreposição? Sim — e devem. O DKIM não tem regra de registo único: cada seletor é o seu próprio nome DNS, portanto os registos das duas ferramentas vivem lado a lado sem conflito, o que torna gratuita a regra de manter os seletores antigos até ao escoamento. (O SPF é o oposto — dois registos v=spf1 anulam-no, razão pela qual o guia de migração do SPF é sobre fundir.)

Envie o relatório ao proprietário

Se está a fazer esta migração para um cliente ou para o seu empregador, feche-a com evidência. Quando a nova ferramenta assinar e alinhar, volte a executar a verificação gratuita e reencaminhe o relatório classificado ao dono do negócio: prova datada, em linguagem simples, de que a mudança deixou o domínio totalmente autenticado. É o comprovativo de que vão precisar na renovação do seguro cibernético e no próximo questionário de segurança de fornecedor — transforma “a migração está feita” de uma afirmação num documento.

Verifique o seu DKIM gratuitamente

Veja se os seletores da sua nova ferramenta resolvem — e exatamente o que corrigir — em privado e apenas para o proprietário.

Verifique o seu domínio → · O SPF partiu-se depois de mudar de fornecedor → · Corrigir o DKIM → · Configurar o DKIM no Google Workspace → · Apenas dados agregados. Dados armazenados e processados na UE.