Principal Outros Como corrigir o erro 550 5.7.515 — Autenticação de e-mail via Google Workspace

Como corrigir o erro 550 5.7.515 — Autenticação de e-mail via Google Workspace

Última atualização em May 21, 2026

Quando usar

  • Você usa Google Workspace e suas mensagens enviadas pelo Cloud Chat para destinatários Microsoft (Outlook, Hotmail, Live, Microsoft 365) estão sendo rejeitadas com o erro 550 5.7.515
  • O envio direto pelo Gmail funciona, mas pelo Cloud Chat (ou qualquer outra plataforma de terceiros) falha
  • Você precisa configurar SPF, DKIM e DMARC alinhados ao seu domínio para passar nos requisitos da Microsoft

Pré-requisitos

  • Acesso Super Admin ao Google Workspace (admin.google.com)
  • Acesso ao provedor de DNS do seu domínio (Registro.br, Cloudflare, GoDaddy, AWS Route 53 etc.)
  • Gmail ativado no domínio há pelo menos 24 a 72 horas antes de gerar a chave DKIM
  • Caixa de e-mail conectada — ver Como conectar caixa de e-mail do Google ao Cloud Chat

Substitua SEUDOMINIO.COM.BR pelo seu domínio real ao longo de todo este documento. Os exemplos usam esse placeholder apenas para ilustrar.


Sobre este artigo

Esse erro não é uma fragilidade do Cloud Chat — o mesmo aconteceria com qualquer plataforma de atendimento que envie e-mails em nome do seu domínio.

Quando você envia pelo Gmail direto, a mensagem sai dos servidores do Google — que já estão autorizados no SPF e assinam o DKIM com o seu domínio automaticamente. Tudo passa.

Quando o e-mail sai pelo Cloud Chat (ou qualquer plataforma de terceiros), ele parte de servidores diferentes, que não estão no SPF do seu domínio e não têm acesso à chave DKIM dele. Resultado: SPF falha, DKIM não alinha, DMARC não passa, e a Microsoft rejeita com 550 5.7.515:

550 5.7.515 Access denied, sending domain SEUDOMINIO.COM.BR doesn't meet
the required authentication level. The sender's domain in the 5322.From
address doesn't meet the authentication requirements defined for the
sender. Spf=Fail , Dkim=Pass , DMARC=None

A causa raiz: o domínio não tem SPF, DKIM e DMARC devidamente configurados. O Gmail direto "esconde" o problema porque o Google cuida disso automaticamente para os seus próprios servidores. Qualquer envio por fora expõe a lacuna.

Este guia corrige essa configuração no Google Workspace e no seu provedor de DNS. Depois de aplicada, a autenticação passa tanto pelo Gmail quanto pelo Cloud Chat.


Diagnóstico

A Microsoft rejeita suas mensagens porque falta autenticação alinhada ao domínio do cabeçalho From:. O cabeçalho da devolução costuma mostrar:

  • SPF = Fail — o registro SPF não inclui _spf.google.com, ou não existe

  • DKIM = Pass, mas sem alinhamento — o Google assina com d=gmail.com em vez de d=<seu-dominio>. Passa tecnicamente, mas não conta para o DMARC

  • DMARC = None — não existe registro DMARC publicado

Desde o fim de 2024, a Microsoft exige pelo menos um mecanismo de autenticação alinhado ao From: para remetentes de alto volume (≥ 5.000 mensagens para outlook.com, hotmail.com, live.com, msn.com). Se você já está recebendo esse erro, seu domínio ultrapassou esse limiar.

Sobre alinhamento: para o DMARC passar, basta SPF ou DKIM estar alinhado. Este guia configura os dois para maior confiabilidade, mas o DKIM alinhado (Etapa 2) é o componente principal.

Inspecionar o cabeçalho de uma mensagem devolvida

Antes de mexer no DNS, confirme o estado atual. Localize uma mensagem devolvida com o código 550 5.7.515, abra-a no Gmail e clique em Mostrar original. Procure a linha Authentication-Results:

Authentication-Results: ...
  spf=fail (sender IP is ...) smtp.mailfrom=<seu-dominio>;
  dkim=pass header.d=gmail.com;       ← d=gmail.com = SEM alinhamento
  dmarc=none action=none header.from=<seu-dominio>;

Se o padrão for esse, siga este guia. Se for diferente (ex: SPF pass, DMARC quarantine), a investigação deve seguir por outro caminho — abra um chamado de suporte.


Passo a passo

Etapa 1 — Publicar o registro SPF

No seu provedor de DNS, publique (ou atualize) um registro TXT no apex do domínio:

Campo Valor
Tipo TXT
Host / Nome @ (ou o próprio domínio)
Valor v=spf1 include:_spf.google.com ~all
TTL 3600

Só pode existir um único registro SPF por domínio. Se já houver um, edite-o e mescle os includes:

v=spf1 include:_spf.google.com include:outro-servico.com ~all

Verificação:

dig TXT <seu-dominio> +short
# Deve retornar uma linha contendo v=spf1 include:_spf.google.com ~all

Etapa 2 — Configurar o DKIM no Google Workspace (passo principal)

Este é o passo mais importante. Ele faz o Google assinar suas mensagens com d=<seu-dominio> em vez de d=gmail.com, resolvendo o problema de alinhamento.

2.1 — Gerar a chave DKIM

  1. Acesse admin.google.com como Super Admin

  2. Vá em Menu → Apps → Google Workspace → Gmail → Autenticar e-mail

  3. Selecione o seu domínio e clique em Gerar novo registro

  4. Configure: 2048 bits, prefixo do seletor: google

  5. Copie os dois valores exibidos:

    • Nome do host DNS: google._domainkey

    • Valor TXT: texto longo começando com v=DKIM1; k=rsa; p=MIIBIjAN...

Botão desabilitado? Aguarde 24–72h desde a ativação do Gmail no domínio.

2.2 — Publicar o registro DKIM no DNS

Campo Valor
Tipo TXT
Host / Nome google._domainkey
Valor Texto copiado do Admin console
TTL 3600

2.2.1 — Erro CharacterStringTooLong ao publicar o DKIM

Sintoma

Ao publicar o registro TXT google._domainkey, o provedor exibe erro semelhante a:

⚠️ Ocorreu um erro. Tente novamente mais tarde. CharacterStringTooLong (Value is too long) encountered with '"v=DKIM1; k=rsa; p=XXXXXXXX..."'

O registro não é salvo e a autenticação DKIM não pode ser ativada.

Causa

A RFC 1035 (seção 3.3) limita cada character-string de um registro TXT a 255 caracteres. A chave pública RSA de 2048 bits gerada pelo Google Workspace ultrapassa esse limite (≈400 caracteres), então o provedor rejeita quando o valor é enviado como string única. Não é problema da chave nem do Google Workspace — é limitação do protocolo DNS.

Solução

Quebre o valor em múltiplas strings de até 255 caracteres, cada uma entre aspas duplas e separadas por espaço. O servidor DNS concatena automaticamente na entrega, e o resolver enxerga uma única chave DKIM contínua.

Formato esperado:

"v=DKIM1; k=rsa; p=XXXXXXXXXXXXXXXXXXXXXXXXXXXX...ate_255_chars" "continuacao_ate_255_chars..." "parte_final_da_chave"

Como quebrar a chave

  1. Cole o valor copiado do Admin console (v=DKIM1; k=rsa; p=...) em um editor de texto

  2. A cada 255 caracteres do conteúdo, insira " " (aspas — espaço — aspas)

  3. Envolva o valor inteiro com aspas duplas no início e no fim

  4. Cole o resultado no campo Valor / Content do registro TXT

Dica: Não conte as aspas externas no limite de 255 — apenas o conteúdo da string.

Comportamento por provedor de DNS:

Provedor Como colar
Cloudflare Cole o valor já quebrado com aspas e espaços no campo Content. A UI aceita direto.
AWS Route 53 Cole as strings quebradas com aspas no campo Value. Cada string em linha separada também funciona.
Registro.br Formato de múltiplas strings entre aspas em linha única.
GoDaddy / HostGator / outros Aceitam o mesmo formato. Se a UI recusar aspas, procure a opção raw ou advanced.

Verificação

Após salvar e aguardar propagação (até 30 minutos), valide:

dig TXT google._domainkey.<seu-dominio> +short

A saída deve exibir a chave concatenada. Se o retorno mostrar várias strings separadas, ainda é válido — o que importa é a chave RSA reconstruída ser idêntica ao valor do Admin console. Para confirmar, compare a chave retornada pelo dig com a do passo de geração no Google Workspace.

2.3 — Ativar a autenticação

  1. Volte a Gmail → Autenticar e-mail no Admin console

  2. Clique em Iniciar autenticação

  3. Aguarde o status mudar para Autenticando e-mails com DKIM

Pode levar até 48 horas para começar a funcionar.

Verificação:

dig TXT google._domainkey.<seu-dominio> +short
# Deve retornar v=DKIM1; k=rsa; p=... completo

Etapa 3 — Publicar o registro DMARC

Publique o DMARC somente depois que SPF e DKIM estiverem autenticando corretamente por pelo menos 48 horas.

Campo Valor
Tipo TXT
Host / Nome _dmarc
Valor v=DMARC1; p=none; rua=mailto:dmarc-reports@<seu-dominio>; pct=100; adkim=s; aspf=s
TTL 3600

Crie uma caixa ou alias dmarc-reports@<seu-dominio> para receber os relatórios agregados (XML) que os provedores enviam diariamente.

Roteiro de endurecimento

Avance de fase somente depois de pelo menos uma semana sem falsos positivos nos relatórios.

Fase Semana Política Efeito
1 — Monitoramento 0 p=none Apenas gera relatórios
2 — Quarentena parcial ≥ 1 p=quarantine; pct=10 10% das não autenticadas vão para spam
3 — Quarentena total ≥ 2–3 p=quarantine; pct=100 Todas vão para spam
4 — Rejeição ≥ 4 p=reject; pct=100 Servidor rejeita mensagens não autenticadas

Desbloqueio rápido (se for urgente)

Se precisar destravar o envio para destinatários Microsoft imediatamente, publique apenas:

  1. Etapa 1 — o registro SPF

  2. Etapa 3 — o registro DMARC com p=none (sem esperar as 48h do DKIM)

Na maioria dos casos, isso já encerra o 550 5.7.515, porque a Microsoft mira especificamente domínios sem nenhum DMARC. Ter um DMARC publicado (mesmo permissivo) já muda o tratamento.

A Etapa 2 (DKIM alinhado) continua sendo a correção definitiva e precisa ser executada em seguida — sem ela, SPF e DMARC ficam sobre uma base frágil.


Verificação final

Depois da propagação (30 min para SPF/DMARC, até 48h para DKIM):

dig TXT <seu-dominio> +short                          # SPF
dig TXT google._domainkey.<seu-dominio> +short        # DKIM
dig TXT _dmarc.<seu-dominio> +short                   # DMARC

Teste funcional

Envie um e-mail de teste para qualquer endereço @outlook.com, @hotmail.com ou conta Microsoft 365. No cabeçalho do e-mail recebido, confira:

Authentication-Results: ...
  spf=pass smtp.mailfrom=<seu-dominio>;
  dkim=pass header.d=<seu-dominio>;   ← prova do alinhamento
  dmarc=pass header.from=<seu-dominio>;

Se as três linhas mostrarem pass com header.d=<seu-dominio> e header.from=<seu-dominio>, a configuração está correta — o erro 550 5.7.515 não voltará a ocorrer.

Se dkim=pass ainda aparecer com header.d=gmail.com, a Etapa 2.3 ainda não foi concluída ou o DNS continua propagando. Aguarde mais algumas horas e teste de novo.


Fontes oficiais


Observações