Como configurar DMARC, DKIM e SPF para o seu domínio

Se seu domínio não tem SPF, DKIM e DMARC configurados, seus e-mails já estão caindo no spam. Ou pior, alguém está enviando e-mail como se fosse você.

Google e Yahoo tornaram a autenticação de remetentes em massa obrigatória em fevereiro de 2024. Desde então, os requisitos só ficaram mais rígidos. No começo de 2026, domínios sem autenticação adequada enfrentam rejeição direta — não só ida pra pasta de spam, mas hard bounce. A Microsoft seguiu com aplicação parecida nos domínios Outlook e Hotmail.

Isso não é mais opcional. Aqui está como configurar os três registros corretamente.

O que esses três registros realmente fazem

SPF, DKIM e DMARC são mecanismos de autenticação baseados em DNS. Cada um faz algo diferente:

• SPF diz aos servidores receptores quais endereços IP podem enviar e-mail pelo seu domínio.
• DKIM anexa uma assinatura criptográfica a cada e-mail enviado, provando que ele não foi adulterado em trânsito.
• DMARC amarra SPF e DKIM com uma política que diz aos receptores o que fazer quando a autenticação falha.

Eles funcionam como um sistema. Só SPF não vai te salvar. Só DKIM também não. Você precisa dos três.

SPF: autorize seus remetentes

SPF (Sender Policy Framework) é um registro TXT no seu domínio que lista cada servidor permitido a enviar e-mail em seu nome.

O registro DNS

Adicione um registro TXT no seu domínio raiz (seudominio.com):

v=spf1 include:sendkit.dev include:_spf.google.com ~all

Destrinchando:

• v=spf1 — declara que é um registro SPF.
• include:sendkit.dev — autoriza os servidores de e-mail da Sendkit.
• include:_spf.google.com — autoriza o Google Workspace (se você usa).
• ~all — soft-fail pra qualquer coisa não listada. Use -all pra hard fail depois que estiver confiante na sua configuração.

O limite de 10 lookups

SPF tem um limite rígido de 10 lookups de DNS. Cada mecanismo include:, a:, mx: e redirect= conta como um lookup. Includes aninhados também contam — se include:sendkit.dev referencia outros dois domínios, já são três lookups no total.

Passou de 10 e todo o seu registro SPF vira inválido. Os receptores tratam como se você não tivesse SPF nenhum.

Isso pega times que usam várias ferramentas SaaS pra e-mail. Seu provedor transacional, sua ferramenta de marketing, seu helpdesk, seu CRM — cada um adiciona diretivas include:. Soma rápido.

Como ficar abaixo do limite:

• Audite seu registro SPF trimestralmente. Remova serviços que você não usa mais.
• Use ip4: e ip6: pra IPs estáticos em vez de include: — mecanismos de IP não contam pro limite de lookups.
• Considere ferramentas de SPF flattening se você realmente precisa de mais de 10 serviços (embora isso traga sua própria carga de manutenção).

Erros comuns de SPF

Múltiplos registros SPF. Você só pode ter um registro TXT de SPF por domínio. Se adicionar um segundo, os dois ficam inválidos. Junte em um só registro.

Usar +all. Isso diz aos receptores que literalmente qualquer um pode enviar como seu domínio. Nunca faça isso.

Esquecer subdomínios. Registros SPF não são herdados. Se você envia de mail.seudominio.com, ele precisa do próprio registro SPF.

DKIM: assine seus e-mails

DKIM (DomainKeys Identified Mail) usa criptografia de chave pública. Seu servidor de envio assina cada mensagem enviada com uma chave privada. O servidor receptor busca a chave pública no seu DNS e verifica a assinatura.

Se a assinatura bate, o receptor sabe que o e-mail veio mesmo da sua infraestrutura e não foi modificado depois do envio.

O registro DNS

Registros DKIM são registros TXT publicados em um subdomínio específico:

selector._domainkey.seudominio.com

O selector é uma label escolhida pelo seu provedor de e-mail. Permite que você tenha várias chaves DKIM pra serviços diferentes. Um registro típico se parece com isso:

Host: sendkit._domainkey.seudominio.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2pmMpTj...

O valor p= é sua chave pública, codificada em base64. Vai ser longa — geralmente 400+ caracteres pra uma chave de 2048 bits.

Tamanho da chave importa

Use chaves de 2048 bits no mínimo. Alguns guias mais antigos ainda referenciam chaves de 1024 bits, mas elas são consideradas fracas pelos padrões atuais e alguns receptores começam a sinalizá-las. A maioria dos provedores, Sendkit incluída, gera chaves de 2048 bits por padrão.

Como a Sendkit lida com DKIM

Quando você adiciona um domínio na Sendkit, ela gera um par de chaves DKIM único pra você. Você recebe um registro CNAME pra adicionar no seu DNS — a Sendkit hospeda a chave pública, então a rotação de chaves acontece automaticamente sem você mexer no DNS de novo.

A abordagem de CNAME fica assim:

Host: sendkit._domainkey.seudominio.com
Type: CNAME
Value: sendkit._domainkey.sendkit.dev

Isso é mais limpo do que colar chaves públicas brutas em registros TXT e permite que a Sendkit rotacione chaves em uma programação sem quebrar sua configuração.

Erros comuns de DKIM

Quebras de linha no registro TXT. Alguns provedores de DNS não lidam bem com valores TXT longos. Se seu registro DKIM não está validando, cheque se o provedor dividiu o valor em múltiplas strings incorretamente.

Selector errado. Cada provedor usa um selector diferente. Garanta que você está publicando a chave no subdomínio exato que o provedor especifica.

Não assinar todo o e-mail de saída. Se você tem vários serviços de envio e só um tem DKIM configurado, mensagens não assinadas vão falhar no alinhamento DMARC (mais sobre isso a seguir).

DMARC: defina sua política

DMARC (Domain-based Message Authentication, Reporting & Conformance) faz duas coisas: diz aos receptores como lidar com mensagens que falham em SPF e DKIM, e te envia relatórios sobre resultados de autenticação.

O registro DNS

Adicione um registro TXT em _dmarc.seudominio.com:

v=DMARC1; p=none; rua=mailto:[email protected]

Os parâmetros chave:

• v=DMARC1 — versão do protocolo.
• p= — a política. O que os receptores devem fazer com mensagens que falham?
• rua= — pra onde enviar relatórios agregados (arquivos XML com estatísticas de autenticação).

Níveis de política

DMARC tem três níveis de política. Comece permissivo e aperte com o tempo:

p=none — Só monitora. Mensagens que falham ainda são entregues normalmente. Você recebe relatórios mostrando o que está passando e falhando. Comece aqui.

p=quarantine — Mensagens que falham vão pro spam. Migre pra cá depois que seus relatórios mostrarem que o e-mail legítimo está passando consistentemente.

p=reject — Mensagens que falham são rejeitadas de vez. Esse é o objetivo. Impede que alguém faça spoofing do seu domínio.

Uma timeline realista de rollout:

1. Faça deploy de p=none e monitore relatórios por 2-4 semanas.
2. Revise os relatórios. Corrija qualquer remetente legítimo que não está alinhado.
3. Migre pra p=quarantine por mais 2-4 semanas.
4. Quando estiver limpo, mude pra p=reject.

Alinhamento DMARC

Aqui está a parte que a maioria das pessoas pula. DMARC não checa apenas se SPF e DKIM passam — ele checa alinhamento. O domínio no header From: precisa bater com o domínio que passou em SPF ou DKIM.

Se seu endereço From: é [email protected] mas o SPF passa pra bounce.sendkit.dev, isso é uma passagem de SPF mas uma falha de alinhamento DMARC. Você precisa que SPF ou DKIM (ou os dois) alinhem com o domínio From: pro DMARC passar.

É exatamente por isso que DKIM importa tanto pra provedores de e-mail transacional. A Sendkit assina mensagens com a chave DKIM do seu domínio, então o alinhamento DKIM passa mesmo quando o envelope sender é diferente.

Um registro DMARC mais completo

Depois da fase de monitoramento:

v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=s; aspf=s; pct=100

• ruf= — relatórios forenses (detalhes de falha por mensagem). Nem todos os provedores enviam.
• adkim=s — alinhamento DKIM estrito (bate exato com o domínio, sem subdomínios).
• aspf=s — alinhamento SPF estrito.
• pct=100 — aplica a política a 100% das mensagens. Você pode subir isso gradualmente, por exemplo, pct=25 pra começar.

Verifique sua configuração

Não confie que suas mudanças de DNS propagaram direito. Verifique.

Usando dig

Checar SPF:

dig +short TXT seudominio.com | grep spf

Checar DKIM (troque sendkit pelo seu selector):

dig +short TXT sendkit._domainkey.seudominio.com

Checar DMARC:

dig +short TXT _dmarc.seudominio.com

Usando nslookup (Windows)

nslookup -type=TXT seudominio.com
nslookup -type=TXT sendkit._domainkey.seudominio.com
nslookup -type=TXT _dmarc.seudominio.com

Ferramentas online

Algumas ferramentas gratuitas que vale deixar nos favoritos:

• MXToolbox (mxtoolbox.com/SuperTool) — checa SPF, DKIM e DMARC de uma vez.
• Google Admin Toolbox (toolbox.googleapps.com/apps/checkmx) — bom pra verificar configs específicas do Google.
• Mail Tester (mail-tester.com) — envie um e-mail de teste e receba uma pontuação de entregabilidade com resultados específicos de autenticação.

Envie um e-mail de teste real depois de configurar tudo. Cheque os headers brutos da mensagem recebida — procure por headers Authentication-Results mostrando spf=pass, dkim=pass e dmarc=pass.

Erros comuns e como corrigir

Registro SPF excede o limite de 10 lookups. Rode seu SPF por um contador de lookups (o MXToolbox faz isso). Remova includes não usados. Achate se necessário.

Registro DKIM não encontrado. Cheque duas vezes o nome do selector e o subdomínio exato. Propagação de DNS pode levar até 48 horas, mas a maioria das mudanças aparece em minutos. Verifique também se seu provedor de DNS não está truncando silenciosamente valores TXT longos.

Relatórios DMARC indo pra um domínio diferente. Se seu endereço rua está em um domínio diferente daquele publicando o registro DMARC, o domínio receptor precisa de um registro DNS especial pra autorizá-lo: seudominio.com._report._dmarc.dominiorelatorio.com TXT "v=DMARC1".

E-mail de subdomínio falhando no DMARC. Políticas DMARC se aplicam a subdomínios via a tag sp=. Se você não definir, subdomínios herdam a política do domínio pai. Se você envia de notificacoes.seudominio.com, garanta que ele tenha seu próprio SPF e DKIM ou que seu registro DMARC o contemple.

Usar p=reject cedo demais. Você vai bloquear e-mail legítimo. Sempre comece com p=none, leia os relatórios, corrija problemas de alinhamento, depois escale. Pular a fase de monitoramento é a causa mais comum de dano de entregabilidade auto-infligido.

Esquecer de autenticar todos os remetentes. Audite cada serviço que envia e-mail como seu domínio. Plataformas de marketing, ferramentas de helpdesk, sistemas de billing, alertas de monitoramento — cada um precisa ser coberto por SPF e idealmente assinar com DKIM usando seu domínio.

Fechando

Acertar SPF, DKIM e DMARC é uma configuração única que compensa pra sempre. Seus e-mails caem na caixa de entrada em vez do spam. Ninguém consegue fazer spoof do seu domínio. E você atende aos requisitos de autenticação que os grandes provedores agora aplicam.

A ordem importa: configure SPF primeiro, depois DKIM, depois DMARC em modo monitor. Se dê algumas semanas de dados de relatório antes de apertar a política DMARC. Correr pra p=reject sem esses dados é pedir pra ter problema.

Se você está usando a Sendkit pra e-mail transacional, a maior parte do trabalho pesado é resolvida pra você — chaves DKIM são geradas e rotacionadas automaticamente, e os registros DNS que você precisa são fornecidos no dashboard. Você só precisa adicioná-los no seu DNS e verificar.