Gmail a rejeté un e-mail de mon domaine

Quelle méthode choisir ?

Le code de rejet dicte la vérification suivante. Ne commencez pas par remplacer le DNS d’après un exemple en ligne, ni par prendre le blocage d’un message pour la preuve d’un blocage de tout le domaine.

Les erreurs et codes SMTP de Gmail de Google distinguent les échecs d’authentification, de TLS, de DNS inverse, de format et de réputation. Pour 5.7.26, 5.7.27 ou 5.7.30, examinez la configuration d’authentification ou de transport de l’expéditeur. Pour 5.7.25, voyez avec le propriétaire de l’IP d’envoi et de son DNS inverse. Pour un message de réputation 5.7.1 ou 5.7.28, conservez les preuves et revoyez les pratiques d’envoi avant tout changement DNS.

N’utilisez la publication DNS automatique que si le compte expéditeur peut modifier la bonne zone DNS et que ses valeurs générées correspondent au domaine choisi. Passez au DNS manuel si votre fournisseur DNS, votre gestion des changements ou votre politique de sécurité exige une revue. Une IP dédiée ne compte que si le fournisseur l’a attribuée à votre chemin d’envoi de production. Elle ne corrige pas à elle seule un échec SPF, DKIM, DMARC, TLS ou de format.

Configurer SPF et DKIM pour Gmail

1. Lisez le rejet complet dans le service d’envoi

Ouvrez l’événement de livraison, le journal SMTP ou l’avis de rejet du message en échec. Notez le code SMTP et conservez le texte exact. Google documente ces variantes 5.7.26 distinctes :

This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM.

The (E)MAIL FROM domain [_domain-name_] has an SPF record with a hard fail policy (-all) but it fails to pass SPF checks with the ip: [_ip-address_].

Unauthenticated email from domain-name is not accepted due to domain’s DMARC policy. Contact the administrator of _domain-name_ domain if this was legitimate email.

Le premier message indique une authentification absente. Le deuxième, une IP d’envoi qui échoue à la politique SPF stricte (hard fail) du domaine d’enveloppe. Le troisième signifie que la politique DMARC publiée du domaine From visible a rejeté un courrier sans SPF ni DKIM aligné réussi.

2. Identifiez le domaine et le service visés

Comparez le domaine From visible, le domaine MAIL FROM d’enveloppe, le domaine DKIM d= et l’expéditeur à l’origine du rejet. SPF évalue le chemin d’enveloppe, alors que DMARC exige l’alignement du domaine From visible avec une identité SPF ou DKIM réussie. Les règles d’alignement DMARC de la RFC 9989 expliquent pourquoi un SPF ou DKIM valide mais sans lien peut quand même échouer à DMARC.

Si un fournisseur envoie en votre nom, suivez ses consignes actuelles d’authentification de domaine pour générer ses propres enregistrements. N’ajoutez pas de second TXT SPF à la racine. Combinez les mécanismes SPF dans l’unique enregistrement SPF existant, après vérification de la valeur include documentée par chaque fournisseur.

3. Publiez les enregistrements générés

Ne publiez que les enregistrements générés pour ce compte expéditeur et ce domaine. Ces formes sont purement indicatives.

Type SPF : TXT

Hôte SPF : yourdomain.com

Valeur SPF, à titre d’exemple :

v=spf1 include:sender.example -all

Type DKIM : CNAME ou TXT, selon ce que génère l’expéditeur

Hôte DKIM, à titre d’exemple :

selector1._domainkey.yourdomain.com

Valeur DKIM, à titre d’exemple :

selector1.example-sender.invalid

Ne publiez pas ces exemples. Copiez l’hôte et la valeur exacts générés dans le service d’envoi pour votre compte et votre domaine.

Certaines interfaces DNS ajoutent automatiquement yourdomain.com au champ hôte. Saisir un domaine complet là où le fournisseur attend un hôte relatif peut créer selector1._domainkey.yourdomain.com.yourdomain.com. Après l’enregistrement, vérifiez le nom DNS complet final.

Avant de modifier SPF, gardez chaque mécanisme requis par les expéditeurs légitimes. Avant d’ajouter DKIM, vérifiez si le sélecteur existe déjà. N’écrasez pas un sélecteur actif, sauf en suivant la rotation de clés documentée par l’expéditeur.

4. Vérifiez le statut d’authentification du domaine

Revenez chez le fournisseur d’envoi et consultez son statut de vérification documenté pour le domaine choisi. Ce statut indique que le fournisseur trouve ou accepte la configuration DNS à cet instant. Il ne prouve pas qu’une route de production donnée signe les messages ou utilise le return-path prévu.

Pour un rejet 550 5.7.27, Gmail indique : « This message was blocked because it didn’t pass SPF authentication. Gmail requires bulk email senders to authenticate their email with SPF. » Pour 550 5.7.30, Gmail indique : « This message was blocked because it didn’t pass DKIM authentication. Gmail requires bulk email senders to authenticate their email with DKIM. » Associez le code au protocole avant de modifier les enregistrements.

5. Envoyez un vrai message par le même chemin

Envoyez un nouveau test par le système exact à l’origine du rejet. Utilisez une boîte où lire la source brute. Vérifiez le champ Authentication-Results ajouté par le destinataire, que la RFC 8601 définit comme une évaluation d’authentification avec un périmètre de confiance.

Cherchez les résultats SPF et DKIM, puis comparez l’identité qui réussit avec le domaine From visible. Si le message satisfait DMARC par DKIM, confirmez que le domaine d= est aligné sur le domaine From. Joignez une copie caviardée des en-têtes au registre des changements.

Quel effet sur DMARC ?

DMARC applique la politique du domaine From visible après évaluation de SPF ou DKIM aligné. Un expéditeur peut réussir SPF pour un domaine et DKIM pour un autre, et échouer quand même à DMARC si aucun des deux n’est aligné sur le domaine From visible.

Utilisez le test DMARC de Palisade pour inspecter l’enregistrement DMARC publié après le changement DNS. Une vérification publique ne montre pas si l’expéditeur réel utilise le return-path prévu, si Gmail a accepté un message précis, ni si le futur courrier sera aligné.

Si le rejet dit que la politique DMARC de votre domaine a refusé le message, comparez ses résultats SPF et DKIM alignés avant d’affaiblir la politique DMARC. La bonne correction peut être d’authentifier l’expéditeur manquant, pas de changer une politique qui protège le courrier légitime.

Valider la configuration

DNS public

Interrogez le serveur DNS faisant autorité et au moins un résolveur public pour les noms SPF, DKIM et DMARC exacts. Vérifiez que le nom complet n’a pas de suffixe de zone en double et que la réponse correspond au compte expéditeur choisi.

dig +short TXT yourdomain.com
dig +short TXT _dmarc.yourdomain.com
dig +short CNAME selector1._domainkey.yourdomain.com

Statut du fournisseur

Consultez l’état de vérification actuel du domaine chez le fournisseur d’envoi. En cas d’erreur, comparez l’enregistrement attendu avec la réponse DNS faisant autorité. Un voyant vert du fournisseur ne vaut pas un contrôle de message livré.

Inspectez un message livré

Envoyez un nouveau message par le même chemin et inspectez ses en-têtes bruts. Confirmez les résultats SPF et DKIM, les identités authentifiées concernées et l’alignement DMARC. Testez à part chaque route vraiment différente : marketing, transactionnel et courrier des boîtes hébergées.

Rapports DMARC

Quand les rapports agrégés arrivent, vérifiez que l’expéditeur y figure comme source authentifiée et alignée. L’agent DMARC de Palisade peut analyser les rapports agrégés, identifier les sources d’envoi et les problèmes d’alignement, et créer des tickets de correction priorisés. Il peut proposer l’étape de politique suivante si les preuves le justifient ; un humain les examine et applique tout changement de politique DNS.

Dépannage

Gmail renvoie 5.7.26 mais SPF semble publié

Comparez le texte 5.7.26 précis du rejet avec l’expéditeur d’enveloppe et l’IP d’envoi. Un SPF terminé par -all peut à juste titre rejeter une IP que votre fournisseur n’a pas autorisée. N’ajoutez au SPF existant que l’autorisation documentée du fournisseur, puis retestez la même route.

Gmail renvoie 5.7.29

Google documente 550 5.7.29 ainsi : « This message was blocked because it wasn’t sent over a TLS connection. Gmail requires all bulk email senders to use TLS/SSL for SMTP connections. » C’est un réglage de transport SMTP sur le vrai chemin d’envoi. Un changement d’authentification DNS ne peut ni prouver ni réparer la négociation TLS.

Gmail renvoie 5.7.25

Google documente 550 5.7.25 quand l’IP d’envoi n’a pas d’enregistrement PTR ou que son DNS direct ne renvoie pas à cette IP. Le DNS inverse relève en général du fournisseur de l’IP ou de la plateforme d’envoi. Demandez-lui de valider le PTR et le DNS direct confirmé de l’IP de production. La page 550 5.7.25 donne le texte exact du rejet et les contrôles à faire.

Gmail renvoie un message de réputation 5.7.1 ou 5.7.28

Voyez-y une preuve sur le message ou l’IP, pas un blocage permanent du domaine. Selon Google, le taux de spam est calculé chaque jour et les expéditeurs en masse dont le taux signalé par les utilisateurs dépasse 0,3 % sont exclus de l’atténuation. L’éligibilité revient après sept jours consécutifs sous 0,3 %, d’après sa FAQ des consignes expéditeur. Réduisez le courrier non désiré, examinez la source compromise ou peu performante, et retestez une fois le comportement d’envoi changé.

Gmail renvoie 421 4.7.28

Ne le classez pas comme un rejet. Google documente 421 4.7.28 ainsi : « Gmail has detected an unusual rate of email. To protect our users from spam, email has been temporarily rate limited. » Laissez faire les nouvelles tentatives conformes et examinez le signal de débit cité, qui peut viser une IP, un bloc réseau, un domaine SPF, DKIM ou d’URL, ou un Message-ID: répété.

Vérifiez le DMARC derrière le rejet Gmail

Inspectez l’enregistrement DMARC publié avant de modifier la politique qui a pu rejeter le courrier non aligné. Passez le domaine d’envoi dans le test DMARC de Palisade, puis comparez le résultat avec les preuves SPF, DKIM et domaine From visible du message rejeté.

Vérifier le DMARC

Une vérification DMARC publique ne peut ni prouver pourquoi Gmail a rejeté un message, ni réparer une configuration SPF ou DKIM, ni surveiller les dérives DNS, ni contrôler la décision de réputation privée de Gmail. Si le domaine a plusieurs expéditeurs de production, Palisade est un logiciel DMARC qui peut analyser les rapports agrégés et repérer les sources encore à corriger. Commencez avec Palisade.