Erreur SPF dans Gmail : pourquoi ?

Causes habituelles

Le service d’envoi manque dans la politique SPF évaluée

Une plateforme marketing, un CRM, un help desk, un service de facturation ou un relais sortant peut utiliser une IP que le domaine d’enveloppe n’autorise pas. Les consignes SPF de Google demandent d’identifier chaque service qui envoie pour un domaine et d’ajouter l’autorisation requise à son SPF.

C’est la cause probable seulement si l’en-tête montre l’IP d’un service attendu et que le fournisseur documente l’autorisation nécessaire. N’ajoutez pas une valeur include: parce qu’elle figure dans le SPF d’un autre domaine.

L’enregistrement modifié est celui du From visible

SPF évalue normalement smtp.mailfrom, pas l’adresse que les destinataires voient dans le champ From. Un message peut avoir From: notices@yourdomain.com alors que Gmail évalue smtp.mailfrom=bounce@mail.yourdomain.com.

Cela découle de la règle du protocole SPF. Ce n’est pas une correspondance documentée propre à Gmail. Si Gmail a évalué mail.yourdomain.com, examinez le TXT publié à ce nom. Modifier yourdomain.com ne répare pas une politique publiée sur son sous-domaine.

Plusieurs SPF coexistent

La RFC 7208 exige permerror quand une requête DNS renvoie plus d’un SPF. Cela arrive souvent quand un second TXT commençant par v=spf1 est ajouté au lieu de fusionner les mécanismes requis dans la politique existante.

Le nom évalué a besoin d’une seule politique SPF. D’autres TXT peuvent exister, mais pas d’autres SPF.

Le SPF dépasse la limite de requêtes DNS

La RFC 7208 limite l’évaluation SPF à 10 mécanismes et modificateurs à requête DNS. include, a, mx, exists, redirect et les requêtes imbriquées peuvent compter dans cette limite. La dépasser donne permerror.

Retirez les services qui n’envoient plus avant de modifier l’enregistrement. Si des changements fréquents d’expéditeurs compliquent son entretien, n’envisagez une gestion SPF qu’après avoir confirmé le nombre de requêtes et les vrais expéditeurs actifs. Cette approche exige toujours une validation DNS publique et ne prouve pas la livraison chez Gmail.

Échec temporaire de l’évaluation DNS

Un temperror signale une erreur temporaire de l’évaluation SPF. La RFC 7208 distingue erreurs temporaires et erreurs permanentes de politique SPF.

Vérifiez le DNS faisant autorité et les résolveurs publics avant de modifier l’enregistrement. Un résultat DNS public est une observation ponctuelle. Il ne prouve pas que Gmail a reçu la même réponse ni que l’expéditeur de production a utilisé le chemin de retour attendu.

Un transfert a changé l’IP de connexion

Google explique que transfert et listes de diffusion peuvent affecter l’authentification. SPF dépend de la dernière connexion SMTP : un relais peut faire voir à Gmail son IP au lieu de l’IP autorisée de l’expéditeur d’origine.

Le transfert reste une hypothèse avant de comparer la route d’origine et la copie reçue par Gmail. Après un échec SPF sur un message transféré, DKIM peut encore fournir une authentification DMARC alignée.

Comment diagnostiquer l’échec ?

1. Conservez la source du message reçu par Gmail

Ouvrez la source du message original dans Gmail et enregistrez les en-têtes complets. Notez la ligne Authentication-Results exacte, Return-Path, le domaine From visible, smtp.mailfrom, smtp.helo, les résultats SPF, DKIM et DMARC, le Message-ID et l’heure d’envoi.

Utilisez le résultat ajouté par Gmail à la réception. Ne partez pas d’une capture du message affiché ni d’une copie transférée par un tiers : le transfert peut créer un autre chemin SMTP.

2. Réunissez les preuves SPF

Gardez ces éléments ensemble avant tout changement DNS ou de plateforme d’envoi :

• Domaine From visible : le domaine du champ From: que voit le destinataire.
• Domaine d’enveloppe SPF : le domaine ou l’adresse de smtp.mailfrom, ou l’identité HELO si le chemin de retour était vide.
• Résultat exact : le diagnostic de confiance complet spf=pass, spf=fail, spf=softfail, spf=temperror ou spf=permerror.
• SPF public du nom évalué : le TXT au nom d’hôte exact que Gmail a évalué.
• Chaîne d’include : chaque cible include: ou redirect= active nécessaire à la décision d’autorisation.
• Décompte des requêtes : les termes à requête DNS et les chemins imbriqués, si l’on soupçonne permerror ou la limite.
• Preuves du message : Message-ID, heure d’envoi, IP de connexion indiquée dans le résultat, et service d’envoi ou relais censé utiliser cette route.
• Test contrôlé : un message neuf via les mêmes application, chemin de retour, relais et chemin destinataire.

yourdomain.com. IN TXT "v=spf1 include:spf.sender.example -all"
spf.sender.example. IN TXT "v=spf1 ip4:192.0.2.10 -all"

Le fournisseur doit documenter les vraies valeurs d’autorisation. Examinez le SPF public avec le test SPF Palisade une fois le domaine évalué identifié. Une requête publique ne peut pas lire le message brut reçu par Gmail, prouver que l’expéditeur a utilisé cet enregistrement, suivre les changements ni expliquer la décision privée de Gmail.

3. Reliez l’IP de connexion au vrai chemin d’envoi

Comparez l’IP citée dans le diagnostic SPF de Gmail avec l’application, le relais sortant et l’IP ou le mécanisme include documenté pour ce flux. Vérifiez si le service utilise un chemin de retour personnalisé ou un sous-domaine de rejet distinct.

Si l’IP appartient à un service attendu, comparez son autorisation documentée avec la politique SPF du domaine évalué. Si l’IP est inattendue, examinez la configuration du service, le routage ou l’accès au compte avant de modifier le DNS.

4. Vérifiez le DNS et les requêtes SPF

Interrogez le nom évalué via ses serveurs DNS faisant autorité et au moins un résolveur public. Confirmez qu’un seul SPF utilisable commence par v=spf1 et qu’aucun SPF en double ne subsiste.

Suivez chaque terme à requête DNS, y compris les include: imbriqués. Un SPF peut sembler court alors que ses include épuisent le budget de requêtes. Notez le chemin réellement évalué, sans estimer d’après les seuls mécanismes visibles.

5. Vérifiez DMARC à part

SPF et DMARC sont des contrôles distincts. DMARC exige qu’un identifiant authentifié s’aligne sur le domaine du champ From visible. Un SPF réussi pour mail.yourdomain.com peut quand même échouer à DMARC pour yourdomain.com en alignement SPF strict. Un DKIM réussi et aligné peut faire réussir DMARC quand SPF échoue.

Pour le lien entre protocoles, voir la rubrique sur l’authentification. Si Gmail signale un problème de transport et non un résultat SPF, voir pourquoi Gmail signale des erreurs TLS.

Comment corriger ?

Réparez un SPF manquant

Si le nom évalué n’a aucun SPF, publiez une politique qui autorise seulement ses chemins d’envoi confirmés. Prenez le mécanisme réel ou les consignes de chemin de retour dans la documentation du fournisseur.

Ne remplacez pas un SPF racine qui fonctionne par une politique de sous-domaine, et n’ajoutez pas de second TXT v=spf1. Un changement DNS peut couper les e-mails d’un autre expéditeur actif.

La réparation change l’authentification SPF. Elle ne garantit pas la livraison Gmail et ne règle pas un autre échec d’alignement DMARC.

Corrigez un permerror de requêtes SPF

Si les preuves montrent plus de 10 termes à requête DNS, retirez d’abord les include inactifs et les mécanismes obsolètes. Ne consolidez que si les fournisseurs documentent une configuration prise en charge. Retestez chaque expéditeur restant, y compris les flux transactionnels moins fréquents.

N’assouplissez pas la politique DMARC en réponse. Elle change l’application demandée, mais ne réduit pas les requêtes SPF et ne répare pas un permerror SPF.

Autorisez la source d’envoi confirmée

Si l’IP de connexion vue par Gmail appartient à un fournisseur attendu dont l’autorisation SPF documentée manque, ajoutez-la à l’unique SPF du domaine d’enveloppe évalué. Conservez les mécanismes requis existants.

Si la source est inconnue, arrêtez-vous avant de l’autoriser. Ajouter un relais inconnu au SPF élargit qui peut envoyer avec ce domaine d’enveloppe.

Examinez un SPF réussi avec un autre échec

Si Gmail indique spf=pass, SPF a autorisé l’IP de connexion pour l’identité évaluée. Vérifiez si cette identité s’aligne sur le domaine From visible pour DMARC, puis examinez les résultats DKIM et DMARC. Le SPF réussi n’établit pas que Gmail placera le message en boîte de réception, et n’explique pas un problème de TLS, de contenu, de réputation ou de politique du destinataire.

Pour d’autres erreurs de fournisseur, voir comment résoudre les codes d’erreur Yahoo et Gmail.

Comment valider la réparation ?

Envoyez un nouveau message via les mêmes application, expéditeur d’enveloppe, relais sortant, contenu et chemin destinataire Gmail. Vérifiez le résultat SPF attendu dans le nouvel en-tête Authentication-Results du destinataire, et notez l’IP de connexion.

Validez quatre couches séparément :

• DNS : vérifiez que le nom évalué a un seul SPF public correct, via le DNS faisant autorité et un résolveur public.
• Fournisseur : confirmez que le service d’envoi indique l’état attendu du domaine authentifié ou du chemin de retour, s’il fournit ce statut.
• Message : confirmez que le nouveau message reçu par Gmail a le résultat SPF attendu pour l’identité smtp.mailfrom prévue.
• DMARC : lisez les rapports agrégés quand les données s’accumulent, pour confirmer que source et schéma d’alignement restent compris.

Vérifiez le SPF derrière le résultat Gmail

Quand l’en-tête de confiance identifie le domaine d’enveloppe évalué, vérifiez ce SPF public avec Palisade.

Commencez avec Palisade pour lire les données des rapports agrégés DMARC, identifier les sources d’envoi et les problèmes d’authentification ou d’alignement, et créer des tickets de remédiation priorisés une fois le chemin SPF réparé. Palisade ne contrôle pas le filtrage privé de Gmail, ne change pas la politique DMARC sans revue humaine et ne prouve pas que les futurs messages s’authentifieront.