550 5.7.26 « This message does not have authentication information » : corriger l’erreur Gmail

Si Gmail fait rebondir vos e-mails avec cette réponse SMTP, vous vous heurtez aux règles que Gmail applique aux expéditeurs en masse :

550-5.7.26 This message does not have authentication information or fails to
550-5.7.26 pass authentication checks (SPF or DKIM). To best protect our users
550-5.7.26 from spam, the message has been blocked. Please visit
550 5.7.26 https://support.google.com/mail/answer/81126 for more information.

C'est un rejet pour authentification ; la réputation, le contenu et les filtres propres à chaque utilisateur n'y jouent aucun rôle. Les exigences de Gmail pour les expéditeurs (en vigueur depuis février 2024 et appliquées plus durement depuis novembre 2025) imposent à chaque expéditeur de passer SPF ou DKIM, et à ceux qui envoient environ 5 000 messages par jour ou plus vers des comptes Gmail personnels de passer SPF et DKIM, d'aligner le domaine From sur l'un des deux et de publier un enregistrement DMARC. Quand l'authentification échoue, Gmail rejette le message dès l'échange SMTP.

Ce que veut vraiment dire 550 5.7.26

L'erreur a trois causes possibles, par ordre de fréquence :

1. Ni SPF ni DKIM n'est aligné sur le domaine From: visible.
2. La politique DMARC de votre propre domaine (p=quarantine ou p=reject) dit à Gmail de refuser les e-mails en échec. Un enregistrement DMARC absent a son propre code, 4.7.40 ou 5.7.40, dans la liste d'erreurs de Gmail.
3. SPF et DKIM passent tous les deux, mais le domaine de l'en-tête From: ne correspond pas au domaine authentifié (échec d'alignement).

Gmail ne compte pas un SPF réussi sur le seul domaine Return-Path/de bounce. Si votre domaine de bounce est bounces.esp.com et votre From hello@yourdomain.com, SPF passe mais n'est pas aligné : vous devez donc vous appuyer sur un DKIM signé par yourdomain.com.

Étape 1 : regardez les en-têtes du message d'origine

Envoyez-vous un test depuis la même plateforme d'envoi vers un compte Gmail qui l'accepte encore (ou un compte Workspace où vous pouvez lire le spam). Ouvrez le message → trois points → Afficher l'original.

Cherchez l'en-tête Authentication-Results: :

Authentication-Results: mx.google.com;
       dkim=pass header.i=@esp.com;
       spf=pass smtp.mailfrom=bounces.esp.com;
       dmarc=fail (p=NONE) header.from=yourdomain.com

Dans cet exemple, DKIM passe pour esp.com mais le From est yourdomain.com : c'est pour cela que DMARC échoue. Le correctif consiste à configurer la signature DKIM sur yourdomain.com dans votre ESP, pas à modifier SPF.

Étape 2 : corrigez l'alignement DKIM

L'alignement DKIM est la victoire la plus facile. Presque tous les grands ESP (Mailchimp, HubSpot, SendGrid, Brevo, Klaviyo, ActiveCampaign, Customer.io, Resend, Postmark) prennent en charge un DKIM sur domaine personnalisé. Vous ajoutez l'enregistrement CNAME ou TXT qu'ils fournissent sur selector._domainkey.yourdomain.com, puis vous activez la signature DKIM dans leur tableau de bord.

Après propagation (de quelques minutes à quelques heures), l'en-tête Authentication-Results doit afficher dkim=pass header.i=@yourdomain.com, et DMARC passera par la voie DKIM même si SPF n'est pas aligné.

Vérifiez avec notre outil de recherche DKIM.

Étape 3 : publiez un enregistrement DMARC (même en p=none)

Les règles de Gmail pour les expéditeurs en masse exigent la présence d'un enregistrement DMARC. p=none suffit à remplir cette exigence pendant que vous surveillez encore. L'enregistrement conforme minimal est :

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Ajoutez-le en enregistrement TXT sur _dmarc.yourdomain.com. Créez-en un avec notre générateur DMARC.

Étape 4 : vérifiez que SPF n'est pas cassé en silence

Même si DKIM fait le travail, vous voulez un SPF propre. Problèmes fréquents :

• Plus de 10 recherches DNS dans l'enregistrement SPF (provoque un permerror)
• Deux enregistrements SPF sur le même domaine (un seul est autorisé)
• Un -all (échec strict) là où vous vouliez ~all (cela ne compte que si votre ESP n'est pas dans la liste des include)

Vérifiez avec notre outil de recherche SPF. Si vous dépassez la limite de 10 recherches, aplatissez avec une délégation de sous-domaine ou un service de macros SPF.

Étape 5 : inscrivez-vous à Google Postmaster Tools et lisez-le

Si vous recevez des 550 5.7.26, inscrivez le domaine From dans Google Postmaster Tools. Après 24 à 48 heures de trafic, il affiche :

• Le taux de réussite de l'authentification (cible : >99 %)
• La réputation du domaine
• La réputation de l'IP
• Le taux de spam (le plafond absolu de Gmail est 0,3 % ; visez moins de 0,1 %)

Si le graphique d'authentification n'est pas vert à presque 100 %, vos corrections n'ont pas encore pleinement pris effet.

Étape 6 : testez à nouveau depuis une connexion neuve

Les files de nouvelles tentatives des ESP peuvent mettre 30 minutes à se vider. Mettez la campagne d'envoi en pause puis relancez-la, ou envoyez un nouveau message de test une fois DKIM et DMARC propagés. Le bounce doit disparaître immédiatement dès que l'authentification passe. Gmail ne « garde pas en mémoire » l'échec précédent contre votre IP.

Pourquoi vous pouvez encore avoir 550 5.7.26 après avoir tout corrigé

Quelques causes moins évidentes que nous voyons au support :

• Sous-domaine différent. Si votre From est hello@mail.yourdomain.com mais que DKIM est configuré sur yourdomain.com, l'alignement est relaxed par défaut et devrait passer, mais certains ESP publient un alignement strict dans DMARC (adkim=s). Passez à adkim=r.
• Cache DNS périmé. Gmail garde le DNS en cache pendant des heures. Après avoir publié DKIM, attendez au moins 4 heures avant de conclure que le correctif ne marche pas.
• Mauvais sélecteur. Certains ESP font tourner leurs sélecteurs (par exemple s1, s2). Si vous avez supprimé l'ancien enregistrement TXT avant que le nouveau prenne effet, vous verrez des échecs DKIM jusqu'à ce que vous le remettiez.

FAQ

550 5.7.26 est-il la même chose que le 550-5.7.1 de Gmail ? Non. 550-5.7.1 Our system has detected... est un blocage lié au contenu ou à la réputation. 550-5.7.26 est strictement un bounce d'application de l'authentification, et le correctif est technique (DKIM/SPF/DMARC), sans rapport avec le contenu.

Gmail va-t-il bloquer toute mon IP après un 550 5.7.26 ? Non. Ce bounce est évalué message par message, expéditeur par expéditeur. Il n'abîme pas à lui seul la réputation de l'IP. Mais réessayer sans cesse avec une authentification cassée gaspille des créneaux de connexion et peut finir par vous ralentir via un throttling 421.

Faut-il appliquer DMARC (p=quarantine ou p=reject) pour corriger cela ? Non. Gmail exige un enregistrement DMARC publié. p=none suffit pour le contrôle des expéditeurs en masse. Ne passez à l'application qu'une fois que vos rapports agrégés DMARC sont propres.

Gardez une longueur d'avance sur les règles de Gmail

Gmail durcit ces exigences tous les 12 à 18 mois. MailVitals surveille en continu votre SPF, votre DKIM, votre DMARC et l'alignement, et vous alerte dès qu'un enregistrement dérive.

Sources

• Gmail SMTP errors and codes (Google Workspace Help) : les trois textes du 550 5.7.26 (expéditeur non authentifié, échec SPF strict, politique DMARC) et le code distinct 5.7.40 pour un enregistrement DMARC absent.
• Email sender guidelines (Gmail Help) : SPF ou DKIM pour tous les expéditeurs ; SPF, DKIM, DMARC et alignement du From pour les expéditeurs en masse ; clés DKIM d'au moins 1024 bits.
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) : la norme DMARC actuelle (mai 2026, qui remplace la RFC 7489), y compris l'alignement des identifiants et les modes adkim/aspf.
• RFC 7208: Sender Policy Framework (SPF) : la limite de 10 recherches DNS et le permerror qu'elle produit en cas de dépassement.