Gmail « 550-5.7.1 Message Blocked » — décodez le rebond et corrigez-le (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.1 quand il bloque un message pour des raisons de politique plutôt que pour un enregistrement manquant : la politique d’un domaine émetteur ou destinataire, une connexion IPv6 sans DNS inverse, ou un spam présumé. Sur les 12 145 313 domaines qui autorisent les serveurs de Google dans leur SPF, seuls 18,5 % appliquent DMARC, selon le recensement Defaults.Exposed de 261 millions de domaines.

550-5.7.1 est le plus ancien rejet fourre-tout de Gmail, et la correction dépend de la phrase après le code dans votre rebond. Ci-dessous : un tableau de décodage pour la formulation exacte, puis le chemin de correction par variante — rejets de politique, serveurs IPv6 sans DNS inverse, blocages spam ou contenu — plus les codes proches avec lesquels on le confond, dont la famille 5.7.26 que Google utilise désormais pour le rejet de politique DMARC que les références plus anciennes classaient sous 5.7.1.

Que signifie réellement le 550-5.7.1 de Gmail ?

Dans le schéma SMTP de statuts étendus (RFC 3463), chaque code 5.7.x signifie « échec permanent, raisons de politique ». Gmail utilise 550-5.7.1 comme sa famille de politique historique : blocages de politique côté expéditeur ou destinataire, blocages de réputation anti-spam, et — la variante qui surprend le plus d’administrateurs — le courrier arrivant en IPv6 depuis un serveur sans enregistrement de DNS inverse (PTR).

Google re-code les variantes au fil du temps. Le rejet de politique DMARC (“not accepted due to domain’s DMARC policy”) figure désormais sous 550-5.7.26 dans la référence actuelle de Google, même si d’anciens rebonds dans la nature peuvent encore l’afficher en 5.7.1 ; le blocage de sécurité du contenu est désormais codé 552 5.7.0. Deux autres cousins se confondent avec 5.7.1 : 550-5.7.26, la famille des exigences d’authentification (son propre guide), et 550-5.7.25, le code de PTR manquant quelle que soit la version d’IP. Quel que soit le code, décodez le texte ci-dessous.

Quelle variante du 550-5.7.1 avez-vous ?

Comparez la formulation de votre rapport de non-remise (NDR). Google ajuste ces chaînes d’une année à l’autre — cherchez le sens général, pas la ponctuation.

Votre rebond ressemble à…	Ce que cela signifie	Votre chemin de correction
”This message does not meet IPv6 sending guidelines regarding PTR records and authentication.”	Votre serveur a livré en IPv6 sans DNS inverse (ou avec un DNS inverse non concordant)	Enregistrement PTR pour l’adresse IPv6, ou relais via le smarthost de votre fournisseur (ci-dessous)
“The user or domain that you are sending to (or from) has a policy that prohibited the email that you sent.”	Un blocage de politique — celle du destinataire, ou celle de votre propre domaine	Contactez l’administrateur destinataire ; si c’est le DMARC de votre propre domaine qui joue, voir ci-dessous
”This message is likely unsolicited email. To reduce the amount of spam sent to Gmail, this message has been blocked.”	Blocage spam/réputation sur votre contenu, IP ou domaine	Postmaster Tools + hygiène de liste + désabonnement en un clic (ci-dessous)
“This message is likely suspicious due to the very low reputation of the sending domain” (ou “…sending IP address”)	Blocage de réputation — domaine ou IP	Même chemin réputation (ci-dessous)
“Unauthenticated email from yourdomain is not accepted due to domain’s DMARC policy.” — codé 550-5.7.26 dans la référence actuelle de Google ; d’anciens rebonds peuvent encore afficher 5.7.1	Votre propre politique DMARC a demandé à Gmail de rejeter un message non authentifié	Trouvez la source non authentifiée — n’assouplissez pas la politique en premier (ci-dessous)
“…blocked because its content presents a potential security issue.” — désormais codé 552 5.7.0	Blocage contenu/politique (type de pièce jointe, réputation des liens)	Retirez la classe de contenu signalée ; vérifiez liens et pièces jointes
Le code est 550-5.7.25, “the sending IP address doesn’t have a PTR record”	DNS inverse manquant, quelle que soit la version d’IP	Même correction rDNS que la variante IPv6
Le code est 550-5.7.26	Famille des exigences d’authentification, pas 5.7.1	Voir le guide 550-5.7.26
Le code est 421-4.7.0, “Try again later, closing connection.”	Report temporaire — débit ou réputation, pas un blocage permanent	Ralentissez, corrigez l’authentification et le taux de spam ; cela se dissipe généralement

Comment corriger un rebond 550-5.7.1 ?

Lancez le scan gratuit sur defaults.exposed — il note vos SPF, DKIM et DMARC tels que le monde les voit, avant que vous touchiez au DNS, et montre si la variante DMARC est seulement possible pour votre domaine.
Lisez le texte complet du NDR face au tableau de décodage — c’est la phrase, pas le code, qui identifie la cause.
Variante DMARC : trouvez quelle source d’envoi a échoué à l’authentification et corrigez cette source (section suivante).
Variante IPv6/PTR : ajoutez un DNS inverse correspondant pour l’adresse IPv6 du serveur, ou relayez via le smarthost de votre fournisseur.
Variante spam/politique : Postmaster Tools, taux de spam sous 0,10 % (le plafond dur des exigences de Google est 0,30 %), hygiène de liste, désabonnement en un clic RFC 8058.
Renvoyez un test vers une boîte Gmail et relancez le scan — confirmez que le rebond a disparu et que la note le reflète.

Le rebond mentionne votre politique DMARC — pourquoi c’est votre politique qui fonctionne

La référence actuelle de Google code cette formulation en 550-5.7.26, mais d’anciens rebonds et des documentations tierces l’affichent encore sous 5.7.1 — dans les deux cas la mécanique est identique. Cela se lit à l’envers jusqu’à ce qu’on le voie : Gmail a vérifié un message prétendant venir de votre domaine, a constaté que ni SPF ni DKIM ne passait avec alignement, a consulté votre enregistrement DMARC, et a fait exactement ce que vous demandiez — rejeter. Votre clôture a tenu. La question est de savoir ce qui s’y est pris : un expéditeur légitime oublié (un CRM, un outil de facturation, une plateforme de newsletter) ou une véritable usurpation.

N’assouplissez donc pas la politique en première étape. Trouvez la source non authentifiée. Deux pièges couvrent la plupart des cas :

SPF passe, mais sur le mauvais domaine. Les serveurs de réception évaluent SPF contre le domaine du Return-Path (RFC5321.MailFrom), pas l’en-tête From. Un outil SaaS envoyant « de votre part » passe généralement SPF sur son propre domaine de rebond, qui ne s’aligne pas avec votre domaine From — donc DMARC échoue quand même. Pas à pas : DMARC échoue mais SPF et DKIM passent.
DKIM passe, mais avec la signature par défaut. Les valeurs par défaut gappssmtp.com de Google Workspace et onmicrosoft.com de Microsoft se vérifient très bien et ne s’alignent avec rien. Voir DKIM passe mais DMARC échoue quand même.

Cette variante est plus rare qu’on ne le croit : 27 640 987 des 261 086 232 domaines — 10,59 % — appliquent une politique DMARC quarantine ou reject, selon le recensement Defaults.Exposed (2026-06-29). Les 89,41 % restants ne voient jamais ce rebond car ils n’ont aucune clôture à faire tenir. Corriger la source, pas la politique, est traité de bout en bout dans le guide de réparation DMARC.

Le rebond mentionne les règles d’envoi IPv6 — la correction du DNS inverse

Les serveurs modernes se connectent souvent à Gmail en IPv6 par défaut, et Google exige que l’adresse IPv6 de connexion ait un enregistrement PTR résolvant vers un nom d’hôte qui résout en retour vers la même adresse (DNS inverse à confirmation directe). Sans cela, chaque message reçoit 550-5.7.1, aussi propre que soit votre SPF.

Trois corrections, par ordre de préférence :

Définissez l’enregistrement PTR de l’adresse IPv6 de votre serveur — là où vit l’IP (le panneau de votre hébergeur VPS ou FAI, pas la zone DNS de votre domaine), avec un enregistrement AAAA correspondant qui pointe en retour.
Relayez via le smarthost de votre fournisseur. Si vous ne contrôlez pas le rDNS, routez le courrier sortant par le relais de votre fournisseur de messagerie ou FAI, qui a déjà un rDNS correct.
Préférez le transport IPv4 comme palliatif. Cela masque généralement le symptôme parce que votre adresse IPv4 a un PTR — un contournement, pas une correction. Définissez le PTR IPv6 dès que possible.

Le rebond dit “likely unsolicited email” — le chemin de la réputation

Ici l’authentification est peut-être bonne, mais les filtres de Gmail ne font pas confiance au courrier. L’authentification est le plancher, pas le plafond — parmi les 12 145 313 domaines autorisant _spf.google.com, seuls 8,0 % verrouillent SPF avec un -all strict, donc une vérification qui passe ne dit pas grand-chose à elle seule. (Comparaison complète : quel fournisseur d’e-mail offre les valeurs SPF par défaut les plus solides.)

La checklist réputation :

Inscrivez-vous dans Google Postmaster Tools et surveillez le tableau de bord du taux de spam — gardez-le sous 0,10 %, et ne le laissez jamais atteindre le plafond de 0,30 % que les règles de Google pour les expéditeurs en masse posent comme exigence dure.
Nettoyez votre liste. Écartez les non-engagés et tout ce qui est acheté ou moissonné ; n’envoyez qu’aux personnes qui l’ont demandé.
Implémentez le désabonnement en un clic RFC 8058 sur le courrier en masse — exigé par les règles de Google, et chaque désabonnement qui n’est pas un clic « spam » protège votre taux.
Gardez une authentification alignée (SPF et DKIM sur votre propre domaine) pour que la réputation s’accumule sur un domaine que vous contrôlez.

Foire aux questions

550-5.7.1 est-il la même chose que 550-5.7.26 ? Non. 550-5.7.26 est la famille des exigences d’authentification de Gmail (SPF/DKIM manquant ou en échec) — et la référence actuelle de Google y classe aussi le rejet de politique DMARC. 550-5.7.1 est la famille de politique plus ancienne : blocages de politique côté destinataire et expéditeur, IPv6 sans PTR, blocages spam et réputation. C’est le texte du rebond, pas le numéro, qui vous dit quelle correction s’applique (au 2026-06-29 et selon les règles Google en vigueur).

Dois-je remettre ma politique DMARC à p=none pour arrêter les rebonds ? Cela les arrête en démolissant la clôture. Seuls 10,59 % des 261 086 232 domaines du recensement Defaults.Exposed (2026-06-29) appliquent DMARC tout court ; si vous en faites partie, gardez-la et corrigez la source non authentifiée — assouplir la politique rouvre l’usurpation du domaine exact.

Pourquoi Gmail bloque-t-il mon courrier alors que mon enregistrement SPF passe tous les vérificateurs ? Les vérificateurs testent l’enregistrement ; Gmail teste le message. SPF est évalué contre le domaine du Return-Path, pas l’adresse From visible, donc un pass sur le domaine de rebond d’un prestataire ne fait rien pour votre alignement DMARC — et les blocages de réputation ignorent SPF entièrement. Le scan gratuit montre quelle couche échoue réellement.

550-5.7.1 signifie-t-il que mon IP est sur une liste noire ? Pas nécessairement. Gmail gère son propre système de réputation ; vous pouvez être bloqué par Google sans figurer sur aucune liste publique. Consultez Postmaster Tools pour le point de vue de Google — et notez que corriger l’authentification prévient les dégâts futurs mais ne réinitialise pas à elle seule une mauvaise réputation d’envoi.

Envoyez le rapport au propriétaire

Une fois le rebond corrigé, relancez le scan et transférez le rapport noté au propriétaire de l’entreprise ou au client dont le courrier rebondissait. Il montre, en langage clair, ce qui était cassé, ce que vous avez corrigé, et où se situe désormais le domaine face à la base de référence de 261 millions de domaines — exactement ce qu’il leur faut pour le renouvellement d’assurance ou le questionnaire de sécurité client qui demande « authentifiez-vous vos e-mails ? ». Un rebond corrigé en silence est un travail invisible ; un rapport avant-après est une preuve.

Vérifiez votre domaine → · Gmail 550-5.7.26 — la correction dans l’ordre des exigences → · Réparer DMARC → · Comment nous notons → · Données agrégées uniquement. Données stockées et traitées dans l’UE.