Dernière mise à jour : juillet 2026

En bref : Lorsque Gmail rejette tes e-mails sortants avec des codes d’erreur, la cause principale est presque toujours une absence d’enregistrements d’authentification (SPF/DKIM), une configuration DNS inverse (PTR) incorrecte ou un taux élevé de signalements de spam. Examine les définitions exactes des messages de rejet ci-dessous ainsi que les étapes concrètes pour les résoudre immédiatement.

Recevoir un message de rejet (bounce) provenant des relais entrants de Google (gmail-smtp-in.l.google.com) peut paralyser des communications importantes. Suite à l’application des directives strictes de Google pour les expéditeurs, Gmail exige une infrastructure d’envoi authentifiée et surveille de près la réputation des domaines via les Google Postmaster Tools. Pour garantir une délivrabilité ininterrompue, tu dois maintenir un taux de signalement de spam rapporté par les utilisateurs strictement en dessous du seuil acceptable : below 0.3%.

Voici un dictionnaire de diagnostic détaillé des messages d’erreur SMTP Gmail les plus courants — y compris leur texte exact, leurs causes sous-jacentes, les étapes concrètes de résolution et des délais de rétablissement réalistes.

Erreur 550 5.7.26 — Expéditeur non authentifié

Chaîne d’erreur exacte de Gmail

This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM.

Signification et cause racine

Gmail rejette ton e-mail de manière permanente (hard bounce 550) parce que le message ne dispose pas d’un enregistrement Sender Policy Framework (SPF) valide ni d’une signature DomainKeys Identified Mail (DKIM) valide. Pour protéger les utilisateurs contre l’usurpation d’identité et le phishing, Google impose une exigence d’authentification obligatoire sur l’ensemble du flux entrant.

Étapes de résolution concrètes

  1. Configure SPF ou DKIM : Publie un enregistrement SPF valide dans les paramètres DNS de ton domaine pour autoriser l’adresse IP de ton serveur de messagerie, ou active la signature DKIM dans le panneau de contrôle de ton fournisseur ou serveur.
  2. Vérifie la syntaxe SPF : Assure-toi que l’enregistrement SPF de ton domaine inclut correctement ton hébergeur (include:) ou ton adresse IP (ip4:/ip6:).
  3. Vérifie l’alignement du domaine : Si tu as publié un enregistrement DMARC, confirme que le domaine dans ta signature DKIM (d=) ou dans l’enveloppe SPF (Return-Path) correspond exactement à l’en-tête visible From.

Délai réaliste

Une fois que tes enregistrements DNS SPF ou DKIM sont publiés, la propagation mondiale prend généralement entre 15 et 60 minutes. Dès que les serveurs de résolution de Google détectent des enregistrements d’authentification valides, l’acceptation des e-mails entrants reprend immédiatement.

Erreur 421 4.7.28 — Débit d’envoi inhabituel / Limitation temporaire

Chaîne d’erreur exacte de Gmail

Gmail has detected an unusual rate of email. To protect our users from spam, email has been temporarily rate limited.

Signification et cause racine

Il s’agit d’un rejet temporaire (soft bounce 421). Les systèmes anti-abus de Google ont détecté une augmentation anormale du trafic e-mail provenant de ton adresse IP ou de ton domaine sur un court laps de temps, ou des messages récents ont généré un pic de plaintes pour spam de la part des utilisateurs.

Étapes de résolution concrètes

  1. Réduis le rythme d’envoi : Ralentis le taux de connexion et le débit de livraison de ton serveur vers les relais Google (par exemple, en ajustant les limites de concurrence dans Postfix ou en échelonnant l’envoi de tes campagnes).
  2. Audite les Postmaster Tools : Connecte-toi aux Google Postmaster Tools pour ton domaine d’envoi et vérifie si ton taux de plaintes pour spam a dépassé le seuil critique (below 0.3%.).
  3. Respecte les intervalles de nouvelle tentative : Ne configure pas ton serveur pour tenter de renvoyer agressivement les messages échoués toutes les quelques secondes. Laisse s’écouler les délais normaux de nouvelle tentative exponentielle.

Délai réaliste

Les blocages dus à la limitation de débit (421) disparaissent automatiquement une fois que ton volume d’envoi se stabilise et que la fenêtre de restriction temporaire expire. La période de carence typique varie entre 2 et 24 heures.

Erreur 4.7.25 — DNS inverse (enregistrement PTR) manquant ou incorrect

Chaîne d’erreur exacte de Gmail

The sending IP address for this message doesn't have a PTR record, or the PTR record's forward DNS entry doesn't match the sending IP address. To protect users from spam, your email has been temporarily rate limited.

Signification et cause racine

L’adresse IP de ton serveur de messagerie échoue à la vérification DNS inverse confirmée directe (FCrDNS). Soit ton adresse IP ne possède aucun enregistrement de DNS inverse (PTR) attribué chez ton fournisseur d’hébergement, soit le nom de domaine renvoyé par la recherche PTR ne pointe pas en retour (enregistrement A ou AAAA) vers cette adresse IP exacte.

Étapes de résolution concrètes

  1. Attribue un enregistrement PTR : Dans le panneau de contrôle de ton hébergeur de serveur, configure un nom d’hôte unique et entièrement qualifié (mail.tondomaine.fr) en tant qu’enregistrement PTR de DNS inverse pour tes adresses IPv4 et IPv6.
  2. Aligne le DNS direct : Dans la zone DNS de ton nom de domaine, assure-toi qu’un enregistrement A (et AAAA) existe pour mail.tondomaine.fr et pointe exactement vers l’adresse IP publique de ton serveur de messagerie.

Délai réaliste

La mise à jour d’un enregistrement PTR nécessite que les serveurs DNS faisant autorité de ton fournisseur d’hébergement propagent les modifications, ce qui prend généralement entre 30 minutes et 4 heures avant la mise à jour des caches DNS de Google.

Erreur 550 5.7.1 — Message interdit par la politique de l’utilisateur ou du domaine

Chaîne d’erreur exacte de Gmail

The user or domain that you are sending to (or from) has a policy that prohibits the email that you sent. Contact your domain administrator for assistance.

Signification et cause racine

Ce rejet permanent (550 5.7.1) se produit lorsqu’une politique administrative bloque explicitement la transmission. Le plus souvent, cela arrive quand ton domaine publie une politique DMARC stricte (p=reject) et que ton message sortant échoue à l’alignement SPF et DKIM, ou lorsque l’organisation réceptrice Google Workspace applique des filtres de contenu administratifs ou des règles de routage restrictives.

Étapes de résolution concrètes

  1. Audite les expéditeurs tiers : Vérifie que tous tes outils de marketing, plateformes CRM ou services de transfert qui envoient des e-mails en ton nom sont correctement authentifiés avec DKIM et SPF afin de respecter DMARC.
  2. Contacte l’administrateur du destinataire : Si tu livres des messages à une organisation d’entreprise sous Google Workspace, demande à leur administrateur informatique de vérifier si des filtres de conformité personnalisés ou des listes d’expéditeurs restreints bloquent ton domaine ou ton adresse IP.

Délai réaliste

Dès que le défaut d’alignement DMARC est corrigé ou que l’administrateur du destinataire supprime la restriction dans le panneau de configuration de son espace Google Workspace, la livraison reprend immédiatement.

Vérification de ta configuration

Pour t’assurer que tes enregistrements d’authentification DNS (SPF, DKIM, DMARC) et ta configuration de DNS inverse (PTR) respectent parfaitement les exigences techniques de Google, lance un audit complet avec le scanner gratuit MXAudit.

Pour aller plus loin