Délivrabilité email : SPF, DKIM, DMARC et exigences de Gmail, Yahoo et Outlook

La délivrabilité email désigne la part de vos messages qui arrive en boîte de réception. Depuis 2024, elle obéit à des règles écrites : Gmail et Yahoo, puis Outlook.com, classent en indésirables ou refusent les messages dont le domaine n'est pas authentifié. Un devis, une relance de facture ou une lettre d'information qui part en courrier indésirable n'existe pas pour son destinataire. Ce guide rassemble les exigences des trois messageries, le réglage de SPF, DKIM et DMARC dans le DNS de votre domaine, et ce qui a changé en 2026 avec la nouvelle norme DMARC. Les règles citées viennent des pages d'aide des messageries et des RFC de l'IETF, listées en fin d'article.

Calendrier des exigences

Microsoft avait d'abord annoncé un classement en courrier indésirable. La version à jour de son annonce indique un rejet avec le code 550 5.7.515, en vigueur depuis le 5 mai 2025.

Qui est concerné

Les trois messageries ne fixent pas le même seuil.

• Gmail. Tout expéditeur qui écrit à des comptes Gmail personnels a des obligations de base. Un expéditeur en masse envoie près de 5 000 messages ou plus en 24 heures vers ces comptes ; les envois d'un même domaine principal s'additionnent (2 500 messages depuis exemple.fr et 2 500 depuis promo.exemple.fr font un expéditeur en masse), et ce statut devient définitif dès qu'il est atteint. Les messages reçus par Google Workspace et les échanges internes à un domaine ne sont pas concernés.
• Outlook.com. Les exigences visent les domaines qui envoient plus de 5 000 emails par jour vers le service grand public de Microsoft.
• Yahoo. Yahoo ne publie aucun seuil de volume pour définir un expéditeur en masse.

Une PME qui écrit à quelques centaines de clients par semaine reste loin de ces seuils. Les règles des expéditeurs en masse restent pourtant la bonne base de travail : Google précise qu'un message non authentifié peut être classé en indésirable ou rejeté avec l'erreur 5.7.26.

Exigences par messagerie

Gmail demande aussi à tout expéditeur des enregistrements DNS direct et inverse (PTR) valides pour ses adresses IP d'envoi, une connexion TLS et des messages conformes à la RFC 5322 ; il interdit d'imiter les en-têtes From de Gmail. Yahoo exige des enregistrements PTR valides et non génériques pour toutes les adresses IP d'envoi. Microsoft recommande en plus une adresse d'expédition qui peut recevoir des réponses, une liste débarrassée des adresses invalides et des objets fidèles au contenu du message.

SPF, la liste des serveurs autorisés

SPF (Sender Policy Framework, RFC 7208) publie dans le DNS la liste des serveurs autorisés à envoyer pour votre domaine. L'enregistrement est un TXT posé à la racine du domaine :

v=spf1 include:_spf.google.com include:_spf.outil-emailing.example ~all

Dans cet exemple, la messagerie Google Workspace et un outil d'emailing (au nom fictif) sont autorisés ; tout autre serveur reçoit un échec léger. Les règles qui cassent le plus souvent un SPF :

• Un seul enregistrement par domaine. Deux TXT qui commencent par v=spf1 rendent SPF invalide. Un nouvel outil s'ajoute dans l'enregistrement existant.
• Dix recherches DNS au plus. Les mécanismes include, a, mx, ptr et exists, et le modificateur redirect, comptent ; ip4, ip6 et all ne comptent pas. Les include contenus dans un include comptent aussi. Au-delà de dix, le résultat est une erreur permanente et SPF échoue pour tous les messages.
• Deux recherches vides au plus. Un include qui pointe vers un nom sans enregistrement, ou vers un nom qui n'existe pas, compte comme une recherche vide ; la RFC en tolère deux.
• Un TXT, découpé si besoin. Une chaîne DNS fait 255 caractères au plus. Un enregistrement plus long se découpe en plusieurs chaînes, que les serveurs recollent sans espace. La RFC recommande que la réponse complète tienne dans 512 octets.
• La fin de l'enregistrement. -all déclare qu'aucun autre serveur n'est autorisé (échec) ; ~all indique qu'un autre serveur n'est probablement pas autorisé (échec léger).

Pour rester sous dix recherches, certains remplacent un include par les adresses IP qu'il contient. La méthode casse le jour où le fournisseur change ses adresses. Mieux vaut retirer les outils qui n'envoient plus, ou faire envoyer un outil depuis un sous-domaine qui a son propre SPF.

SPF vérifie le domaine de l'enveloppe du message, c'est-à-dire l'adresse de retour (Return-Path), que le destinataire ne voit pas. Le domaine affiché dans le champ From peut être différent : DMARC relie les deux.

DKIM, la signature des messages

DKIM (DomainKeys Identified Mail, RFC 6376) signe les messages avec une clé privée détenue par l'outil qui envoie. La clé publique correspondante est publiée dans un TXT à l'adresse sélecteur._domainkey.exemple.fr, avec les balises v=DKIM1 et p= (la clé). Le destinataire vérifie la signature : le message vient bien du domaine indiqué dans la balise d= et n'a pas été modifié en route.

• Un sélecteur par outil. L'outil choisit son sélecteur : google pour Google Workspace, selector1 et selector2 pour Microsoft 365, un nom qui lui est propre pour la plupart des outils d'emailing. Un sélecteur ne se devine pas depuis l'extérieur : notez ceux de vos outils.
• Des clés de 2 048 bits. La RFC 8301 interdit l'algorithme rsa-sha1, impose des clés RSA d'au moins 1 024 bits et recommande 2 048 bits ; Yahoo exige au moins 1 024 bits. Une clé de 2 048 bits dépasse la limite de 255 caractères d'une chaîne DNS et se publie donc en plusieurs chaînes.
• Ed25519 en complément. La RFC 8463 ajoute l'algorithme Ed25519 (k=ed25519), dont la clé tient dans une seule chaîne. Pour rester lisible par les vérificateurs qui ne le connaissent pas, la RFC prévoit une double signature, RSA et Ed25519, sous deux sélecteurs.
• La signature couvre la désinscription. La RFC 8058 exige que la signature DKIM porte sur les en-têtes List-Unsubscribe et List-Unsubscribe-Post.

Un message peut porter une signature DKIM valide et échouer à DMARC : c'est le cas quand l'outil signe avec son propre domaine (d=outil-emailing.example) plutôt qu'avec le vôtre. Les outils d'emailing proposent de signer avec votre domaine, à condition de publier chez vous les enregistrements qu'ils fournissent.

DMARC, la règle et les rapports

DMARC relie les deux contrôles au domaine que voit le destinataire. Un message passe DMARC quand SPF ou DKIM réussit pour un domaine aligné avec celui du champ From. En alignement souple, le réglage par défaut (adkim=r et aspf=r), un sous-domaine du même domaine principal suffit : un message de factures@exemple.fr signé par news.exemple.fr est aligné.

L'enregistrement est un TXT publié à _dmarc.exemple.fr :

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

La balise p fixe le sort des messages qui échouent :

La balise rua indique où envoyer les rapports agrégés (RFC 9990) : pour chaque adresse IP qui a envoyé au nom du domaine, le volume de messages et les résultats SPF, DKIM et DMARC. Ces rapports révèlent les outils oubliés et les tiers qui usurpent le domaine.

Gmail et Outlook.com se contentent de p=none. Une politique d'observation ne protège pourtant de rien : un tiers peut toujours envoyer au nom du domaine. p=quarantine puis p=reject bloquent ces messages, et l'affichage du logo de marque dans les messageries (BIMI) exige l'une des deux.

Ce que change la RFC 9989

En mai 2026, l'IETF a publié DMARC comme norme (RFC 9989), avec deux documents compagnons : la RFC 9990 pour les rapports agrégés et la RFC 9991 pour les rapports d'échec. La RFC 7489 de 2015, un document informatif, est remplacée.

Conséquence pratique : un enregistrement en p=quarantine; pct=0, qui servait à publier une politique sans l'appliquer, peut être appliqué en totalité par un récepteur qui suit la nouvelle norme. Pour tester une politique, écrivez p=quarantine; t=y. Les pages d'aide des messageries et du groupe BIMI mentionnent encore pct : lisez-les avec cette réserve.

Désinscription en un clic et taux de plaintes

La désinscription en un clic de la RFC 8058 repose sur deux en-têtes, que la messagerie transforme en bouton à côté de l'expéditeur :

List-Unsubscribe: <https://exemple.fr/desinscription/abc123>, <mailto:desinscription@exemple.fr>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

L'en-tête List-Unsubscribe doit contenir une adresse en https, et la signature DKIM doit couvrir les deux en-têtes. Gmail l'exige pour les messages marketing et d'abonnement des expéditeurs en masse, avec en plus un lien de désinscription visible dans le corps du message ; les messages transactionnels (facture, confirmation de commande, réinitialisation de mot de passe) en sont exclus. La désinscription retire le destinataire de la liste liée au message, sans le priver des autres envois. Le délai de prise en compte est de 48 heures chez Gmail et de 2 jours chez Yahoo, qui demande aussi une désinscription sans connexion à un compte.

Le taux de plaintes mesure la part des destinataires qui signalent un message comme indésirable. Gmail demande de le garder sous 0,10 % dans Postmaster Tools et de ne jamais atteindre 0,30 % ; un expéditeur en masse qui dépasse 0,3 % ne peut plus obtenir l'aide de Gmail sur ses problèmes de distribution avant sept jours consécutifs sous ce seuil. Yahoo fixe la limite à 0,3 % et la surveille par sa boucle de retour des plaintes (Complaint Feedback Loop), à activer pour tous les domaines qui signent en DKIM. Un destinataire qui ne trouve pas comment se désinscrire clique sur « Signaler comme spam » : une désinscription visible coûte moins cher qu'une plainte.

PTR, TLS, MTA-STS, TLS-RPT et BIMI

• PTR et TLS. Le DNS inverse relie l'adresse IP d'envoi à un nom d'hôte, qui doit lui-même pointer vers cette adresse ; TLS chiffre la connexion entre serveurs. Avec une messagerie en ligne ou un outil d'emailing, ces deux points relèvent du fournisseur ; ils concernent surtout les serveurs d'envoi gérés par l'entreprise elle-même.
• MTA-STS (RFC 8461). Il protège le courrier que votre domaine reçoit : un TXT à _mta-sts.exemple.fr (v=STSv1; id=...) annonce une politique servie en https à l'adresse https://mta-sts.exemple.fr/.well-known/mta-sts.txt, en mode testing puis enforce. En mode enforce, les serveurs compatibles qui vous écrivent ne livrent qu'en connexion chiffrée, vers les serveurs de réception que la politique déclare.
• TLS-RPT (RFC 8460). Un TXT à _smtp._tls.exemple.fr (v=TLSRPTv1; rua=mailto:tls@exemple.fr) demande des rapports sur les échecs de chiffrement.
• BIMI. Il affiche le logo de l'entreprise à côté de ses messages. Le groupe BIMI demande un DMARC en quarantaine ou en rejet sur le domaine principal et un logo carré au format SVG Tiny PS, déclaré dans un TXT à default._bimi.exemple.fr. Gmail exige en plus un certificat : un VMC, qui suppose une marque déposée et donne une coche bleue, ou un CMC, accepté depuis le 24 septembre 2024, sans coche. Apple Mail (macOS 13, iOS 16 et suivants) s'appuie sur un VMC ; Yahoo peut afficher un logo sans certificat pour les expéditeurs qu'il qualifie. BIMI reste à l'état de projet de norme à l'IETF : aucune RFC ne le définit encore.

Aucun de ces trois derniers enregistrements n'est exigé par les messageries. Ils se posent une fois SPF, DKIM et DMARC en place.

Mise en place dans l'ordre

1. Inventorier les expéditeurs. Messagerie (Google Workspace, Microsoft 365), outil d'emailing, CRM, logiciel de facturation, formulaires du site, prise de rendez-vous, support client : notez pour chacun le domaine d'envoi et le sélecteur DKIM.
2. Écrire un seul SPF qui couvre ces outils, sous dix recherches DNS.
3. Activer DKIM dans chaque outil, en 2 048 bits, en signant avec votre domaine.
4. Publier DMARC en observation (p=none) avec une adresse rua, et lire les rapports pendant au moins un cycle complet d'envois : factures mensuelles, relances, lettre d'information.
5. Corriger les expéditeurs non alignés que les rapports révèlent, puis passer à p=quarantine, d'abord avec t=y si vous voulez une étape de test, puis à p=reject.
6. Régler la désinscription RFC 8058 et son traitement sous 48 heures dans l'outil d'emailing, avec un lien visible dans le corps des messages.
7. Séparer les flux. La prospection part d'un domaine ou d'un sous-domaine dédié, pour que ses plaintes ne touchent pas le domaine qui envoie vos factures ; notre guide sur l'emailing B2B et la prospection détaille les règles de la CNIL sur ce point.
8. Surveiller le taux de plaintes et la conformité dans Postmaster Tools, dont le tableau de conformité vérifie chaque exigence de Gmail, et dans la boucle de plaintes de Yahoo.

Vérifier le résultat

Notre test SPF, DKIM et DMARC, gratuit, lit les enregistrements publics de votre domaine : serveurs de réception, SPF et son nombre de recherches DNS, clés DKIM des sélecteurs courants ou de celui que vous indiquez, politique DMARC et adresse des rapports, BIMI, MTA-STS et TLS-RPT. Il signale ce qui manque au regard des exigences de Gmail, Yahoo et Outlook.

Un test de DNS ne voit pas la réputation du domaine ni la qualité de la liste. Pour vérifier un envoi réel, écrivez depuis chaque outil à une adresse Gmail, ouvrez le message, puis le menu « Afficher l'original » : Gmail y indique le résultat de SPF, DKIM et DMARC. Les définitions de SPF, DKIM et DMARC sont dans notre lexique.

Quand se faire accompagner

Un domaine qui n'envoie que depuis sa messagerie se règle en une heure avec ce guide. L'accompagnement se justifie quand plusieurs outils envoient au nom du domaine, quand les rapports DMARC révèlent des expéditeurs inconnus, ou quand la prospection et la lettre d'information doivent coexister sans se nuire. Les lettres d'information font partie de notre expertise contenus et marque, et les séquences email de nos CRM sur mesure ; les emails envoyés par les outils que nous livrons partent d'un domaine authentifié. Un Diagnostic Express, à 500 € HT, fait en une semaine l'état des lieux de vos outils et de votre présence en ligne.