Defaults.Exposed › Corrections › Guides

Gmail 550 5.7.26 « The Sender Is Unauthenticated » : le correctif, dans l'ordre des exigences (2026)

Publié 2026-07-08

Chiffres au 2026-06-29 · méthodologie v7. Données de recensement agrégées sur 261 millions de domaines évalués. Voir comment nous notons.

Gmail renvoie 550 5.7.26 quand votre message échoue aux vérifications d’authentification SPF et DKIM. Corrigez-le en faisant passer au moins l’un des deux, SPF ou DKIM, pour votre domaine d’envoi — c’est ce qui manque à la plupart des expéditeurs : sur les 12 145 313 domaines qui autorisent les serveurs de Google via _spf.google.com, seuls 18,5 % ont une politique DMARC contraignante, selon le recensement Defaults.Exposed portant sur 261 086 232 domaines.

Le correctif relève du DNS, pas d’un ticket de support : confirmez que votre IP d’envoi a un DNS inverse, faites passer SPF ou DKIM pour le domaine que Gmail vérifie réellement, puis alignez DKIM avec votre adresse From et publiez un enregistrement DMARC. Ci-dessous : l’ordre complet des exigences, plus une table de décodage de la famille 550 5.7.26 et de ses codes voisins.

Que signifie l’erreur Gmail 550 5.7.26 ?

Depuis les exigences expéditeurs 2024 de Google, chaque expéditeur vers Gmail — pas seulement les expéditeurs de masse — doit passer au moins l’un des deux, SPF ou DKIM, pour le domaine d’envoi. Échouez aux deux et Gmail rejette dès la session SMTP avec 550 5.7.26 au lieu de livrer en spam.

La version actuelle du texte complet dit : “This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. Authentication results: DKIM = did not pass, SPF [domain] with ip: [ip] = did not pass.” Des rebonds plus anciens peuvent encore porter la formulation précédente de Google (“This mail is unauthenticated, which poses a security risk…”), et il existe un cousin côté limitation de débit — 421 4.7.26 This email has been rate limited because it is unauthenticated — avec la même cause.

550 5.7.26 n’est pas un message unique mais une famille de codes, et la formulation vous dit quel volet a échoué : la référence actuelle de Google conserve trois chaînes 5.7.26 (unauthenticated, SPF hard fail, politique DMARC) et déplace les échecs SPF seul et DKIM seul des expéditeurs de masse vers leurs propres codes, 5.7.27 et 5.7.30. Lisez le texte exact avant de toucher au DNS — c’est votre premier diagnostic.

L’ampleur de l’écart explique la fréquence de ce rebond : 12 145 313 domaines autorisent les serveurs de messagerie de Google dans leur enregistrement SPF (sur 138 927 207 domaines dans le monde qui publient SPF), mais seuls 18,5 % ont une politique DMARC contraignante et à peine 8,0 % utilisent un SPF strict (-all). La plupart des expéditeurs hébergés chez Google ne satisfont pas aux propres règles de masse de Google — et Gmail applique désormais les bases à tout le monde.

Quelle variante de 550 5.7.26 — ou quel code voisin — avez-vous ?

Comparez le texte du rebond reçu à cette table. Les fragments cités suivent la référence actuelle des erreurs SMTP de Google — vérifiez-les toujours contre votre NDR réel, car Google révise la formulation périodiquement.

Comment corriger 550 5.7.26, dans l’ordre des exigences ?

Google ne publie aucun « ordre de vérification » littéral — mais ses exigences s’empilent logiquement ; travaillez donc dans cet ordre des exigences. La plupart des expéditeurs sont débloqués après l’étape 3 ; finissez tout de même la liste, car les étapes suivantes sont ce qui vous garde hors du spam une fois sorti du rebond.

1. Lancez d’abord le scan gratuit. Il lit vos SPF, DKIM, DMARC et votre configuration DNS en direct et montre exactement quel volet échoue — diagnostiquez avant de toucher au DNS.
2. Donnez un DNS inverse (PTR) à votre IP d’envoi. L’IP de connexion doit avoir un enregistrement PTR dont le nom d’hôte se résout vers la même IP. Les grands prestataires s’en chargent pour vous ; cela mord ceux qui envoient depuis leurs propres serveurs (et c’est toute l’histoire du code voisin 550 5.7.25).
3. Faites passer SPF ou DKIM. Un garde-fou d’abord : les serveurs de réception évaluent SPF sur le domaine du Return-Path (RFC5321.MailFrom), pas sur l’en-tête From — vérifiez vers quel domaine votre courrier rebondit réellement avant de décider que SPF « devrait » passer. Ajoutez vos vrais services d’envoi à l’enregistrement SPF de ce domaine (guide SPF complet), ou activez la signature DKIM chez votre prestataire (guide DKIM complet). L’un des deux qui passe suffit à lever le blocage 550 5.7.26 de base.
4. Alignez DKIM avec votre domaine From. Pour l’envoi de masse — et pour DMARC — Gmail veut une authentification pour le domaine de votre adresse From, pas une valeur par défaut du prestataire. Utilisateurs Google Workspace : publiez votre propre clé DKIM (configuration DKIM Workspace) ; une signature gappssmtp.com par défaut passe DKIM mais ne s’aligne pas — un piège qui a son propre guide. Un DKIM aligné survit aussi au transfert, ce que SPF ne fait jamais.
5. Publiez un enregistrement DMARC. Les exigences expéditeurs de Google demandent au minimum p=none avec une adresse de rapport. C’est cinq minutes d’édition DNS — voir « politique DMARC non activée » pour le premier pas honnête et ce que p=none protège ou non.
6. Envoyez via TLS. Tout serveur ou prestataire de messagerie moderne le fait par défaut ; si vous exploitez votre propre MTA, confirmez que le TLS sortant est actif — le courrier de masse sans TLS rebondit désormais avec son propre code, 550 5.7.29.
7. Ajoutez la désinscription en un clic RFC 8058 (en-têtes List-Unsubscribe + List-Unsubscribe-Post) pour le courrier marketing et les envois sur abonnement.
8. Gardez votre taux de spam sous 0,10 % dans Google Postmaster Tools — et ne le laissez jamais atteindre 0,30 %. Le plafond exigé par Google est 0,3 % ; sa recommandation est de rester sous 0,10 %. Inscrivez-y votre domaine ; c’est le bulletin de notes que Google tient sur vous, et le seuil de taux de spam est l’exigence qu’aucun enregistrement DNS ne peut corriger.

Une chose que cette liste ne fera pas : vous retirer d’une liste de blocage tierce. L’authentification stoppe les rejets unauthenticated de Gmail ; une IP avec un historique de spam est un problème de réputation avec son propre parcours de nettoyage — corriger l’authentification prévient les rechutes, cela ne vous retire pas des listes.

Les règles expéditeurs de masse s’appliquent-elles si vous envoyez moins de 5 000 e-mails par jour ?

La checklist complète — authentification alignée, DMARC publié, désinscription en un clic, taux de spam — s’applique formellement à partir de 5 000 messages par jour vers Gmail, et les codes réservés à la masse (5.7.27, 5.7.29, 5.7.30) viennent de ce palier. Mais les bases de l’authentification (SPF ou DKIM qui passe, PTR valide) sont appliquées à tout le monde, raison pour laquelle les petits expéditeurs rencontrent aussi 550 5.7.26. Considérez les étapes 1–5 comme obligatoires à tout volume, les étapes 7–8 comme obligatoires dès que vous envoyez en masse. L’ensemble complet des exigences des deux fournisseurs est dans notre article de données sur les exigences expéditeurs de Google et Yahoo.

Questions fréquentes

550 5.7.26 signifie-t-il que mon domaine ou mon IP est sur liste noire ? Non. C’est un échec d’authentification, pas un jugement de réputation — Gmail dit « prouvez qui vous êtes », pas « nous savons que vous êtes un spammeur ». Bonne nouvelle : c’est entièrement corrigeable dans le DNS. La mauvaise, c’est à quel point c’est banal — sur le recensement de 261 086 232 domaines (au 2026-06-29), seuls 10,59 % ont une politique DMARC contraignante.

Corriger SPF seul stoppera-t-il les rebonds ? Généralement oui, pour la variante de base — Gmail exige au moins l’un de SPF ou DKIM. Mais SPF est évalué sur le domaine du Return-Path et casse au transfert ; le DKIM aligné (étape 4) est donc le correctif durable. Seuls 8,0 % des 12 145 313 domaines expéditeurs hébergés chez Google utilisent un SPF strict (données au 2026-06-29), donc dans les deux cas vous serez en avance sur le peloton.

J’utilise Google Workspace — pourquoi Google fait-il rebondir mon propre courrier ? Parce que Gmail authentifie le domaine, pas le fournisseur de boîtes aux lettres. Un domaine Workspace sans enregistrement SPF ni clé DKIM personnalisée envoie du courrier que Google lui-même ne peut pas vérifier — sur 12 145 313 domaines qui autorisent les serveurs de Google, seuls 18,5 % ont une politique DMARC contraignante (données au 2026-06-29). Être client de Google et respecter les règles de Google sont deux choses différentes.

Combien de temps après le correctif DNS Gmail acceptera-t-il mon courrier ? Dès que les nouveaux enregistrements sont visibles — typiquement de quelques minutes à quelques heures, jusqu’à 48 heures pour les TTL lents. Les correctifs d’authentification agissent immédiatement sur la vérification 550 5.7.26 ; la récupération du taux de spam et de la réputation (421-4.7.0, 5.7.28) prend des jours, voire des semaines, d’envoi propre.

Envoyez le rapport au propriétaire

Si vous corrigez cela pour un client, ne fermez pas le ticket sur « rebonds résolus ». Relancez le scan gratuit après vos changements DNS et transmettez le rapport noté au chef d’entreprise. Il montre, en langage clair, que son domaine authentifie désormais son e-mail et où il pèche encore — la preuve qu’il lui faudra au renouvellement de la cyberassurance et dans les questionnaires de sécurité fournisseurs. Vous avez corrigé le rebond ; le rapport le prouve.

Vérifiez votre domaine gratuitement

Voyez sur quel volet de SPF, DKIM et DMARC Gmail vous recale — en privé, visible du propriétaire uniquement.

Vérifiez votre domaine → · Corriger SPF → · Gmail « 550-5.7.1 message blocked » → · Comment nous notons → · Données agrégées uniquement. Données stockées et traitées dans l’UE.