Configuração de SPF, DKIM e DMARC: guia passo a passo para cold email

Se você envia cold emails a partir do seu próprio domínio, três registros DNS decidem se os servidores receptores acreditam que o e-mail é realmente seu: SPF, DKIM e DMARC. Sem eles, até um primeiro e-mail bem escrito pode ser filtrado antes que alguém o leia.

Este guia é para fundadores e equipes de vendas que fazem prospecção a partir de um endereço como you@yourcompany.com, normalmente pelo Google Workspace. Nós, do Outreach, percorremos cada registro na ordem em que você deve configurá-lo, mostramos os formatos de registro exatamente como as páginas de ajuda do Google e as RFCs os publicam e apontamos os erros que fazem um registro parecer correto enquanto falha em silêncio.

Você não precisa ser especialista em DNS. Precisa de acesso às configurações de DNS do seu domínio (no seu registrador ou provedor de DNS) e, para o DKIM, de acesso de administrador ao Google Workspace.

O que são SPF, DKIM e DMARC, em uma frase cada?

O SPF lista os servidores autorizados a enviar e-mails pelo seu domínio, o DKIM adiciona uma assinatura criptográfica que comprova que uma mensagem não foi falsificada nem alterada, e o DMARC diz aos servidores receptores o que fazer quando uma mensagem falha nessas verificações. Os três são publicados como registros TXT no DNS do seu domínio.

Registro	Onde fica	O que responde
SPF	`yourcompany.com` (host `@`)	“Este servidor tem permissão para enviar e-mails por este domínio?”
DKIM	`google._domainkey.yourcompany.com`	“Esta mensagem foi assinada pelo domínio e não foi alterada?”
DMARC	`_dmarc.yourcompany.com`	“Se uma verificação falha, o que o dono do domínio quer que seja feito?”

Eles funcionam em conjunto. O SPF e o DKIM comprovam, cada um, algo bem específico; o DMARC liga essas provas ao endereço que as pessoas realmente veem no cabeçalho From.

Esses registros são mesmo obrigatórios para cold email?

Sim — pelo menos o SPF ou o DKIM é obrigatório para todo remetente que envia ao Gmail e ao Yahoo, e os remetentes em massa precisam dos três. Isso não é uma sugestão de boas práticas; está nas regras para remetentes publicadas pelos dois provedores.

As diretrizes para remetentes de e-mail do Google dizem que todos os remetentes devem “configurar a autenticação de e-mail do SPF ou DKIM para seus domínios de envio.” Os remetentes de “mais de 5.000 mensagens por dia para contas do Gmail” também devem “configurar o SPF e o DKIM”, além da “autenticação de e-mail DMARC para o seu domínio de envio”, e o domínio do cabeçalho From precisa estar alinhado com o domínio do SPF ou do DKIM. Essas regras entraram em vigor em 1º de fevereiro de 2024.

As melhores práticas do Sender Hub do Yahoo coincidem: todo remetente deve “implementar pelo menos SPF ou DKIM”, e os remetentes em massa devem “implementar SPF e DKIM” e “publicar uma política DMARC válida com pelo menos p=none.”

Um programa pequeno de cold email talvez nunca chegue a 5.000 mensagens por dia. Configure os três mesmo assim: não custa nada, leva uma tarde e evita que você precise descobrir onde fica o limite.

Como configurar o SPF?

Adicione um registro TXT no seu domínio raiz que comece com v=spf1, liste todos os serviços que enviam e-mails em seu nome e termine com ~all. Para um domínio que envia somente pelo Google Workspace, a página de configuração do SPF do Google fornece exatamente este registro:

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

Passos:

Acesse as configurações de DNS do seu provedor de domínio.
Crie um registro TXT. No campo de host ou nome, o Google orienta a digitar @ se você estiver adicionando o registro ao domínio raiz, e não a um subdomínio.
Cole o registro como valor e salve.
Aguarde. O Google informa que “pode levar até 48 horas para a autenticação SPF começar a funcionar.”

Se outros serviços também enviam e-mails a partir do seu domínio — uma ferramenta de newsletter, um CRM, um serviço de e-mail transacional —, cada um precisa do seu próprio include: no mesmo registro. A página do Google traz estes exemplos combinados:

v=spf1 include:_spf.google.com include:amazonses.com ~all
v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all
v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all

Use o valor de include que cada serviço de envio documenta para si; não tente adivinhá-lo.

O registro SPF deve terminar em ~all ou -all?

O guia de configuração do Google usa ~all, e esse é o padrão seguro enquanto você ainda está descobrindo todos os serviços que enviam e-mails em seu nome. Os dois finais têm significados diferentes na RFC 7208, o padrão do SPF:

~all (softfail) é “uma declaração fraca, feita pelo ADMD que publica o registro, de que o host provavelmente não está autorizado.”
-all (fail) é “uma declaração explícita de que o cliente não está autorizado a usar o domínio na identidade informada.”

Com -all, um serviço de envio que você esqueceu de incluir sofre uma falha rígida. Depois que o DMARC estiver ativo e os relatórios dele mostrarem todas as fontes legítimas passando na verificação, o final do SPF importa menos, porque a política do DMARC passa a ser a instrução que os servidores receptores seguem.

Por que o SPF deixa de funcionar com includes demais?

Porque uma verificação SPF pode acionar no máximo 10 consultas de DNS; acima disso, o resultado inteiro vira um erro. A RFC 7208, seção 4.6.4 diz que as implementações “DEVEM limitar o número total desses termos a 10 durante a avaliação do SPF” e que “se esse limite for excedido, a implementação DEVE retornar ‘permerror’.”

Os termos que contam são include, a, mx, ptr, exists e o modificador redirect. O ponto crucial é que a contagem abrange a avaliação inteira — por isso, um include: que contém outros includes consome vários dos seus 10. A própria página do Google descreve isso como “um registro SPF pode ter até 10 tags include:”; a RFC é a leitura mais rigorosa, porque as consultas aninhadas também contam.

Se você adicionou várias ferramentas de vendas e marketing ao longo dos anos, remova as que não usa mais antes de adicionar novos includes.

O que acontece se um domínio tiver dois registros SPF?

O SPF falha com um erro — dois registros são tratados como uma configuração quebrada, e não como duas listas a combinar. A RFC 7208 diz que, quando existe mais de um registro v=spf1 para um domínio, a verificação “produz o resultado ‘permerror’.”

Uma forma comum de isso acontecer: alguém adiciona um segundo registro TXT para uma nova ferramenta em vez de editar o existente. A solução é unir os dois em um único registro com vários termos include:, como nos exemplos acima.

Como ativar o DKIM no Google Workspace?

Gere uma chave no Admin Console, publique-a como um registro TXT em google._domainkey e clique em “Iniciar autenticação.” A página de configuração do DKIM do Google descreve o caminho:

No Admin Console do Google, acesse Apps > Google Workspace > Gmail > Autenticar e-mails. (Você precisa do privilégio de administrador “Configurações do Gmail”.)
Escolha o domínio e gere um novo registro.
Escolha o tamanho da chave. O Google diz para escolher 2048 “se o provedor de domínio for compatível com chaves de 2048 bits”, porque “chaves mais longas são mais seguras do que chaves mais curtas”, e 1024 somente “se o host do domínio não for compatível com chaves de 2048 bits.”
Mantenha o seletor de prefixo padrão, google — o Google o chama de “a opção recomendada” para o Workspace.
O Google mostra um nome de host DNS, google._domainkey, e um valor TXT que começa com v=DKIM1. Copie os dois para um novo registro TXT no seu provedor de DNS.
De volta ao Admin Console, clique em Iniciar autenticação.

O valor TXT gerado pelo Google tem este formato (a chave em si é uma longa sequência de caracteres exclusiva do seu domínio):

v=DKIM1; k=rsa; p=MIIBIjANBgkqh...(your public key continues)

Prazo: o Google diz que “pode levar até 48 horas para a autenticação DKIM começar a funcionar” depois que você adiciona a chave. Se você acabou de configurar o Gmail para um novo domínio, o Google observa que é preciso “aguardar de 24 a 72 horas” antes de a chave DKIM ficar disponível no Admin Console.

Se outro serviço enviar e-mails em seu nome, ele fornecerá o próprio registro DKIM, com o próprio seletor. Publique esse também — várias chaves DKIM com seletores diferentes podem coexistir, ao contrário do SPF.

Como configurar o DMARC sem bloquear os seus próprios e-mails?

Publique primeiro um registro TXT em _dmarc.yourcompany.com com p=none, leia os relatórios e só depois torne a política mais rígida. A página de configuração do DMARC do Google diz: “Quando você começar a usar o DMARC, recomendamos definir a opção de política (p) como none.” Ela também aconselha que você “aguarde 48 horas depois de configurar o SPF e/ou o DKIM antes de configurar o DMARC.”

A página do Google traz este exemplo completo de registro:

v=DMARC1; p=reject; rua=mailto:postmaster@example.com, mailto:dmarc@example.com; pct=100; adkim=s; aspf=s

Esse exemplo mostra o estado final e mais rigoroso. Para um primeiro registro, basta o mesmo formato com uma política de monitoramento e um endereço para relatórios — por exemplo, v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com. A tag rua envia relatórios agregados a essa caixa de e-mail; o Google recomenda uma caixa ou um grupo exclusivo, porque os relatórios podem chegar em grande volume.

Os três valores de política, conforme definidos na especificação do DMARC:

Política	O que você pede que os servidores receptores façam
`p=none`	Nenhuma ação específica — apenas gerar relatórios
`p=quarantine`	Tratar as falhas como suspeitas (por exemplo, enviando para a pasta de spam)
`p=reject`	Rejeitar e-mails que falham na verificação do DMARC

Um domínio recebe um registro DMARC. Segundo a RFC 9989, se vários registros DMARC forem retornados, “todos eles são descartados” — ou seja, nenhuma política se aplica.

O que significa “alinhamento” e por que o DMARC falha quando o SPF passa?

O DMARC só passa quando o SPF ou o DKIM passa para um domínio que corresponde ao endereço do cabeçalho From que as pessoas veem. O SPF pode passar para o domínio do próprio serviço de envio enquanto o cabeçalho From mostra o seu — e, nesse caso, o DMARC ainda falha, porque o domínio aprovado não está alinhado.

A especificação do DMARC afirma que uma mensagem passa quando pelo menos um método de autenticação produz uma aprovação “com base em um identificador que está em alinhamento” (RFC 7489, agora continuada na RFC 9989). Por padrão, o alinhamento é relaxado (adkim e aspf têm r como padrão): mail.yourcompany.com e yourcompany.com contam como correspondentes porque compartilham o mesmo domínio organizacional. O modo estrito (s), como no exemplo do Google, exige uma correspondência exata.

Na prática, é por isso que o DKIM importa tanto para cold email: quando o seu serviço de envio assina com o seu domínio, o alinhamento do DKIM passa mesmo que o do SPF não passe.

O padrão DMARC mudou em 2026?

Sim. A RFC 9989, publicada em maio de 2026 como documento de trilha de padrões (Standards Track), torna obsoleta a RFC 7489 original — e remove a tag pct. Os registros v=DMARC1 existentes continuam funcionando.

A principal mudança que a maioria dos remetentes vai notar: pct (aplicar a política a apenas uma porcentagem dos e-mails que falham) deixou de existir. A RFC explica que “a experiência operacional mostrou que a tag ‘pct’ geralmente não era aplicada com precisão, a menos que o valor especificado fosse 0 ou 100.” No lugar dela há um indicador de teste, t=y, que pede aos servidores receptores que não apliquem a política declarada enquanto você a testa.

A página de ajuda do Google ainda mostra pct=100 no exemplo. Isso não quebra nada: a RFC 9989 diz que “tags desconhecidas DEVEM ser ignoradas”, portanto um pct que sobrou é simplesmente ignorado. Na próxima vez que editar o seu registro, você pode removê-lo.

Como verificar se tudo está funcionando?

Consulte os registros que você publicou e depois envie uma mensagem real para um endereço do Gmail e leia os resultados de autenticação dela. Duas verificações rápidas:

Consulte os registros DNS. O nosso verificador gratuito consulta os registros SPF, DKIM e DMARC do domínio do endereço que você digitar — sem necessidade de cadastro. Ele verifica o seletor DKIM padrão do Google (google._domainkey); se o seu serviço de envio usa um seletor diferente, o verificador indicará o DKIM como não confirmado mesmo que ele esteja configurado. A ferramenta está disponível em inglês e coreano; digite o seu endereço de e-mail de envio.
Verifique uma mensagem real. Envie um e-mail para uma conta do Gmail que você controla, abra-o, escolha “Mostrar original” e procure por SPF: PASS, DKIM: PASS e DMARC: PASS.

Depois, dê uma ou duas semanas aos relatórios do DMARC. Quando todas as fontes legítimas que você usa aparecerem como aprovadas, passe de p=none para p=quarantine e, mais tarde, para p=reject, se quiser a proteção mais forte contra falsificação de identidade (spoofing).

Quais erros mais quebram a autenticação?

Dois registros SPF, consultas SPF demais, DKIM gerado mas nunca iniciado e DMARC publicado antes de o SPF e o DKIM terem tido tempo de funcionar. Uma lista de verificação:

Um único registro SPF, com cada remetente como um include: dentro dele e no máximo 10 termos de consulta.
Clique em “Iniciar autenticação” depois de publicar a chave DKIM — o registro DNS sozinho não basta.
Aguarde cerca de 48 horas depois do SPF e do DKIM antes de adicionar o DMARC e publique-o em _dmarc, e não na raiz.
Envie a partir de um domínio que você controla. Você não pode publicar DMARC para um endereço @gmail.com.

A autenticação faz o seu e-mail ser considerado; ela não faz os destinatários quererem recebê-lo. As reclamações de spam continuam contando — o Google e o Yahoo dizem que você deve manter a sua taxa de spam abaixo de 0,3%, como explicamos em por que os cold emails caem no spam. E enviar para endereços que não existem gera devoluções, por isso recomendamos que você verifique os endereços antes de enviar.

A versão curta

O Google e o Yahoo exigem SPF ou DKIM de todos os remetentes e os três, mais o alinhamento, dos remetentes em massa (5.000+ mensagens por dia para o Gmail).
SPF: um registro TXT em @, por exemplo v=spf1 include:_spf.google.com ~all; fique dentro de 10 termos de consulta DNS.
DKIM: chave de 2048 bits, seletor google, TXT em google._domainkey e, depois, Iniciar autenticação.
DMARC: um registro TXT em _dmarc, comece com p=none e um endereço para relatórios e torne a política mais rígida depois. A RFC 9989 (maio de 2026) substituiu pct por t=y.
Verifique os seus registros com o nosso verificador gratuito de autenticação de e-mail e depois confirme em uma mensagem real.