Registros DNS Google Workspace: MX, SPF, DKIM

Quais registros DNS do Google Workspace um domínio realmente precisa?

Um domínio no Google Workspace precisa de um conjunto pequeno e fixo de registros. Cada um tem sua função, e confundir um com o outro é a causa da maioria das falhas de configuração. A verificação prova ao Google que o domínio é seu. O MX diz aos outros servidores para onde entregar os e-mails destinados a você. SPF, DKIM e DMARC cuidam dos e-mails que você envia. Se você pretende fazer cold email a partir desse domínio, nenhum registro desta tabela é opcional. As diretrizes de remetentes do Gmail esperam autenticação de todo remetente, e as regras para remetentes em massa exigem SPF, DKIM e um registro DMARC com pelo menos p=none.

Registro	Tipo	Host / nome	Valor (exemplo)
Verificação do domínio	TXT	@	google-site-verification=… (string do Admin Console)
E-mail de entrada	MX	@	smtp.google.com, prioridade 1
SPF	TXT	@	v=spf1 include:_spf.google.com ~all
DKIM	TXT	google._domainkey	v=DKIM1; k=rsa; p=… (gerado no Admin Console)
DMARC	TXT	_dmarc	v=DMARC1; p=none; rua=mailto:dmarc@seudominio.com

Alterações de DNS não valem na hora. Os resolvedores continuam entregando o valor antigo até o TTL do registro expirar, então confira o registro publicado com o dig antes de concluir que uma alteração deu errado.

Quais são os registros DNS do Google Workspace para envio de e-mail?

Os registros de envio são SPF, DKIM e DMARC. O MX cuida só do recebimento. O SPF lista os servidores autorizados a enviar em nome do seu domínio. O DKIM adiciona uma assinatura criptográfica que o destinatário confere com uma chave pública publicada no DNS. O DMARC diz ao servidor de destino o que fazer quando o domínio do From de uma mensagem não está alinhado com um resultado de SPF ou DKIM aprovado. Configure-os nesta ordem:

1. 1 SPF: publique exatamente um registro TXT na raiz que comece com v=spf1 e inclua _spf.google.com. Se houver dois registros SPF, o resultado é permerror e o SPF falha.
2. 2 DKIM: no Admin Console, acesse Apps > Google Workspace > Gmail > Autenticar e-mail (Authenticate email), gere uma chave e publique-a como registro TXT em google._domainkey.
3. 3 Ativação do DKIM: assim que o registro estiver resolvendo, volte à mesma tela e clique em Iniciar autenticação (Start authentication). Enquanto você não fizer isso, o Gmail não assina com a sua chave.
4. 4 DMARC: publique v=DMARC1; p=none com um endereço rua para receber os relatórios agregados antes de endurecer a política.
5. 5 Fique dentro do limite de consultas DNS do SPF. Cada include conta, e os includes aninhados dentro dele também.

Uma chave DKIM longa pode ultrapassar o limite de tamanho de uma única string TXT. Alguns provedores de DNS dividem a chave automaticamente, outros não. Nesse caso, publique o valor em partes, exatamente como o Admin Console o entrega, e confira depois se a chave completa aparece na consulta.

Quais são os registros MX do Google Workspace?

Domínios mais recentes no Google Workspace usam um único registro MX apontando para smtp.google.com. Domínios mais antigos muitas vezes ainda têm o conjunto legado de vários registros, com ASPMX.L.GOOGLE.COM como host principal e vários hosts ALT como reserva, e o Google continua dando suporte a ele. Você pode manter qualquer um dos dois, mas não misture e não deixe registros apontando para o provedor antigo. Quando há vários registros MX, os servidores remetentes tentam primeiro o de menor valor de prioridade. Um MX esquecido apontando para um provedor anterior acaba dividindo seus e-mails de entrada entre dois sistemas.

Configuração	Host MX	Prioridade
Atual (registro único)	smtp.google.com	1
Legado	ASPMX.L.GOOGLE.COM	1
Legado	ALT1.ASPMX.L.GOOGLE.COM	5
Legado	ALT2.ASPMX.L.GOOGLE.COM	5
Legado	ALT3.ASPMX.L.GOOGLE.COM	10
Legado	ALT4.ASPMX.L.GOOGLE.COM	10

O MX não interfere na autenticação de saída, mas faz diferença na prospecção a frio. As respostas às suas mensagens vão para o endereço do From ou do Reply-To e, se o MX estiver errado, essas respostas voltam como bounce ou caem num lugar que você nunca olha. Rode dig MX seudominio.com e confirme que só aparecem hosts do Google.

Os registros DNS do Google Workspace cobrem e-mails enviados pelo Brevo?

Não. A chave google._domainkey do Google só assina e-mails que saem dos servidores do Google. O EmailFlow OS funciona assim: você grava um único vídeo e faz o upload, 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. O EmailFlow OS então cria uma versão personalizada dessa gravação para cada destinatário e a envia pela sua conta Brevo, a partir do seu domínio. Quem envia é o Brevo, não o Google. Por isso o domínio precisa dos registros DKIM do Brevo, exatamente como o Brevo os mostra nas configurações de autenticação de domínio, ao lado dos registros do Google. Os dois convivem sem conflito porque cada um usa um seletor diferente.

É no SPF que muita gente tropeça. Junte tudo em um único registro, e não um por provedor. Cada include consome parte do limite de consultas do SPF. O alinhamento DMARC passa quando o SPF ou o DKIM está alinhado com o domínio do From, então é a chave DKIM do Brevo publicada no seu próprio domínio que permite o alinhamento dos e-mails enviados pelo Brevo. Como o domínio e a conta Brevo são seus, os registros ficam no seu DNS e sob o seu controle. Vale entender bem como SPF, DKIM e DMARC se alinham antes de começar a enviar cold email.

Por que os registros DNS do Google Workspace falham mesmo parecendo certos?

A maioria das falhas se resume a poucas causas, que você encontra com o dig ou com a opção Mostrar original do Gmail, que exibe os resultados de SPF, DKIM e DMARC de uma mensagem recebida:

• Dois registros SPF na raiz: o SPF retorna permerror, e os servidores de destino tratam isso como falha.
• Consultas DNS demais no SPF: o mesmo permerror, muitas vezes causado por empilhar um include para cada ferramenta.
• Chave DKIM publicada, mas nunca ativada: o registro existe, mas o Gmail não assina até você clicar em Iniciar autenticação.
• Chave DKIM truncada: o provedor de DNS cortou o valor, e a chave pública não bate mais com a assinatura.
• Registro DMARC no host errado: ele precisa ficar em _dmarc. Um registro DMARC na raiz é ignorado.
• TTL desatualizado: você alterou um registro, mas os resolvedores continuam entregando o valor antigo até o TTL expirar.

Registros corretos são um pré-requisito. Eles não decidem onde o seu e-mail cai, porque quem decide é o servidor de destino. Um domínio novo ainda precisa de um aumento gradual de volume, ou seja, de um aquecimento de domínio com volumes diários crescentes depois que o DNS estiver configurado.

Perguntas frequentes

? Qual é o registro MX do Google Workspace?

Domínios mais recentes usam um único registro MX apontando para smtp.google.com. Domínios mais antigos podem usar o conjunto legado, com ASPMX.L.GOOGLE.COM como host principal e vários hosts ALT como reserva. O Google aceita os dois, mas use só um conjunto e remova qualquer registro MX que aponte para o provedor anterior. Caso contrário, os e-mails de entrada e as respostas ficam divididos entre dois sistemas.

? Qual é o registro SPF do Google Workspace?

É v=spf1 include:_spf.google.com ~all, publicado como um único registro TXT na raiz do domínio. Se você também envia pelo Brevo ou por outro serviço, adicione o include dele nesse mesmo registro em vez de criar um segundo. Um domínio só pode ter um registro SPF, e o SPF limita o número de consultas DNS que um registro pode disparar.

? Quanto tempo os registros DNS do Google Workspace levam para funcionar?

Depende do TTL do registro. Os resolvedores entregam o valor em cache até ele expirar, então a alteração aparece aos poucos. O DKIM tem um passo a mais: quando o registro google._domainkey estiver resolvendo, você precisa clicar em Iniciar autenticação no Admin Console para o Gmail passar a assinar seus e-mails. Só publicar o registro não ativa a assinatura.

? Preciso de DMARC no Google Workspace?

Sim, se você envia em volume. As regras do Gmail para remetentes em massa exigem um registro DMARC com pelo menos p=none, e uma política p=none já gera relatórios agregados sem bloquear nada. Publique-o como registro TXT em _dmarc.seudominio.com com um endereço rua para ver quais servidores enviam em nome do seu domínio.