Por que o Gmail rejeita seus e-mails (e como resolver)

Se os seus correios ao Gmail voltam com um código que começa por 550, você não está diante de uma falha passageira nem de um capricho do filtro de spam. Você está diante de uma decisão: o Gmail olhou a sua mensagem, viu que ela não cumpre os seus requisitos e a devolveu antes de chegar a qualquer pasta. Durante quase dois anos, o correio que descumpria as regras que Google e Yahoo anunciaram em outubro de 2023 costumava acabar na pasta de spam, o que deixava uma saída: o destinatário diligente que ia resgatá-lo. Em novembro de 2025 essa saída se fechou.

A diferença importa mais do que parece. Uma mensagem na pasta de spam chegou mesmo assim; alguém pode recuperá-la e você pode recuperar a sua reputação com o tempo. Uma mensagem rejeitada não chega: não há pasta da qual resgatá-la, nem segunda chance de interação, só um bounce nos seus registros e um cliente que não recebeu a sua confirmação. Para quem tratou o guia de 2024 como uma recomendação, a passagem da filtragem à rejeição é o momento em que o conselho virou obrigação.

O que mudou, exatamente

Em 3 de novembro de 2025, o Google adicionou uma linha às perguntas frequentes das suas Diretrizes para remetentes — o documento que antes se chamava Diretrizes para remetentes em massa — avisando que naquele mês intensificava a aplicação contra o tráfego não conforme, e que o correio que falhasse sofreria interrupções que incluíam rejeições temporárias e permanentes. Nada dos requisitos de fundo era novo; a novidade foi confirmar que a aplicação, prometida havia tempo, chegava a sério.

Na prática, um regime brando ficou duro. Durante 2024 e quase todo o 2025 a aplicação tinha sido, nas palavras do próprio Google, de mão leve: uma parte pequena do correio não conforme via erros e o resto se colava às pastas de spam. Desde novembro de 2025 a postura é ativa. O correio que falha a autenticação ou cruza os limiares de política se limita primeiro e se rejeita depois no nível SMTP, antes de chegar a qualquer pasta. O período de carência que começou quando se anunciaram as regras se acabou.

Como ler a rejeição: os códigos

A vantagem da rejeição é que ela se explica sozinha. Onde uma colocação no spam era silenciosa — você só ficava sabendo pela interação que faltava —, uma rejeição nomeia o motivo no seu código. Estes são os que convém reconhecer de relance, segundo a documentação do Google.

A leitura operativa é simples. Os códigos da série 4.x são temporários: um adiamento que limita a sua frequência de envio e pede que você reintente, o equivalente SMTP de mandarem você reduzir o ritmo. São recuperáveis; corrija a causa e o correio volta a fluir. Os da série 5.x são permanentes e definitivos para aquela mensagem: um bounce do qual só um reenvio corrigido salva você. Como o lançamento é gradual, ignorar os adiamentos 4.x é, na prática, aceitar as rejeições 5.x que vêm depois.

Por que o Gmail rejeita o seu correio: as causas reais

Atrás de quase todos os bounces 550 há uma destas razões, e raramente é a que se suspeita primeiro.

• Autenticação ausente ou mal alinhada. A causa mais frequente do 5.7.26. Não basta ter SPF e DKIM: eles têm que se alinhar com o domínio do remetente visível. Uma ferramenta nova que envia sem assinar, ou um SPF que já não cobre os seus IPs, basta para falhar.
• DMARC ausente ou em p=none mal entendido. Sem DMARC, o Gmail não tem uma política a aplicar; com p=none, tem mas não faz nada. Cumpre o requisito no papel e não protege contra quem se passe pelo seu domínio.
• IP ou domínio em lista negra. Se o seu IP de envio figura em uma lista de bloqueio por histórico de spam, muitos servidores — Gmail incluído — rejeitam o seu correio de entrada.
• Taxa de reclamações alta. Acima do limiar, o Gmail age independentemente de quão limpa esteja a sua autenticação.
• Cabeçalhos, PTR, TLS e a porta 25. Mensagens mal formadas segundo a RFC 5322, falta de DNS reverso válido ou ausência de TLS na conexão também provocam rejeições. No Brasil soma-se um ponto de rede: se o envio sai de uma rede que bloqueia a porta 25 — as residenciais o fazem pela Gerência de Porta 25 do CGI.br, e nuvens como a AWS bloqueiam por padrão —, a entrega ao Gmail nem chega a se estabelecer, e o sintoma aparece como falha de conexão antes de qualquer código de conteúdo.

Como chegamos até aqui

A mudança de novembro é o final de um caminho visível desde 2023, e a cronologia merece ser tida presente, porque cada passo apertou o anterior.

• Outubro de 2023 — Google e Yahoo anunciam conjuntamente os requisitos: autenticação, alinhamento, descadastro simples, um teto de reclamações e cabeçalhos válidos.
• Fevereiro de 2024 — começa a aplicação inicial. Uma pequena porcentagem do correio não conforme começa a ver erros temporários como o 5.7.26.
• Abril de 2024 — o Google começa a rejeitar uma porcentagem do correio não conforme, que sobe com o tempo.
• 1 de junho de 2024 — o descadastro em um clique passa a ser obrigatório para o correio em massa de marketing.
• Outubro de 2025 — o Google retira o Postmaster Tools antigo e lança o Postmaster Tools v2, que substitui as notas de reputação por um estado de conformidade.
• Novembro de 2025 — a aplicação sobe para rejeição ativa. O período brando termina.

Lido em conjunto, a lição é que «isto a gente resolveu em 2024» quase nunca equivale a «cumprimos agora». Cada fase dava por absorvida a anterior, e o passo de novembro dá por certo que você leva mais de um ano autenticado e alinhado.

Postmaster Tools v2: da reputação à conformidade

A mudança mais silenciosa de outubro de 2025 pode pesar tanto quanto a de novembro. O Google retirou o painel antigo do Postmaster Tools, com as suas notas de reputação Alta, Média, Baixa e Ruim, e o substituiu pelo Postmaster Tools v2, construído em torno de um Estado de conformidade binário. A mudança de linguagem é a mudança de filosofia: durante anos uma reputação forte podia sustentar um remetente apesar de algum deslize, e o objetivo era manter o indicador no verde. Com o v2, a primeira pergunta não é quão boa é a sua reputação, e sim se você cumpre os requisitos, sem mais.

Isso converte as velhas notas de reputação em algo necessário mas já não suficiente. Quem antes se apoiava em uma reputação alta para sobreviver a uma autenticação descuidada já não tem esse colchão: a conformidade se verifica primeiro, e um domínio que não a passa não pode recorrer ao seu histórico. Se a sua estratégia de entregabilidade era, em essência, «manter alta a reputação no Postmaster Tools», o v2 é o aviso para reconstruí-la em torno da lista de conformidade.

Quem conta agora como remetente em massa

O limiar segue sendo cinco mil mensagens por dia, mas há dois detalhes fáceis de errar. A contagem é por domínio de envio rumo às caixas de entrada de consumo de um provedor, então o volume repartido entre subdomínios soma ao domínio principal em vez de se dividir limpamente. E o Google estreitou a definição desde o anúncio original: onde o texto de 2023 cobria o correio tanto a contas gratuitas do Gmail quanto a contas pagas do Google Workspace, o guia atual aplica as regras de remetente em massa ao correio enviado a contas pessoais e gratuitas do Gmail. O correio ao Workspace se rege pelos seus próprios controles administrativos.

O estreitamento não é uma isenção para relaxar. As expectativas de autenticação, descadastro e reclamações se leem já como a base para qualquer remetente de certo peso, em massa ou não, porque os filtros favorecem o correio autenticado e bem-educado para todos. Um remetente logo abaixo do limiar que pule a autenticação não está a salvo; simplesmente, ainda não o rejeitam por isso.

Por que uma rejeição é pior que a pasta de spam

Convém ser concreto com o custo, porque as equipes que imaginavam a pasta de spam tendem a subestimá-lo. Uma mensagem transacional rejeitada é uma redefinição de senha que não chega, um recibo que o cliente não vê, uma confirmação de pedido que gera um chamado de suporte. Uma mensagem de marketing rejeitada é uma campanha que falha em silêncio, com o bounce enterrado em registros que a equipe de marketing talvez nunca leia. Em ambos os casos a falha é invisível no momento do envio e cara no momento da descoberta, que costuma ser um cliente confuso ou uma métrica que despencou. A pasta de spam, ao menos, mantinha o correio dentro de casa; a rejeição, não.

Como saber se você é afetado

Três sinais dizem a você onde está, e são rápidos de conferir. O primeiro são os seus registros de bounces: um aumento de adiamentos 4.7.x ou de rejeições 5.7.x vindas do Gmail, cada um com o seu motivo, é a prova mais clara de que a aplicação alcançou você. O segundo é o Postmaster Tools v2, onde o Estado de conformidade diz já sem rodeios se o seu domínio cumpre os requisitos em vez de deixar você deduzir de uma nota de reputação. O terceiro é a sua própria autenticação: se SPF, DKIM e DMARC não estão todos presentes e alinhados com o domínio do remetente visível, você está exposto aconteça o que acontecer hoje nos registros, porque a aplicação é gradual e a sua vez chegará.

Como resolver, passo a passo

A correção é a mesma lista de sempre, com a urgência que a mudança de novembro acrescenta.

1. Autentique e alinhe. SPF, DKIM e DMARC válidos, e alinhados com o domínio do From. O que passa o filtro é o alinhamento, não a mera presença.
2. Publique DMARC e faça-o avançar. O registro é obrigatório; uma política em p=none cumpre a letra e não protege nada, então planeje o passo para quarentena e depois para rejeição quando os seus relatórios estiverem limpos.
3. Honre os descadastros rápido. Descadastro em um clique no correio de marketing, processado em uns dois dias, e fora do correio transacional para que ninguém se descadastre de um recibo.
4. Mantenha baixas as reclamações. Abaixo de 0,10% como objetivo; 0,30% é a linha na qual os provedores agem independentemente da autenticação.
5. Valide os cabeçalhos. Estrutura conforme a RFC, DNS reverso válido e TLS na conexão.
6. Vigie o Postmaster Tools v2. Trate o seu Estado de conformidade como o placar e leia os códigos de bounce como o diagnóstico quando algo se torcer.

SPF: o limite de dez consultas e o que o estoura

O SPF parece o registro mais simples dos três e é o que falha de formas mais discretas. A regra que mais pega gente é o limite de dez consultas de DNS: a especificação manda que avaliar um registro SPF não dispare mais de dez resoluções, e cada include de um provedor terceiro conta para esse teto. Um domínio que acumula o ESP de marketing, a ferramenta de faturas, a plataforma de suporte e o servidor próprio cruza esse limite sem perceber, e quando isso acontece o resultado não é um aviso, e sim um permerror que faz o SPF inteiro falhar — inclusive para o correio que estava perfeitamente coberto. A leitura prática é tratar o SPF como um inventário vivo: cada fonte de envio nova entra no registro, cada uma que sai dele se retira, e o total de consultas se mede de vez em quando, porque um SPF que passava no ano passado pode ter estourado o teto com a última integração que ninguém revisou.

DKIM: seletores, rotação e o alinhamento que falha

O DKIM assina a mensagem com uma chave privada e publica a pública em um seletor dentro do seu DNS, e a maioria das falhas vive na junta entre os dois. Um seletor é o rótulo que liga a assinatura à chave publicada; quando uma equipe rotaciona a chave por higiene e esquece de manter o seletor antigo no ar enquanto o novo se propaga, o correto em trânsito de repente não verifica. O outro flanco é o alinhamento: o Gmail não pergunta só se a assinatura DKIM é válida, e sim se o domínio que assina coincide com o domínio que o destinatário vê no campo De. Uma ferramenta que assina com o seu próprio domínio em vez do seu passa a verificação técnica de DKIM e mesmo assim falha o alinhamento que o DMARC exige. Por isso convém auditar não só que o DKIM assina, e sim com que domínio assina cada fluxo, porque é ali — na identidade da assinatura, não na sua presença — que mora a maior parte das rejeições por autenticação.

ARC e o correio encaminhado

Há um cenário em que a sua autenticação está impecável e o correio mesmo assim falha na chegada: o encaminhamento. Quando uma mensagem passa por uma lista de distribuição ou por um endereço que a reencaminha, o servidor intermediário muitas vezes modifica o cabeçalho ou o corpo o suficiente para quebrar a assinatura DKIM que era válida na origem, e o destinatário final recebe um correio que falha a verificação por culpa do trânsito, não do remetente. O ARC existe para esse problema: é uma cadeia de selos que cada intermediário acrescenta, atestando que a autenticação passava quando a mensagem chegou às suas mãos, de modo que o receptor final possa confiar na avaliação original ainda que a assinatura tenha se quebrado depois. Para quem envia, o ARC não é algo que você publique no seu DNS, e sim algo que os intermediários honrem; mas entender que o encaminhamento quebra o DKIM explica rejeições que de outro modo pareceriam impossíveis em um domínio bem configurado.

O descadastro em um clique na prática

Desde junho de 2024, o correio em massa de marketing tem que oferecer um descadastro em um clique que funcione sem páginas intermediárias nem logins, e o detalhe técnico importa mais do que parece. A especificação que o rege pede dois cabeçalhos no envio: um que declara o método de baixa e outro que sinaliza que um único clique basta, de modo que o cliente de correio possa mostrar um botão de descadastro nativo que o destinatário aperta sem sair da caixa de entrada. Um link de baixa enterrado no rodapé, que leva a um formulário com várias etapas, já não cumpre para o tráfego em massa. E há uma janela: a baixa tem que ser processada em uns dois dias, não em algum momento do próximo ciclo. O descadastro em um clique se aplica ao marketing, não ao transacional — ninguém deveria poder se descadastrar de um recibo —, e confundir os dois fluxos no mesmo cabeçalho é um erro que custa reclamações.

BIMI: o que vem depois da conformidade

Uma vez que o domínio cumpre — SPF, DKIM e DMARC alinhados, com uma política em quarentena ou rejeição —, abre-se a porta para o BIMI, que exibe o logotipo da marca ao lado da mensagem na caixa de entrada dos provedores que o suportam. O BIMI não é um requisito nem melhora a entrega por si só; é uma recompensa de confiança que só está disponível para quem já fez o trabalho de autenticação, porque exige uma política DMARC de imposição como condição de entrada. Para os grandes provedores, o passo seguinte costuma pedir um certificado de marca verificada, que por sua vez exige uma marca figurativa registrada — no Brasil, no INPI — que coincida com o logotipo do arquivo. A leitura útil é que o BIMI transforma a conformidade de um custo defensivo em um ativo visível: o mesmo trabalho que evita as rejeições do Gmail também desbloqueia o logotipo que faz a mensagem se destacar, então convém tê-lo no horizonte como o destino natural depois de fechar a base, e não como um pré-requisito que atrase o trabalho de autenticação que de verdade decide a entrega.

Ler um bounce do Gmail linha a linha

Vale fechar com a habilidade que torna tudo o anterior acionável: ler um bounce real. Uma mensagem de rejeição do Gmail traz, além do código básico e do estado melhorado, um texto que nomeia a causa e os identificadores gsmtp e, às vezes, gcdp. Um 550 5.7.26 com o texto sobre autenticação aponta direto para SPF ou DKIM ausente ou mal alinhado, e a tarefa é o DNS, não o conteúdo. Um 550 5.7.1 acompanhado de gcdp não é um problema seu, e sim de uma regra que um administrador do domínio receptor configurou — uma distinção que poupa horas de procurar no lugar errado. O host que rejeita e a marca de tempo dizem a você que servidor e que envio concreto falharam. Ler essas três peças juntas — código, identificador e contexto — converte um bounce de algo alarmante em uma instrução precisa, e é o hábito que separa quem corrige a causa de quem reenvia às cegas contra uma porta que não vai abrir.

Se você opera o seu próprio MTA

Para quem envia com a sua própria infraestrutura de PowerMTA ou KumoMTA em vez de um ESP, a mudança de novembro cai bem na parte da pilha que você controla, e isso é ao mesmo tempo o risco e a vantagem. A autenticação e o alinhamento se configuram no MTA e no DNS, não se compram de uma plataforma, então um domínio de assinatura DKIM mal alinhado ou um SPF que já não cobre os seus IPs de envio são seus para encontrar e corrigir. Os códigos de adiamento também importam no operativo: um limite 4.7.x é o Gmail pedindo ao seu MTA que afrouxe, e um MTA que o ignora moendo a mesma fila ganha o trato duro antes. Um bom modelado de tráfego — taxas por provedor, intervalos de retentativa medidos e uma postura de backoff de verdade quando o receptor a pede — faz parte já de cumprir, não só de enviar rápido. Essa é a camada na qual trabalhamos, e onde um remetente que se auto-hospeda tem o controle mais direto sobre o resultado.

Onde tropeçam os que parecem estar em ordem

A maioria das rejeições que nos pedem explicar vem de remetentes que se creem conformes, e a causa costuma ser um de uns poucos buracos corriqueiros.

• Uma ferramenta nova de marketing ou vendas começou a enviar como o domínio sem se adicionar ao SPF nem se assinar com DKIM.
• Rotacionou-se uma chave DKIM e um fluxo seguiu assinando com o seletor retirado, ou deixou de assinar.
• Um encaminhador ou uma lista de distribuição quebrou a assinatura DKIM em trânsito, de modo que a autenticação que passava na origem falhou ao chegar; aí entra o ARC.
• Uma limpeza de DNS alterou o SPF e o empurrou acima do limite de dez consultas, fazendo-o falhar.
• Um subdomínio começou a enviar sem a sua própria autenticação, apoiado em um registro do domínio pai que não o cobre.

Nenhum se anuncia até começarem os bounces, por isso «isto a gente montou em 2024» merece ser conferido de novo contra o que de verdade sai hoje dos seus sistemas.

Após a rejeição: como é a recuperação

Corrigir o buraco de conformidade detém rápido as rejeições novas: uma vez arrumada a autenticação e o alinhamento, os adiamentos e os bounces 5.7.x cedem em um ou dois ciclos de envio. A reputação é mais lenta. Uma onda de correio rejeitado, adiado ou com reclamações deixa uma marca em como o Gmail pondera o seu domínio, e essa marca dura mais que o conserto; a porta de conformidade se reabre antes que a caixa de entrada. O caminho de volta é a disciplina de uma repartida a frio e não um interruptor: baixe o volume, envie primeiro aos destinatários com mais probabilidade de abrir e responder, e reconstrua o sinal de correio desejado ao longo de dias e semanas. Retomar o volume completo na manhã seguinte a corrigir os registros é como um remetente recém-recuperado ganha outra rodada de problemas.

Convém separar os dois relógios: a conformidade, que você arruma esta tarde, e a reputação, que você recupera durante semanas. Confundi-los é o que converte um problema resolvido em um recorrente. E vigie a taxa de bounces conforme sobe o volume: um segundo pico de adiamentos durante a rampa é o sinal de frear de novo, não de empurrar.

Separe o transacional do marketing

Os remetentes a quem a mudança mais prejudica costumam ser os que enviam o correio transacional e o de marketing pelo mesmo domínio e a mesma reputação. Quando uma campanha dispara as reclamações ou falha a autenticação, a rejeição não fica educadamente na campanha: cai sobre a identidade de envio compartilhada, e as redefinições de senha e os recibos que viajam com ela começam a voltar também. A solução é separar: envie o correio transacional de um subdomínio próprio, com a sua autenticação e a sua reputação limpas, isolado do que faça o fluxo de marketing. É a mudança estrutural que mais reduz o raio de dano de um deslize de conformidade, e a aplicação de novembro torna esse argumento muito mais difícil de adiar.

O que não resolve o problema

Diante de uma onda de rejeições, a reação instintiva costuma ir pelo caminho errado. Trocar de IP sem corrigir a autenticação só transfere o problema para um IP novo e sem histórico, que parte do zero e muitas vezes pior. Baixar o volume ajuda a reputação, mas não resolve uma falha de alinhamento: um correio não autenticado seguirá sendo rejeitado envie você mil ou cem mil. Reenviar a mesma mensagem uma e outra vez contra um 5.7.x permanente não muda o resultado e piora o sinal. E «pedir ao Google que deixe a gente em paz» não é uma alavanca: a aplicação é automática e se apoia no que o seu correio demonstra em cada conexão, não em um apelo. O único que reabre a porta é cumprir o requisito que a fechou, e depois ganhar de novo a reputação com envios limpos.

O panorama mais amplo

O Gmail não age sozinho, e é isso que converte novembro de 2025 em um marco e não na política de um único provedor. O Yahoo aplica os mesmos requisitos desde fevereiro de 2024, e a Microsoft começou a aplicar os seus em maio de 2025 — com o conhecido 550 5.7.515 —, então um domínio com autenticação fraca fica hoje exposto ao mesmo tempo diante dos provedores que movem a maior parte do correio. No Brasil, os provedores locais como UOL, Terra e BOL operam sobre a mesma base comum de SPF, DKIM e DMARC, de modo que um domínio mal autenticado encontra a mesma porta fechada também nas caixas brasileiras. Um registro DMARC mal configurado já não é o problema de uma única caixa de entrada: é um buraco que vários grandes provedores penalizarão por separado. A convergência é a questão: o setor se assentou sobre uma base comum, e o custo de ignorá-la se multiplica com cada provedor que a adota.

A nossa leitura é pouco romântica. A conformidade é já o preço de entrada, não uma vantagem competitiva: cumpri-la dá a você o direito de competir pela caixa de entrada, não a garante. A partir daqui sairão bem os remetentes que tratam a autenticação e a higiene como infraestrutura resolvida e gastam o seu esforço onde de verdade se decide a colocação, na reputação e na interação que vivem acima da porta. Se você não tem claro de que lado dessa porta está, a forma mais rápida de descobrir é olhar: leia os seus códigos de bounce do Gmail, confira o seu Estado de conformidade e confirme o seu alinhamento. E se você prefere que a gente revise a fundo, a nossa auditoria gratuita de 25 pontos faz justo isso em toda a sua configuração.

Fontes: Diretrizes para remetentes do Google Workspace e a sua documentação de erros SMTP do Gmail, atualizadas a novembro de 2025; PowerDMARC; cobertura do setor, 2025–2026. Os códigos de erro seguem o guia publicado pelo Google.