Rejets Gmail 550‑5.7.26 et UsernameCaseMapped : causes, diagnostic et solutions
Par CaptainDNS
Publié le 26 février 2026
- Gmail renvoie 550 5.7.26 quand SPF, DKIM ou l'alignement DMARC échouent : c'est un rejet permanent, le serveur ne réessaiera pas
- L'erreur UsernameCaseMapped provient de la normalisation PRECIS (RFC 8265) : la local-part de l'adresse From doit être en minuscules
- Depuis février 2024, Google exige SPF + DKIM + DMARC pour les expéditeurs de masse (>5 000 emails/jour) et SPF ou DKIM pour tous les autres
- Corrigez en normalisant vos adresses en lowercase, en vérifiant SPF/DKIM/DMARC et en contrôlant l'alignement du domaine From:
Vos emails vers Gmail reviennent avec un code 550. Pas de mise en spam, pas de délai : un rejet net et définitif. Le serveur coupe la connexion et ne réessaiera pas. C'est ce que constatent de plus en plus d'équipes de délivrabilité depuis début 2026, avec deux motifs de rejet en hausse : 550 5.7.26 (expéditeur non authentifié) et UsernameCaseMapped (casse de l'adresse invalide).
Ces deux erreurs partagent un point commun : elles résultent du renforcement continu des politiques anti-spoofing de Google. Ce qui passait il y a un an est désormais bloqué. Ce guide couvre les causes techniques de chaque erreur, le diagnostic précis via les logs SMTP, et les correctifs à appliquer sur votre infrastructure d'envoi.
Comprendre l'erreur 550 5.7.26 de Gmail
Le code 550 5.7.26 est un rejet permanent (classe 5xx) qui signifie que Gmail n'a pas pu valider l'authenticité de votre message. Contrairement à un code 4xx (temporaire), le serveur émetteur ne doit pas réessayer : l'email est définitivement refusé.
Les trois variantes du code 550 5.7.26
Google renvoie trois messages différents sous le même code, chacun correspondant à une cause distincte :
Variante 1 - Expéditeur non authentifié :
550-5.7.26 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 [captaindns.com] with ip: [203.0.113.42] = did not pass.
Ni SPF ni DKIM n'ont réussi la vérification. C'est la variante la plus fréquente.
Variante 2 - SPF hard fail :
550-5.7.26 The MAIL FROM domain [captaindns.com] has an SPF record
with a hard fail policy (-all) but it fails to pass SPF checks
with the ip: [203.0.113.42].
Votre enregistrement SPF se termine par -all (rejet strict), mais l'IP qui envoie n'est pas autorisée. Gmail applique votre propre politique à la lettre.
Variante 3 - Politique DMARC :
550-5.7.26 Unauthenticated email from captaindns.com is not accepted
due to domain's DMARC policy. Contact the administrator of
captaindns.com domain if this was legitimate email.
SPF ou DKIM peut avoir réussi, mais l'alignement DMARC échoue : le domaine From: ne correspond pas au domaine authentifié par SPF ou DKIM.
Différence entre 550 5.7.26 et 421 4.7.26
| Code | Classe | Comportement | Action requise |
|---|---|---|---|
| 421 4.7.26 | Temporaire | Le serveur émetteur réessaie plus tard | Vérifier, mais le mail peut finir par passer |
| 550 5.7.26 | Permanent | L'email est définitivement rejeté | Corriger la configuration avant de renvoyer |
Un 421 est un avertissement avec rate limiting. Un 550 est un mur. Si vous voyez des 550, le problème est structurel et ne se résoudra pas en réessayant.
Pourquoi ces rejets augmentent maintenant ?
Depuis le 1er février 2024, Google a durci ses exigences pour les expéditeurs :
| Exigence | Tous les expéditeurs | Bulk senders (>5 000/jour) |
|---|---|---|
| SPF ou DKIM | Obligatoire | Obligatoire |
| SPF et DKIM | Recommandé | Obligatoire |
| DMARC | Recommandé | Obligatoire (p=none minimum) |
| Alignement From: | Recommandé | Obligatoire |
| TLS (STARTTLS) | Obligatoire | Obligatoire |
| Taux de spam <0,3 % | Obligatoire | Obligatoire |
Ce qui a changé concrètement : avant, un email sans authentification atterrissait en spam. Aujourd'hui, Gmail le rejette avec un 550. C'est une différence majeure.
Comprendre l'erreur UsernameCaseMapped
L'erreur UsernameCaseMapped est moins documentée mais tout aussi bloquante. Elle provoque un rejet permanent 550 lié à la casse de l'adresse expéditeur.
Qu'est-ce que le profil UsernameCaseMapped ?
Le terme vient de la RFC 8265 (PRECIS - Preparation, Enforcement, and Comparison of Internationalized Strings). Cette RFC définit comment les serveurs doivent normaliser les identifiants utilisateur avant de les comparer.
Le profil UsernameCaseMapped impose deux opérations :
- Normalisation Unicode (NFKC) : les caractères sont réduits à leur forme canonique
- Case folding : les majuscules sont converties en minuscules
Concrètement, quand Gmail reçoit un email, il normalise la local-part (la partie avant le @) de l'adresse From: en appliquant ce profil. Si le résultat ne correspond pas à l'adresse attendue, le message est rejeté.
Comment cette erreur se produit ?
Le scénario typique :
- Votre CRM ou script envoie un email avec
From: Marketing@captaindns.com - Gmail normalise la local-part :
marketing@captaindns.com - La comparaison échoue si le serveur attend exactement
Marketing@captaindns.comou si l'authentification (SPF/DKIM) a été effectuée avec une casse différente - Résultat : rejet 550 UsernameCaseMapped
Les systèmes qui déclenchent le plus souvent cette erreur :
- CRM et plateformes marketing qui stockent l'adresse avec la casse saisie par l'utilisateur
- Alias email et redirections qui préservent la casse originale
- Scripts legacy qui construisent l'adresse From sans normalisation
- Formulaires web qui reprennent la saisie utilisateur telle quelle dans le MAIL FROM
RFC 5321 et la casse des adresses email
La RFC 5321 (SMTP) stipule que la local-part d'une adresse email est théoriquement case-sensitive : c'est le serveur de réception qui décide si User et user sont la même boîte. En pratique, la quasi-totalité des serveurs traitent la local-part en minuscules. Gmail va plus loin en appliquant la normalisation PRECIS et en rejetant les messages dont la casse ne correspond pas.
Le piège : la RFC autorise la casse, mais les implémentations modernes l'interdisent de fait. Si votre infrastructure d'envoi préserve des majuscules dans l'adresse From ou le MAIL FROM, vous risquez un rejet.
Diagnostiquer ces erreurs
Lire les logs SMTP
Le diagnostic commence par les logs de votre serveur de messagerie ou de votre prestataire d'envoi. Cherchez les réponses 550 :
Feb 12 14:23:01 mail postfix/smtp[12345]: to=<contact@gmail.com>,
relay=gmail-smtp-in.l.google.com[142.250.115.27]:25,
status=bounced (host gmail-smtp-in.l.google.com said:
550-5.7.26 This email has been blocked because the sender is
unauthenticated.)
Points à vérifier dans les logs :
- Le code exact (550 vs 421)
- L'IP d'envoi mentionnée dans le message
- Les résultats SPF et DKIM cités par Gmail
- Le domaine From: et le domaine MAIL FROM (envelope sender)
Vérifier l'authentification avec les en-têtes
Si vous avez accès à un email qui est passé (ou à un rapport DMARC), examinez les en-têtes Authentication-Results :
Authentication-Results: mx.google.com;
dkim=pass header.d=captaindns.com header.s=selector1;
spf=pass (google.com: domain of bounce@captaindns.com
designates 203.0.113.42 as permitted sender)
smtp.mailfrom=bounce@captaindns.com;
dmarc=pass (p=REJECT sp=REJECT) header.from=captaindns.com
Si un de ces trois résultats est fail, vous avez trouvé la source du problème. Utilisez le vérificateur DMARC CaptainDNS pour contrôler votre configuration en quelques secondes.
Utiliser Google Postmaster Tools
Google Postmaster Tools fournit des métriques sur vos envois vers Gmail :
- Taux de spam signalé par les destinataires
- Réputation de votre domaine et de vos IPs d'envoi
- Volume de rejets par code d'erreur
Si votre taux de spam dépasse 0,3 %, Gmail commence à rate-limiter vos envois (421) puis à les rejeter (550).
Corriger l'erreur 550 5.7.26
Étape 1 : configurer SPF correctement
Votre enregistrement SPF doit autoriser toutes les IPs et services qui envoient au nom de votre domaine :
captaindns.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0/24 -all"
Erreurs fréquentes :
- Un prestataire d'envoi absent du SPF (CRM, outil marketing, service transactionnel)
- Un
-all(hard fail) alors que tous les expéditeurs ne sont pas listés : utilisez~all(soft fail) le temps de compléter la liste - Plus de 10 lookups DNS dans l'enregistrement SPF, ce qui invalide toute la politique
Vérifiez avec le vérificateur SPF CaptainDNS.
Étape 2 : activer DKIM sur tous les flux d'envoi
Chaque service qui envoie des emails pour votre domaine doit signer avec DKIM :
selector1._domainkey.captaindns.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."
Points critiques :
- La clé doit être de 1 024 bits minimum (2 048 recommandé par Google)
- Le domaine de signature DKIM (
d=) doit correspondre au domaine From: pour l'alignement DMARC - Vérifiez que la clé publique est accessible dans le DNS :
dig TXT selector1._domainkey.captaindns.com
Étape 3 : déployer une politique DMARC
Si vous n'avez pas encore de DMARC, commencez par une politique de monitoring :
_dmarc.captaindns.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@captaindns.com; adkim=r; aspf=r"
Progression recommandée :
| Étape | Politique | Durée | Objectif |
|---|---|---|---|
| 1 | p=none | 2-4 semaines | Collecter les rapports, identifier les flux |
| 2 | p=quarantine; pct=25 | 2 semaines | Tester sur 25 % du trafic |
| 3 | p=quarantine; pct=100 | 2 semaines | Quarantaine complète |
| 4 | p=reject | Permanent | Rejet des emails non authentifiés |
Étape 4 : vérifier l'alignement DMARC
L'alignement est la pièce manquante la plus fréquente. Il exige que le domaine From: (en-tête RFC 5322) corresponde au domaine authentifié par SPF ou DKIM :
| Vérification | Domaine comparé | Alignement |
|---|---|---|
| SPF | Domaine du MAIL FROM (envelope) | Doit matcher le domaine From: |
| DKIM | Domaine d= de la signature | Doit matcher le domaine From: |
Exemple d'échec d'alignement :
- From:
contact@captaindns.com - MAIL FROM:
bounce@promo.captaindns.com - SPF passe pour
promo.captaindns.com, mais DMARC échoue car le From: estcaptaindns.com
En mode relaxed (adkim=r; aspf=r), les sous-domaines sont acceptés. En mode strict (adkim=s; aspf=s), le domaine doit être identique.
Étape 5 : assurer le chiffrement TLS
Gmail exige une connexion TLS (STARTTLS) pour accepter les emails. Vérifiez que votre serveur supporte STARTTLS :
openssl s_client -starttls smtp -connect mail.captaindns.com:25
Si la connexion TLS échoue, Gmail renverra un rejet. Activez TLS-RPT pour recevoir des rapports quotidiens sur les échecs de négociation TLS.
Corriger l'erreur UsernameCaseMapped
Étape 1 : normaliser toutes les adresses en minuscules
La correction est simple mais doit être appliquée partout. Chaque adresse dans vos envois doit être en minuscules :
| Champ | Avant (risque de rejet) | Après (correct) |
|---|---|---|
| From: (RFC 5322) | Marketing@captaindns.com | marketing@captaindns.com |
| MAIL FROM (envelope) | Bounce@captaindns.com | bounce@captaindns.com |
| Return-Path | Return@captaindns.com | return@captaindns.com |
| Reply-To | Support@captaindns.com | support@captaindns.com |
Étape 2 : auditer les systèmes d'envoi
Listez tous les systèmes qui envoient des emails au nom de votre domaine et vérifiez comment ils construisent l'adresse From :
| Système | Risque | Vérification |
|---|---|---|
| CRM (HubSpot, Salesforce, Brevo) | Moyen, reprend souvent la saisie utilisateur | Vérifier les paramètres d'adresse expéditeur |
| Outil marketing (Mailchimp, SendGrid) | Faible, normalise généralement | Confirmer dans les logs |
| Application interne / script | Élevé, aucune normalisation par défaut | Auditer le code source |
| Alias et redirections | Élevé, préserve la casse originale | Tester un envoi et vérifier les en-têtes |
| Formulaire web (contact, inscription) | Élevé, reprend la saisie telle quelle | Ajouter une normalisation en amont |
Étape 3 : automatiser la normalisation
Ajoutez une étape de normalisation systématique dans vos flux d'envoi :
Python :
def normalize_email(address: str) -> str:
local, domain = address.rsplit("@", 1)
return f"{local.lower()}@{domain.lower()}"
# Utilisation
from_address = normalize_email("Marketing@CaptainDNS.com")
# Résultat : marketing@captaindns.com
Node.js :
function normalizeEmail(address) {
const [local, domain] = address.split('@');
return `${local.toLowerCase()}@${domain.toLowerCase()}`;
}
// Utilisation
const fromAddress = normalizeEmail('Marketing@CaptainDNS.com');
// Résultat : marketing@captaindns.com
Postfix (main.cf) :
# Forcer la local-part en minuscules pour le MAIL FROM
lmtp_lowercase_quote_localpart = yes
🎯 Plan d'action recommandé
- Auditer vos flux d'envoi : listez tous les systèmes qui envoient au nom de votre domaine (CRM, marketing, transactionnel, scripts, formulaires)
- Normaliser en minuscules : forcez toutes les adresses From, MAIL FROM et Return-Path en lowercase dans chaque système
- Vérifier SPF : tous les expéditeurs sont-ils autorisés ? Le nombre de lookups DNS est-il <10 ?
- Vérifier DKIM : clé ≥1 024 bits publiée dans le DNS, domaine
d=aligné avec le From: ? - Publier une politique DMARC :
p=noneminimum avec rapports RUA actifs pour commencer - Contrôler l'alignement : le domaine From: correspond-il au domaine SPF ou DKIM ?
- Activer TLS-RPT : pour monitorer les échecs de chiffrement sur vos emails entrants
- Surveiller Postmaster Tools : vérifier quotidiennement le taux de spam et la réputation domaine/IP
FAQ
Quelle est la différence entre 550 5.7.26 et 421 4.7.26 ?
Le code 421 4.7.26 est un rejet temporaire avec rate limiting : Gmail ralentit vos envois mais le serveur émetteur peut réessayer plus tard. Le code 550 5.7.26 est un rejet permanent : l'email est définitivement refusé et le serveur ne doit pas réessayer. Un 421 signale un problème ponctuel ou un volume inhabituel. Un 550 signale un défaut structurel d'authentification qui nécessite une correction de configuration.
Comment savoir si mon erreur est UsernameCaseMapped ou 550 5.7.26 ?
Le texte du message d'erreur SMTP fait la distinction. Un rejet 550 5.7.26 mentionne explicitement "unauthenticated", "SPF" ou "DMARC policy". L'erreur UsernameCaseMapped apparaît dans le texte de la réponse SMTP avec le terme "UsernameCaseMapped" et concerne la casse de l'adresse, pas l'authentification du domaine. Consultez les logs SMTP de votre serveur ou de votre prestataire pour lire le message complet.
Mon SPF est configuré, pourquoi j'ai quand même 550 5.7.26 ?
Trois causes fréquentes : (1) l'IP d'envoi n'est pas listée dans le SPF, vérifiez que tous vos prestataires sont inclus ; (2) le SPF dépasse 10 lookups DNS, ce qui invalide toute la politique ; (3) SPF passe mais l'alignement DMARC échoue parce que le domaine MAIL FROM ne correspond pas au domaine From:. Vérifiez l'alignement en plus du SPF.
Faut-il une politique DMARC p=reject pour éviter le rejet ?
Non. Gmail exige un enregistrement DMARC publié pour les bulk senders, mais p=none suffit comme politique minimum. Le rejet 550 5.7.26 se produit quand l'authentification échoue (SPF et DKIM ne passent pas), indépendamment de votre politique DMARC. Cependant, la variante "not accepted due to domain's DMARC policy" peut se déclencher si votre propre politique est p=reject et que l'alignement échoue.
L'erreur UsernameCaseMapped affecte-t-elle aussi Google Workspace ?
Oui. Google Workspace applique les mêmes règles de normalisation PRECIS que Gmail personnel. Si vous envoyez des emails vers des adresses @votreentreprise.com hébergées sur Google Workspace avec une casse incorrecte dans l'adresse From, le rejet UsernameCaseMapped peut se produire. La normalisation en minuscules s'applique à tous les comptes Google.
Comment tester l'alignement DMARC avant d'envoyer en production ?
Publiez une politique p=none avec des rapports RUA activés (rua=mailto:dmarc@captaindns.com). Envoyez un email de test vers un compte Gmail et examinez les en-têtes Authentication-Results. Vérifiez que dmarc=pass apparaît. Si dmarc=fail, comparez le domaine From: avec les domaines SPF et DKIM dans les résultats pour identifier le défaut d'alignement.
Que signifie 'Unauthenticated email not accepted due to domain's DMARC policy' ?
Ce message indique que votre domaine a publié une politique DMARC restrictive (p=quarantine ou p=reject) et que l'email n'a réussi ni la vérification SPF alignée ni la vérification DKIM alignée. Gmail applique votre propre politique : puisque vous avez demandé le rejet des emails non authentifiés, Gmail rejette. Vérifiez l'alignement SPF et DKIM avec le domaine From:.
Les rejets 550 5.7.26 affectent-ils ma réputation d'expéditeur ?
Oui, indirectement. Des rejets permanents répétés signalent à Gmail que votre infrastructure d'envoi n'est pas correctement configurée. Cela peut dégrader la réputation de vos IPs et de votre domaine dans Google Postmaster Tools, ce qui entraîne ensuite du rate limiting (421) sur vos envois qui passent l'authentification. Corrigez rapidement pour éviter l'effet boule de neige.
📖 Glossaire
- 550 : code SMTP de rejet permanent. Le serveur émetteur ne doit pas réessayer l'envoi.
- 5.7.26 : enhanced status code (RFC 3463) indiquant un échec d'authentification de l'expéditeur.
- UsernameCaseMapped : profil de normalisation défini dans la RFC 8265 (PRECIS) qui impose la conversion en minuscules de la local-part des identifiants.
- Alignement DMARC : correspondance entre le domaine de l'en-tête From: (RFC 5322) et le domaine authentifié par SPF ou DKIM. Requis pour passer la vérification DMARC.
- Envelope sender : adresse MAIL FROM utilisée dans la transaction SMTP (RFC 5321), distincte de l'en-tête From: visible par le destinataire.
- Bulk sender : expéditeur envoyant plus de 5 000 emails par jour vers des comptes Gmail. Soumis à des exigences renforcées depuis février 2024.
