Correção do erro `550 5.7.515` — Autenticação de e-mail via Google Workspace
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
- Set up DKIM — Google Workspace Admin Help
- Turn on DKIM for your domain — Google Workspace Admin Help
- Set up SPF — Google Workspace Admin Help
- Define your SPF record — Google Workspace Admin Help
- Add your DMARC record — Google Workspace Admin Help
- Recommended DMARC rollout — Google Workspace Admin Help
- Email sender guidelines — Google Workspace Admin Help
- Microsoft: Corrigir o erro NDR 550 5.7.515 — Outlook.com
