Pourquoi Gmail rejette-t-il un email alors que SPF et DKIM passent tous les deux ? Le tableau de bord de votre outil d’emailing affiche « envoyé ». Une partie de vos destinataires Gmail ne reçoit pourtant jamais rien. L’explication tient dans un code que peu de monde sait lire : 550 5.7.25.
Erreur 550 5.7.25 = l’IP d’envoi n’a pas de PTR (reverse DNS) valide ou ce PTR ne re-résout pas vers la même IP en sens inverse (forward-confirmed reverse DNS, FCrDNS). 3 vérifications DNS suffisent à isoler laquelle des 2 causes vous concerne. La correction dépend ensuite de qui contrôle la zone reverse : l’hébergeur sur un VPS ou un serveur dédié, le prestataire sur un ESP.
Ce que signifie vraiment le code 550 5.7.25
Quand votre serveur contacte Gmail, l’échange commence par un EHLO puis un MAIL FROM qui annonce l’expéditeur. Gmail vérifie à ce moment l’identité réseau de l’IP source, avant même de lire le contenu du message. Le code 5.7.25 est un Enhanced Status Code. La classe 5.7.x couvre les rejets liés à la sécurité et à l’authentification. Le suffixe .25 pointe précisément vers un problème de reverse DNS. Cette précision est une chance : un rejet générique comme l’erreur SMTP 554 5.0.0 laisse 5 causes possibles ouvertes, là où le 5.7.25 en désigne une seule.
« 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. »
C’est le texte exact que renvoie le serveur de réception. 2 enregistrements DNS sont en jeu. Le PTR (pointer) traduit une IP en nom d’hôte : c’est la recherche inversée. L’enregistrement A (ou AAAA en IPv6) fait l’inverse. Il traduit un nom d’hôte en IP. Gmail exige que les 2 se répondent : le PTR de votre IP doit pointer vers un hostname et ce hostname doit re-résoudre vers la même IP. Sans cette boucle fermée, le message atterrit dans le NDR (Non-Delivery Report) de votre serveur avec le code 550 5.7.25, avant même d’être filtré pour du spam.
Pourquoi ce rejet est devenu plus fréquent depuis décembre 2025
Le code 5.7.25 existe depuis plusieurs années. Les rejets étaient rares avant fin 2025. D’après Spam Resource (décembre 2025), Google a durci l’application de cette règle : les IP dont le reverse DNS est incomplet ou incohérent, qui passaient auparavant entre les mailles, sont désormais bloquées plus systématiquement.
Ce durcissement suit une tendance amorcée en février 2024, quand Gmail et Yahoo ont commencé à appliquer des exigences communes aux expéditeurs, avec un seuil de plaintes spam fixé à 0,3 %. Notre article sur la hausse des rejets SMTP et les exigences expéditeur de Gmail détaille l’ensemble de ces seuils. Le PTR n’est qu’un des contrôles de cette liste mais c’est l’un des rares qui bloque la connexion avant même que le contenu du message soit examiné.
Diagnostiquer le PTR en 3 vérifications
Avant de contacter qui que ce soit, vérifiez 3 choses dans l’ordre. Chacune élimine une cause possible.
- Vérifiez le PTR IPv4 de l’IP qui envoie réellement le message, pas l’IP de votre serveur web mais l’IP SMTP sortante. Le rebond vous la donne, elle apparaît entre crochets juste après le code 550-5.7.25. Lancez
dig -x 203.0.113.10 +shortdepuis n’importe quelle machine. Sous Windows,nslookup 203.0.113.10donne la même réponse. Une réponse vide signe un PTR absent, donc la cause n°1. - Vérifiez le PTR IPv6 avec
dig -x 2001:db8::25 +shortsi votre serveur peut émettre par ce protocole. C’est le point que la plupart des checklists sautent. Un serveur qui dispose d’une connectivité IPv6 ouvre la connexion vers Gmail en IPv6 par défaut, puisque les MX de Gmail publient des enregistrements AAAA. Les consignes officielles de Google pour les expéditeurs sont explicites sur ce point : une erreur d’autorisation IPv6 vient le plus souvent d’un PTR qui existe uniquement en IPv4. Un PTR IPv4 impeccable accompagné d’un PTR IPv6 absent fait donc rejeter ces connexions-là, avec un 550 5.7.25 ou avec le 550 5.7.1 réservé aux exigences IPv6 selon les cas. - Vérifiez le forward match : le hostname renvoyé par le PTR doit avoir un enregistrement A (ou AAAA) qui repointe vers la même IP de départ. Reprenez le hostname de l’étape précédente et lancez
dig A mail.votredomaine.fr +short, puisdig AAAA mail.votredomaine.fr +shorten IPv6. L’IP retournée doit être exactement celle de départ. Un écart à cette étape, même minime, casse le FCrDNS.
Le détail pas à pas de ces manipulations, commandes comprises, est couvert dans notre guide sur le reverse DNS lookup.
Corriger selon qui contrôle votre reverse DNS
Un PTR ne se modifie jamais depuis votre panneau d’administration de domaine : il appartient au propriétaire du bloc d’adresses IP. La marche à suivre change du tout au tout selon qui possède cette zone reverse.
| Type d’hébergement | Qui contrôle le PTR | Marche à suivre | Délai de propagation |
|---|---|---|---|
| VPS ou serveur dédié (OVH, Hetzner, DigitalOcean, AWS EC2) | L’hébergeur, via son panneau réseau ou un ticket support | Renommer le droplet ou l’instance avec le hostname voulu (DigitalOcean), demander le PTR via les paramètres d’IP élastique (AWS) ou l’ajouter dans la section réseau du panneau client (Hetzner, OVH) | Quelques minutes à quelques heures |
| Hébergement mutualisé | L’hébergeur uniquement, souvent sur un pool d’IP partagé | Ouvrir un ticket support en précisant l’IP sortante exacte et le hostname attendu | Variable, parfois plusieurs jours selon le prestataire |
| ESP ou SaaS d’emailing (Brevo, Mailgun, SendGrid, Google Workspace) | Le prestataire, sur ses propres IP | Rien à faire de votre côté sur le PTR : vérifier plutôt l’alignement SPF, DKIM et DMARC sur le domaine d’envoi | Sans objet, déjà géré |
Sur AWS, le PTR se demande depuis la console EC2 (section IP élastique) ou par ticket si l’IP n’est pas élastique. Sur DigitalOcean, renommer le droplet avec le FQDN souhaité suffit : le PTR se met à jour automatiquement. Vérifiez ensuite avec un envoi de test que la boucle A/PTR est bien fermée. Le délai de propagation réel se situe généralement entre quelques minutes et quelques heures. Prévoyez une fenêtre de 2 à 4 heures avant de retester si la première vérification échoue encore.
Le piège du PTR générique qui passe le contrôle technique
Un cas revient souvent : le PTR existe et résout même correctement en aller-retour. Le rejet persiste quand même. La cause la plus fréquente est un PTR générique attribué automatiquement par l’hébergeur, du type 123-45-67-89.provider.com.
Techniquement, ce PTR passe le contrôle FCrDNS : il pointe vers un hostname et ce hostname repointe vers la même IP. Le problème est ailleurs. Une IP qui n’a jamais servi qu’à de l’hébergement générique, sans historique d’envoi dédié ni hostname personnalisé, correspond au profil des serveurs compromis utilisés pour du spam de masse. Gmail traite ce signal comme faible, même quand la boucle technique est fermée. La correction consiste à demander un PTR personnalisé qui reprend le nom de domaine ou le sous-domaine réellement utilisé pour l’envoi, par exemple mail.votredomaine.fr plutôt que le hostname par défaut du serveur.
Autre objection fréquente : « je passe par une plateforme d’emailing, ce problème ne me concerne pas ». C’est vrai pour le PTR lui-même : les grands ESP gèrent leurs propres IP et leur reverse DNS. Mais le même symptôme, un rejet Gmail alors que tout semble configuré, peut venir d’un domaine d’envoi mal aligné en DKIM, un problème distinct du PTR. Vérifier lequel des deux est en cause évite de perdre du temps à contacter le mauvais interlocuteur. Un rapport DMARC agrégé montre quelle source d’envoi échoue à l’alignement.
Une fois le PTR corrigé, vérifier que le reste ne plombe pas votre réputation d’expéditeur
Corriger le PTR résout le rejet SMTP immédiat. Ça ne garantit rien sur la suite. La réputation d’expéditeur (sender reputation) chez Gmail se construit sur plusieurs signaux cumulés : le taux de hard bounce, le taux de plainte (complaint rate) et l’historique d’envoi de l’IP. La conformité DNS seule ne suffit pas.
Sur une IP en pool mutualisé, ce cumul se joue à plusieurs : si un autre client du même pool génère un taux de hard bounce élevé, votre propre délivrabilité en subit les conséquences même avec un PTR nickel. Sur une IP dédiée en phase d’IP warm-up, chaque envoi vers une adresse invalide ou inactive pèse davantage sur la courbe de confiance que Gmail construit, parce que le volume de référence est encore faible.
« Vérifier les emails avant d’envoyer, ça coûte cher, autant filtrer après coup. » L’ordre compte justement ici : un hard bounce relevé par Gmail après envoi dégrade déjà la réputation de l’IP au moment où il survient. Une adresse invalide retirée avant l’envoi ne laisse aucune trace négative. Passer un échantillon de votre prochaine liste par une vérification avant campagne montre concrètement l’écart entre les 2 approches sur le taux de hard bounce réel.
Le postmaster Gmail (Google Postmaster Tools) reste la source la plus fiable pour suivre cette réputation dans la durée, à l’échelle de l’IP comme du domaine. Notre guide sur la réputation d’une adresse IP détaille comment lire ces données et détecter un blacklistage naissant.
Questions fréquentes sur l’erreur 550 5.7.25
Le code 550 5.7.25 bloque-t-il tous mes emails ou seulement certains ?
Le rejet s’applique par IP. Il peut même se limiter à un seul protocole si le PTR IPv4 est correct mais que le PTR IPv6 manque. Si votre infrastructure envoie depuis plusieurs IP, seuls les flux passant par l’IP en défaut sont rejetés et les autres continuent d’arriver normalement.
Mes emails transférés vers une adresse Gmail rebondissent en 550 5.7.25, pourquoi ?
Gmail contrôle le PTR de la machine qui ouvre la connexion, pas celui de l’expéditeur d’origine. Sur un transfert automatique, une boîte professionnelle qui redirige vers une Gmail personnelle par exemple, c’est donc le serveur qui relaie qui doit avoir un PTR valide, même quand l’expéditeur initial est parfaitement configuré de son côté. Le même mécanisme vaut pour un relais SMTP secondaire ou une passerelle antispam placée devant votre serveur. Lisez l’IP entre crochets dans le rebond : c’est celle dont il faut corriger le reverse. Elle appartient souvent à une machine à laquelle vous auriez pensé en dernier.
Combien de temps faut-il pour que la correction du PTR soit effective ?
La propagation se joue généralement entre quelques minutes et quelques heures. Attendez une fenêtre de 2 à 4 heures avant de retester, le temps que les résolveurs DNS mettent leur cache à jour.
Passer par un ESP me protège-t-il automatiquement de cette erreur ?
Oui pour le PTR lui-même : les grandes plateformes gèrent leur propre reverse DNS sur leurs IP. Un rejet Gmail qui persiste malgré un ESP vient généralement d’un problème d’alignement DKIM ou d’un domaine d’envoi mal configuré, rarement du PTR lui-même.
Un PTR IPv4 suffit-il si mon serveur envoie aussi en IPv6 ?
Non, voir la vérification n°2 ci-dessus pour diagnostiquer ce cas précis. Si votre hébergeur ne propose pas de PTR IPv6, désactiver l’envoi sortant en IPv6 côté serveur reste une solution de repli plus rapide qu’un ticket support en attente de réponse.
