Pular para o conteúdo

Aprenda

SPF, DKIM e DMARC, um registro de cada vez

Três registros no DNS do seu domínio mostram ao mundo que o seu e-mail é mesmo seu. Veja o que cada um faz, em que ordem configurar e como endurecer o DMARC sem perder e-mails de verdade.

Por que o servidor de e-mail pede uma prova

Qualquer pessoa pode digitar qualquer endereço no campo De de um e-mail. A RFC 7208, o padrão por trás do SPF, começa dizendo que e-mails podem ser forjados de várias formas. Então um servidor que recebe uma mensagem não pode simplesmente acreditar nela. Ele procura a prova no DNS do domínio de onde a mensagem diz que veio.

O DNS é uma lista pública de fatos sobre um domínio, e qualquer servidor pode lê-la. Cada item dessa lista é um registro DNS. Três registros importam para o e-mail, e cada um responde a uma pergunta diferente:

SPF
O servidor que enviou esta mensagem está na lista de remetentes permitidos do domínio?
DKIM
A mensagem traz uma assinatura do domínio? O Google diz que quem recebe usa o DKIM para confirmar que o dono do domínio realmente enviou a mensagem.
DMARC
O que fazer quando essas conferências falham? O Google diz que o DMARC orienta quem recebe sobre o que fazer com as mensagens que não passam no SPF nem no DKIM.

SPF: quem pode enviar pelo seu domínio

Um registro SPF é uma linha de texto no DNS do seu domínio. Ele lista os servidores que podem enviar e-mails por esse domínio. O Google diz que, quando uma mensagem chega, os servidores de quem recebe conferem o registro SPF para confirmar que a mensagem veio de servidores autorizados.

Este é o registro que o Google indica para um domínio que envia só pelo Google Workspace. O seu vai listar o seu próprio provedor.

example.com.  TXT  "v=spf1 include:_spf.google.com ~all"
v=spf1
Todo registro SPF começa com esta marca.
include:
Soma a lista de servidores de outro remetente. A página do Google manda usá-lo antes de cada domínio de remetente no seu registro.
~all
É o último termo. Ele sempre corresponde, então define o padrão para todo servidor que não está na lista. O til faz desse padrão um softfail, que a RFC 7208 chama de uma afirmação fraca de que o host provavelmente não está autorizado. O Google recomenda este final.
-all
O mesmo, mas o resultado é um fail, que a RFC chama de uma declaração explícita de que o cliente não está autorizado. Use só quando tiver certeza de que a lista está completa.

Dois limites pegam muita gente de surpresa.

DKIM: uma assinatura em cada mensagem

O DKIM coloca uma assinatura em cada mensagem. Quem envia o seu e-mail faz a assinatura com uma chave privada que só essa pessoa ou empresa tem. Quem recebe confere com a chave pública correspondente, que, nas palavras da RFC 6376, vem de consultar diretamente o domínio de quem assinou.

A chave fica num nome montado a partir de um seletor, um rótulo que quem assina escolhe para que um mesmo domínio possa ter várias chaves. A RFC 6376 diz que todas as chaves DKIM ficam num subdomínio chamado _domainkey. Para o seletor mail e o domínio example.com, quem recebe pede ao DNS este nome:

mail._domainkey.example.com.  TXT  "v=DKIM1; p=<public key>"

Você não cria a chave. O seu provedor de e-mail a gera e mostra o registro para publicar. Publique exatamente como ele mostra, no nome exato. Uma chave no nome errado é uma chave que ninguém encontra.

O Google diz que enviar para contas pessoais do Gmail exige uma chave DKIM de 1024 bits ou mais e recomenda uma chave de 2048 bits se o seu provedor de domínio permitir.

DMARC: o que fazer quando a prova falha

O campo De é o endereço que a pessoa vê. O SPF não confere esse endereço. Ele confere o que o servidor de envio anuncia, a identidade MAIL FROM ou HELO. O DKIM também não, porque separa quem assina de quem escreve. O DMARC fecha essa brecha. O Google diz que o domínio do campo De precisa estar alinhado com o domínio do SPF ou com o domínio do DKIM. Basta um dos dois.

Um registro DMARC fica em _dmarc, na frente do nome do seu domínio. Ele diz o que quem recebe deve fazer com uma mensagem que falha e para onde mandar relatórios sobre o que viu.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"
p=none
O dono não declara preferência sobre o que acontece com o e-mail que falha (nas palavras da RFC 9989, não expressa preferência). O Google recomenda começar por aqui.
p=quarantine
O dono considera suspeito o e-mail que falha: é possível que ele seja válido, mas a falha gera uma preocupação significativa.
p=reject
O dono encara cada falha como uma indicação clara de que o uso do nome de domínio não é válido.
rua=
Para onde quem recebe manda os relatórios agregados, que podem revelar e-mails que usam o seu domínio e não passam. Alguns serão de falsários. Outros serão de serviços seus que ainda não estão configurados.

Aponte o rua para um endereço criado só para os relatórios. Eles vêm num formato que a RFC 9989 recomenda que seja lido por máquina, e muitos serviços leem para você.

Do p=none a uma política mais rígida

Política mais rígida quer dizer quarantine ou reject. Ir para lá cedo demais transforma uma falha nos seus registros em e-mail perdido. A RFC 9989 explica por que o registro começa em none: para se certificar de que nada ficou de fora nas primeiras configurações de SPF e DKIM. A Microsoft aconselha avançar aos poucos, de none para quarantine e depois para reject, para evitar perda de e-mail sem querer.

Nenhum dos passos abaixo é regra de provedor. É um jeito de seguir esse conselho.

  1. Configure o SPF de cada serviço que envia pelo seu domínio e peça ao seu provedor de e-mail que assine com DKIM.
  2. Publique o DMARC em none, com um endereço rua usado só para relatórios. Por enquanto você não pede nada a quem recebe, só os relatórios.
  3. Leia os relatórios. A RFC 9989 diz que, dependendo da frequência dos seus envios, pode levar muitos meses lendo relatórios até você ter certeza de que todo o seu e-mail se autentica.
  4. Corrija cada serviço legítimo que falha. A RFC diz que essas falhas devem ser resolvidas antes de qualquer política mais rígida.
  5. Passe para quarantine e acompanhe os relatórios e as respostas que chegam. Passe para reject só quando os relatórios continuarem limpos.

Para as regras de remetente, talvez você nunca precise passar do none. O guia do Google diz que a política do DMARC pode ficar em none, e a regra da Microsoft para quem envia muito pede pelo menos p=none. Ir além é escolha sua. As regras pedem o registro, não uma política mais rígida.

Por que o e-mail de um app ganha um subdomínio

Imagine que o seu produto envia recibos e códigos de acesso e você também faz prospecção por e-mail. Os provedores guardam um histórico para cada domínio de envio. O Yahoo diz que cada IP e cada domínio DKIM tem uma reputação e manda não enviar e-mail em massa ou de marketing dos mesmos IPs que você usa para o e-mail que o seu produto envia. Se os dois tipos de e-mail dividem um domínio, dividem uma reputação.

Então envie o e-mail do app de um subdomínio só dele, como mail.example.com, e deixe a prospecção fora dele. A RFC 7208 diz que cada registro SPF fica no nome a que se refere, então o subdomínio precisa do seu próprio. Peça também ao provedor que assine o e-mail do subdomínio com uma chave publicada nele, para que o subdomínio tenha um domínio DKIM próprio.

O DMARC dá menos trabalho. O Google diz que, sem uma marca sp, os subdomínios herdam a política de DMARC do domínio principal. A RFC 9989 diz o mesmo e acrescenta que a política vale para os subdomínios a menos que a política do subdomínio seja descrita explicitamente com as marcas sp ou np. Um registro no domínio principal cobre o subdomínio até você dizer o contrário.

Um subdomínio não escapa das regras de volume. O Google soma o e-mail de um mesmo domínio principal para decidir quem é remetente em massa, e o exemplo dele divide o envio entre um domínio e um subdomínio e ainda conta como um remetente só. Para uma separação que se sustente, envie a prospecção de outro domínio.

O que o colding confere

O colding nunca assina o seu e-mail e nunca mexe no seu DNS. O seu provedor de e-mail assina, e você publica os registros. O colding só os lê.

Para cada caixa de e-mail, ele procura um registro SPF no domínio da própria caixa e um registro DMARC nesse domínio ou no domínio acima mais próximo que tenha um. Um DMARC em none conta. Os dois precisam existir para o domínio passar.

O DKIM nunca decide. O DNS não lista os seletores de um domínio, então o colding tenta os nomes que os provedores mais usam. Se acha uma chave, ele avisa. Se não acha, diz que a chave não foi verificada, nunca que falta, porque a sua pode ter outro nome.

Se o SPF ou o DMARC continuar faltando por 72 horas, o aquecimento e as campanhas deixam de usar essa caixa até uma conferência passar. Uma campanha em que todas as caixas falham pausa e diz o motivo. Se o DNS não responde, nada para: uma consulta que falhou não é um veredito. Veja como ler o estado do domínio de uma caixa pela API.

O colding não conta as consultas do SPF e não percebe um segundo registro SPF. Confira essas duas coisas você mesmo a cada remetente novo.

Quando um domínio envia o e-mail de um app e também campanhas, a página da caixa sugere um subdomínio para o e-mail do app. É só um conselho e não bloqueia nada.

Fontes

Lemos estas páginas em 5 de outubro de 2026. Elas estão em inglês. Se um provedor mudou a página desde então, vale o que a página dele diz, e este texto está desatualizado.

Continue lendo