Como autenticar um domínio de envio: guia de configuração de SPF, DKIM e DMARC

Para autenticar um domínio de envio, você publica três registros DNS que comprovam ao Gmail, ao Yahoo, ao Outlook e a todos os outros servidores receptores que as suas mensagens realmente são suas: o SPF lista os servidores autorizados a enviar em seu nome, o DKIM adiciona uma assinatura criptográfica a cada mensagem e o DMARC informa aos receptores o que fazer quando essas verificações falham. Feito de uma só vez, o processo costuma levar cerca de 30 minutos e é o passo mais importante que você pode dar para a entrega na caixa de entrada.

A versão resumida

1. Verifique o que já existe. Consulte seus registros SPF, DKIM e DMARC atuais para editá-los em vez de duplicá-los.
2. Publique um único registro SPF. Um único registro TXT na raiz do domínio que inclua todos os serviços que enviam e-mails em seu nome.
3. Publique o DKIM. O registro do seletor fornecido no seu painel, para que cada mensagem seja assinada.
4. Publique o DMARC com p=none. Comece em modo de monitoramento, com um endereço para receber relatórios.
5. Verifique. Execute o dig, envie uma mensagem de teste e leia os cabeçalhos.
6. Aplique a política. Analise os relatórios e depois passe para p=quarantine e p=reject.

O que significa autenticar um domínio de envio?

O e-mail foi concebido sem uma forma de verificar quem enviou uma mensagem. Qualquer pessoa pode digitar o seu endereço no campo From, e é por isso que phishing e falsificação são tão comuns. A autenticação fecha essa lacuna com três verificações complementares, cada uma respondendo a uma pergunta diferente do servidor receptor:

• Este servidor está autorizado a enviar em nome deste domínio? Isso é o SPF (Sender Policy Framework, definido na RFC 7208).
• A mensagem é realmente deste domínio e não foi alterada? Isso é o DKIM (DomainKeys Identified Mail, RFC 6376).
• O que deve acontecer se uma das verificações falhar, e quem recebe o relatório? Isso é o DMARC (RFC 7489).

Os receptores combinam os três em um sinal de confiança. As mensagens que se autenticam e se alinham ao seu domínio From constroem, com o tempo, uma reputação de domínio estável. As que não o fazem são filtradas, atrasadas ou rejeitadas e, em volumes maiores, hoje são recusadas de imediato pelos principais provedores de caixa postal.

SPF, DKIM e DMARC em resumo

	SPF	DKIM	DMARC
O que comprova	O servidor de envio está autorizado para o domínio	A mensagem foi assinada pelo domínio e não foi alterada em trânsito	As verificações se alinham ao domínio visível no From, e define a política
Onde fica no DNS	Registro TXT na raiz do domínio	TXT ou CNAME em selector._domainkey	Registro TXT em _dmarc
O que é verificado	Domínio do Return-Path (remetente do envelope) e IP de envio	Assinatura no cabeçalho DKIM-Signature	Domínio do cabeçalho From em relação aos resultados de SPF e DKIM
Sobrevive ao encaminhamento?	Normalmente não	Sim, se o conteúdo não for modificado	Passa se o DKIM passar e estiver alinhado
Principal causa de falha	Remetente ausente ou mais de 10 consultas	Seletor errado ou chave copiada incorretamente	Falta de alinhamento

Antes de começar: o que você precisa

• Acesso para editar o DNS do domínio (registrador, Cloudflare, cPanel ou seu provedor de DNS).
• Uma lista de todos os serviços que enviam e-mails em nome do seu domínio: sua conta do MigoSMTP, o e-mail corporativo (Google Workspace ou Microsoft 365), CRM, sistemas de cobrança e ferramentas de suporte.
• Uma caixa de e-mail para receber os relatórios DMARC, de preferência um endereço dedicado, como dmarc-reports no seu domínio.
• Os valores do include de SPF e do registro DKIM da página Domínios do painel do MigoSMTP.

Passo 1: verifique seus registros atuais

Registros duplicados são a causa mais comum de falhas de autenticação. Consulte o que já está publicado antes de adicionar qualquer coisa. No macOS ou no Linux use dig; no Windows use nslookup.

dig +short TXT example.com
dig +short TXT _dmarc.example.com

# Windows
nslookup -type=TXT example.com

Procure qualquer registro TXT que comece com v=spf1 (SPF) e qualquer um em _dmarc que comece com v=DMARC1. Se algum deles existir, você o editará em vez de adicionar outro.

Passo 2: adicione o registro SPF

O SPF é um único registro TXT na raiz do seu domínio. Ele lista os serviços autorizados a enviar e-mails usando o seu domínio como remetente do envelope (o Return-Path).

Sintaxe do registro SPF

v=spf1 include:YOUR-MIGOSMTP-INCLUDE include:_spf.google.com ~all

Parte	Significado
v=spf1	Obrigatório. Marca o registro como SPF versão 1.
include:domain	Autoriza tudo o que o próprio registro SPF desse domínio autoriza. Use o valor do seu painel do MigoSMTP.
ip4:203.0.113.10	Autoriza um endereço IPv4 ou uma faixa específica. O IPv6 usa ip6:.
a, mx	Autoriza os IPs dos registros A ou MX do seu domínio.
~all	Soft fail: tudo o que não estiver listado é suspeito, mas não é rejeitado de imediato. Comum enquanto você ainda está adicionando remetentes.
-all	Hard fail: tudo o que não estiver listado não é autorizado. Use quando tiver certeza de que todos os remetentes estão listados.

O limite de 10 consultas

A avaliação do SPF pode gerar no máximo 10 consultas DNS. Cada include, a, mx, exists e redirect conta, inclusive as consultas feitas dentro dos registros que você inclui. Se ultrapassar o limite, os receptores retornam um erro permanente, e o SPF falha para todas as mensagens. Mantenha a contagem baixa removendo serviços que você não usa mais, substituindo a e mx por faixas ip4 explícitas quando forem estáveis e movendo ferramentas pouco usadas para um subdomínio próprio.

Erros comuns de SPF

• Dois registros SPF no mesmo nome (reúna-os em um só).
• Usar +all, que autoriza a internet inteira.
• Digitar o valor do include com espaços extras ou sem os dois-pontos.
• Esquecer um remetente, como um sistema de cobrança ou uma central de atendimento, cujos e-mails então falham no SPF.
• Publicar o SPF no nome errado, como o host www em vez da raiz do domínio.

Passo 3: publique o registro DKIM

O DKIM adiciona uma assinatura digital a cada mensagem. Sua plataforma de envio assina os e-mails de saída com uma chave privada mantida em sigilo, e você publica no DNS a chave pública correspondente para que os receptores possam verificar a assinatura.

Seletores e onde o registro fica

Cada chave fica sob um nome chamado seletor, no formato selector._domainkey.yourdomain.com. O seletor permite publicar várias chaves ao mesmo tempo e rotacioná-las sem indisponibilidade. O painel do MigoSMTP mostra o nome e o valor exatos para o seu domínio.

Name:  selector1._domainkey.example.com
Type:  TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...(long public key)

TXT ou CNAME?

Algumas plataformas pedem que você publique a chave pública diretamente como um registro TXT. Outras fornecem um CNAME que aponta para um registro hospedado por elas, o que lhes permite rotacionar as chaves por você. Publique exatamente o tipo que o seu painel mostrar. Não converta um no outro.

Tamanho da chave e formatação

• Use chaves RSA de 2048 bits quando disponíveis. Chaves de 1024 bits ainda são aceitas por muitos receptores, mas são consideradas fracas.
• Uma chave de 2048 bits tem mais de 255 caracteres, e uma única string de DNS não pode ultrapassar 255 caracteres. Seu provedor de DNS precisa dividir o valor em várias strings entre aspas dentro de um único registro TXT. A maioria dos painéis faz isso automaticamente; se o seu não fizer, divida manualmente.
• Copie o valor sem quebras de linha adicionais nem aspas tipográficas e não o envolva em aspas extras, a menos que o seu provedor de DNS exija.

Rotação

Rotacione as chaves DKIM a cada seis a doze meses, ou imediatamente se houver suspeita de exposição de uma chave privada. Publique primeiro o novo seletor, mude a assinatura para ele e exclua o seletor antigo somente depois que os e-mails assinados com ele terminarem de chegar.

Passo 4: publique o registro DMARC

O DMARC vincula o SPF e o DKIM ao domínio que seus destinatários realmente veem na linha From e informa aos receptores o que fazer com os e-mails que falham. É um registro TXT em _dmarc.yourdomain.com. Comece em modo de monitoramento para ver quem está enviando em seu nome antes de aplicar qualquer restrição.

Name:  _dmarc.example.com
Type:  TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1

Tag	O que faz	Valor típico
v	Versão. Deve vir primeiro.	DMARC1
p	Política para e-mails que falham: none (monitorar), quarantine (pasta de spam) ou reject (recusar).	none no início
rua	Para onde são enviados os relatórios agregados diários.	mailto:dmarc-reports@example.com
ruf	Para onde são enviadas amostras de falhas. Poucos receptores as enviam.	Opcional
pct	Porcentagem dos e-mails com falha à qual a política se aplica, usada durante a implantação gradual.	25, 50, 100
sp	Política para subdomínios, se for diferente da do domínio principal.	Igual a p, salvo necessidade
adkim, aspf	Modo de alinhamento: r (relaxado) ou s (estrito).	r (relaxado) é o padrão
fo	Quando gerar relatórios de falha.	1

O que "alinhamento" realmente significa

O DMARC passa quando o SPF ou o DKIM passa e o domínio aprovado se alinha ao domínio From. Com alinhamento relaxado, um subdomínio do domínio From conta como alinhado; assim, um Return-Path de bounce.example.com se alinha a um From de news@example.com. Com alinhamento estrito, os domínios precisam ser idênticos. A causa mais comum de "o SPF passa, mas o DMARC falha" é um Return-Path ou domínio DKIM que pertence à sua plataforma de envio em vez de a você. Ative um Return-Path personalizado e o seu próprio domínio de assinatura DKIM para resolver.

Passo 5: verifique se tudo funciona

Confira os registros no DNS

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com

Cada comando deve retornar o registro que você publicou. Se nada voltar, o registro está no nome errado ou ainda não se propagou. Aguarde o TTL expirar e teste novamente.

Envie uma mensagem de teste e leia os cabeçalhos

1. Envie uma mensagem do seu domínio autenticado para um endereço do Gmail que você controle.
2. Abra a mensagem, clique no menu de três pontos e selecione Mostrar original.
3. No topo você verá SPF, DKIM e DMARC, cada um com PASS ou FAIL.
4. Confirme que o domínio exibido ao lado de cada PASS corresponde ao seu domínio From.

Implante o DMARC com segurança: de p=none a p=reject

O objetivo é chegar a p=reject, porque essa é a única política que impede terceiros de falsificar o seu domínio. Mas ir direto para ela sem cautela pode bloquear e-mails legítimos de ferramentas das quais você se esqueceu. Avance por etapas e deixe os relatórios guiarem você.

Etapa	Política	Duração	O que fazer
1. Monitorar	p=none	2 a 4 semanas	Leia os relatórios agregados. Liste todas as origens que enviam em nome do seu domínio e corrija ou autorize cada uma das legítimas.
2. Quarentena parcial	p=quarantine; pct=25	1 a 2 semanas	Os e-mails com falha em 25 por cento do tráfego vão para o spam. Fique atento a reclamações de e-mails ausentes.
3. Quarentena total	p=quarantine	2 semanas	Eleve o pct para 100 quando os relatórios mostrarem que apenas origens não autorizadas estão falhando.
4. Rejeição	p=reject	Contínuo	Passe para reject, aumentando o pct em etapas, se desejar. Continue lendo os relatórios todo mês.

Os relatórios agregados do DMARC chegam como arquivos XML compactados e não foram feitos para leitura manual. Use um analisador de relatórios DMARC, gratuito ou pago, para transformá-los em uma tabela com origens de envio, volumes e resultados de aprovação ou falha.

Requisitos do Gmail, do Yahoo e da Microsoft para remetentes em massa

Desde fevereiro de 2024, o Gmail e o Yahoo passaram a aplicar regras de autenticação e de cancelamento de inscrição a quem envia em volume, e a Microsoft começou a aplicar requisitos comparáveis às caixas postais de consumidores do Outlook.com a partir de maio de 2025. Em resumo:

Requisito	Todos os remetentes	Remetentes em massa (cerca de 5.000+ mensagens por dia ao provedor)
SPF ou DKIM	Obrigatório	Ambos obrigatórios
Registro DMARC	Recomendado	Obrigatório, pelo menos p=none, alinhado ao From
Cancelamento de inscrição com um clique	Não exigido para e-mails transacionais	Obrigatório para e-mails de marketing e de assinantes (cabeçalhos da RFC 8058); atenda aos pedidos em até dois dias
Taxa de reclamações de spam	Mantenha baixa	Fique abaixo de 0,10 por cento e nunca chegue a 0,30 por cento (Google Postmaster Tools)
DNS direto e reverso válidos, TLS	Obrigatório	Obrigatório

Os provedores podem alterar os limites, portanto consulte as diretrizes atuais de cada um. Os links estão na lista de referências no final deste guia.

Separe e-mails de marketing e transacionais com subdomínios

A reputação é monitorada por domínio e IP de envio. Se uma campanha promocional gerar reclamações, você não quer que os e-mails de redefinição de senha caiam no spam. O padrão habitual é um subdomínio por fluxo:

Fluxo	Exemplo de endereço From	Por que separar
Transacional	noreply@mail.example.com	Precisa chegar sempre com rapidez. Baixo volume e alto engajamento mantêm a reputação elevada.
Marketing	hello@news.example.com	Maior volume e mais reclamações. Os problemas ficam contidos.
E-mail corporativo	name@example.com	As caixas postais dos seus colaboradores ficam livres do risco do envio em massa.

Cada subdomínio precisa dos próprios registros SPF e DKIM. Um registro DMARC no domínio principal protege os subdomínios por padrão; adicione uma tag sp= ou um registro separado no subdomínio se precisar de uma política diferente.

Erros comuns de autenticação e como corrigi-los

Sintoma	Causa provável	Solução
SPF permerror ou "too many DNS lookups"	Mais de 10 consultas ou um erro de sintaxe	Remova includes não usados, converta faixas estáveis para ip4 e mova remetentes raros para um subdomínio.
Multiple SPF records found	Dois registros TXT começam com v=spf1	Reúna-os em um único registro.
DKIM: no key for signature	Nome do seletor errado ou registro não publicado	Verifique o seletor no cabeçalho DKIM-Signature e compare-o com o nome no seu DNS.
DKIM: body hash did not verify	A mensagem foi alterada após a assinatura (rodapés, reescrita de links por outro sistema)	Desative a etapa que modifica a mensagem ou mova-a para antes da assinatura.
Falha no DMARC com SPF aprovado	O domínio do Return-Path não se alinha ao From	Use um Return-Path personalizado no seu próprio domínio.
Falha no DMARC com DKIM aprovado	O domínio d= do DKIM não se alinha ao From	Assine com o seu próprio domínio, não com o padrão da plataforma.
Registro não encontrado	Nome de host errado, ponto final ou domínio acrescentado duas vezes pelo seu painel de DNS	Muitos painéis acrescentam o domínio automaticamente. Digite apenas a parte que vem antes dele, por exemplo selector1._domainkey.
Registros não atualizam	Registro antigo em cache	Aguarde o TTL expirar. Reduza o TTL antes de alterações planejadas.

Checklist de autenticação

• Um registro SPF na raiz do domínio, com menos de 10 consultas, terminando em ~all ou -all.
• Registro de seletor DKIM publicado, de 2048 bits se o seu provedor de DNS permitir.
• Registro DMARC em _dmarc com p=none e um endereço rua funcionando.
• Return-Path e domínio DKIM personalizados, para que ambos se alinhem ao seu domínio From.
• A mensagem de teste mostra SPF, DKIM e DMARC como PASS.
• Relatórios DMARC revisados semanalmente durante a implantação.
• E-mails de marketing e transacionais separados por subdomínio.
• Lembrete no calendário para rotacionar as chaves DKIM.

Leituras complementares e fontes

• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 7489: Domain-based Message Authentication, Reporting and Conformance (DMARC)
• RFC 8058: Signaling One-Click Functionality for List Email Headers
• Google: Email sender guidelines
• Yahoo: Sender best practices
• Guias relacionados: Guia de aquecimento de e-mail e Códigos de bounce SMTP explicados.