550 5.7.26 “This message does not have authentication information”: como corrigir no Gmail

Se o Gmail está devolvendo os seus e-mails com esta resposta SMTP, você esbarrou nas regras do Gmail para remetentes em massa:

550-5.7.26 This message does not have authentication information or fails to
550-5.7.26 pass authentication checks (SPF or DKIM). To best protect our users
550-5.7.26 from spam, the message has been blocked. Please visit
550 5.7.26 https://support.google.com/mail/answer/81126 for more information.

É uma rejeição por autenticação; reputação, conteúdo e filtros por usuário não têm nenhum papel nela. Os requisitos do Gmail para remetentes (em vigor desde fevereiro de 2024 e aplicados com mais rigor desde novembro de 2025) exigem que todo remetente passe em SPF ou DKIM, e que quem envia cerca de 5.000 mensagens ou mais por dia para contas pessoais do Gmail passe em SPF e DKIM, alinhe o domínio do From com um deles e publique um registro DMARC. Quando a autenticação falha, o Gmail rejeita a mensagem já na conversa SMTP.

O que o 550 5.7.26 significa de verdade

O erro tem três causas raiz possíveis, da mais para a menos frequente:

1. Nem o SPF nem o DKIM estão alinhados com o domínio visível do From:.
2. A política DMARC do seu próprio domínio (p=quarantine ou p=reject) manda o Gmail recusar o que falha. Um registro DMARC ausente tem código próprio, 4.7.40 ou 5.7.40, na lista de erros do Gmail.
3. SPF e DKIM passam, mas o domínio do cabeçalho From: não bate com o domínio autenticado (falha de alinhamento).

O Gmail não conta um SPF aprovado apenas no domínio do Return-Path/bounce. Se o seu domínio de bounce é bounces.esp.com e o seu From é hello@yourdomain.com, o SPF passa mas não alinha, então você precisa contar com um DKIM assinado por yourdomain.com.

Etapa 1: veja os cabeçalhos da mensagem original

Envie um teste para você mesmo, pela mesma plataforma de envio, para uma conta Gmail que ainda aceita a mensagem (ou uma conta Workspace em que você consiga ler o Spam). Abra a mensagem → três pontos → Mostrar original.

Procure o cabeçalho Authentication-Results::

Authentication-Results: mx.google.com;
       dkim=pass header.i=@esp.com;
       spf=pass smtp.mailfrom=bounces.esp.com;
       dmarc=fail (p=NONE) header.from=yourdomain.com

Neste exemplo, o DKIM passa para esp.com, mas o From é yourdomain.com, e é por isso que o DMARC falha. A correção é configurar a assinatura DKIM de yourdomain.com dentro do seu ESP, não mexer no SPF.

Etapa 2: corrija o alinhamento do DKIM

O alinhamento do DKIM é a vitória mais fácil. Quase todos os grandes ESPs (Mailchimp, HubSpot, SendGrid, Brevo, Klaviyo, ActiveCampaign, Customer.io, Resend, Postmark) aceitam DKIM com domínio próprio. Você adiciona o registro CNAME ou TXT que eles fornecem em selector._domainkey.yourdomain.com e depois ativa a assinatura DKIM no painel deles.

Depois da propagação (de alguns minutos a algumas horas), o cabeçalho Authentication-Results deve mostrar dkim=pass header.i=@yourdomain.com, e o DMARC passa pelo caminho do DKIM mesmo que o SPF não esteja alinhado.

Confira com a nossa ferramenta de consulta DKIM.

Etapa 3: publique um registro DMARC (mesmo que seja p=none)

As regras do Gmail para remetentes em massa exigem que exista um registro DMARC. p=none basta para cumprir esse requisito enquanto você ainda está monitorando. O registro mínimo que atende à regra é:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Adicione-o como registro TXT em _dmarc.yourdomain.com. Gere um com o nosso gerador de DMARC.

Etapa 4: confirme que o SPF não está quebrado sem você saber

Mesmo com o DKIM fazendo o trabalho, você quer o SPF limpo. Problemas comuns:

• Mais de 10 consultas DNS no registro SPF (causa permerror)
• Dois registros SPF no mesmo domínio (só um é permitido)
• Um -all (hard fail) onde você queria ~all (só importa se o seu ESP não está na lista de include)

Confira com a nossa ferramenta de consulta SPF. Se você passou do limite de 10 consultas, faça o flattening com delegação para subdomínios ou com um serviço de macros SPF.

Etapa 5: cadastre-se no Google Postmaster Tools e acompanhe

Se o 550 5.7.26 está atingindo você, cadastre o domínio do From no Google Postmaster Tools. Depois de 24 a 48 horas de tráfego, ele mostra:

• Taxa de aprovação na autenticação (meta: >99%)
• Reputação do domínio
• Reputação do IP
• Taxa de spam (o teto rígido do Gmail é 0,3%; mire em menos de 0,1%)

Se o gráfico de autenticação não estiver perto de 100% verde, as suas correções ainda não fizeram efeito completo.

Etapa 6: teste de novo a partir de uma conexão nova

As filas de nova tentativa dos ESPs podem levar 30 minutos para esvaziar. Pause e retome a campanha de envio, ou mande uma mensagem de teste nova depois que o DKIM e o DMARC propagarem. O bounce deve sumir na hora assim que a autenticação passar. O Gmail não "lembra" a falha anterior contra o seu IP.

Por que o 550 5.7.26 pode continuar mesmo depois de corrigir tudo

Algumas causas menos óbvias que vemos no suporte:

• Subdomínio diferente. Se o seu From é hello@mail.yourdomain.com mas o DKIM está configurado em yourdomain.com, o alinhamento é relaxed por padrão e deveria passar, mas alguns ESPs publicam alinhamento strict no DMARC (adkim=s). Mude para adkim=r.
• Cache de DNS desatualizado. O Gmail guarda DNS em cache por horas. Depois de publicar o DKIM, espere pelo menos 4 horas antes de concluir que a correção não funcionou.
• Seletor errado. Alguns ESPs fazem rodízio de seletores (por exemplo s1, s2). Se você removeu o registro TXT antigo antes de o novo entrar em vigor, vai ver falhas de DKIM até adicioná-lo de volta.

Perguntas frequentes

O 550 5.7.26 é a mesma coisa que o 550-5.7.1 do Gmail? Não. 550-5.7.1 Our system has detected... é um bloqueio por conteúdo/reputação. O 550-5.7.26 é estritamente um bounce de exigência de autenticação, e a correção é técnica (DKIM/SPF/DMARC), não tem a ver com conteúdo.

O Gmail vai bloquear o meu IP inteiro depois de um 550 5.7.26? Não. Esse bounce é avaliado por mensagem e por remetente. Sozinho, ele não prejudica a reputação do IP. Mas tentar de novo várias vezes com a autenticação quebrada desperdiça vagas de conexão e pode acabar freando você com throttling 421.

Preciso de uma política DMARC ativa (p=quarantine ou p=reject) para resolver isso? Não. O Gmail exige um registro DMARC publicado. p=none basta para a verificação de remetentes em massa. Passe para uma política ativa só depois que os relatórios agregados de DMARC estiverem limpos.

Fique à frente das regras do Gmail

O Gmail aperta esses requisitos a cada 12 a 18 meses. A MailVitals monitora o seu SPF, DKIM, DMARC e alinhamento continuamente e avisa você no momento em que qualquer registro sair do lugar.

Fontes

• Gmail SMTP errors and codes (Google Workspace Help), os três textos do 550 5.7.26 (remetente não autenticado, hard fail de SPF, política DMARC) e o 5.7.40, separado, para um registro DMARC ausente.
• Email sender guidelines (Gmail Help), SPF ou DKIM para todos os remetentes, SPF, DKIM, DMARC e alinhamento do From para remetentes em massa, e chaves DKIM de pelo menos 1024 bits.
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), o padrão DMARC atual (maio de 2026, substituindo a RFC 7489), incluindo o alinhamento de identificadores e os modos adkim/aspf.
• RFC 7208: Sender Policy Framework (SPF), o limite de 10 consultas DNS e o permerror que ele gera quando é ultrapassado.