Defaults.Exposed › Correções › Guides

Gmail 550 5.7.26 "O remetente não está autenticado": a correção, por ordem de requisito (2026)

Publicado 2026-07-08

Números a 2026-06-29 · metodologia v7. Dados agregados do censo de 261 milhões de domínios classificados. Veja como classificamos.

O Gmail devolve 550 5.7.26 quando a sua mensagem falha as verificações de autenticação SPF e DKIM. Corrija-o fazendo com que pelo menos um dos dois — SPF ou DKIM — passe para o seu domínio de envio: à maioria dos remetentes falta exatamente isto. Dos 12.145.313 domínios que autorizam os servidores da Google via _spf.google.com, só 18,5% aplicam o DMARC, segundo o censo do Defaults.Exposed de 261.086.232 domínios.

A correção é trabalho de DNS, não um pedido de suporte: confirme que o seu IP de envio tem DNS inverso, faça o SPF ou o DKIM passar para o domínio que o Gmail realmente verifica, depois alinhe o DKIM com o seu endereço From e publique um registo DMARC. Abaixo está a ordem completa de requisitos, mais uma tabela descodificadora para a família 550 5.7.26 e os seus códigos irmãos.

O que significa o erro 550 5.7.26 do Gmail?

Desde os requisitos de remetentes de 2024 da Google, todos os remetentes para o Gmail — não só os remetentes em massa — têm de passar pelo menos um dos dois, SPF ou DKIM, para o domínio de envio. Falhe ambos e o Gmail rejeita em tempo de SMTP com 550 5.7.26, em vez de entregar em spam.

A versão de texto completo atual diz: “This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. Authentication results: DKIM = did not pass, SPF [domain] with ip: [ip] = did not pass.” Devoluções mais antigas ainda em circulação podem trazer a redação anterior da Google (“This mail is unauthenticated, which poses a security risk…”), e há um código irmão de limitação de ritmo — 421 4.7.26 This email has been rate limited because it is unauthenticated — com a mesma causa.

O 550 5.7.26 não é uma mensagem única, mas parte de uma família de códigos, e a redação diz-lhe qual das verificações falhou: a referência atual da Google mantém três frases sob 5.7.26 (não autenticado, falha rígida de SPF, política DMARC) e move as falhas exclusivas de SPF e exclusivas de DKIM dos remetentes em massa para os seus próprios códigos, 5.7.27 e 5.7.30. Leia o texto exato antes de tocar no DNS — é o seu primeiro diagnóstico.

A dimensão desta lacuna explica porque esta devolução é tão comum: 12.145.313 domínios autorizam os servidores de correio da Google no seu registo SPF (de 138.927.207 domínios em todo o mundo que publicam SPF), mas só 18,5% têm uma política DMARC aplicada e apenas 8,0% usam SPF estrito (-all). A maioria dos remetentes alojados na Google não cumpre as próprias regras da Google para remetentes em massa — e o Gmail agora aplica o básico a todos.

Que variante do 550 5.7.26 — ou código irmão — tem?

Compare o texto da devolução que recebeu com esta tabela. Os fragmentos citados seguem a referência atual da Google para erros SMTP — verifique-os sempre contra o seu NDR real, já que a Google revê a redação periodicamente.

Como se corrige o 550 5.7.26, por ordem de requisito?

A Google não publica uma “ordem de verificação” literal — mas os seus requisitos empilham-se logicamente, por isso percorra-os por esta ordem de requisito. A maioria dos remetentes fica desbloqueada depois do passo 3; termine a lista na mesma, porque os passos seguintes são o que o mantém fora do spam depois de sair da devolução.

1. Execute primeiro a verificação gratuita. Lê a sua configuração real de SPF, DKIM, DMARC e DNS e mostra exatamente qual das verificações está a falhar — diagnostique antes de tocar no DNS.
2. Dê ao seu IP de envio DNS inverso (PTR). O IP de ligação tem de ter um registo PTR cujo hostname resolve de volta para o mesmo IP. Os fornecedores convencionais tratam disto por si; morde quem envia a partir dos seus próprios servidores (e é toda a história por trás do código irmão 550 5.7.25).
3. Faça o SPF ou o DKIM passar. Primeiro, uma salvaguarda: os recetores avaliam o SPF contra o domínio do Return-Path (RFC5321.MailFrom), não contra o cabeçalho From — verifique para que domínio o seu correio devolve realmente antes de decidir que o SPF “devia” passar. Adicione os seus serviços de envio reais ao registo SPF desse domínio (guia completo de SPF), ou ative a assinatura DKIM no seu fornecedor (guia completo de DKIM). Qualquer um dos dois a passar remove o bloqueio básico do 550 5.7.26.
4. Alinhe o DKIM com o seu domínio From. Para envio em massa — e para o DMARC — o Gmail quer autenticação para o domínio no seu endereço From, não uma predefinição do fornecedor. Utilizadores do Google Workspace: publiquem a vossa própria chave DKIM (configuração de DKIM no Workspace); uma assinatura predefinida gappssmtp.com passa o DKIM mas não alinha — uma armadilha com o seu próprio guia. O DKIM alinhado também sobrevive ao reencaminhamento, o que o SPF nunca faz.
5. Publique um registo DMARC. Os requisitos da Google para remetentes pedem pelo menos p=none com um endereço de relatórios. É uma edição de DNS de cinco minutos — veja “Política DMARC não ativada” para o primeiro passo honesto e o que o p=none protege e não protege.
6. Envie por TLS. Qualquer servidor de correio ou fornecedor moderno faz isto por omissão; se gerir o seu próprio MTA, confirme que o TLS de saída está ativo — o correio em massa sem ele agora é devolvido com o seu próprio código, 550 5.7.29.
7. Adicione a anulação de subscrição com um clique do RFC 8058 (cabeçalhos List-Unsubscribe + List-Unsubscribe-Post) para correio de marketing e de subscrição.
8. Mantenha a sua taxa de spam abaixo de 0,10% no Google Postmaster Tools — e nunca a deixe chegar a 0,30%. O teto de requisito da Google é 0,3%; a sua recomendação é manter-se abaixo de 0,10%. Registe lá o seu domínio; é o próprio boletim de avaliação da Google sobre si, e o limiar da taxa de spam é o requisito que nenhum registo DNS consegue corrigir.

Uma coisa que esta lista não faz: tirá-lo de uma lista de bloqueio de terceiros. A autenticação trava as rejeições não autenticadas do Gmail; um IP com histórico de spam é um problema de reputação com o seu próprio caminho de limpeza — corrigir a autenticação previne recaídas, não o remove da lista.

As regras para remetentes em massa aplicam-se se eu enviar menos de 5000 emails por dia?

A lista de verificação completa — autenticação alinhada, DMARC publicado, anulação de subscrição com um clique, taxa de spam — aplica-se formalmente a partir de 5000+ mensagens por dia para o Gmail, e os códigos exclusivos de remetentes em massa (5.7.27, 5.7.29, 5.7.30) vêm desse escalão. Mas o básico da autenticação (SPF ou DKIM a passar, PTR válido) é aplicado a todos, por isso os pequenos remetentes também apanham o 550 5.7.26. Trate os passos 1–5 como obrigatórios em qualquer volume, e os passos 7–8 como obrigatórios a partir do momento em que envia em massa. O conjunto completo de requisitos para os dois fornecedores está no nosso artigo de dados sobre os requisitos da Google e da Yahoo para remetentes.

Perguntas frequentes

O 550 5.7.26 significa que o meu domínio ou IP está numa lista de bloqueio? Não. É uma falha de autenticação, não um veredito de reputação — o Gmail está a dizer “prove quem é”, não “sabemos que é um spammer”. É uma boa notícia: é totalmente corrigível no DNS. A má notícia é o quão normal isto é — em todo o censo de 261.086.232 domínios (a 2026-06-29), só 10,59% têm uma política DMARC aplicada.

Corrigir só o SPF vai parar as devoluções? Normalmente sim, para a variante básica — o Gmail exige pelo menos um dos dois, SPF ou DKIM. Mas o SPF é avaliado contra o domínio do Return-Path e quebra-se com o reencaminhamento, por isso o DKIM alinhado (passo 4) é a correção duradoura. Só 8,0% dos 12.145.313 domínios remetentes alojados na Google usam SPF estrito (dados a 2026-06-29), por isso, de qualquer forma, ficará à frente da maioria.

Uso o Google Workspace — porque é que a Google está a devolver o meu próprio correio? Porque o Gmail autentica o domínio, não o fornecedor da caixa de correio. Um domínio Workspace sem registo SPF e sem chave DKIM personalizada envia correio que a própria Google não consegue verificar — dos 12.145.313 domínios que autorizam os servidores da Google, só 18,5% têm o DMARC aplicado (dados a 2026-06-29). Ser cliente da Google e cumprir as regras da Google são coisas diferentes.

Quanto tempo depois da correção de DNS é que o Gmail vai aceitar o meu correio? Assim que os novos registos estiverem visíveis — normalmente minutos a algumas horas, até 48 horas para TTLs lentos. As correções de autenticação atuam de imediato na verificação 550 5.7.26; a recuperação da taxa de spam e da reputação (421-4.7.0, 5.7.28) leva dias a semanas de envio limpo.

Envie o relatório ao proprietário

Se está a corrigir isto para um cliente, não feche o pedido com “devoluções resolvidas”. Volte a executar a verificação gratuita depois das suas alterações de DNS e reencaminhe o relatório classificado ao dono do negócio. Mostra, em linguagem simples, que o domínio dele agora autentica o seu email e onde ainda fica aquém — a evidência de que precisam para as renovações do seguro cibernético e os questionários de segurança de fornecedores. Você corrigiu a devolução; o relatório prova-o.

Verifique o seu domínio gratuitamente

Veja qual das verificações de SPF, DKIM e DMARC o Gmail está a reprovar-lhe — em privado e só para o proprietário.

Verifique o seu domínio → · Corrigir o SPF → · Gmail “550-5.7.1 message blocked” → · Como classificamos → · Apenas dados agregados. Dados armazenados e processados na UE.