DMARC : les exigences de Google, Yahoo et Microsoft expliquées

Depuis février 2024, Gmail et Yahoo exigent des expéditeurs qu'ils authentifient leurs e-mails. Microsoft a suivi en mai 2025 pour Outlook.com, et Google a durci l'application de ses règles fin 2025, avec des refus de messages de plus en plus fréquents. Pour une PME, une boutique en ligne ou une agence, la question n'est plus de savoir s'il faut configurer SPF, DKIM et DMARC, mais comment le faire sans bloquer ses propres e-mails. Voici les exigences exactes, puis une méthode pas à pas, de p=none jusqu'à p=reject.

Ce qu'exigent Google, Yahoo et Microsoft

Gmail : des règles pour tous, et davantage pour les gros volumes

Depuis le 1er février 2024, Google impose à tous les expéditeurs écrivant à des adresses Gmail personnelles :

• SPF ou DKIM configuré pour le domaine d'envoi ;
• des enregistrements DNS directs et inverses (PTR) valides pour les adresses IP d'envoi ;
• une connexion TLS pour la transmission ;
• un taux de spam signalé inférieur à 0,3 % dans Postmaster Tools (Google recommande de rester sous 0,1 %) ;
• des messages conformes au format RFC 5322.

Les expéditeurs de masse, c'est-à-dire ceux qui envoient plus de 5 000 messages par jour vers des comptes Gmail personnels, doivent en plus :

• configurer SPF et DKIM ;
• publier un enregistrement DMARC, la politique p=none étant acceptée ;
• aligner le domaine de l'en-tête From: avec le domaine SPF ou le domaine DKIM ;
• proposer le désabonnement en un clic dans les messages marketing, avec un lien visible dans le corps du message.

Google considère qu'un domaine ayant atteint le seuil des expéditeurs de masse le reste durablement, même si ses volumes baissent ensuite. Depuis novembre 2025, Google a annoncé renforcer l'application de ces règles : les messages non conformes peuvent être temporairement ou définitivement refusés, et non plus seulement classés en spam.

Yahoo : des exigences comparables

Yahoo a annoncé des règles similaires à la même période : authentification pour tous, DMARC et désabonnement en un clic pour les gros expéditeurs, taux de plainte à maintenir sous 0,3 %. Si vous respectez les exigences de Gmail, vous couvrez l'essentiel de celles de Yahoo.

Microsoft Outlook : rejet depuis le 5 mai 2025

Microsoft applique depuis le 5 mai 2025 des exigences aux domaines qui envoient plus de 5 000 e-mails par jour vers ses services grand public (outlook.com, hotmail.com, live.com) : SPF valide, signature DKIM valide, et DMARC publié avec au minimum p=none, aligné sur SPF ou DKIM. Microsoft avait d'abord annoncé un classement en courrier indésirable, puis a opté pour le rejet pur et simple, avec ce message :

550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.

Et si j'envoie moins de 5 000 e-mails par jour ?

Les règles « pour tous » s'appliquent quand même chez Gmail, et une configuration complète protège aussi votre domaine contre l'usurpation : sans DMARC en mode strict, n'importe qui peut envoyer des e-mails qui semblent venir de contact@votre-entreprise.fr. Les seuils ne sont pas une raison pour attendre.

Étape 1 : inventorier tout ce qui envoie des e-mails en votre nom

C'est l'étape la plus négligée, et la cause de la plupart des blocages. Listez chaque source :

• la messagerie principale (Google Workspace, Microsoft 365, messagerie de l'hébergeur) ;
• le site web : formulaires de contact et e-mails transactionnels de WordPress, PrestaShop ou Shopify ;
• l'outil de newsletter ;
• le logiciel de facturation, le CRM, l'outil de support client ;
• les serveurs ou scripts internes (alertes, sauvegardes, impression).

Un formulaire de contact qui envoie via la fonction mail() du serveur web, depuis une adresse IP qui ne figure nulle part dans votre SPF, est un grand classique.

Étape 2 : SPF, la liste des serveurs autorisés

SPF est un enregistrement TXT publié sur le domaine utilisé dans l'adresse de retour (Return-Path). Vérifiez l'existant :

dig TXT exemple.fr +short | grep spf1

Exemple pour une entreprise sous Google Workspace qui envoie aussi depuis un serveur dédié :

exemple.fr.  3600  IN  TXT  "v=spf1 include:_spf.google.com ip4:203.0.113.10 ~all"

Les règles à respecter :

• Un seul enregistrement SPF par domaine. Deux enregistrements commençant par v=spf1 produisent une erreur et SPF échoue.
• Dix requêtes DNS maximum lors de l'évaluation (chaque include, a, mx, redirect compte, y compris les include imbriqués). Au-delà, SPF renvoie une erreur permanente.
• Jamais +all, qui autorise la terre entière.
• ~all (échec léger) est un bon point de départ ; -all est plus strict. Avec DMARC en place, c'est surtout la politique DMARC qui décide du sort des messages.

Étape 3 : DKIM, la signature cryptographique

DKIM signe chaque message avec une clé privée ; la clé publique est publiée dans le DNS sous un sélecteur. Activez DKIM dans chaque service d'envoi : chacun vous fournit un enregistrement TXT ou CNAME à publier. Quelques repères :

• Google Workspace utilise par défaut le sélecteur google ;
• Microsoft 365 utilise deux enregistrements CNAME, selector1._domainkey et selector2._domainkey ;
• les outils de newsletter et de transactionnel ont leurs propres sélecteurs.

dig TXT google._domainkey.exemple.fr +short
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Préférez des clés de 2048 bits. Envoyez-vous ensuite un message et vérifiez dans les en-têtes qu'il porte dkim=pass avec header.d=exemple.fr, et non le domaine du prestataire.

Étape 4 : comprendre l'alignement

DMARC ne se contente pas d'un SPF ou d'un DKIM valide : il exige que le domaine validé corresponde au domaine visible dans From:.

• Alignement SPF : le domaine du Return-Path doit correspondre au domaine du From:.
• Alignement DKIM : le domaine d= de la signature doit correspondre au domaine du From:.

En mode relâché (par défaut), un sous-domaine suffit : d=mail.exemple.fr est aligné avec From: contact@exemple.fr. Un outil de newsletter qui signe avec son propre domaine passe DKIM, mais n'est pas aligné : il faut configurer un domaine d'envoi personnalisé chez ce prestataire. DMARC passe si au moins l'un des deux mécanismes est valide et aligné. DKIM est le plus robuste, car il survit aux transferts automatiques qui cassent souvent SPF.

Étape 5 : publier DMARC en mode observation

_dmarc.exemple.fr.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@exemple.fr"

p=none ne change rien à la distribution : il demande aux destinataires de vous envoyer des rapports agrégés (rua), au format XML, qui listent les adresses IP ayant envoyé des e-mails en votre nom et le résultat SPF, DKIM et DMARC de chacune. Si les rapports doivent arriver sur un autre domaine, ce domaine doit publier une autorisation, par exemple exemple.fr._report._dmarc.rapports-dmarc.fr avec la valeur v=DMARC1.

Vérifiez la publication :

dig TXT _dmarc.exemple.fr +short

Étape 6 : analyser les rapports et corriger

Pendant quelques semaines, idéalement un cycle complet d'activité (facturation mensuelle, newsletter, relances), lisez les rapports. Pour chaque source en échec :

1. Source légitime (votre outil de facturation, par exemple) : ajoutez-la à SPF ou, mieux, configurez DKIM avec votre domaine chez ce prestataire.
2. Source inconnue qui usurpe votre domaine : c'est précisément ce que DMARC bloquera ensuite.
3. Transferts et listes de diffusion : des échecs ponctuels sont normaux ; ils concernent surtout SPF.

Étape 7 : passer à quarantine, puis à reject

Quand toutes les sources légitimes passent DMARC, durcissez la politique :

"v=DMARC1; p=quarantine; rua=mailto:dmarc@exemple.fr"

p=quarantine demande de placer les messages non conformes en courrier indésirable. Continuez à surveiller les rapports, puis passez à :

"v=DMARC1; p=reject; rua=mailto:dmarc@exemple.fr"

p=reject demande de refuser les messages non conformes : l'usurpation directe de votre domaine devient inopérante chez les destinataires qui appliquent DMARC. Pensez aussi à la balise sp=, qui fixe la politique des sous-domaines, et protégez les domaines qui n'envoient aucun e-mail avec v=spf1 -all et p=reject.

Beaucoup de guides recommandent une montée progressive avec la balise pct. Notez que la nouvelle version de la spécification DMARC (RFC 9989, publiée en 2026) retire cette balise, appliquée de façon inégale par les destinataires. Mieux vaut progresser par paliers de politique, avec une analyse des rapports à chaque étape.

Les autres exigences à ne pas oublier

• Désabonnement en un clic pour les messages marketing : en-têtes List-Unsubscribe et List-Unsubscribe-Post: List-Unsubscribe=One-Click, que les outils de newsletter gèrent en général.
• PTR : si vous envoyez depuis votre propre serveur, dig -x 203.0.113.10 +short doit renvoyer un nom qui, lui-même, résout vers cette adresse IP.
• Réputation : vérifiez que vos adresses IP d'envoi ne figurent pas sur des listes noires.

Checklist récapitulative

• Toutes les sources d'envoi sont inventoriées.
• Un seul enregistrement SPF, moins de dix requêtes DNS, pas de +all.
• DKIM actif avec votre domaine sur chaque service d'envoi.
• DMARC publié avec une adresse rua réellement lue.
• Rapports analysés, sources légitimes alignées.
• Passage à p=quarantine, puis à p=reject.
• Domaines inactifs protégés.
• Désabonnement en un clic et PTR en place.

Ces enregistrements vivent dans votre zone DNS et peuvent être modifiés ou supprimés lors d'une migration sans que personne ne s'en aperçoive ; c'est l'un des risques décrits dans notre article sur les attaques DNS discrètes.

Contrôlez votre domaine en une minute

Avant de toucher à quoi que ce soit, faites un état des lieux avec notre outil gratuit de sécurité e-mail : il analyse vos enregistrements SPF, DKIM et DMARC et signale les erreurs courantes. Vous saurez immédiatement à quelle étape de ce guide vous en êtes. Domains Defender surveille ensuite ces enregistrements en continu et vous prévient s'ils changent ou se dégradent.