Erreur Gmail 550 5.7.26 « unauthenticated email » : cause et solution

Votre email revient avec un message d'échec de remise (« Mail Delivery Subsystem ») contenant une erreur de ce type :

550-5.7.26 This mail is unauthenticated, which poses a security risk to the
550-5.7.26 sender and Gmail users, and has been blocked. The sender must
550-5.7.26 authenticate with at least one of SPF or DKIM. For this message,
550-5.7.26 DKIM checks did not pass and SPF check for [votre-domaine.fr] did
550 5.7.26 not pass with ip: [203.0.113.50]. gsmtp

Traduction : Gmail refuse votre email parce que votre domaine n'est pas authentifié. Ce n'est ni un problème de contenu, ni un blocage de votre destinataire, ni une panne : c'est la configuration DNS de votre domaine qui est incomplète. Et cela se corrige en une fois, pour de bon.

Ce que signifie le code 550 5.7.26

Décomposons le code :

• 550 - rejet définitif : le serveur destinataire refuse l'email, il ne sera pas retenté (contrairement aux codes 4xx, temporaires).
• 5.7.x - la famille des rejets de sécurité et de politique : le problème n'est pas technique (l'adresse existe), il est lié à la confiance.
• 5.7.26 - le motif précis : défaut d'authentification de l'expéditeur. Votre domaine ne prouve pas son identité via SPF ou DKIM.

Le message de Gmail le dit explicitement : « The sender must authenticate with at least one of SPF or DKIM ». Depuis février 2024, c'est le ticket d'entrée minimal pour être accepté par Gmail - et Yahoo applique la même règle. Pour comprendre le contexte complet de ces exigences, voir notre article pourquoi mes emails arrivent en spam.

Pourquoi Gmail bloque vos emails

Concrètement, quand votre email arrive chez Gmail, ses serveurs font deux vérifications :

1. SPF : l'adresse IP qui a envoyé l'email figure-t-elle dans l'enregistrement SPF publié dans le DNS de votre domaine ? Si votre domaine n'a pas de SPF, ou si votre serveur d'envoi n'y est pas listé, c'est un échec.
2. DKIM : l'email porte-t-il une signature cryptographique DKIM vérifiable avec la clé publique publiée dans votre DNS ? Pas de signature, ou clé absente : échec.

Si les deux échouent, Gmail renvoie le rejet 550 5.7.26. Il suffit en théorie qu'un seul des deux passe, mais en pratique il faut configurer les deux (plus DMARC) pour une délivrabilité stable - c'est d'ailleurs obligatoire au-delà de 5 000 emails/jour.

Les situations typiques qui déclenchent cette erreur :

• un domaine dont la zone DNS n'a jamais été configurée pour l'email (cas le plus courant pour les TPE/PME) ;
• un changement d'hébergeur ou de messagerie : l'ancien SPF ne couvre pas les nouveaux serveurs d'envoi ;
• un outil tiers (CRM, logiciel de facturation, site web) qui envoie des emails « de votre part » sans être autorisé dans votre SPF ni signer en DKIM ;
• une erreur de syntaxe dans un enregistrement existant (deux enregistrements SPF, faute de frappe, dépassement des 10 lookups DNS).

La solution pas à pas

Étape 1 - Diagnostiquez votre domaine

Lancez le diagnostic ci-dessus : il vous dit précisément quels enregistrements manquent et lesquels sont invalides, et détecte votre hébergeur DNS pour adapter les instructions.

Étape 2 - Publiez votre enregistrement SPF

Dans la zone DNS de votre domaine, ajoutez un enregistrement TXT qui autorise vos serveurs d'envoi. Exemples selon votre messagerie :

# Google Workspace
v=spf1 include:_spf.google.com ~all

# Microsoft 365
v=spf1 include:spf.protection.outlook.com ~all

# OVH Mail
v=spf1 include:mx.ovh.com ~all

Attention : un domaine ne doit avoir qu'un seul enregistrement SPF. S'il en existe déjà un, complétez-le au lieu d'en créer un second. Guide complet : configurer SPF.

Étape 3 - Activez DKIM

DKIM s'active chez votre fournisseur de messagerie (Google Workspace, Microsoft 365, OVH…), qui vous fournit une clé publique à publier dans votre DNS. Suivez notre guide configurer DKIM ou directement le guide de votre plateforme : Google Workspace, Microsoft 365, OVH, Gandi, IONOS, o2switch, Infomaniak.

Étape 4 - Publiez DMARC

Ajoutez un enregistrement TXT nommé _dmarc :

v=DMARC1; p=none; rua=mailto:vous@votre-domaine.fr

Commencez avec la politique p=none (observation), puis durcissez vers p=quarantine une fois que vos rapports confirment que tout passe. Guide complet : configurer DMARC.

Étape 5 - Vérifiez et renvoyez

Après propagation DNS (souvent quelques minutes, jusqu'à 48h), relancez le diagnostic, puis envoyez un email de test à une adresse Gmail. Ouvrez-le côté destinataire : menu ⋮ → « Afficher l'original ». Vous devez voir SPF: PASS et DKIM: PASS. Le rejet 550 5.7.26 ne laisse aucune pénalité durable : dès que l'authentification passe, vos emails passent.

Les erreurs Gmail voisines

• 550 5.7.1 - rejet de politique ou de réputation : le contenu, l'IP ou le domaine est mal noté. Authentifiez d'abord le domaine, puis travaillez la réputation.
• 550 5.7.25 - l'IP d'envoi n'a pas d'enregistrement DNS inverse (PTR). À corriger côté hébergeur de messagerie ou serveur d'envoi.
• 421 4.7.0 - ralentissement temporaire : Gmail limite le débit d'un expéditeur suspect ou trop rapide. Souvent le symptôme d'un domaine non authentifié qui envoie en volume.
• 550 5.7.26 (DMARC) - variante indiquant « unauthenticated email from [domaine] is not accepted due to domain's DMARC policy » : ici c'est votre propre politique DMARC qui fait rejeter des emails non alignés - typiquement un outil tiers qui envoie en votre nom sans DKIM aligné.

Questions fréquentes

Que signifie l'erreur Gmail 550 5.7.26 ?

Le code 550 5.7.26 signifie que Gmail refuse définitivement votre email parce que votre domaine expéditeur n'est pas authentifié : il ne publie pas d'enregistrement SPF ou DKIM valide et aligné avec l'adresse d'expédition. C'est une exigence de Gmail depuis février 2024.

L'erreur vient-elle de mon destinataire ?

Non. Le message de rejet est envoyé par les serveurs de Google, mais la cause est la configuration DNS de votre domaine expéditeur. C'est à vous (ou à votre prestataire) de publier les enregistrements SPF, DKIM et DMARC manquants.

Combien de temps pour que la correction prenne effet ?

Dès que les enregistrements DNS sont propagés - de quelques minutes à 48 heures selon votre hébergeur. Une fois SPF et DKIM valides, les envois suivants passent : ce rejet ne laisse pas de pénalité durable.

Quelle différence entre 550 5.7.26 et 550 5.7.1 ?

550 5.7.26 indique un défaut d'authentification du domaine (SPF/DKIM). 550 5.7.1 est un rejet lié à la politique du destinataire ou à la réputation : contenu bloqué, IP ou domaine mal noté. Les deux se corrigent d'abord en authentifiant proprement le domaine.