Defaults.Exposed › Corrections › Guides

DKIM passe mais DMARC échoue : le piège de la signature par défaut gappssmtp.com / onmicrosoft.com (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.

Votre courrier passe DKIM avec la signature par défaut du prestataire — d= se terminant par gappssmtp.com (Google Workspace) ou onmicrosoft.com (Microsoft 365) — mais ce domaine ne correspond pas à votre domaine From, donc DMARC n’obtient aucun pass aligné. Activez la signature sur votre propre domaine pour corriger. Sur 12 145 313 domaines autorisant les serveurs mail de Google, seuls 18,5 % appliquent DMARC, selon le recensement Defaults.Exposed portant sur 261 086 232 domaines évalués.

Le correctif est l’un des plus propres de l’authentification e-mail : activer la signature DKIM sur votre domaine. Sur Google Workspace, c’est l’écran « Authentifier les e-mails » de la console d’administration — générez la clé, publiez un enregistrement TXT, activez. Sur Microsoft 365, c’est la page DKIM du portail Defender — publiez deux CNAME de sélecteurs, activez. Vingt minutes de travail, et DMARC obtient enfin le pass aligné qu’il attendait.

Pourquoi DKIM passe-t-il mais DMARC échoue quand même ?

Parce que DMARC ne demande pas « y a-t-il une signature DKIM valide ? » — il demande « y a-t-il une signature DKIM valide pour le domaine de l’en-tête From ? » Cette seconde condition s’appelle l’alignement, et c’est tout l’objet de DMARC : prouver que le domaine que votre destinataire voit est celui qui a signé.

D’origine, Google Workspace signe votre courrier avec un domaine comme yourdomain-com.20230601.gappssmtp.com (l’horodatage varie par domaine) et Microsoft 365 signe avec yourtenant.onmicrosoft.com. Les deux signatures sont cryptographiquement valides — les vérificateurs DKIM disent pass — mais le domaine d= appartient à Google ou Microsoft, pas à vous. Même sous l’alignement souple de DMARC, qui n’exige que la correspondance des domaines organisationnels, gappssmtp.com n’est pas yourdomain.com. Pas de correspondance, pas de pass aligné, et si SPF ne s’aligne pas non plus (souvent il ne le peut pas — les serveurs de réception évaluent SPF sur le domaine du Return-Path, pas sur l’en-tête From, et le transfert le casse entièrement), DMARC échoue.

C’est le piège caractéristique des défauts de prestataire : le défaut vous donne la délivrabilité, pas la protection — l’alignement est le tour de clé manquant. Le recensement montre combien d’expéditeurs s’arrêtent au défaut : sur les 12 145 313 domaines qui autorisent les serveurs mail de Google via _spf.google.com (sur 138 927 207 éditeurs SPF dans le monde), seuls 18,5 % appliquent DMARC. Le tableau côté Microsoft a la même forme : 10 205 070 domaines autorisent spf.protection.outlook.com, 85,0 % portent l’enregistrement SPF strict que la configuration M365 leur remet — et seuls 21,7 % appliquent DMARC. Comparaison complète dans notre classement SPF des fournisseurs d’e-mail.

Le piège est invisible au quotidien : le courrier arrive, les tests de boîte de réception semblent bons, rien n’échoue — jusqu’à ce que vous publiiez une politique DMARC et que votre propre courrier commence à y échouer. Notre scan gratuit révèle exactement cette faille.

Comment repérer le piège de la signature par défaut dans Authentication-Results ?

Ouvrez un message que vous avez envoyé (vers une boîte Gmail ou Outlook), affichez la source brute/originale, et trouvez l’en-tête Authentication-Results. L’indice est un pass DKIM avec le mauvais d= — un exemple reçu par Gmail ressemble à :

Authentication-Results: mx.google.com;
       dkim=pass [email protected];
       spf=pass smtp.mailfrom=yourdomain.com;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

Lisez-le comme trois questions :

Sur le courrier reçu par Microsoft, la même histoire apparaît comme dkim=pass (signature was verified) header.d=yourtenant.onmicrosoft.com accompagné de compauth=fail — le schéma couvert dans le guide des rejets Outlook.

Si votre en-tête montre au contraire à la fois dkim=pass et spf=pass avec un échec DMARC, vous êtes dans le cas d’alignement plus large — le guide DMARC échoue mais SPF et DKIM passent détaille l’alignement souple contre strict.

Comment activer la signature DKIM sur mon propre domaine ?

1. Lancez le scan gratuit sur defaults.exposed avant de toucher à quoi que ce soit. Il montre si votre domaine a un DKIM aligné, quelle est réellement votre politique DMARC, et si autre chose (SPF, syntaxe de l’enregistrement DMARC) vous bloquera encore après ce correctif — pour faire tout le travail en une fois.
2. Identifiez avec quel défaut vous signez. Vérifiez header.d= dans Authentication-Results comme ci-dessus : gappssmtp.com signifie défaut Google Workspace, onmicrosoft.com signifie défaut Microsoft 365.
3. Google Workspace : générez et publiez votre propre clé. Dans la console d’administration, allez dans Applications → Google Workspace → Gmail → Authentifier les e-mails, sélectionnez votre domaine et cliquez sur Générer un nouvel enregistrement (2048 bits sauf si votre hébergeur DNS ne peut pas le stocker). Publiez l’enregistrement TXT fourni à google._domainkey.yourdomain.com, attendez le DNS (jusqu’à 48 heures), puis — l’étape que l’on rate — cliquez sur Démarrer l’authentification. Générer l’enregistrement ne fait rien tant que vous n’activez pas la signature. Pas-à-pas complet : configurer DKIM sur Google Workspace.
4. Microsoft 365 : publiez les deux CNAME de sélecteurs et activez. Dans le portail Defender, allez dans Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM, sélectionnez votre domaine personnalisé et créez les clés. Publiez les deux CNAME — selector1._domainkey et selector2._domainkey, pointant vers les cibles que Microsoft vous montre (copiez les cibles exactes du portail — les domaines activés avant mai 2025 se terminent par le .onmicrosoft.com de votre tenant ; les plus récents par .dkim.mail.microsoft) — puis activez la signature. Deux sélecteurs, ce n’est pas optionnel : Microsoft fait tourner les clés entre eux. Pas-à-pas complet : configurer DKIM sur Microsoft 365.
5. Vérifiez la nouvelle signature. Envoyez un message frais vers une boîte externe et revérifiez Authentication-Results : dkim=pass doit désormais afficher header.d=yourdomain.com. Si votre panneau DNS a ajouté automatiquement votre zone à la cible du CNAME ou mutilé la longue valeur TXT, la signature ne basculera pas — ce sont les caprices des panneaux, pas le prestataire, qui causent la plupart des échecs ici.
6. Relancez le scan et faites fructifier le pass aligné. Confirmez que le scan montre un DKIM aligné, puis servez-vous-en : une politique DMARC à p=none ne protège rien. Sur l’ensemble des 261 086 232 domaines évalués, seuls 10,59 % appliquent DMARC (données au 2026-06-29) — le DKIM aligné est ce qui rend le resserrage sûr. Commencez par comment corriger DMARC.

Activer le DKIM personnalisé va-t-il casser quelque chose ?

Non — c’est le rare correctif d’authentification e-mail quasiment sans rayon d’impact : le courrier qui partait avec la signature par défaut part simplement avec une meilleure, et le prestataire continue de gérer les clés (Microsoft alterne automatiquement entre les deux sélecteurs). Le vrai mode d’échec est de le faire à moitié — publier le TXT de Google sans jamais cliquer sur Démarrer l’authentification, ou publier un seul sélecteur M365 au lieu des deux. Et ne supprimez pas les enregistrements DNS plus tard « pour faire du ménage » ; la signature s’arrête dès que la clé disparaît.

Une précision de périmètre : ceci corrige le courrier envoyé via Google ou Microsoft. Les outils de newsletter et les CRM signent aussi avec leurs propres défauts, et chacun a besoin de son propre DKIM personnalisé activé — ce schéma, et les règles Gmail pour expéditeurs en masse qui l’exigent désormais, sont couverts dans le guide 550-5.7.26.

Questions fréquentes

DKIM affiche « pass » sur tous les outils de test — pourquoi faudrait-il corriger quoi que ce soit ? Parce que les outils répondent à une question plus étroite que DMARC. La signature est valide — mais c’est celle de gappssmtp.com ou d’onmicrosoft.com, pas la vôtre, donc elle ne compte pour rien dans l’alignement DMARC. C’est pourquoi tant d’expéditeurs s’arrêtent au défaut : sur 12 145 313 domaines autorisant Google, seuls 18,5 % appliquent DMARC (données au 2026-06-29).

L’alignement DMARC souple laisse-t-il passer la signature par défaut ? Non. L’alignement souple n’assouplit la correspondance qu’aux domaines organisationnels — mail.yourdomain.com s’aligne avec yourdomain.com. Le domaine organisationnel de la signature par défaut est gappssmtp.com ou onmicrosoft.com, qui n’a rien de commun avec le vôtre. Aucun mode d’alignement ne sauve un d= tiers.

La signature gappssmtp.com / onmicrosoft.com est-elle mauvaise ? Dois-je la retirer ? Elle n’est pas mauvaise — elle garantit que votre courrier porte une signature valide, ce qui aide le filtrage anti-spam. Elle n’est simplement pas la vôtre. Vous ne la retirez pas ; vous la remplacez en activant la signature sur votre domaine.

Mon domaine est sur Microsoft 365 avec un SPF strict — suis-je déjà couvert ? Probablement pas : cet enregistrement strict est le défaut M365 qui fait son unique travail. Sur 10 205 070 domaines autorisant spf.protection.outlook.com, 85,0 % ont un SPF strict mais seuls 21,7 % appliquent DMARC (données au 2026-06-29). SPF casse aussi au transfert, car il est évalué sur le Return-Path plutôt que sur l’en-tête From — le DKIM aligné est la jambe qui survit, et c’est exactement pourquoi ce correctif compte.

Combien de temps prend le correctif ? Le travail en console se compte en minutes par prestataire. Le DNS est l’attente : Google demande de compter jusqu’à 48 heures avant de démarrer l’authentification ; les CNAME de Microsoft sont généralement actifs en quelques heures. Prévoyez une journée ouvrée de bout en bout, essentiellement de l’attente.

Envoyez le rapport au propriétaire

Si vous corrigez ceci pour un client ou votre employeur, bouclez la boucle avec des preuves. Relancez le scan gratuit une fois la nouvelle signature en production et transmettez le rapport noté au chef d’entreprise : daté, en langage clair, montrant DKIM aligné avec son domaine. C’est la pièce pour le renouvellement de la cyberassurance et le prochain questionnaire de sécurité fournisseur — la preuve que le domaine s’authentifie comme lui-même, pas comme un sous-locataire de gappssmtp.com.

Vérifiez votre alignement DKIM gratuitement

Voyez si votre courrier signe comme votre propre domaine — et exactement quoi corriger — en privé, visible du propriétaire uniquement.

Vérifiez votre domaine → · DMARC échoue mais SPF et DKIM passent → · Corriger DKIM → · Configurer DKIM sur Google Workspace → · Données agrégées uniquement. Données stockées et traitées dans l’UE.