SPF, DKIM & DMARC para Google Workspace.
Autenticar o Google Workspace significa provar que os servidores do Gmail que enviam em nome do seu domínio são realmente você. Tudo se resume a três registros DNS mais uma chave dentro do Admin console: um registro SPF TXT que adiciona o include compartilhado do Google, uma chave DKIM que você gera no console e publica como registro TXT (depois ativa com "Start authentication") e um registro de política DMARC. O Google Workspace é um dos poucos remetentes que também é o destinatário, então alinhar os três é o que faz o seu e-mail cair na caixa de entrada do Gmail em vez de gerar um aviso "via" ou escorregar para o spam.
Por que autenticar o Google Workspace?
O e-mail do Google Workspace já trafega pela própria infraestrutura do Google, mas até você autenticar, esse e-mail é apenas fracamente atribuível ao seu domínio — o Gmail pode exibir uma nota "via", o DMARC não consegue passar e o seu endereço From não é criptograficamente seu. Desde fevereiro de 2024, as próprias diretrizes de remetentes do Google exigem que todo remetente passe em SPF ou DKIM, e que todo remetente em massa (aproximadamente 5.000+ mensagens por dia para o Gmail) publique adicionalmente uma política DMARC de no mínimo p=none, com alinhamento. O Yahoo adotou as mesmas regras no mesmo mês e a Microsoft começou a aplicá-las em 2025. Como o Google avalia o e-mail aqui contra as suas próprias diretrizes, um domínio Workspace não autenticado é o caminho mais rápido para a pasta de spam ou para uma rejeição direta. Fazer SPF + DKIM + DMARC corretamente alinha os dois mecanismos ao seu domínio, remove a tag "via", permite que o DMARC passe e constrói reputação de envio em seu próprio nome.
A realidade do SPF para o Google Workspace
O Google Workspace é um verdadeiro provedor de "include": você adiciona um mecanismo compartilhado, include:_spf.google.com, ao único registro SPF TXT no seu domínio raiz — o registro completo é v=spf1 include:_spf.google.com ~all. Este é um include compartilhado real (todo cliente Workspace usa o mesmo), diferente dos provedores de delegação via CNAME. Isso importa mais aqui do que para a maioria dos remetentes porque o e-mail que você envia pelo Google usa um envelope sender no seu próprio domínio, então o SPF realmente alinha ao seu domínio organizacional e contribui para um DMARC pass (não só o DKIM). Uma atualização importante: include:_spf.google.com agora é um único registro SPF plano contendo apenas mecanismos ip4:/ip6: — ele não aninha mais a antiga cadeia include:_netblocks.google.com / _netblocks2 / _netblocks3. Isso significa que ele custa apenas uma consulta DNS em relação ao limite de 10 da RFC 7208, e não as três a quatro que guias mais antigos e alguns verificadores de SPF em cache ainda reportam. O Google recomenda terminar com ~all (softfail) em vez de -all, porque usuários do Workspace costumam também enviar legitimamente por outras ferramentas; só endureça para -all quando tiver certeza de que todo remetente está listado. E deve haver exatamente um registro SPF TXT no domínio — se você também usa SendGrid, Mailchimp, Microsoft 365 etc., mescle todos os mecanismos nessa única linha v=spf1 em vez de publicar um segundo registro SPF (dois registros SPF geram um PermError).
Passo a passo
- 1
Abra o Authenticate email
Faça login em admin.google.com como super admin, depois vá em Menu (☰) → Apps → Google Workspace → Gmail → Authenticate email. Esta é a página do DKIM; o SPF e o DMARC são adicionados diretamente no seu provedor de DNS, não aqui.
- 2
Selecione o domínio correto
Se você gerencia mais de um domínio, escolha o domínio de envio no menu suspenso no topo da página Authenticate email. Cada domínio primário, domínio secundário e alias de domínio é autenticado separadamente.
- 3
Gere a chave DKIM
Clique em Generate new record. Defina o comprimento da chave como 2048-bit (recomendação do Google; só recorra a 1024-bit se o seu provedor de DNS não conseguir armazenar um valor TXT longo) e deixe o prefixo de seletor como o padrão google. Clique em Generate.
- 4
Copie o registro DKIM
O Google exibe um registro TXT: o host/nome é google._domainkey e o valor começa com v=DKIM1; k=rsa; p=… seguido de uma longa chave pública. Copie ambos. Deixe esta aba aberta — você vai voltar para clicar em Start authentication.
- 5
Publique o registro DKIM TXT
No seu provedor de DNS, adicione um registro TXT com host google._domainkey e o valor que o Google forneceu. Uma chave de 2048-bit é mais longa que o limite TXT de 255 caracteres por string, então alguns provedores exigem que você a mantenha como vários trechos entre aspas em um registro — a maioria dos painéis lida com isso automaticamente; se não, cole o valor dividido exatamente como mostrado.
- 6
Adicione ou mescle o registro SPF
Adicione um registro TXT no domínio raiz (host @ ou em branco) com v=spf1 include:_spf.google.com ~all. Se já existir um registro SPF, não crie um segundo — mescle include:_spf.google.com na linha v=spf1 existente junto com quaisquer outros remetentes.
- 7
Publique o registro DMARC
Adicione um registro TXT no host _dmarc com v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Comece em p=none (apenas monitoramento) para que nada seja afetado enquanto você confirma o alinhamento; você vai endurecê-lo depois.
- 8
Clique em Start authentication
De volta à página Authenticate email, espere até o DKIM TXT ter propagado, depois clique em Start authentication. Este é o passo que as pessoas esquecem — gerar a chave não faz nada até você iniciar a autenticação, após o que o status passa a exibir 'Authenticating email for this domain.'
- 9
Envie um teste e verifique os cabeçalhos
Envie uma mensagem de um endereço Workspace, abra-a em outra conta do Gmail e use ⋮ → Show original. Confirme SPF: PASS, DKIM: PASS com 'signed-by: yourdomain.com' (seletor google) e DMARC: PASS — todos alinhados ao seu domínio, não a google.com.
- 10
Repita para outros domínios e aliases
O DKIM e o passo Start authentication precisam ser repetidos para cada domínio secundário e alias de domínio a partir do qual você envia. Registros SPF e DMARC também precisam existir em cada um desses domínios, ou o e-mail deles não vai autenticar.
Registros a adicionar
O Google Workspace gera os valores exatos no seu assistente de configuração — estes mostram o formato do que você vai adicionar no seu provedor de DNS.
| Tipo | Host | Valor |
|---|---|---|
| TXT | @ | v=spf1 include:_spf.google.com ~allSPF raiz — mantenha apenas um registro SPF; mescle outros remetentes nesta linha. include:_spf.google.com agora custa 1 consulta DNS. |
| TXT | google._domainkey | v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…(2048-bit public key from the Admin console)Ilustrativo — a chave real é gerada por domínio em Apps → Google Workspace → Gmail → Authenticate email. Chaves de 2048-bit podem precisar ser publicadas como strings divididas entre aspas. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comUm registro DMARC por domínio. Comece em p=none, depois endureça para quarantine/reject. |
Mantenha exatamente um registro TXT de SPF (v=spf1) no seu domínio raiz — combine todos os remetentes nele. Ter dois registros SPF já é, por si só, um erro.
O limite de 10 consultas de DNS
O SPF tem um limite rígido de 10 consultas de DNS — se passar disso, ele retorna um permerror e para de validar em todo lugar. Veja quanto a configuração do Google Workspace consome desse limite.
O Google Workspace usa 1 das suas 10 consultas; os mecanismos ip4: e ip6: são gratuitos.
DKIM
O DKIM para o Google Workspace é gerado dentro do Admin console, não copiado de um valor fixo. Vá em Apps → Google Workspace → Gmail → Authenticate email, selecione o domínio, clique em Generate new record e escolha 2048-bit com o prefixo de seletor padrão google. O Google então mostra um registro TXT cujo host é google._domainkey.yourdomain.com e cujo valor é v=DKIM1; k=rsa; p=<sua chave pública>. Você publica esse TXT no seu provedor de DNS — o Google guarda a chave privada correspondente e assina o e-mail de saída com ela. Duas coisas tornam o DKIM do Workspace diferente da maioria dos provedores. Primeiro, publicar o registro não basta: você precisa voltar à página Authenticate email e clicar em Start authentication, ou o Google nunca começa de fato a assinar com a sua chave (este é o motivo mais comum de um registro corretamente publicado ainda não mostrar um DKIM pass). Segundo, uma chave pública de 2048-bit excede o limite de 255 caracteres de uma única string TXT, então muitos provedores de DNS a armazenam como vários trechos entre aspas dentro de um registro; o Admin console mostra o valor já formatado, e a maioria dos painéis (GoDaddy, Cloudflare, Namecheap etc.) o reagrupa corretamente — se o Gmail depois reportar a chave como inválida, uma concatenação quebrada costuma ser a culpada. O seletor google pode ser mantido; você só o mudaria se esse seletor já estivesse em uso por outro serviço no domínio. Migre de qualquer chave legada de 1024-bit assim que puder, e lembre-se de que o DKIM é habilitado por domínio e por alias, não uma única vez para a conta inteira.
DMARC
O DMARC é um registro de política separado que você mesmo publica — o Google não o cria para você. Adicione um registro TXT em _dmarc.yourdomain.com com v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none é apenas monitoramento: não muda nada na entrega, mas diz aos destinatários para lhe enviarem relatórios agregados por e-mail para que você possa confirmar que o e-mail do Google Workspace está passando em SPF e DKIM alinhados ao seu domínio. Como o Workspace alinha os dois mecanismos (SPF via o seu próprio domínio de envelope, DKIM via o seletor google no seu domínio), você deve ver passes limpos rapidamente. Acompanhe os relatórios rua por uma ou duas semanas, certifique-se de que todo remetente legítimo — o Workspace mais quaisquer ferramentas de terceiros — está autenticando, e então endureça a política para p=quarantine e, por fim, p=reject. Mantenha exatamente um registro _dmarc para o domínio inteiro, independentemente de quantos remetentes você usa; nunca adicione um segundo registro DMARC especificamente para o Google. Note que a própria regra de remetente em massa do Google exige apenas p=none como piso, mas p=reject é o que de fato protege o seu domínio contra spoofing.
Confirme que funcionou de verdade
Não confie apenas no status do Admin console — ele pode atrasar e ainda dizer "up to 48 hours" mesmo depois de o DNS já estar no ar. Confirme em uma mensagem real: envie de um endereço Workspace para outra caixa de correio, abra no Gmail e escolha ⋮ → Show original. Você quer SPF: PASS, DKIM: PASS e DMARC: PASS, com os domínios signed-by do DKIM e do SPF ambos mostrando yourdomain.com (seletor google) em vez de google.com. O Google também publica seu próprio diagnóstico, a ferramenta Admin Toolbox CheckMX (toolbox.googleapps.com/apps/checkmx), que sinaliza registros SPF/DKIM/DMARC e MX ausentes ou malformados. Você pode fazer uma verificação pontual dos registros brutos com dig TXT google._domainkey.yourdomain.com e dig TXT _dmarc.yourdomain.com. Por fim, passe o domínio pela verificação de saúde do domínio da Qualisend para confirmar que todos os registros resolvem e que o SPF permanece abaixo do limite de 10 consultas, e assim que os relatórios agregados DMARC começarem a chegar, jogue um deles no analisador de relatórios DMARC — o Google deve aparecer como uma fonte alinhada e totalmente aprovada.
Pegadinhas comuns
- Quebra a autenticação
Gerar a chave DKIM não faz nada até você clicar em Start authentication na página Authenticate email. Um registro google._domainkey publicado com a assinatura nunca iniciada é o motivo nº 1 de o DKIM ainda falhar em uma verificação.
- Quebra a autenticação
Chaves DKIM de 2048-bit são mais longas que uma única string TXT de 255 caracteres, então são armazenadas como vários trechos entre aspas. Se o Gmail reportar a chave como inválida após a publicação, uma concatenação corrompida (ou o seu painel descartando a divisão) é quase sempre a causa.
- Quebra a autenticação
O Admin console pode continuar mostrando 'not authenticating' ou 'up to 48 hours' mesmo depois de o seu DNS estar correto — o status é reverificado com atraso. Confie no Show original / Admin Toolbox em vez do banner do console.
- Cobertura
O DKIM precisa ser configurado separadamente para cada domínio secundário e alias de domínio, e cada um desses domínios também precisa dos seus próprios registros SPF e DMARC. Autenticar o domínio primário não cobre os demais.
- Quebra a autenticação
Mantenha exatamente um registro SPF TXT na raiz. Se você também enviar via SendGrid, Mailchimp, Microsoft 365 etc., mescle include:_spf.google.com na única linha v=spf1 — dois registros SPF geram um PermError.
- Configuração de DNS
include:_spf.google.com agora é um único registro plano (1 consulta), mas guias mais antigos e alguns verificadores de SPF em cache ainda o contam como 3–4 — não superdimensione nem faça flatten em pânico com base em números desatualizados.
- Cobertura
Use ~all, não -all. O Google recomenda softfail porque usuários do Workspace frequentemente enviam legitimamente por outros serviços; um -all prematuro pode dar hard-fail em e-mails que você esqueceu de listar.
- Cobertura
E-mail enviado por um relay de terceiros, por um SMTP externo 'Send mail as' do Gmail ou por uma plataforma de marketing não é assinado com DKIM pelo Google — esses caminhos precisam da própria autenticação e não vão alinhar só porque o DKIM do Workspace está ativado.
Monte seu registro SPF
O Google Workspace já vem pré-selecionado abaixo. Adicione as outras plataformas pelas quais você envia e publique o registro único e combinado.
Os servidores próprios deste domínio
Autorize o próprio domínio, se ele envia e-mail diretamente (não por uma plataforma acima).
Outros remetentes e IPs
Qualquer coisa fora da lista — o host SPF de outro provedor ou endereços IP específicos.
Nós adicionamos o prefixo include: — informe o nome de host que seu provedor documenta.
Política para todos os demais
O que os destinatários devem fazer com e-mails de qualquer servidor não listado acima (o mecanismo all).
- Publique-o como um registro TXT no seu domínio raiz — host @ (o domínio puro), valor a string completa acima.
- Mantenha apenas um registro SPF por domínio. Mescle toda fonte de envio nesta única linha — um segundo registro TXT começando com v=spf1 invalida os dois.
- Fique em 10 consultas DNS ou menos. Cada include:, a e mx conta, e um include pode disparar mais consultas dentro de si — ip4: e ip6: são gratuitos.
Autenticação publicada? O próximo passo é enviar para uma lista limpa e verificada.
Verificar uma listaSPF do Google Workspace — Perguntas frequentes
Leituras relacionadas
Outros provedores de Workspace e caixa de e-mail
- mailbox.org
- Microsoft 365
- Microsoft 365 (GoDaddy / IONOS)
- Migadu
- Namecheap Private Email
- Proton Mail
- Purelymail
- Rackspace Email
Depois de publicado, confirme se tudo resolve corretamente com o verificação de saúde do domínio e, em seguida, veja quem está enviando em seu nome com o analisador de relatórios DMARC. Explore todas as fontes de envio no gerador. A autenticação, porém, é só metade da entregabilidade — um IP ou domínio de envio que esteja listado ainda te joga no spam por mais limpo que seu SPF esteja, então vale a pena acompanhar as blacklists com o monitoramento de blacklists.
Autenticado — agora mantenha a lista limpa
Passar em SPF, DKIM e DMARC te leva à caixa de entrada; uma lista limpa te mantém lá. Verifique a sua — comece grátis com 100 créditos, sem precisar de cartão.