Identifique todos os serviços de envio
Antes de editar DNS, liste os sistemas que enviam usando seu domínio. Inclua caixas postais, formulário do site, serviço transacional, newsletter, cobrança e atendimento. Site e e-mail podem estar em empresas diferentes. Mudar a hospedagem da página não transfere necessariamente o serviço que envia ou assina mensagens.
Para cada emissor, anote domínio visível em From, remetente de envelope usado nas devoluções, domínio de assinatura DKIM e instruções atuais do provedor. Esse inventário ajuda mais do que adicionar qualquer valor sugerido. Remover um include antigo ou trocar um seletor sem conferir seu emissor pode interromper mensagens que antes funcionavam.
Separe configuração DNS de autenticação
Um verificador recupera a configuração publicada. Pode mostrar SPF, chave pública DKIM e DMARC em um nome específico. Isso é um passo diagnóstico, mas não prova que uma mensagem real usou o IP correto, carregou assinatura válida ou respeitou alinhamento.
A ferramenta Savvy Toolkit inspeciona os nomes exatos informados. Não envia e-mail, não lê caixas postais, não verifica o corpo de mensagens, não percorre todas as dependências SPF e não afirma descobrir políticas DMARC herdadas. Interprete cada resultado dentro desse alcance. Registro ausente, aviso de sintaxe e tempo esgotado no DNS descrevem problemas distintos, não três versões de falha de autenticação.
Registros e autenticação da mensagem são diferentes
Publique uma política SPF no nome correto
SPF declara quais sistemas podem enviar com a identidade de envelope correspondente. O TXT começa com v=spf1. Dois registros SPF independentes no mesmo nome são problema; não mantenha ambos esperando que o receptor escolha. Combine somente os mecanismos necessários aos emissores ativos, conforme as instruções dos serviços.
O painel DNS pode dividir um TXT longo em várias strings entre aspas. Elas formam um registro ao serem concatenadas e não equivalem a registros independentes. Confira também o nome consultado: um subdomínio de devoluções pode usar política diferente do domínio visível. Copiar a política principal para um nome errado não resolve essa relação.
Entenda mecanismos e limites SPF
ip4 e ip6 autorizam faixas de endereços. include consulta outra política; redirect delega a avaliação segundo regras próprias. Não são atalhos intercambiáveis. O mecanismo all e seu qualificador definem o resultado dos emissores que não corresponderam antes. Escolha a configuração com o inventário completo.
A avaliação tem limites. SPF permite dez termos que provocam pesquisas DNS, inclusive dependências aninhadas. Entre eles estão include, a, mx, ptr, exists e redirect; não se contam todos os caracteres nem todas as faixas IP. Contar apenas include visível não verifica o caminho inteiro. Evite substituir políticas gerenciadas por IPs fixos sem atualização confiável.
Encontre o seletor DKIM real
A assinatura DKIM informa o domínio em d= e o seletor em s=. A chave normalmente fica em seletor._domainkey.domínio-de-assinatura. O emissor escolhe o seletor e pode alterá-lo na rotação. A ausência de um nome adivinhado, como default, não demonstra que o domínio não assina.
Leia uma mensagem legítima recebida ou a tela de configuração do provedor. Use o domínio d= daquela assinatura, mesmo que seja diferente do remetente visível. Alguns provedores publicam CNAME para uma chave gerenciada. Guarde o nome solicitado e o alias retornado para distinguir delegação de dados ausentes em um chamado.
Um erro comum é colar o nome DKIM completo no campo que espera somente o seletor. Para mail2026._domainkey.example.com, o seletor é mail2026 e o domínio de assinatura é example.com. Mantenha esses valores separados. Compare também o nome consultado com o nome esperado nas instruções do provedor antes de editar qualquer registro. Um erro de digitação na consulta pode explicar a resposta ausente sem exigir nenhuma mudança em uma zona DNS que já está funcionando corretamente.
Uma chave pública não valida a mensagem
O registro publica informações usadas para verificar assinaturas. O emissor ainda precisa ter a chave privada e assinar corretamente as partes relevantes. Alterações durante o transporte podem afetar a verificação. Ler uma chave não autentica corpo, assunto ou remetente de uma mensagem específica.
Um p= vazio pode revogar uma chave DKIM. Uma chave antiga também pode ser trocada durante rotação. Mantenha seletores anteriores pelo período de sobreposição recomendado, em vez de apagá-los imediatamente. Chaves privadas pertencem ao sistema emissor, nunca a um TXT público, formulário do navegador ou captura de suporte.
Leia DMARC com o alinhamento
DMARC relaciona autenticação ao domínio visível no campo From. Um SPF aprovado para um domínio de devolução sem relação não basta. Uma assinatura DKIM válida de outro domínio também não está automaticamente alinhada. A mensagem pode passar por SPF aprovado e alinhado ou DKIM aprovado e alinhado.
none, quarantine e reject descrevem o tratamento solicitado para mensagens que falham em DMARC. p=none é uma escolha de monitoramento e não significa que mensagens legítimas falharam. Uma política mais rígida pode prejudicar emissores ainda mal configurados. Revise inventário e mensagens reais antes de exigir mais. O receptor também pode aplicar critérios locais.
Consulte a especificação atual
RFC 9989 substitui a descrição central anterior do RFC 7489. A descoberta de política agora descreve um percurso DNS limitado, em vez de depender apenas da lista de sufixos públicos. A especificação introduz t para testes e retira pct do formato central. Ferramentas e receptores antigos ainda podem interpretar regras anteriores.
Não copie exemplos antigos de implantação gradual sem conferir a orientação atual do provedor. A ferramenta mostra o _dmarc exato consultado, sem descobrir todas as políticas herdadas ou calcular alinhamento somente com um domínio. Relatórios agregados estão no RFC 9990. Um destino de relatórios em outro domínio também exige a autorização apropriada.
Confira DNS e depois envie mensagens
Guarde os valores anteriores e altere uma parte por vez. Confira conta autoritativa, nome, tipo e conteúdo antes de salvar. Um campo que acrescenta a zona automaticamente pode duplicar o domínio quando recebe o nome completo. O painel parece correto, mas o registro foi publicado no lugar errado.
Depois da publicação, compare respostas públicas e considere caches de acordo com a validade anterior. Envie uma mensagem legítima de cada serviço para uma conta que você controla. Leia a autenticação no receptor e compare domínio de envelope, DKIM d= e s= e From visível. Uma consulta DNS não substitui essa etapa.
Investigue entrega sem prometer caixa de entrada
SPF, DKIM e DMARC fazem parte da entrega, mas não formam uma nota completa de reputação. Os receptores também consideram comportamento de envio, reclamações, formato, TLS, DNS reverso e políticas próprias. Leia o código de devolução e as exigências atuais do receptor antes de atribuir toda rejeição a um TXT.
Um relatório útil contém domínio, seletor, nomes consultados, registros observados, horários e autenticação com dados sensíveis ocultos de uma mensagem controlada. Não publique conteúdo completo de caixas postais ou chaves privadas. Corrija a divergência, teste cada emissor novamente e limite a conclusão aos registros e mensagens verificados. Isso não garante a entrega de todo e-mail futuro.