Un domaine qui publie SPF et DKIM, avec une politique DMARC stricte, peut-il quand même finir en quarantaine chez Gmail ? Oui. La console d’admin Google Workspace contient des réglages qui court-circuitent cette authentification après coup, sans jamais remonter dans Postmaster Tools. Une règle de content compliance qui modifie le sujet ou le corps d’un message après la signature DKIM invalide cette signature. Même un SPF et un DKIM bien configurés en amont n’y changent rien. Un score seedlist qui chute après une mise à jour Gmail sans explication visible trouve souvent son origine dans ces réglages de la console admin plutôt que dans le DNS.
Content compliance : la règle qui casse la signature DKIM après coup
Une règle de content compliance ajoute un bandeau [Confidentiel] en tête du sujet, pour respecter une politique de classification interne. Le message part avec ce bandeau. Sa signature DKIM a été calculée sur le sujet original, avant modification. Google documente ce comportement sans en tirer la conséquence deliverability. Le paramètre se configure dans Apps > Google Workspace > Gmail > Compliance. Il réécrit un en-tête ou reroute le message ; il peut aussi ajouter l’en-tête X-gm-spam selon des mots-clés ou motifs définis par l’administrateur. Le problème apparaît quand cette modification touche le sujet ou le corps du message, deux champs couverts par la signature DKIM calculée en amont. L’alignement DMARC échoue alors côté DKIM. Si le SPF n’est pas non plus strictement aligné, le rapport agrégé affiche un policy_evaluated avec une disposition passée en quarantine ou reject, visible dans n’importe quel parseur de rapports comme parsedmarc. Sans enregistrement DMARC publié du tout, aucune évaluation d’alignement n’a lieu : la rupture de signature DKIM ne remonte nulle part, faute de politique à appliquer. Le résultat pratique : un domaine qui affiche 100% de conformité DKIM dans Postmaster Tools continue de perdre en placement. La règle de compliance modifie le message après le calcul de la signature et rien dans l’admin console ne signale cette collision entre les deux.
Default routing et le catch-all qui masque les rejets 550 5.1.1
Le default routing gère la livraison par défaut de l’organisation ; le paramètre Routing crée des règles spécifiques ou surcharge ce comportement par défaut, sur quatre catégories de flux : entrant, sortant, interne-émis, interne-reçu. Google précise qu’un changement de règle peut prendre jusqu’à 24 heures pour se propager, un délai que peu d’administrateurs anticipent avant de tester une modification en production. Le piège fréquent tient à la relance sortante configurée via un smart host interne pour le courrier applicatif : si ce relais sort avec une adresse IP dont le PTR record (reverse DNS) ne correspond pas au nom d’hôte annoncé, une partie du trafic revient en rejet 550 5.1.1 user unknown côté serveur distant, un code que le catch-all de la boîte de réception masque totalement à l’utilisateur final. L’administrateur ne voit rien remonter, sauf dans les logs SMTP bruts.
DKIM key rotation oubliée dans Authenticate email
Deux minutes suffisent pour générer une clé DKIM depuis Apps > Google Workspace > Gmail > Authenticate email. Google ne propose aucune rotation planifiée par défaut. Google recommande une clé 2048 bits quand le fournisseur DNS l’accepte, contre 1024 bits en repli. Une clé publiée en 2019 sur un domaine repris depuis par une nouvelle équipe technique continue de signer sans erreur en 2026, y compris si le sélecteur date d’un ancien prestataire d’emailing résilié depuis. La clé fonctionne. Sa robustesse cryptographique n’a pas suivi les recommandations publiées entre-temps.
Allowlist Gmail et bypass spam filter : le point aveugle credential stuffing
Certaines organisations ajoutent leur propre plage d’IP sortante à une liste d’exception, pour éviter que le trafic interne ne passe deux fois par les filtres. Une règle de compliance peut aussi porter l’option bypass spam filter, pensée à l’origine pour fiabiliser des flux applicatifs internes critiques. Combinée à un compte compromis par credential stuffing, cette même règle laisse passer l’expédition de spam ou de phishing sans aucun filtrage, puisque le message emprunte exactement le chemin que l’administrateur a explicitement dispensé de contrôle. La compromission ne se voit dans aucun tableau de bord Workspace tant que la volumétrie reste sous les seuils d’alerte par défaut.
Emplacements dans la console et impact sur la délivrabilité
Chaque protocole d’authentification vit dans un sous-menu distinct de l’admin console, avec un niveau de risque propre en cas d’oubli.
| Protocole | Emplacement admin console | Impact si mal configuré |
|---|---|---|
| SPF | Géré au niveau du DNS, hors admin console (enregistrement TXT chez le registrar) | Soft fail toléré par Gmail mais rejeté par un nombre croissant de MTA tiers |
| DKIM | Apps > Google Workspace > Gmail > Authenticate email | Signature invalidée par toute réécriture de contenu en aval (content compliance, footer automatique) |
| DMARC | DNS uniquement, avec le tag pct= pour cadrer le pourcentage de mail soumis à la politique | Un pct= trop bas laisse passer le trafic frauduleux pendant la phase de ramp-up vers p=reject |
| BIMI | Apps > Google Workspace > Gmail > Branding | Nécessite DMARC en p=quarantine ou reject déjà actif, sinon le logo n’apparaît jamais |
| MTA-STS | DNS et fichier de policy hébergé, hors admin console | Absent chez la majorité des PME, ce qui expose au downgrade TLS en interception active |
La mise à jour Gmail de décembre 2025 et la chute des scores seedlist
« La mise à jour Gmail de décembre 2025 a changé quelque chose et nos scores seedlist ont chuté sans explication » : ce constat, remonté par plusieurs administrateurs sur les forums postmaster, se recoupe rarement avec une cause DNS. Google ne publie pas de changelog détaillé de ses ajustements de filtrage. La documentation officielle reste en revanche explicite sur les seuils qui déclenchent une dégradation :
Pour respecter les consignes d’expéditeur, maintenez votre taux de plainte signalé par l’utilisateur sous 0,1% et évitez qu’il n’atteigne 0,3% ou plus.
Ce texte date de la mise à jour des consignes bulk sender de Google, appliquées depuis février 2024 à tout domaine expédiant plus de 5000 messages par jour à des comptes Gmail personnels, avec obligation de désabonnement en un clic conforme à la RFC 8058 depuis juin 2024, traité sous 48 heures maximum : l’exigence vient directement de Gmail et de Yahoo. Validity, dont les outils alimentent une bonne part des seedlists du marché, documente ce point de friction parmi les plus fréquents dans les signalements spam qui remplacent un clic de désinscription raté. Un audit de liste avant l’envoi limite justement ce risque en amont : écarter les adresses obsolètes qui génèrent des 550 5.1.1 avant qu’elles n’atteignent une règle de content compliance et ne faussent le complaint rate, plutôt que de le découvrir après coup sur le tableau seedlist. Le rapprochement entre un score qui chute et une modification récente de la console mérite d’être vérifié avant d’incriminer le DNS.
Ce qui limite ce diagnostic
Ce mécanisme explique une part significative des chutes de score inexpliquées. Pas toutes. Une Suppression List mal synchronisée entre plusieurs outils d’envoi produit exactement les mêmes symptômes sans qu’aucune règle de compliance ne soit en cause. Rien dans l’admin console ne permet de trancher entre les deux sans croiser les en-têtes du message rejeté avec l’historique des règles actives à la date d’envoi.
Les serveurs de Google vérifient l’alignement DMARC en quelques millisecondes. La règle de compliance qui casse cet alignement, elle, peut dormir des années dans la console avant qu’un administrateur la retrouve.
