SPF, DKIM e DMARC para cold email

A configuração do DMARC vem depois de SPF e DKIM, porque o DMARC apenas avalia os resultados dos dois. Publique um registro TXT em _dmarc.seudominio, por exemplo v=DMARC1; p=none; rua=mailto:dmarc-reports@seudominio. Leia os relatórios agregados até que todo remetente legítimo apareça com DKIM alinhado, depois passe para p=quarantine e, por fim, p=reject. O restante deste artigo explica o que cada um dos três registros verifica, em que ordem publicá-los e quais falhas aparecem quando um domínio envia ao mesmo tempo pelo Google Workspace e pelo Brevo.

DKIM vs SPF vs DMARC: o que cada um verifica de fato?

Muita gente trata SPF, DKIM e DMARC como uma única caixinha para marcar. Na prática, são três testes separados, e cada um olha para uma parte diferente da mensagem. O SPF olha para o remetente do envelope, o endereço MAIL FROM que o servidor de destino vê durante a conversa SMTP. Ele não olha para a linha From que o destinatário lê. O DKIM confere uma assinatura criptográfica no cabeçalho da mensagem contra uma chave pública publicada sob um seletor. O DMARC é o único dos três que amarra o resultado ao domínio visível no From, e ele diz ao servidor de destino o que fazer quando esse vínculo não existe.

• SPF: um registro TXT na raiz do domínio, começando com v=spf1. Passa quando o IP que se conecta está listado. A especificação do SPF limita quantas consultas DNS uma única avaliação pode disparar, então cadeias longas de includes quebram o registro.
• DKIM: um registro TXT em seletor._domainkey.seudominio. Passa quando a assinatura é verificada, ou seja, quando os cabeçalhos assinados e o corpo não foram alterados no caminho.
• DMARC: um registro TXT em _dmarc.seudominio. Passa quando SPF ou DKIM passa e esse domínio está alinhado com o domínio do From.
• Relatórios: a tag rua do DMARC envia relatórios agregados em XML para um endereço que você escolhe. SPF e DKIM não têm relatórios próprios.

O que não funciona: confiar só no SPF. O encaminhamento (forward) muda o IP de conexão, então o SPF quebra, enquanto uma assinatura DKIM normalmente sobrevive ao encaminhamento.

Como SPF, DKIM e DMARC funcionam juntos em uma única verificação?

O servidor de destino roda SPF e DKIM primeiro e depois entrega os dois resultados ao DMARC. No alinhamento relaxado, que a especificação do DMARC define como padrão (aspf=r e adkim=r), o domínio autenticado só precisa compartilhar o domínio organizacional com o endereço From. Com o From definido como anna@example.com, uma assinatura DKIM de d=mail.example.com está alinhada. Uma assinatura de d=brevo-owned-domain.com passa no DKIM, mas falha no alinhamento, então não ajuda em nada o DMARC. Essa é a surpresa mais comum para quem envia por uma plataforma de terceiros: todas as verificações nos cabeçalhos dizem "pass" e mesmo assim o DMARC falha. O alinhamento estrito (adkim=s) exige correspondência exata de domínio, o que raramente compensa o trabalho em um domínio de cold outreach. A regra prática é que pelo menos um dos dois mecanismos precisa passar sob o seu próprio domínio. O DKIM é o melhor candidato, porque sobrevive ao encaminhamento e não depende do endereço de bounce que a plataforma usa. Você vê os três resultados no cabeçalho Authentication-Results de uma mensagem de teste, escritos como spf=, dkim= e dmarc=.

SPF, DKIM e DMARC no Google Workspace: por que os e-mails do Brevo não aproveitam os registros do Google?

O Google Workspace só autentica os e-mails que saem dos servidores do Google. O include de SPF dele é include:_spf.google.com. A chave DKIM é gerada no Admin console em Apps, Google Workspace, Gmail, Autenticar e-mail, com google como seletor padrão; a Ajuda do Admin do Google Workspace recomenda o maior dos tamanhos de chave oferecidos, quando o seu provedor de DNS suporta. Depois de publicar o registro, a mesma página de ajuda avisa que as alterações de DNS podem levar um tempo para propagar antes de você clicar em Iniciar autenticação. Nada disso cobre os e-mails que o Brevo envia pelo seu domínio. O Brevo assina com a própria chave, sob o próprio seletor, então você fica com dois registros DKIM lado a lado, e tudo bem, porque seletores não colidem. Com o SPF é diferente. A especificação do SPF permite apenas um registro v=spf1 por domínio, então o include do Google e o que o Brevo mostra na tela de autenticação de domínio precisam entrar na mesma linha. Se você publicar dois registros SPF separados, o resultado é um permerror, que não é tratado como aprovação. O conjunto completo de registros DNS do Google Workspace (MX, SPF, DKIM) tem um guia próprio, e a chave do lado do Google, assim como a forma de dividir uma chave longa em várias strings, são tratadas no guia sobre DKIM do G Suite com registro do Google e configuração do Brevo.

Como configurar SPF, DKIM e DMARC, passo a passo?

A ordem importa. O DMARC avalia os outros dois, então ele é publicado por último. Comece com um registro que apenas gera relatórios e só endureça a política quando os relatórios estiverem limpos.

1. 1 Liste todos os serviços que enviam em nome do seu domínio: Google Workspace, Brevo, seu CRM, sua ferramenta de cobrança. Cada um precisa de uma entrada no SPF ou de uma chave DKIM própria.
2. 2 Publique um único registro TXT de SPF na raiz, por exemplo v=spf1 include:_spf.google.com mais o include do Brevo, terminando em ~all. Conte os mecanismos que fazem consulta DNS, incluindo os includes aninhados, e fique dentro do limite de consultas definido pela especificação do SPF.
3. 3 Gere as chaves DKIM em cada serviço e publique-as como TXT (ou CNAME, se o provedor pedir) em seletor._domainkey. Depois clique em verificar em cada serviço.
4. 4 Publique o DMARC em _dmarc com v=DMARC1; p=none; rua=mailto:seu-endereco-de-relatorios. A política p=none pede aos servidores de destino que não tomem nenhuma ação em caso de falha. Ela só coleta dados.
5. 5 Envie um teste para um endereço do Gmail, abra Mostrar original e confirme que SPF, DKIM e DMARC aparecem como PASS.
6. 6 Leia os relatórios agregados por várias semanas antes de passar para p=quarantine.

No DNS da GoDaddy, o campo Host acrescenta o seu domínio automaticamente. Digitar o nome completo gera seletor._domainkey.example.com.example.com, como descrito no guia de configuração de DKIM na GoDaddy para quem envia pelo Brevo.

Por que SPF, DKIM ou DMARC falham mesmo depois de configurados?

A maioria das falhas vem de erros de DNS ou de domínios não alinhados, não dos protocolos em si. Estas são as que mais vemos, junto com as causas:

• Permerror no SPF: dois registros v=spf1 no mesmo domínio, ou mais termos que fazem consulta DNS (include, a, mx, ptr, exists, redirect, contados recursivamente) do que o limite de consultas da especificação do SPF permite. Consultas demais que voltam vazias também terminam em permerror.
• Body hash mismatch no DKIM: algo reescreveu a mensagem depois da assinatura, como um rodapé adicionado por um gateway ou por uma lista de discussão.
• Chave DKIM não encontrada: o nome do seletor está errado, o hostname foi duplicado pelo painel de DNS ou o registro ainda não propagou.
• Chave longa truncada: uma única string TXT no DNS tem limite de tamanho, então uma chave DKIM longa precisa ser dividida em várias strings entre aspas. Alguns painéis cortam a chave em vez de dividir.
• DMARC falha apesar de dois "pass": SPF e DKIM passaram sob o domínio da plataforma, não o seu, então nenhum dos dois está alinhado com o From.
• DMARC ausente: as Diretrizes para remetentes de e-mail do Google exigem um registro DMARC de remetentes em massa que enviam para contas pessoais do Gmail, então e-mails sem ele ficam em desvantagem por lá.

Você pode conferir cada registro com dig TXT mais o hostname (_dmarc.example.com ou seletor._domainkey.example.com) antes de começar a culpar o conteúdo.

Com qual política de DMARC um domínio de cold outreach deve começar?

Comece com p=none. É o mínimo que as Diretrizes para remetentes de e-mail do Google aceitam de remetentes em massa (Ajuda do Admin do Google Workspace, em outubro de 2026). Ela pede aos servidores de destino que não tomem nenhuma ação sobre e-mails que falham, então uma ferramenta esquecida que envia em nome do seu domínio aparece nos relatórios em vez de ir para a quarentena. Quando os relatórios agregados listarem apenas fontes que você reconhece, todas alinhadas, passe para p=quarantine. Se quiser endurecer aos poucos, a tag pct aplica a política só a uma porcentagem dos e-mails que falham; sem a tag, a política cobre todos. p=reject é o estado final. O que não funciona é pular direto para reject em um domínio cujos remetentes você ainda não inventariou. Convites de agenda, notas fiscais ou um formulário esquecido podem simplesmente parar de chegar, sem aviso. A sintaxe do registro e a implantação em etapas estão no guia sobre como implantar um registro DMARC no Google Workspace. Lembre também que o DMARC não faz o aquecimento por você. Um domínio novo com registros corretos ainda não tem histórico de envio, e os servidores de destino avaliam volume e taxa de reclamações separadamente; as Diretrizes para remetentes de e-mail do Google definem um limite de taxa de spam medido no Postmaster Tools. Planeje o aumento de volume junto com o trabalho de DNS, como explicado no guia de aquecimento de e-mail com volumes diários e configuração de DNS.

Exemplo de configuração de DMARC: um domínio de outreach com Workspace e Brevo

Pense em um domínio chamado example.com. As pessoas escrevem a partir dele no Google Workspace, e o cold outreach sai pela conta Brevo do mesmo domínio. Este é o registro DMARC que publicaríamos primeiro, como registro TXT no host _dmarc (em painéis que acrescentam o domínio) ou em _dmarc.example.com (em painéis que não acrescentam):

• v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r
• v=DMARC1 precisa ser a primeira tag. Um registro que começa de outra forma não é lido como registro DMARC.
• adkim=r e aspf=r apenas deixam explícitos os valores padrão. Assim, quem editar o registro no futuro vê que o alinhamento relaxado está em uso.
• sp= fica de fora de propósito. Sem ele, os subdomínios herdam o p. Adicione sp= apenas se um subdomínio como mail.example.com precisar de uma política própria.
• Publique exatamente um registro v=DMARC1 em _dmarc. Se aparecer um segundo, por exemplo um adicionado anos atrás por um construtor de sites, os servidores de destino tratam o domínio como se não tivesse política válida.

Para ler o primeiro relatório agregado, abra o arquivo XML e confira três campos em cada registro: source_ip, header_from e o domínio em auth_results/dkim. Uma linha com header_from example.com e domínio DKIM example.com está alinhada. Uma linha vinda de um IP do Brevo em que o domínio DKIM pertence ao Brevo significa que a autenticação de domínio do Brevo para example.com ainda não foi concluída. Corrija isso antes de endurecer a política, não depois. Linhas de IPs que você não reconhece são uma ferramenta que você esqueceu de listar ou alguém falsificando o domínio (spoofing). Nos dois casos, elas são o motivo de o p=none vir primeiro. Uma armadilha que os guias genéricos pulam: se o rua aponta para uma caixa de outro domínio, por exemplo de um fornecedor que processa relatórios, a especificação do DMARC exige que esse domínio publique um registro de autorização em example.com._report._dmarc.dominiodofornecedor. Sem ele, os servidores de destino que verificam esse registro não enviam os relatórios, e você acaba olhando uma caixa vazia achando que está tudo certo.

Como o EmailFlow OS usa os seus registros SPF, DKIM e DMARC?

O EmailFlow OS não envia a partir de um endereço compartilhado da plataforma. Você grava um único vídeo e faz o upload no EmailFlow OS, conecta a sua própria conta Brevo e o seu domínio de envio e importa a sua lista de prospects para o EmailFlow OS. Em seguida, o EmailFlow OS cria uma versão personalizada dessa gravação para cada destinatário, não para cada empresa, e envia cada uma a partir da sua caixa de entrada, pela sua conta Brevo, sob o seu domínio. É por isso que acertar os registros acima é responsabilidade sua. A chave DKIM que o Brevo verifica para o seu domínio e a política DMARC em _dmarc.seudominio são o que os servidores de destino avaliam em cada mensagem personalizada. Um domínio de remetente compartilhado colocaria os seus e-mails sob a reputação de outra pessoa. Com essa configuração, a reputação, os relatórios e o DNS continuam sob o seu controle. O que um servidor de destino faz com cada mensagem continua sendo decisão dele, com base em autenticação, histórico de envio e reclamações. Como o vídeo por destinatário se encaixa em uma sequência completa está descrito no guia de cold outreach com um único vídeo personalizado.

Perguntas frequentes

? Como configurar o DMARC?

Primeiro confirme que SPF e DKIM passam sob o seu próprio domínio. Depois publique um registro TXT em _dmarc.seudominio com v=DMARC1; p=none; rua=mailto:seu-endereco-de-relatorios. Envie um teste para o Gmail e verifique se Mostrar original indica DMARC: PASS. Leia os relatórios agregados, corrija as fontes não alinhadas e então passe para p=quarantine e, mais tarde, p=reject. As Diretrizes para remetentes de e-mail do Google aceitam p=none como mínimo para remetentes em massa (em outubro de 2026).

? Por que não estou recebendo relatórios de DMARC?

As três causas mais comuns são: a tag rua está ausente ou tem erro de digitação no mailto:; o registro não está em _dmarc, mas na raiz ou em um hostname duplicado; ou o rua aponta para um domínio externo que não publicou o registro de autorização em seudominio._report._dmarc.outrodominio exigido pela especificação do DMARC. Confira o registro com dig TXT _dmarc.seudominio antes de começar a investigar a caixa de entrada.

? Preciso dos três: SPF, DKIM e DMARC?

Para envio em massa ao Gmail, sim: as Diretrizes para remetentes de e-mail do Google exigem que remetentes em massa para contas pessoais do Gmail publiquem SPF, DKIM e DMARC (no mínimo p=none), com alinhamento. Remetentes menores precisam pelo menos de SPF ou DKIM, mas DKIM mais DMARC é a única combinação que amarra a autenticação ao domínio visível no From e sobrevive ao encaminhamento.

? Um domínio pode ter dois registros SPF?

Não. A especificação do SPF permite exatamente um registro v=spf1 por domínio. Dois registros geram um permerror, que os servidores de destino tratam como falha, não como aprovação. Para combinar Google Workspace e Brevo, coloque os dois mecanismos include em um único registro, terminando em ~all, e mantenha o total de consultas DNS dentro do limite definido pela mesma especificação.

? O que é alinhamento de DKIM?

Alinhamento significa que o domínio d= da assinatura DKIM corresponde ao domínio do From. No modo relaxado (adkim=r, o padrão do DMARC), um subdomínio como mail.example.com está alinhado com example.com. No modo estrito (adkim=s), a correspondência precisa ser exata. Uma assinatura válida, mas não alinhada, como uma sob o próprio domínio da plataforma, não conta para o DMARC.

? Quanto tempo o DNS leva para o DKIM ser verificado?

Depende do TTL do registro, que é o tempo que os resolvedores mantêm a resposta antiga em cache. No Workspace, a Ajuda do Admin do Google Workspace avisa que a propagação pode levar um tempo antes que a autenticação DKIM possa ser ativada. Se a verificação ainda falhar depois disso, rode dig TXT no hostname do seletor. Procure um hostname duplicado ou uma chave que o painel de DNS cortou em vez de dividir.