Como configurar SPF, DKIM e DMARC no Google Workspace

Quando uma empresa migra para o Google Workspace e começa a usar e-mail corporativo com domínio próprio, existe uma etapa técnica que define se esses e-mails vão chegar na caixa de entrada ou sumir no caminho: a configuração dos registros de autenticação no DNS.

SPF, DKIM e DMARC são três registros publicados nas configurações do seu domínio que provam para os servidores de destino que o e-mail enviado é legítimo. Sem eles, qualquer mensagem que saia do seu domínio pode ser classificada como spam, rejeitada silenciosamente ou, pior, utilizada por terceiros para se passar pela sua empresa em ataques de phishing.

Este artigo explica o que cada registro faz, como configurar cada um corretamente no contexto do Google Workspace e qual é a ordem certa de implementação para não bloquear e-mails legítimos durante o processo.

Por que a autenticação de e-mail virou obrigatória

Até alguns anos atrás, a autenticação de e-mail era uma boa prática recomendada. Hoje é um requisito técnico imposto pelos principais provedores do mundo.

O Google e o Yahoo anunciaram mudanças estritas nas políticas de recebimento de e-mail que passaram a valer em 2024. Para quem envia mais de 5.000 e-mails por dia para contas pessoais do Gmail, a tríade completa de SPF, DKIM e DMARC é obrigatória. Para volumes menores, ao menos SPF ou DKIM são exigidos. E para qualquer remetente, usar domínios gratuitos como @gmail.com ou @yahoo.com em disparos corporativos passou a resultar em rejeição imediata.

Mas as regras vão além do volume. Os provedores monitoram a taxa de reclamações de spam do domínio remetente, e ela precisa ficar abaixo de 0,3% para que os e-mails continuem sendo entregues normalmente. Isso é monitorável pelo Google Postmaster Tools, uma ferramenta gratuita que mostra a reputação do seu domínio em tempo real.

Além da questão de entregabilidade, há um problema de segurança sério que esses registros resolvem: o spoofing. Sem autenticação, qualquer pessoa pode enviar um e-mail usando o endereço da sua empresa como remetente. Clientes recebem golpes em nome da sua marca, e você não tem como provar que não foi você quem enviou.

A configuração correta de SPF, DKIM e DMARC elimina essa vulnerabilidade.

O que cada registro faz, em termos simples

Antes de entrar nos registros técnicos, vale entender o papel de cada um.

O SPF (Sender Policy Framework) é uma lista publicada no DNS do seu domínio que declara quais servidores têm permissão para enviar e-mails em seu nome. Quando um e-mail chega em outro servidor, ele consulta essa lista. Se o servidor que enviou não estiver na lista, o e-mail falha na verificação SPF.

O DKIM (DomainKeys Identified Mail) funciona de forma diferente. Ele adiciona uma assinatura criptografada no cabeçalho de cada e-mail enviado. O servidor destinatário usa uma chave pública publicada no DNS para verificar essa assinatura e confirmar que o e-mail não foi alterado durante o trajeto.

O DMARC (Domain-based Message Authentication, Reporting and Conformance) é a política que usa os resultados do SPF e do DKIM para decidir o que fazer com um e-mail que falhou nas verificações. Ele também exige o alinhamento de domínios, garantindo que o domínio visível no campo “De:” seja o mesmo validado pelo SPF ou DKIM. E envia relatórios para o administrador sobre o que está acontecendo com os e-mails do domínio.

Os três trabalham em conjunto. SPF e DKIM são as verificações. DMARC é a política que age sobre os resultados.

Configurando o SPF no Google Workspace

O SPF é publicado como um registro do tipo TXT no painel de DNS do seu provedor de hospedagem ou registrador de domínio. Se a sua empresa usa apenas o Google Workspace para enviar e-mails, o registro é direto:

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

O trecho include:_spf.google.com autoriza os servidores do Google a enviar em nome do seu domínio. O ~all ao final instrui os servidores destinatários a tratar mensagens de origens não listadas como suspeitas (soft fail), sem rejeitá-las imediatamente. Isso é o recomendado enquanto o DMARC ainda não está configurado, pois evita bloqueios indesejados durante a transição.

Há uma regra fundamental: um domínio só pode ter um único registro SPF. Se você tiver dois registros separados, a verificação falha. Se a sua empresa usa outros sistemas de envio além do Google Workspace, como Mailchimp, Salesforce ou Amazon SES, todos precisam estar consolidados em um único registro:

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

Outro limite importante é o de 10 lookups DNS. Cada include: no registro SPF faz uma consulta ao DNS. Se o total ultrapassar 10, ocorre um erro silencioso chamado SPF PermError, e a verificação falha mesmo que os servidores estejam corretos. Para domínios que usam muitos serviços de envio, a solução é o SPF flattening, que substitui os include: por endereços IP diretos.

Para publicar o registro, acesse o painel DNS do seu provedor, crie um novo registro do tipo TXT com o host @ (ou o nome do domínio) e cole o valor SPF consolidado.

Configurando o DKIM no Google Workspace

O DKIM exige uma etapa dentro do Google Workspace antes de qualquer alteração no DNS.

No Admin Console do Google (admin.google.com), navegue até Apps > Google Workspace > Gmail > Autenticar e-mail. Selecione o domínio e clique em “Gerar novo registro”. O console vai criar um par de chaves criptográficas: a chave privada fica armazenada nos servidores do Google e assina cada e-mail enviado; a chave pública é o que você vai publicar no DNS.

O registro gerado terá a seguinte estrutura:

Nome/Host: google._domainkey
Tipo: TXT
Valor: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

Copie o valor completo gerado pelo console, crie um novo registro TXT no seu DNS com o host google._domainkey e cole o valor. O nome do seletor (google) pode variar se você tiver configurações anteriores; use exatamente o que o console do Google mostrar.

Após publicar o registro, volte ao Admin Console e clique em “Iniciar autenticação”. O Google vai verificar se a chave está disponível no DNS. Se a propagação ainda não terminou, aguarde e tente novamente.

A propagação de registros DNS pode levar entre 24 e 48 horas para se completar globalmente. É importante ter isso em mente antes de testar ou validar qualquer configuração.

Configurando o DMARC de forma gradual

O DMARC é o registro que mais gera dúvidas, porque ativar uma política restritiva antes de o SPF e o DKIM estarem funcionando corretamente pode bloquear e-mails legítimos da empresa.

A abordagem correta é a implementação em fases.

Fase 1: monitoramento (p=none)

O primeiro registro DMARC deve instruir os servidores a não fazerem nada com os e-mails que falharem, apenas enviar relatórios. Isso permite mapear todas as fontes de envio legítimas do domínio antes de aplicar qualquer política restritiva.

v=DMARC1; p=none; rua=mailto:alerta@seudominio.com.br

O registro é publicado no DNS como um TXT com o host obrigatório _dmarc. O campo rua é o endereço que vai receber os relatórios XML diários enviados pelos servidores que processaram e-mails do seu domínio. Mantenha essa fase por pelo menos duas a quatro semanas e analise os relatórios para identificar se há serviços legítimos enviando em nome do domínio sem estarem no SPF.

Fase 2: quarentena gradual (p=quarantine)

Quando o SPF e o DKIM estiverem funcionando corretamente para todas as fontes de envio legítimas, avance para a política de quarentena. E-mails que falharem serão direcionados para a pasta de spam em vez de serem rejeitados. Comece com uma porcentagem pequena:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@seudominio.com.br

O pct=25 aplica a política a 25% dos e-mails que falharem. Aumente gradualmente para 50, 75 e depois 100, monitorando os relatórios a cada semana.

Fase 3: rejeição total (p=reject)

Com SPF, DKIM e DMARC em quarentena funcionando sem interceptar e-mails legítimos, a política de rejeição total pode ser ativada. Nela, qualquer e-mail que tente usar seu domínio sem autenticação válida é rejeitado na origem:

v=DMARC1; p=reject; rua=mailto:dmarc@seudominio.com.br

Essa é a configuração mais segura. Golpistas que tentarem se passar pela sua empresa usando seu domínio vão receber rejeição direta dos servidores destinatários, sem que o e-mail chegue a nenhum destinatário.

Como verificar se tudo está funcionando

Após publicar os três registros e aguardar a propagação do DNS, use ferramentas de validação para confirmar que tudo está correto antes de considerar a configuração concluída.

O MxToolbox (mxtoolbox.com) é a ferramenta mais usada para verificar registros SPF, DKIM e DMARC. Ele identifica erros de sintaxe, excesso de lookups SPF e problemas no alinhamento do DMARC. O Google Admin Toolbox tem um verificador de MX e DKIM integrado, útil para confirmar que o Google consegue ler a chave corretamente. O spf.access.nu é uma opção visual que audita a estrutura do SPF e checa a força das chaves DKIM.

Para o DKIM especificamente, o próprio Admin Console do Google indica se a autenticação está ativa. Se o status mostrar “Autenticando e-mail”, o registro foi publicado e verificado com sucesso.

Lembre-se de verificar também se os relatórios do DMARC estão chegando no endereço configurado. Se o endereço rua não receber nada após alguns dias, verifique se o registro _dmarc foi publicado com a sintaxe correta.

O que acontece quando a configuração está incompleta

É comum ver empresas com SPF configurado mas sem DKIM, ou com DKIM ativo mas DMARC ainda em p=none por anos. Cada lacuna deixa uma vulnerabilidade aberta.

Sem DKIM, qualquer intermediário no caminho do e-mail pode modificar o conteúdo da mensagem sem que o destinatário saiba. Sem DMARC, mesmo que SPF e DKIM falhem, os e-mails continuam sendo entregues normalmente, porque não há política definindo o que fazer com as falhas. E sem SPF, servidores de e-mail externos não têm como verificar se o servidor que enviou a mensagem estava autorizado.

O conjunto dos três registros também é o que garante proteção contra o ataque de spoofing mais comum: alguém enviando um e-mail com o campo “De:” mostrando o endereço da sua empresa, mas a mensagem saindo de um servidor não autorizado. O DMARC, com o alinhamento de domínios, identifica exatamente esse cenário e bloqueia a entrega.

Outro ponto que passa despercebido: se a empresa usa plataformas de disparo de e-mail marketing, sistemas de CRM ou ERP que enviam notificações pelo domínio corporativo, todos esses serviços precisam estar no SPF. Se o SPF não autorizar o servidor desse sistema, os e-mails vão falhar na verificação mesmo que o DKIM do Google esteja perfeito, porque o alinhamento do DMARC vai quebrar.

E-mail corporativo bem configurado não é detalhe técnico

Para gestores que cuidam da operação de uma empresa, a configuração de SPF, DKIM e DMARC pode parecer um detalhe de infraestrutura sem impacto no negócio. Na prática, é o que define se propostas comerciais chegam na caixa de entrada do cliente ou desaparecem no spam. É o que impede que criminosos usem o seu domínio para aplicar golpes em nome da sua empresa. E é o requisito técnico que os grandes provedores de e-mail passaram a exigir para aceitar mensagens do seu domínio.

A lógica é direta: um e-mail corporativo que não chega não serve para nada. E um domínio sem autenticação é um passivo de segurança que pode gerar prejuízo real antes mesmo de você perceber o problema.

Se a sua empresa está implantando o Google Workspace agora ou quer revisar a configuração atual de autenticação de e-mail, a implantação e configuração de Google Workspace com todas essas etapas já executadas e validadas evita os problemas que surgem quando a configuração é feita pela metade ou sem o conhecimento do ambiente de envio completo da empresa. Fale com a gente pelas formas de contato e veja como posso ajudar.

Referências

Google Workspace Admin Help. “Set up SPF to prevent email spoofing”. Google LLC. Documentação oficial para configuração de SPF em domínios que usam o Google Workspace como provedor de e-mail. Disponível em: https://support.google.com/a/answer/33786

Google Workspace Admin Help. “Set up DKIM to prevent email spoofing”. Google LLC. Guia oficial de geração e publicação da chave DKIM pelo Admin Console do Google Workspace. Disponível em: https://support.google.com/a/answer/174124

Google Workspace Admin Help. “Add a DMARC record”. Google LLC. Documentação oficial sobre criação e publicação do registro DMARC, incluindo as três fases de implementação recomendadas pelo Google. Disponível em: https://support.google.com/a/answer/2466580

Google. “Email sender guidelines”. Google LLC. Diretrizes atualizadas do Google para remetentes de e-mail, incluindo os requisitos obrigatórios para domínios que enviam e-mail para contas Gmail. Disponível em: https://support.google.com/mail/answer/81126

MxToolbox. “Email Header Analyzer, SPF, DKIM and DMARC Lookup”. MxToolbox SuperTool. Ferramenta de diagnóstico para verificação de registros SPF, DKIM e DMARC publicados em um domínio. Disponível em: https://mxtoolbox.com/SuperTool.aspx

Vídeos do Google sobre autenticação de e-mail

O Google disponibiliza uma série de vídeos curtos em inglês que mostram na prática como executar cada etapa da configuração no Admin Console. São úteis como referência visual complementar ao que foi explicado acima.

Organizando o SPF

Adicionando o SPF no domínio

Sobre o DMARC

Gerando o DKIM