Configurando SPF, DKIM e DMARC no Google Workspace e no Microsoft 365

Configurar SPF, DKIM e DMARC leva menos de uma hora quando você sabe exatamente onde clicar, mas um único caractere errado no registro DNS pode deixar a campanha de outreach inteira sem sair da caixa de spam por semanas. Este guia mostra o passo a passo para Google Workspace e Microsoft 365, os dois provedores mais usados por times de vendas B2B no Brasil, com os erros de sintaxe que mais aparecem na prática.

Antes de começar: onde fica o DNS do domínio

O primeiro passo, que muita gente pula, é confirmar onde o DNS do domínio está hospedado. Nem sempre é no mesmo lugar em que o Google Workspace ou o Microsoft 365 estão configurados — muitas empresas brasileiras registram o domínio na Registro.br, hospedam o site em outro provedor e usam ainda outro serviço de DNS gerenciado.

Para descobrir, basta rodar um comando de consulta NS (name server) para o domínio ou acessar o painel do registrador. Se o DNS estiver na Cloudflare, na própria Registro.br ou em outro provedor de hospedagem, os registros SPF, DKIM e DMARC precisam ser criados lá — não no painel do Google ou da Microsoft, que só fornecem os valores a serem publicados.

Um erro clássico é uma empresa ter dois times cuidando de partes diferentes — TI cuida do domínio, marketing cuida do Google Workspace — e nenhum dos dois sabe exatamente onde o DNS está hospedado. Antes de configurar qualquer coisa, confirme o acesso ao painel de DNS correto.

Google Workspace: SPF, DKIM e DMARC passo a passo

No Google Workspace, o SPF é o mais simples dos três porque o Google fornece um valor fixo. No painel de DNS do domínio, crie um registro TXT na raiz do domínio com o conteúdo v=spf1 include:_spf.google.com ~all. Se a empresa também usa outra ferramenta de outreach ou automação para disparar follow-ups, adicione o include correspondente dessa ferramenta dentro do mesmo registro, sem criar um segundo TXT.

Para o DKIM, acesse o Admin Console do Google Workspace, vá em Apps, depois Google Workspace, depois Gmail, e em seguida Autenticação de email. Lá é possível gerar uma nova chave DKIM (recomenda-se 2048 bits, mais seguro que 1024 bits). O Google vai fornecer um nome de host (algo como google._domainkey) e um valor TXT longo começando com v=DKIM1. Publique exatamente esse valor no DNS e depois volte ao Admin Console para clicar em Iniciar autenticação — sem esse clique final, o DKIM fica gerado mas não ativo.

Para o DMARC, crie um registro TXT em _dmarc.seudominio.com.br. Comece com uma política de monitoramento: v=DMARC1; p=none; rua=mailto:dmarc-relatorios@seudominio.com.br. Esse endereço de rua é para onde os relatórios agregados vão chegar — vale criar uma caixa de email específica para isso, porque o volume de relatórios pode ser alto.

Microsoft 365: SPF, DKIM e DMARC passo a passo

No Microsoft 365, o SPF segue a mesma lógica: um registro TXT na raiz do domínio com v=spf1 include:spf.protection.outlook.com ~all. Se o domínio já tem outro SPF de um provedor anterior (comum em migrações), é preciso mesclar os dois includes em um único registro — nunca deixar dois TXT de SPF separados.

O DKIM no Microsoft 365 funciona de um jeito um pouco diferente: a Microsoft fornece dois registros CNAME (não TXT) que apontam para chaves gerenciadas por ela, geralmente com nomes selector1._domainkey e selector2._domainkey. Isso é feito no Centro de administração do Microsoft 365, em Segurança, depois Políticas e regras, depois Políticas de ameaças, e por fim DKIM. Depois de publicar os dois CNAMEs no DNS, volte ao painel e ative o DKIM para o domínio — ele fica desativado por padrão mesmo depois de os registros existirem.

O DMARC no Microsoft 365 é publicado da mesma forma que no Google: um TXT em _dmarc.seudominio.com.br com a mesma sintaxe v=DMARC1. Não há diferença de formato entre provedores para o DMARC — a política é do domínio, não da caixa de email.

Erros de sintaxe que quebram tudo

A maioria dos problemas de configuração não vem de entender errado o conceito, vem de um detalhe de digitação no painel de DNS. Alguns provedores de DNS pedem o valor entre aspas, outros não aceitam aspas de jeito nenhum — copiar e colar direto de um tutorial genérico costuma quebrar por causa disso.

Outro erro recorrente é publicar dois registros SPF separados quando a empresa já tinha um configurado antes (por exemplo, de um provedor de email de transação como um sistema de notas fiscais) e o time de vendas cria um segundo sem perceber o primeiro. O padrão SPF permite só um registro TXT por domínio — dois registros TXT com v=spf1 tornam o SPF inválido por completo, mesmo que cada um individualmente esteja com sintaxe correta.

Também é comum esquecer o ponto final no nome do host em alguns painéis de DNS mais antigos, ou confundir o campo nome do registro (_dmarc, selector1._domainkey) com o campo valor. Sempre confira com uma ferramenta de verificação externa depois de publicar, em vez de confiar só na aparência do painel.

• Um único registro TXT de SPF por domínio — nunca dois
• DKIM precisa ser ativado no painel após publicar o registro, não só criado
• Confirme se o provedor de DNS exige ou rejeita aspas no valor do TXT
• Subdomínios de envio (mail., campanhas., etc.) precisam de registros próprios
• Propagação de DNS pode levar de alguns minutos a 48 horas — não teste imediatamente
• Sempre valide com uma ferramenta externa de verificação após publicar

Depois de publicar: como confirmar que está tudo certo

Depois de publicar os três registros, o passo seguinte é confirmar que eles estão ativos e legíveis externamente, não só salvos no painel. Ferramentas gratuitas de verificação de DNS mostram exatamente o que um servidor de destino veria ao consultar o domínio — e é comum encontrar diferenças entre o que foi digitado e o que está realmente publicado, especialmente por causa de cache de DNS.

Para times que fazem outreach B2B com uma ferramenta específica de prospecção (além da caixa principal do Google Workspace ou Microsoft 365), vale enviar um email de teste real para uma conta pessoal em Gmail e outra em Outlook, e checar os cabeçalhos técnicos da mensagem recebida. Neles aparece explicitamente se o SPF e o DKIM passaram (pass) ou falharam (fail) para aquele envio específico.

Só depois de confirmar que SPF e DKIM estão passando de forma consistente, em envios reais e não só em teoria, é hora de considerar evoluir a política do DMARC de none para quarantine.

Perguntas frequentes