Depuis novembre 2025, Gmail ne se contente plus du dossier spam : il refuse les emails non conformes. Codes d'erreur, causes et correctifs, un an après.
Pendant des années, un email mal authentifié finissait dans le dossier spam. Pénalisant, oui, mais le message existait encore quelque part. Depuis novembre 2025, Gmail va plus loin, et sa FAQ destinée aux expéditeurs l’écrit noir sur blanc : « Starting November 2025, Gmail is ramping up its enforcement on non-compliant traffic ». En clair, un message qui ne respecte pas ses exigences peut se faire refuser, temporairement ou pour de bon, avant même d’atteindre la boîte.
Un an plus tard, beaucoup d’expéditeurs B-to-B n’ont rien vu passer. Et pour cause. Le rejet n’apparaît pas en rouge dans le tableau de bord de la campagne, il dort dans les logs du serveur d’envoi, sous la forme d’un code à trois chiffres suivi d’une ligne en anglais que personne ne lit.
Les règles elles-mêmes datent d’avant. Google les a annoncées le 3 octobre 2023 pour une application en février 2024, chiffres à l’appui : après avoir imposé l’authentification à ses expéditeurs, il constatait 75 % de messages non authentifiés en moins dans les boîtes de ses utilisateurs. Authentification, enregistrement PTR, connexion TLS, taux de plaintes maîtrisé, désabonnement en un clic pour les gros volumes. Sur le fond, la liste n’a pas bougé.
Ce qui a changé, c’est la façon dont Gmail réagit quand un message ne coche pas les cases. La FAQ évoque désormais des « disruptions, including temporary and permanent rejections ». Un échec temporaire porte un code 4.7.x, et le serveur émetteur peut retenter plus tard. Un blocage porte un code 5.7.x. Là, Gmail ne livrera jamais le message.
Google promet une application « gradual and progressive ». Avec une exception de taille : les nouveaux domaines suivent un calendrier accéléré. Un domaine compte comme nouveau s’il n’a jamais dépassé 5 000 messages par jour vers des comptes Gmail personnels depuis le 1er janvier 2024. Vous lancez un sous-domaine dédié à la prospection, ou une nouvelle marque ? Vous êtes en première ligne.
Une précision d’abord, utile en B-to-B. Ces exigences visent uniquement les envois vers des comptes Gmail personnels, les adresses en @gmail.com et @googlemail.com. Un prospect dont l’entreprise utilise Google Workspace avec son propre nom de domaine échappe donc au dispositif. Sauf que vos fichiers comptent forcément des indépendants, des dirigeants de TPE, des contacts qui ont laissé leur adresse perso sur un formulaire de salon. Ceux-là, les nouvelles règles les protègent.
Le seuil de 5 000 messages par jour entretient ensuite une vraie confusion. Il ne dit pas qui doit respecter les règles, il sépare deux niveaux d’exigence. Tout expéditeur doit authentifier ses messages par SPF ou DKIM, disposer d’un PTR valide, chiffrer la connexion en TLS et garder un taux de spam déclaré sous 0,3 %. Au-delà d’environ 5 000 messages par jour vers Gmail, la barre monte : SPF et DKIM ensemble, un enregistrement DMARC, l’alignement du domaine affiché dans le champ From, le désabonnement en un clic.
Et ce statut d’expéditeur en volume ne se perd pas. Une seule journée au-dessus du seuil suffit, et Google précise qu’il n’a pas de date d’expiration. Une newsletter envoyée à toute la base la veille d’un salon, et Google vous range dans cette catégorie pour toujours.
Le code renvoyé par Gmail désigne l’exigence en cause. Autant le lire avant de toucher au DNS. Voici les principaux, tels que les liste la documentation de Google Workspace :
| Code | Ce que Gmail reproche | Première vérification |
|---|---|---|
| 421 4.7.26 / 550 5.7.26 | Message non authentifié, ou refusé par la politique DMARC du domaine | Résultats SPF, DKIM et DMARC dans l’en-tête |
| 421 4.7.27 / 550 5.7.27 | Échec SPF | IP du routeur absente de l’enregistrement SPF |
| 421 4.7.30 / 550 5.7.30 | Échec DKIM | Clé publique absente ou différente dans le DNS |
| 421 4.7.32 | Domaine du From non aligné avec SPF ou DKIM | Domaine de signature DKIM utilisé par le routeur |
| 421 4.7.40 / 550 5.7.40 | Enregistrement DMARC absent ou invalide | Entrée TXT _dmarc du domaine |
| 451 4.7.23 / 550 5.7.25 | IP d’envoi sans PTR valide | Reverse DNS de l’IP |
| 421 4.7.29 / 550 5.7.29 | Connexion sans TLS | Configuration du serveur SMTP |
| 421 4.7.28 | Volume ou signaux de spam inhabituels | Taux de spam dans Postmaster Tools |
Le 550 5.7.26 mérite qu’on s’y arrête. Google l’emploie pour trois situations bien distinctes : un expéditeur non authentifié, un SPF en échec alors que l’enregistrement se termine par -all, ou un refus imposé par votre propre politique DMARC. Dans ce dernier cas, c’est votre domaine qui demande à Gmail de rejeter le message. Gmail obéit, tout simplement. Quant au 550 5.7.1, il ne parle pas d’authentification mais de contenu jugé indésirable ou de réputation très basse de l’IP ou du domaine.
La plupart des entreprises ont publié SPF et DKIM pour leur routeur. Le rejet vient souvent d’ailleurs, de ces outils qui envoient au nom du domaine sans que personne ne les ait jamais recensés. Le CRM qui expédie les relances commerciales, le logiciel de facturation, le support client, la plateforme de webinaires. Chacun place votre domaine dans le champ From. Chacun doit donc signer en DKIM avec ce domaine, ou figurer dans le SPF.
Le SPF, justement, atteint vite ses limites. La RFC 7208 plafonne à 10 le nombre de recherches DNS nécessaires pour évaluer un enregistrement, et chaque include: ajouté pour un nouveau prestataire en consomme au moins une. Passé ce seuil, l’évaluation renvoie une erreur. Votre SPF ne vaut alors plus rien, pour tous vos envois en même temps.
Reste l’alignement, le point que l’on découvre en général trop tard. Un routeur peut très bien signer vos messages en DKIM avec son propre domaine. La signature est valide, mais elle ne correspond pas à votre From, et un expéditeur en volume reçoit alors un 4.7.32. Il faut que la signature porte votre domaine ou l’un de ses sous-domaines.
Ces trois sujets relèvent de la configuration de base, détaillée dans notre guide pour configurer SPF, DKIM et DMARC. La différence depuis novembre 2025 ? Une erreur oubliée ne se solde plus par un simple placement en spam.
Premier réflexe, Google Postmaster Tools. Son tableau de bord « Compliance status » passe en revue chaque exigence et affiche « Compliant », « Needs work » ou « No data found ». Pour tous les expéditeurs, il contrôle l’authentification SPF et DKIM, les enregistrements DNS, le format des messages, le chiffrement et le taux de spam déclaré. Pour les gros volumes, il ajoute DMARC, le désabonnement en un clic et la prise en compte effective des désabonnements. L’outil est gratuit, il suffit de valider votre domaine.
Deuxième contrôle, manuel celui-là. Envoyez une vraie campagne vers une boîte Gmail de test et ouvrez « Afficher l’original ». Gmail y affiche le résultat de SPF, DKIM et DMARC. Trois « PASS », c’est le minimum, et le domaine indiqué à côté de DKIM doit être le vôtre.
Viennent ensuite les rapports DMARC, trop souvent ignorés. D’après l’Afnic, 19,5 % des domaines en .fr publiaient un enregistrement DMARC en 2025, et près de la moitié d’entre eux (49,7 %) restaient en p=none sans adresse de rapport. Une politique déclarée, mais aucun retour d’information. Ajoutez une adresse rua : les rapports agrégés vous montreront les sources qui envoient en votre nom sans s’authentifier, précisément celles qui déclenchent les rejets.
Dernière vérification, demandez à votre routeur l’export du mois écoulé des retours provenant de gmail.com, avec le code SMTP complet. Des 4.7.x qui grimpent, c’est un avertissement. Un 5.7.x, c’est déjà trop tard pour les messages concernés.
Surtout, ne relancez pas la campagne. Renvoyer en masse vers Gmail des messages refusés ne fait qu’aggraver les signaux négatifs. Isolez d’abord le code dominant dans vos logs, corrigez l’exigence qu’il désigne, testez sur quelques adresses, puis reprenez les envois progressivement.
Si le problème vient des plaintes, Google fixe une règle précise. Au-dessus de 0,3 % de spam déclaré, un expéditeur en volume perd son éligibilité à la « mitigation », la procédure qui permet de demander un réexamen. Il la retrouve après 7 jours consécutifs sous 0,3 %. Pendant cette semaine, levez le pied : ciblez vos contacts actifs, mettez les segments froids de côté.
Gmail n’est d’ailleurs plus seul. Depuis le 5 mai 2025, Microsoft impose SPF, DKIM et DMARC aux expéditeurs de plus de 5 000 messages par jour vers Outlook.com, Hotmail et Live, avec un code de rejet 550 5.7.515. Yahoo applique des règles proches depuis 2024. Une mise en conformité pensée pour Gmail sert donc trois fois.
Gmail a bloqué le message faute d’authentification. Trois causes possibles : aucun SPF ni DKIM valide, un SPF en échec avec une politique -all, ou une politique DMARC du domaine qui réclame le rejet. Gmail ne distribue pas le message. Contrôlez les résultats d’authentification dans l’en-tête d’un email de test avant de modifier vos enregistrements DNS.
Oui, sur les exigences qui les concernent. Sous 5 000 messages par jour, Gmail demande quand même SPF ou DKIM, un PTR valide, une connexion TLS et un taux de spam inférieur à 0,3 %. DMARC, l’alignement du From et le désabonnement en un clic ne s’ajoutent qu’au-delà de ce volume quotidien vers des comptes Gmail.
Non. Google indique que ses exigences et leur application visent uniquement les envois vers des comptes Gmail personnels. Une adresse professionnelle hébergée sur Workspace suit ses propres filtres. Attention au sens inverse : si votre entreprise envoie depuis Workspace vers des adresses @gmail.com, ces mêmes règles s’appliquent à vos messages.
Aucun délai n’est garanti. Un rejet lié à l’authentification cesse en général une fois la cause corrigée, pour peu que les envois reprennent progressivement. Pour un taux de plaintes trop élevé, Google exige 7 jours consécutifs sous 0,3 % avant de rendre l’expéditeur à nouveau éligible à une demande de réexamen.
Pour les exigences de Gmail, oui : la politique minimale demandée aux expéditeurs en volume est p=none. Elle ne protège pourtant pas votre domaine contre l’usurpation. Ajoutez une adresse de rapport, analysez les sources pendant quelques semaines, puis passez par étapes en quarantine et enfin en reject.
Des codes 4.7 ou 5.7 apparaissent dans vos retours Gmail et vous ne savez pas par où commencer ? Envoyez-nous un extrait de vos logs, l’équipe d’Ediware vous aide à trouver la cause, au téléphone et en français. Contactez-nous.
Ce contenu est réalisé par Ediware. Consultez les sites officiels pour les informations les plus récentes.