Por que o Gmail rejeita um e-mail mesmo quando SPF e DKIM passam? O painel da sua ferramenta de e-mail marketing mostra “enviado”. Parte dos seus destinatários no Gmail, no entanto, nunca recebe nada. A explicação está em um código que pouca gente sabe interpretar: 550 5.7.25.
Erro 550 5.7.25 significa que o IP de envio não tem um PTR (reverse DNS) válido ou que esse PTR não resolve de volta para o mesmo IP no sentido inverso (forward-confirmed reverse DNS, FCrDNS). 3 verificações DNS bastam para isolar qual das 2 causas se aplica ao seu caso. A correção depende de quem controla a zona reversa: a hospedagem em um VPS ou servidor dedicado, o provedor em um ESP.
O que o código 550 5.7.25 realmente significa
Quando seu servidor contata o Gmail, a troca começa com um EHLO seguido de um MAIL FROM que anuncia o remetente. Nesse momento, o Gmail verifica a identidade de rede do IP de origem, antes mesmo de ler o conteúdo da mensagem. O código 5.7.25 é um Enhanced Status Code: a classe 5.7.x cobre rejeições ligadas a segurança e autenticação, e o sufixo .25 aponta especificamente para um problema de reverse DNS. Essa precisão é uma vantagem: uma rejeição genérica como o erro SMTP 554 5.0.0 deixa 5 causas possíveis em aberto, enquanto o 5.7.25 aponta para apenas uma.
« 550-5.7.25 [IP] The IP address sending this message does not have a PTR record setup, or the corresponding forward DNS entry does not match the sending IP. As a policy, Gmail does not accept messages from IPs with missing PTR records. »
Esse é o texto exato que o servidor de recepção retorna. 2 registros DNS estão envolvidos. O PTR (pointer) traduz um IP em um nome de host: é a busca reversa. O registro A (ou AAAA em IPv6) faz o inverso: traduz um nome de host em IP. O Gmail exige que os 2 se correspondam: o PTR do seu IP deve apontar para um hostname e esse hostname precisa resolver de volta para o mesmo IP. Sem esse loop fechado, a mensagem cai no NDR (Non-Delivery Report) do seu servidor com o código 550 5.7.25, antes mesmo de ser filtrada como spam.
Por que essa rejeição ficou mais frequente desde dezembro de 2025
O código 5.7.25 existe há vários anos, mas as rejeições eram raras antes do fim de 2025. Segundo a Spam Resource (dezembro de 2025), o Google endureceu a aplicação dessa regra: IPs com reverse DNS incompleto ou inconsistente, que antes passavam despercebidos, agora são bloqueados de forma mais sistemática.
Esse endurecimento segue uma tendência iniciada em fevereiro de 2024, quando Gmail e Yahoo passaram a aplicar exigências comuns aos remetentes, com um limite de reclamações de spam fixado em 0,3%. Nosso artigo sobre o aumento das rejeições SMTP e as exigências de remetente do Gmail detalha todos esses limites. O PTR é apenas um dos controles dessa lista, mas é um dos poucos que bloqueia a conexão antes mesmo de o conteúdo da mensagem ser examinado.
Diagnosticando o PTR em 3 verificações
Antes de contatar quem quer que seja, verifique 3 coisas na ordem. Cada uma elimina uma causa possível.
- Verifique o PTR IPv4 do IP que realmente envia a mensagem, não o IP do seu servidor web, mas o IP SMTP de saída. O retorno da mensagem fornece esse dado, ele aparece entre colchetes logo após o código 550-5.7.25. Execute
dig -x 203.0.113.10 +shorta partir de qualquer máquina. No Windows,nslookup 203.0.113.10dá a mesma resposta. Uma resposta vazia indica ausência de PTR, ou seja, a causa nº 1. - Verifique o PTR IPv6 com
dig -x 2001:db8::25 +shortse o seu servidor consegue enviar por esse protocolo. Esse é o ponto que a maioria das checklists deixa passar. Um servidor com conectividade IPv6 abre a conexão com o Gmail em IPv6 por padrão, já que os MX do Gmail publicam registros AAAA. As diretrizes oficiais do Google para remetentes são claras nesse ponto: um erro de autorização IPv6 geralmente vem de um PTR que existe apenas em IPv4. Um PTR IPv4 impecável acompanhado de um PTR IPv6 ausente faz com que essas conexões sejam rejeitadas, com um 550 5.7.25 ou com o 550 5.7.1 reservado às exigências IPv6, dependendo do caso. - Verifique o forward match: o hostname retornado pelo PTR deve ter um registro A (ou AAAA) que aponte de volta para o mesmo IP de partida. Pegue o hostname da etapa anterior e execute
dig A mail.seudominio.com.br +short, depoisdig AAAA mail.seudominio.com.br +shortem IPv6. O IP retornado deve ser exatamente o de partida. Uma divergência nessa etapa, por menor que seja, quebra o FCrDNS.
O passo a passo detalhado dessas operações, incluindo os comandos, está no nosso guia sobre consulta reversa de DNS.
Corrigindo de acordo com quem controla seu reverse DNS
Um PTR nunca se altera pelo painel de administração do seu domínio: ele pertence ao dono do bloco de endereços IP. O procedimento muda completamente dependendo de quem possui essa zona reversa.
| Tipo de hospedagem | Quem controla o PTR | Procedimento | Prazo de propagação |
|---|---|---|---|
| VPS ou servidor dedicado (OVH, Hetzner, DigitalOcean, AWS EC2) | A hospedagem, via painel de rede ou ticket de suporte | Renomear o droplet ou a instância com o hostname desejado (DigitalOcean), solicitar o PTR pelas configurações de IP elástico (AWS) ou adicioná-lo na seção de rede do painel do cliente (Hetzner, OVH) | De alguns minutos a algumas horas |
| Hospedagem compartilhada | Apenas a hospedagem, geralmente em um pool de IPs compartilhado | Abrir um ticket de suporte especificando o IP de saída exato e o hostname esperado | Variável, às vezes vários dias dependendo do provedor |
| ESP ou SaaS de e-mail marketing (Brevo, Mailgun, SendGrid, Google Workspace) | O provedor, nos próprios IPs | Nada a fazer do seu lado quanto ao PTR: verificar antes o alinhamento de SPF, DKIM e DMARC no domínio de envio | Não aplicável, já gerenciado |
Na AWS, o PTR é solicitado pelo console EC2 (seção de IP elástico) ou por ticket, se o IP não for elástico. No DigitalOcean, basta renomear o droplet com o FQDN desejado: o PTR se atualiza automaticamente. Depois, confirme com um envio de teste que o loop A/PTR está fechado. O prazo de propagação real geralmente fica entre alguns minutos e algumas horas. Reserve uma janela de 2 a 4 horas antes de testar novamente se a primeira verificação ainda falhar.
A armadilha do PTR genérico que passa no controle técnico
Um caso é bastante comum: o PTR existe e resolve corretamente em ambos os sentidos. Mesmo assim, a rejeição persiste. A causa mais frequente é um PTR genérico atribuído automaticamente pela hospedagem, no formato 123-45-67-89.provider.com.
Tecnicamente, esse PTR passa no controle FCrDNS: ele aponta para um hostname e esse hostname aponta de volta para o mesmo IP. O problema está em outro lugar. Um IP que nunca serviu para nada além de hospedagem genérica, sem histórico de envio dedicado nem hostname personalizado, corresponde ao perfil de servidores comprometidos usados para spam em massa. O Gmail trata esse sinal como fraco, mesmo quando o loop técnico está fechado. A correção consiste em solicitar um PTR personalizado que use o nome de domínio ou o subdomínio realmente usado para o envio, por exemplo mail.seudominio.com.br em vez do hostname padrão do servidor.
Outra objeção comum: “eu uso uma plataforma de e-mail marketing, esse problema não me afeta”. Isso é verdade para o PTR em si: os grandes ESPs gerenciam seus próprios IPs e seu próprio reverse DNS. Mas o mesmo sintoma, uma rejeição do Gmail mesmo com tudo aparentemente configurado, pode vir de um domínio de envio mal alinhado no DKIM, um problema distinto do PTR. Verificar qual dos dois é a causa evita perder tempo contatando o interlocutor errado. Um relatório DMARC agregado mostra qual fonte de envio falha no alinhamento.
Depois de corrigir o PTR, verifique se o resto não está prejudicando sua reputação de remetente
Corrigir o PTR resolve a rejeição SMTP imediata. Isso não garante nada quanto ao restante. A reputação de remetente (sender reputation) no Gmail se constrói a partir de vários sinais acumulados: a taxa de hard bounce, a taxa de reclamação (complaint rate) e o histórico de envio do IP. A conformidade de DNS sozinha não é suficiente.
Em um IP de pool compartilhado, esse acúmulo é coletivo: se outro cliente do mesmo pool gera uma taxa de hard bounce alta, sua própria deliverability sofre as consequências mesmo com um PTR impecável. Em um IP dedicado em fase de IP warming, cada envio para um endereço inválido ou inativo pesa ainda mais na curva de confiança que o Gmail constrói, porque o volume de referência ainda é baixo.
“Verificar os e-mails antes de enviar custa caro, é melhor filtrar depois.” A ordem importa justamente aqui: um hard bounce registrado pelo Gmail depois do envio já degrada a reputação do IP no momento em que ocorre. Um endereço inválido removido antes do envio não deixa nenhum rastro negativo. Passar uma amostra da sua próxima lista por uma verificação antes da campanha mostra concretamente a diferença entre as 2 abordagens na taxa real de hard bounce.
O postmaster do Gmail (Google Postmaster Tools) continua sendo a fonte mais confiável para acompanhar essa reputação ao longo do tempo, tanto no nível do IP quanto do domínio. Nosso guia sobre reputação de endereço IP detalha como interpretar esses dados e detectar o início de uma blocklist.
Perguntas frequentes sobre o erro 550 5.7.25
O código 550 5.7.25 bloqueia todos os meus e-mails ou apenas alguns?
A rejeição se aplica por IP. Ela pode até se limitar a um único protocolo, se o PTR IPv4 estiver correto mas o PTR IPv6 estiver ausente. Se sua infraestrutura envia a partir de vários IPs, apenas os fluxos que passam pelo IP com problema são rejeitados, e os demais continuam chegando normalmente.
Meus e-mails encaminhados para um endereço Gmail retornam com 550 5.7.25, por quê?
O Gmail verifica o PTR da máquina que abre a conexão, não o do remetente original. Em um encaminhamento automático, por exemplo uma caixa profissional que redireciona para um Gmail pessoal, é o servidor que retransmite que precisa ter um PTR válido, mesmo quando o remetente inicial está perfeitamente configurado do seu lado. O mesmo mecanismo vale para um relay SMTP secundário ou um gateway antispam colocado antes do seu servidor. Leia o IP entre colchetes na mensagem de retorno: é dele que o reverse precisa ser corrigido. Muitas vezes ele pertence a uma máquina que você lembraria por último.
Quanto tempo leva para a correção do PTR ter efeito?
A propagação geralmente acontece entre alguns minutos e algumas horas. Aguarde uma janela de 2 a 4 horas antes de testar novamente, o tempo necessário para os resolvers DNS atualizarem o cache.
Usar um ESP me protege automaticamente desse erro?
Sim, para o PTR em si: as grandes plataformas gerenciam o próprio reverse DNS nos seus IPs. Uma rejeição do Gmail que persiste apesar de um ESP geralmente vem de um problema de alinhamento de DKIM ou de um domínio de envio mal configurado, raramente do PTR em si.
Um PTR IPv4 é suficiente se meu servidor também envia por IPv6?
Não, veja a verificação nº 2 acima para diagnosticar esse caso específico. Se sua hospedagem não oferece PTR IPv6, desativar o envio de saída em IPv6 no servidor continua sendo uma solução paliativa mais rápida do que um ticket de suporte aguardando resposta.
