Gmail "550-5.7.1 Message Blocked" — descodifique a devolução e corrija-a (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.1 quando bloqueia uma mensagem por razões de política e não por um registo em falta: a política de um domínio remetente ou destinatário, uma ligação IPv6 sem DNS inverso, ou suspeita de spam. Dos 12.145.313 domínios que autorizam os próprios servidores da Google no SPF, só 18,5% aplicam o DMARC, segundo o censo do Defaults.Exposed de 261 milhões de domínios.

O 550-5.7.1 é a rejeição apanha-tudo mais antiga do Gmail, e a correção depende da frase a seguir ao código na sua devolução. Abaixo: uma tabela descodificadora para a redação exata, depois o caminho de correção por variante — rejeições de política, servidores IPv6 sem DNS inverso, bloqueios por spam ou conteúdo — mais os códigos parecidos com que as pessoas o confundem, incluindo a família 5.7.26 que a Google agora usa para a rejeição por política DMARC que as referências mais antigas arquivavam sob 5.7.1.

O que significa realmente o 550-5.7.1 do Gmail?

No esquema de estados melhorados do SMTP (RFC 3463), todos os códigos 5.7.x significam “falha permanente, razões de política”. O Gmail usa o 550-5.7.1 como a sua família de política legada: bloqueios por política do remetente ou do destinatário, bloqueios por reputação de spam, e — a variante que mais surpreende os administradores — correio a chegar por IPv6 a partir de um servidor sem registo de DNS inverso (PTR).

A Google tem vindo a recodificar variantes ao longo do tempo. A rejeição por política DMARC (“not accepted due to domain’s DMARC policy”) está agora sob 550-5.7.26 na referência atual da Google, embora devoluções mais antigas em circulação ainda a possam mostrar como 5.7.1; o bloqueio de segurança de conteúdo tem agora o código 552 5.7.0. Dois outros irmãos são confundidos com o 5.7.1: o 550-5.7.26, a família de requisitos de autenticação (o seu próprio guia), e o 550-5.7.25, o código de PTR em falta em qualquer versão de IP. Seja qual for o código, descodifique o texto abaixo.

Que variante do 550-5.7.1 tem?

Compare a redação no seu relatório de não entrega (NDR). A Google ajusta estas frases de ano para ano — compare o sentido, não a pontuação.

A sua devolução parece-se com…	O que significa	O seu caminho de correção
”This message does not meet IPv6 sending guidelines regarding PTR records and authentication.”	O seu servidor entregou por IPv6 sem DNS inverso (ou com um que não corresponde)	Registo PTR para o endereço IPv6, ou retransmissão via smarthost do seu fornecedor (abaixo)
“The user or domain that you are sending to (or from) has a policy that prohibited the email that you sent.”	Um bloqueio de política — do destinatário, ou do seu próprio domínio	Contacte o administrador recetor; se a política em jogo for o DMARC do seu próprio domínio, veja abaixo
”This message is likely unsolicited email. To reduce the amount of spam sent to Gmail, this message has been blocked.”	Bloqueio por spam/reputação sobre o seu conteúdo, IP ou domínio	Postmaster Tools + higiene de lista + anulação de subscrição com um clique (abaixo)
“This message is likely suspicious due to the very low reputation of the sending domain” (ou “…sending IP address”)	Bloqueio por reputação — domínio ou IP	O mesmo caminho de reputação (abaixo)
“Unauthenticated email from yourdomain is not accepted due to domain’s DMARC policy.” — com o código 550-5.7.26 na referência atual da Google; devoluções mais antigas podem ainda mostrar 5.7.1	A sua própria política DMARC disse ao Gmail para rejeitar uma mensagem não autenticada	Encontre a origem não autenticada — não afrouxe a política primeiro (abaixo)
“…blocked because its content presents a potential security issue.” — agora com o código 552 5.7.0	Bloqueio de conteúdo/política (tipo de anexo, reputação de links)	Remova a classe de conteúdo sinalizada; verifique links e anexos
O código é 550-5.7.25, “the sending IP address doesn’t have a PTR record”	DNS inverso em falta em qualquer versão de IP	A mesma correção de rDNS da variante IPv6
O código é 550-5.7.26	Família de requisitos de autenticação, não 5.7.1	Veja o guia do 550-5.7.26
O código é 421-4.7.0, “Try again later, closing connection.”	Adiamento temporário — ritmo ou reputação, não um bloqueio permanente	Abrande, corrija a autenticação e a taxa de spam; normalmente resolve-se

Como se corrige uma devolução 550-5.7.1?

Execute a verificação gratuita em defaults.exposed — classifica o seu SPF, DKIM e DMARC tal como o mundo os vê, antes de tocar no DNS, e mostra se a variante DMARC é sequer possível para o seu domínio.
Leia o texto completo do NDR contra a tabela descodificadora — é a frase, não o código, que identifica a causa.
Variante DMARC: descubra que origem de envio falhou a autenticação e corrija essa origem (próxima secção).
Variante IPv6/PTR: adicione DNS inverso correspondente para o endereço IPv6 do servidor, ou retransmita pelo smarthost do seu fornecedor.
Variante spam/política: Postmaster Tools, taxa de spam abaixo de 0,10% (o teto de requisito rígido da Google é 0,30%), higiene de lista, anulação de subscrição com um clique conforme o RFC 8058.
Reenvie um teste para uma caixa Gmail e volte a verificar — confirme que a devolução desapareceu e que a nota o reflete.

A devolução menciona a sua política DMARC — porque isso é a sua política a funcionar

A referência atual da Google codifica esta frase como 550-5.7.26, mas devoluções mais antigas e documentação de terceiros ainda a mostram sob 5.7.1 — de qualquer forma a mecânica é idêntica. Parece ao contrário até que se percebe: o Gmail verificou uma mensagem que dizia vir do seu domínio, constatou que nem o SPF nem o DKIM passaram com alinhamento, consultou o seu registo DMARC, e fez exatamente o que lhe pediu — rejeitar. A sua vedação aguentou. A questão é o que ficou preso nela: um remetente legítimo esquecido (um CRM, uma ferramenta de faturação, uma plataforma de newsletters) ou uma falsificação a sério.

Portanto não afrouxe a política como primeiro passo. Encontre a origem não autenticada. Duas armadilhas explicam a maioria dos casos:

O SPF passa, mas no domínio errado. Os recetores avaliam o SPF contra o domínio do Return-Path (RFC5321.MailFrom), não o cabeçalho From. Uma ferramenta SaaS a enviar “como” você normalmente passa o SPF no domínio de devoluções dela, que não alinha com o seu domínio From — portanto o DMARC continua a falhar. Passo a passo: DMARC falha mas SPF e DKIM passam.
O DKIM passa, mas com a assinatura predefinida. Os predefinidos gappssmtp.com do Google Workspace e onmicrosoft.com da Microsoft verificam bem e não alinham com nada. Veja DKIM passa mas o DMARC continua a falhar.

Esta variante é mais rara do que pensaria: 27.640.987 de 261.086.232 domínios — 10,59% — aplicam uma política DMARC de quarantine ou reject, segundo o censo do Defaults.Exposed (2026-06-29). Os outros 89,41% nunca veem esta devolução porque não têm vedação para aguentar. Corrigir a origem, não a política, está coberto de ponta a ponta no guia de correção do DMARC.

A devolução menciona diretrizes de envio IPv6 — a correção do DNS inverso

Os servidores modernos ligam-se muitas vezes ao Gmail por IPv6 por omissão, e a Google exige que o endereço IPv6 da ligação tenha um registo PTR que resolva para um hostname que resolve de volta para o mesmo endereço (DNS inverso confirmado no sentido direto). Falhe isso, e todas as mensagens levam 550-5.7.1, por muito limpo que o seu SPF esteja.

Três correções, por ordem de preferência:

Defina o registo PTR para o endereço IPv6 do seu servidor — feito onde o IP vive (o painel do seu alojamento VPS ou do ISP, não a zona DNS do seu domínio), com um registo AAAA correspondente a apontar de volta.
Retransmita pelo smarthost do seu fornecedor. Se não pode controlar o rDNS, encaminhe o correio de saída pelo relay do seu fornecedor de email ou ISP, que já tem rDNS em ordem.
Prefira transporte IPv4 como paliativo. Normalmente esconde o sintoma porque o seu endereço IPv4 tem PTR — um desenrasque, não uma correção. Defina o PTR do IPv6 quando puder.

A devolução diz “likely unsolicited email” — o caminho da reputação

Aqui a autenticação pode estar bem, mas os filtros do Gmail não confiam no correio. A autenticação é o piso, não o teto — entre os 12.145.313 domínios que autorizam _spf.google.com, só 8,0% trancam o SPF com um -all estrito, portanto uma verificação aprovada diz pouco por si só. (Comparação completa: que fornecedor de email dá os predefinidos de SPF mais fortes.)

A lista de verificação da reputação:

Registe-se no Google Postmaster Tools e vigie o painel da taxa de spam — mantenha-a abaixo de 0,10%, e nunca a deixe chegar ao teto de 0,30% que as diretrizes da Google para remetentes em massa definem como requisito rígido.
Limpe a sua lista. Descarte quem não interage e tudo o que foi comprado ou raspado; envie só a quem pediu.
Implemente a anulação de subscrição com um clique do RFC 8058 no correio em massa — exigida pelas regras da Google, e cada anulação que não é um clique em “spam” protege a sua taxa.
Mantenha a autenticação alinhada (SPF e DKIM no seu próprio domínio) para que a reputação se acumule num domínio que controla.

Perguntas frequentes

O 550-5.7.1 é o mesmo que o 550-5.7.26? Não. O 550-5.7.26 é a família de requisitos de autenticação do Gmail (SPF/DKIM em falta ou a falhar) — e a referência atual da Google também arquiva aí a rejeição por política DMARC. O 550-5.7.1 é a família de política mais antiga: bloqueios por política do destinatário e do remetente, IPv6 sem PTR, bloqueios por spam e reputação. É o texto da devolução, não o número, que lhe diz que correção se aplica (a 2026-06-29 e segundo as diretrizes atuais da Google).

Devo voltar a pôr a minha política DMARC em p=none para parar as devoluções? Isso pára-as deitando a vedação abaixo. Só 10,59% dos 261.086.232 domínios do censo do Defaults.Exposed (2026-06-29) aplicam sequer o DMARC; se é um deles, mantenha-a e corrija a origem não autenticada — afrouxar a política reabre a falsificação de domínio exato.

Porque é que o Gmail bloqueia o meu correio se o meu registo SPF passa em todos os verificadores? Os verificadores testam o registo; o Gmail testa a mensagem. O SPF é avaliado contra o domínio do Return-Path, não contra o endereço From visível, portanto um pass no domínio de devoluções de um fornecedor não faz nada pelo seu alinhamento DMARC — e os bloqueios por reputação ignoram o SPF por completo. A verificação gratuita mostra que camada falha realmente.

O 550-5.7.1 significa que o meu IP está numa lista negra? Não necessariamente. O Gmail tem o seu próprio sistema de reputação; pode ser bloqueado pela Google sem estar em nenhuma lista de bloqueio pública. Consulte o Postmaster Tools para a visão da Google — e note que corrigir a autenticação previne danos futuros mas não repõe, por si só, uma má reputação de envio.

Envie o relatório ao proprietário

Assim que a devolução estiver corrigida, volte a executar a verificação e reencaminhe o relatório classificado ao dono do negócio ou cliente cujo correio estava a ser devolvido. Mostra, em linguagem simples, o que estava partido, o que corrigiu, e onde o domínio está agora face à base de referência de 261 milhões de domínios — exatamente o que eles precisam para a renovação do seguro ou o questionário de segurança do cliente que pergunta “autenticam o vosso email?”. Uma devolução corrigida em silêncio é trabalho invisível; um relatório antes-e-depois é prova.

Verifique o seu domínio → · Gmail 550-5.7.26 — a correção por ordem de requisito → · Corrigir o DMARC → · Como classificamos → · Apenas dados agregados. Dados armazenados e processados na UE.