Principal Outros Correção do erro `550 5.7.515` — Autenticação de e-mail via Google Workspace

Correção do erro `550 5.7.515` — Autenticação de e-mail via Google Workspace

Última atualização em Apr 15, 2026

Por que esse erro acontece no CloudChat e não no envio via Gmail direto?

Esse é um comportamento esperado e não se trata de uma fragilidade do CloudChat. 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 CloudChat (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 CloudChat.

Substitua SEUDOMINIO.COM.BR pelo seu domínio real ao longo de todo este documento.

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 (Passo 2) é o componente principal.

Diagnóstico prévio — 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.

Pré-requisitos

  • Acesso Super Admin ao Google Workspace (admin.google.com).

  • Acesso ao provedor de DNS (Registro.br, Cloudflare, GoDaddy, etc.).

  • O Gmail precisa estar ativado no domínio há pelo menos 24 a 72 horas antes de gerar a chave DKIM.

Passo 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:

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

Verificação:

bash

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

Passo 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.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:

bash

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

Passo 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. Passo 1 — o registro SPF.

  2. Passo 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.

O Passo 2 (DKIM alinhado) continua sendo a correção definitiva e precisa ser executado em seguida — sem ele, 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):

bash

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 dkim=pass ainda aparecer com header.d=gmail.com, o Passo 2.3 ainda não foi concluído ou o DNS continua propagando.

Fontes oficiais