DMARC Google Workspace: registro e políticas

O que o DMARC no Google Workspace verifica, na prática?

O DMARC diz aos servidores de destino o que fazer com e-mails que usam o seu domínio no cabeçalho From visível, mas não conseguem provar que vieram de você. Pela especificação do DMARC, uma mensagem passa quando o SPF ou o DKIM passa e o domínio que passou está alinhado com o domínio do From. Basta um dos dois. No Google Workspace, o DKIM assina com a chave que você gera no Admin Console (o seletor padrão é google), e o SPF cobre os servidores do Google por meio de include:_spf.google.com. Os dois registros ficam no seu domínio. O DMARC fica por cima dessas duas verificações e as transforma em uma política. Muita gente não espera por isto: o Google Workspace nunca publica um registro DMARC por você. O Admin Console tem uma página para o DKIM, mas nenhuma para o DMARC. Você cria o registro no seu provedor de DNS, e ele vale para todos os serviços que enviam em nome do seu domínio, não só para o Gmail. As diretrizes para remetentes de e-mail do Google, voltadas a quem envia em massa para contas pessoais do Gmail, exigem um registro DMARC publicado. p=none é aceito, e o domínio do From precisa estar alinhado com o SPF ou com o DKIM.

Como configurar o DMARC no Google Workspace?

Configurar o DMARC no Google Workspace é trabalho de DNS, e os passos seguem uma ordem fixa. A própria orientação do Google diz que o SPF e o DKIM já devem estar autenticando os e-mails antes de você publicar o DMARC. Assim, seus primeiros relatórios agregados mostram uma configuração funcionando, e não um domínio configurado pela metade. Se os seus registros MX, SPF e DKIM ainda não estiverem prontos, comece pelos registros DNS do Google Workspace para MX, SPF e DKIM e volte aqui quando estiverem no ar.

1. 1 Publique o SPF como um único registro TXT na raiz do domínio contendo include:_spf.google.com. O SPF limita quantos mecanismos que fazem consultas DNS (include, a, mx, ptr, exists, redirect) uma única verificação pode disparar. Cada include que você adiciona para outro remetente conta para esse limite, e ultrapassá-lo retorna permerror em vez de pass.
2. 2 No Admin Console, vá em Apps, Google Workspace, Gmail, Autenticar e-mail e gere uma chave DKIM. Escolha o tamanho de chave maior, a menos que o seu provedor de DNS não consiga armazená-lo. Publique o registro TXT google._domainkey e clique em Iniciar autenticação.
3. 3 Espere até que os e-mails enviados mostrem dkim=pass e spf=pass no cabeçalho Authentication-Results. Antes disso, um registro DMARC só vai relatar uma configuração inacabada.
4. 4 Crie um registro TXT com o host _dmarc e o valor v=DMARC1; p=none; rua=mailto:seu-endereco-de-relatorios.
5. 5 Confira com dig TXT _dmarc.seudominio.com.br. Deve voltar exatamente um registro começando com v=DMARC1.

Como deve ser o registro DMARC do Google Workspace?

Um registro DMARC para o Google Workspace é igual ao de qualquer outro domínio. O Google não exige nenhuma tag especial, e não existe valor específico do Google para colar. Uma boa primeira versão é v=DMARC1; p=none; rua=mailto:dmarc@seudominio.com.br. Ela coleta dados de relatório sem pedir aos servidores de destino que tomem alguma ação sobre as falhas. A tabela abaixo lista as tags que você vai de fato mexer e o que acontece quando alguma fica de fora. Só v e p são obrigatórias, e v=DMARC1 precisa vir primeiro.

Tag	O que faz	Valor inicial
v	Versão; precisa ser a primeira tag	DMARC1
p	Política do domínio: none, quarantine ou reject	none
rua	Endereço para os relatórios agregados (XML)	mailto:dmarc@seudominio.com.br
sp	Política para subdomínios; herda o p se omitida	deixe de fora no início
adkim / aspf	Modo de alinhamento: r (relaxado, padrão) ou s (estrito)	mantenha o padrão r
pct	Parcela dos e-mails com falha à qual a política se aplica; se omitida, vale para todos os e-mails com falha	deixe de fora enquanto estiver em p=none

Dois erros aparecem o tempo todo. O primeiro é publicar dois registros TXT em _dmarc. Se a consulta encontra mais de um registro DMARC, a especificação manda os servidores de destino não aplicarem nenhum processamento DMARC. O segundo é apontar o rua para uma caixa de outro domínio sem que esse domínio tenha publicado um registro de autorização em seudominio.com.br._report._dmarc.outrodominio.com. Sem esse registro, os relatórios nunca chegam.

Quando passar de p=none para quarantine ou reject?

Só mude quando os relatórios agregados mostrarem que todas as fontes legítimas que enviam em nome do seu domínio passam no DMARC. Isso inclui o Google Workspace, o Brevo, o seu CRM, ferramentas de faturamento e qualquer outra coisa. Cada servidor de destino envia relatórios em intervalos regulares e só cobre os e-mails que viu naquele período, então uma rodada de relatórios mostra apenas os remetentes que estavam ativos naquele momento. Espere o suficiente para pegar remetentes que só disparam de vez em quando, como um sistema de cobrança que roda uma vez por mês. Depois suba um degrau por vez: primeiro p=quarantine, opcionalmente com um valor de pct para cobrir só parte dos e-mails com falha, e então p=reject. Pular direto para reject é o erro mais comum. Se uma ferramenta esquecida envia faturas pelo seu domínio, os servidores que respeitam a política vão recusar esses e-mails, e ninguém percebe até um cliente perguntar cadê a fatura. O encaminhamento é o outro ponto fraco conhecido. E-mails encaminhados costumam quebrar o SPF, e listas de discussão que reescrevem o corpo quebram o DKIM, então parte dos e-mails legítimos vai falhar com qualquer política estrita. Para um domínio de cold email, p=none com relatórios limpos já atende ao mínimo de DMARC das diretrizes para remetentes do Google. Endurecer a política é uma decisão separada, sobre risco de spoofing, e não uma chave de entregabilidade. O panorama completo está no nosso guia de DKIM, DMARC e SPF para quem faz cold email.

Antes de endurecer a política, confira estes pontos em cada relatório agregado:

• Cada IP de envio deve pertencer a uma fonte que você reconhece. Uma fonte desconhecida enviando em nome do seu domínio é ou uma ferramenta esquecida ou spoofing, e você precisa saber qual das duas antes de ir para reject.
• Os resultados de DKIM mostram o domínio d=. Um pass no domínio do próprio fornecedor não se alinha com o seu domínio do From e não conta para o DMARC.
• Os resultados de SPF mostram o domínio do envelope. Um pass no domínio de bounce de um fornecedor também não se alinha.
• A coluna disposition. Com p=none, ela deve mostrar none em todas as linhas. Com quarantine, qualquer e-mail enviado por você que apareça em quarentena vem de uma fonte que ficou de fora.

Como o EmailFlow OS funciona com o DMARC do Google Workspace?

O EmailFlow OS não adiciona nenhum remetente próprio ao seu domínio, então não há fonte extra para autorizar no seu registro DMARC. Você grava um único vídeo e faz o upload no EmailFlow OS, conecta a sua 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 personaliza essa única gravação para cada destinatário, e não para cada empresa, e envia cada versão a partir da sua própria caixa de entrada, pela sua conta Brevo e pelo seu domínio de envio. Nenhum endereço compartilhado da plataforma aparece no campo From.

Por isso, o resultado do DMARC dessas mensagens depende de registros que você já controla: a chave DKIM do Brevo publicada no seu domínio e o seu único registro TXT em _dmarc. A chave DKIM do Google não faz nada pelos e-mails que o Brevo envia, porque o Brevo assina com a própria chave. O Return-Path dos e-mails do Brevo normalmente fica no domínio do Brevo, então o DKIM precisa garantir o alinhamento sozinho. Como publicar as duas chaves lado a lado está explicado no nosso guia sobre DKIM do G Suite com o registro do Google e a configuração do Brevo. Se os seus e-mails do Brevo já aparecem alinhados nos relatórios agregados, os e-mails com vídeo seguem esse mesmo caminho. Se não aparecem, corrija os registros DKIM do Brevo antes de enviar, porque nenhuma ferramenta consegue alinhar uma assinatura que o seu DNS não publica. Aceitar ou não a mensagem continua sendo decisão do servidor de destino. Em um domínio novo, aumente o volume aos poucos primeiro, com um aquecimento de domínio com volumes diários e a configuração de DNS em ordem.

Perguntas frequentes

? O Google Workspace cria o registro DMARC automaticamente?

Não. O Admin Console gera a sua chave DKIM e mostra o registro google._domainkey, mas nunca cria o DMARC. Você publica um registro TXT em _dmarc.seudominio.com.br no seu provedor de DNS, começando com v=DMARC1 e uma tag p. Sem ele, os servidores de destino não aplicam nenhuma política DMARC ao seu domínio, e você não atende ao requisito de DMARC das diretrizes para remetentes do Google para quem envia em massa ao Gmail.

? Posso ter dois registros DMARC, um para o Google e outro para o Brevo?

Não. Um domínio tem exatamente um registro DMARC em _dmarc. Se a consulta retorna mais de um registro v=DMARC1, a especificação do DMARC manda os servidores de destino não aplicarem nenhum processamento DMARC. O Google Workspace e o Brevo compartilham esse único registro. Cada serviço precisa da própria chave DKIM alinhada, mas a política é uma única entrada TXT.

? p=none basta para os requisitos de remetente do Gmail?

Sim, no que diz respeito ao DMARC. Para quem envia em massa ao Gmail, as diretrizes para remetentes do Google exigem um registro DMARC publicado com no mínimo p=none e um domínio do From alinhado com o SPF ou o DKIM. Elas também exigem uma taxa baixa de spam denunciado pelos usuários, que você pode acompanhar no Google Postmaster Tools. Com p=none você continua recebendo os relatórios agregados. Diferente de quarantine ou reject, ele só não pede aos servidores de destino que tomem uma ação sobre os e-mails que falham.