Microsoft suit Gmail et Yahoo, avec seize mois de retard

En février 2024, Google et Yahoo ont posé leurs nouvelles exigences pour les expéditeurs en masse. Microsoft a fini par s’aligner. Le 2 avril 2025, l’équipe Defender for Office 365 a publié sur Microsoft Tech Community l’annonce officielle d’un durcissement des règles d’authentification pour Outlook.com, Hotmail.com et Live.com. Application au 5 mai 2025.

L’écart de calendrier est significatif. Pendant plus d’un an, les routeurs B2B ont dû gérer deux référentiels parallèles, avec des règles strictes côté Gmail et Yahoo (DMARC obligatoire, one-click unsubscribe RFC 8058) et un cadre plus tolérant côté Microsoft. Cette asymétrie disparaît, en partie. Microsoft conserve quelques différences notables, on y revient plus loin.

Le 29 avril 2025, Microsoft a renforcé son annonce initiale : les emails non conformes ne seraient pas simplement filtrés en spam, mais rejetés au niveau SMTP. Bounce immédiat, pas de seconde chance. C’est plus direct que le démarrage de Gmail, qui avait commencé par une phase de filtrage progressif avant de durcir.

Ce qui change concrètement le 5 mai 2025

Le seuil des 5 000 emails par jour

Microsoft applique les nouvelles règles aux domaines qui envoient plus de 5 000 emails par jour vers les boîtes Outlook.com et apparentées : Hotmail.com, Live.com, ainsi que les variantes locales comme live.fr, outlook.fr, hotmail.be ou hotmail.it. Le seuil est calculé par domaine d’expédition, pas par adresse IP.

Pour un expéditeur B2B français, ce seuil est atteint plus vite qu’on ne le pense. Une campagne mensuelle sur une base de 100 000 contacts dont 30 % chez Microsoft passe la barre en quelques heures. Et un programme automation qui envoie chaque jour plusieurs milliers de relances peut le franchir sans alerte préalable.

SPF, DKIM et DMARC obligatoires

Microsoft ne réinvente pas l’authentification : la liste est connue, mais elle devient un prérequis absolu pour franchir le seuil des 5 000 emails.

Microsoft recommande de viser rapidement une politique p=quarantine ou p=reject plutôt que de rester en p=none. Pour le détail technique de chaque protocole et la procédure de mise en place, voir notre article dédié à configurer SPF, DKIM et DMARC.

Le rejet SMTP immédiat (550 5.7.515)

C’est le point qui change tout. Au lieu d’un filtrage progressif (spam puis blocage), Microsoft rejette directement les emails non conformes avec ce code :

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

Conséquence pratique : les bounces remontent immédiatement dans les statistiques de votre plateforme emailing. Aucun délai d’observation, aucune marge d’erreur. Si vos enregistrements DNS sont mal configurés au moment de l’envoi, la totalité de la cible Microsoft tombe d’un coup.

À noter : l’erreur 5.7.515 concerne l’authentification du domaine expéditeur. Inutile de purger les destinataires concernés de votre liste, ce sont vos paramètres techniques qui posent problème, pas la validité des adresses.

Outlook.com grand public et Microsoft 365 professionnel : pas le même périmètre

Une confusion fréquente parasite la lecture de l’annonce. Les nouvelles règles ciblent les boîtes Outlook.com, Hotmail.com et Live.com, c’est-à-dire la messagerie webmail grand public de Microsoft. Pas Microsoft 365 (anciennement Office 365), qui correspond aux boîtes professionnelles hébergées sur Exchange Online.

Cette distinction a son importance. En B2B, vos prospects sont majoritairement sur Microsoft 365 (sociétés équipées de la suite Office 365), pas sur Outlook.com. Microsoft 365 dispose de sa propre logique de filtrage anti-spam, davantage sensible à la réputation IP et à l’historique de votre domaine qu’à la simple présence des trois protocoles d’authentification.

Ne vous laissez pas pour autant aller à un faux sentiment de sécurité. Les règles Outlook.com finissent souvent par aligner les standards Microsoft 365, parfois en différé. Et une part non négligeable de vos contacts B2B reste sur Outlook.com : free-lances, TPE sans domaine d’entreprise, contacts personnels d’achat décideurs. La conformité aux nouvelles règles vaut donc pour l’ensemble de votre programme.

Pourquoi cela touche en priorité les expéditeurs B2B français

Le tissu professionnel français est lourdement équipé en Microsoft 365. La plupart des grandes entreprises et des ETI ont migré sur Exchange Online ces dernières années, et la suite Office 365 reste la norme dans les fonctions support. Pour un éditeur de logiciel B2B, un cabinet de conseil ou une agence qui prospecte cette cible, le poids des destinataires sous infrastructure Microsoft est massif.

Concrètement : une campagne de prospection B2B vers les directions marketing France a souvent une part importante de ses contacts sur des domaines hébergés chez Microsoft. Si la politique d’authentification de votre domaine n’est pas en règle, vous perdez une bonne partie de votre audience d’un coup, sans warning préalable. Un seul envoi mal configuré peut suffire à casser une réputation de domaine bâtie sur des années.

Les conséquences sur la délivrabilité globale dépassent le périmètre Microsoft. Un taux de bounce élevé sur un seul opérateur affecte la note de réputation envoyée par votre plateforme emailing, qui à son tour pèse sur les autres MSP comme Gmail, Apple ou Yahoo. Pour comprendre les leviers techniques qui jouent sur l’aboutissement, notre guide délivrabilité email B2B détaille la mécanique.

SNDS, l’outil Microsoft trop souvent ignoré

Côté Google, tout le monde connaît Postmaster Tools. Côté Microsoft, l’équivalent existe mais reste largement sous-utilisé en France : c’est SNDS, le Smart Network Data Services.

SNDS travaille à la maille IP, pas à la maille domaine. C’est sa principale différence avec Postmaster Tools. Pour chaque IP qui envoie vers les boîtes Microsoft, SNDS renvoie :

• Le volume d’envois observé
• Le taux de plaintes des utilisateurs (spam reports)
• La présence sur les listes noires Microsoft
• Le statut de réputation (Green, Yellow, Red)

L’inscription est manuelle et nécessite que l’IP soit confirmée auprès de Microsoft. Pour les expéditeurs sur IP mutualisée, l’accès est limité au gestionnaire de la plateforme. Pour les expéditeurs sur IP dédiée, l’inscription au SNDS est un réflexe à prendre dès le warm-up de l’IP. C’est un signal de pilotage qui complète utilement les rapports de votre routeur, surtout dans les premières semaines.

IP dédiée ou mutualisée : ce que les nouvelles règles changent

Sur une IP mutualisée, votre réputation Microsoft est partagée avec les autres expéditeurs qui utilisent la même IP. Si l’un d’eux dépasse le seuil sans authentification correcte, c’est tout le pool qui prend le rejet 5.7.515. Vous payez la non-conformité d’un voisin.

Sur une IP dédiée, votre réputation est isolée. Vous contrôlez votre conformité, votre warm-up, votre taux de plaintes. C’est une variable que vous pilotez vous-même. Cela explique pourquoi les éditeurs sérieux d’emailing B2B incluent les IP dédiées dans leurs offres dès l’entrée de gamme. Chez Ediware, l’IP dédiée est livrée par défaut sur tous les comptes, sans surcoût.

Les nouvelles règles Microsoft renforcent l’avantage des IP dédiées. Plus l’écosystème durcit ses exigences, plus le contrôle individuel de la réputation devient un levier de délivrabilité, pas un confort technique.

La feuille de route concrète pour rester délivré chez Microsoft

Quatre vérifications à passer si vous expédiez plus de 5 000 emails par jour vers les boîtes Microsoft.

1. Audit DNS : SPF publié et complet (toutes les IPs ou services de routage déclarés), DKIM configuré et aligné, DMARC publié au moins en p=none. Outils gratuits de vérification : MXToolbox, dmarcian, DMARC Analyzer.
2. Vérification du From et du Reply-To : adresse expéditeur valide, capable de recevoir des emails. Évitez les noreply@ sans réception, Microsoft les pénalise.
3. Inscription au SNDS pour vos IPs d’envoi (postmaster.live.com/snds), à activer dès le démarrage de l’IP.
4. Lien de désabonnement visible et fonctionnel dans toutes les campagnes marketing. Le RFC 8058 (one-click) n’est pas obligatoire chez Microsoft, mais il l’est déjà chez Gmail et Yahoo : autant l’implémenter une fois pour toutes, comme l’explique notre article sur les règles Gmail et Yahoo 2024-2025.

Une fois ces quatre points en place, surveillez vos bounces sur la première semaine d’envois. Le code 5.7.515 est explicite et facile à filtrer dans les logs de votre plateforme emailing. Si vous voyez monter les rejets, le problème vient des paramètres DNS, pas de la qualité de votre fichier.

FAQ — Microsoft et l’emailing 2025

À partir de combien d’emails par jour les règles Microsoft s’appliquent-elles ?

Au-delà de 5 000 emails par jour envoyés vers les boîtes Outlook.com, Hotmail.com et Live.com depuis un même domaine d’expédition. Le seuil est calculé sur 24 heures glissantes par Microsoft. Les expéditeurs sous ce seuil restent soumis aux contrôles classiques de filtrage anti-spam, mais ne déclenchent pas le rejet SMTP automatique.

Que se passe-t-il si mes emails ne respectent pas les règles Outlook depuis le 5 mai 2025 ?

Vos messages sont rejetés au niveau SMTP avec le code 550 5.7.515 Access denied. Aucun message ne passe en boîte spam : tout est bloqué en amont. Le bounce remonte immédiatement dans votre plateforme emailing. Pour rétablir la situation, il faut corriger les enregistrements DNS du domaine d’envoi puis relancer une campagne test après propagation DNS, en général 24 à 48 heures.

Les règles Microsoft 2025 s’appliquent-elles aux emails transactionnels ?

Oui. Les exigences SPF, DKIM et DMARC s’appliquent à tous les emails sortants au-delà du seuil de 5 000 par jour, sans distinction marketing ou transactionnel. La principale différence concerne le lien de désabonnement, requis pour les campagnes marketing mais pas pour les emails purement transactionnels (confirmation de commande, mot de passe oublié, alerte de compte).

Quelle différence avec les règles Gmail et Yahoo de 2024 ?

Les exigences techniques sont proches : SPF, DKIM, DMARC, même seuil de 5 000 emails par jour. Trois différences à retenir. Microsoft a démarré seize mois plus tard. Microsoft applique le rejet SMTP immédiat dès le 5 mai 2025, là où Gmail avait procédé par phases progressives. Et le one-click unsubscribe RFC 8058 reste obligatoire chez Gmail et Yahoo, mais seulement recommandé chez Microsoft.

Le one-click unsubscribe RFC 8058 est-il obligatoire chez Microsoft ?

Non, pas au sens strict. Microsoft demande un lien de désabonnement visible et fonctionnel pour les campagnes marketing, sans imposer le format technique RFC 8058 (header List-Unsubscribe-Post). Cela dit, comme Gmail et Yahoo l’imposent depuis 2024, l’implémenter dans votre plateforme emailing une fois pour toutes simplifie la vie et couvre les trois opérateurs en même temps.

Comment surveiller sa réputation d’expéditeur chez Microsoft ?

Via SNDS (Smart Network Data Services), accessible sur postmaster.live.com/snds. SNDS fournit pour chaque IP d’envoi le volume, le taux de plaintes, la présence sur les listes noires Microsoft et un statut de réputation Green, Yellow ou Red. L’inscription est manuelle. Les expéditeurs sur IP dédiée doivent l’activer dès le warm-up. Sur IP mutualisée, le suivi est généralement assuré par le routeur.

Comment vérifier que mon domaine est conforme avant le 5 mai 2025 ?

Trois vérifications rapides. D’abord, contrôler les enregistrements SPF, DKIM et DMARC du domaine via MXToolbox ou dmarcian. Ensuite, envoyer un email test à une boîte mail-tester.com pour obtenir un score d’authentification détaillé. Enfin, regarder dans le rapport DMARC quotidien si toutes vos sources d’envoi (CRM, marketing automation, plateforme emailing, helpdesk) sont bien alignées. Une seule source mal configurée suffit à faire passer une partie du trafic en rejet.

L’époque où l’on pouvait envoyer un emailing depuis un domaine mal configuré et espérer atterrir en boîte de réception est terminée. Les annonces conjointes de Google et Yahoo en octobre 2023 ont marqué un tournant. Microsoft a embrayé un an plus tard. Et la phase de tolérance qui a suivi février 2024 s’est refermée à l’automne 2025.

Pour les responsables emailing B2B français, l’enjeu est concret. Vos campagnes vers des contacts Gmail, Yahoo, Outlook, Hotmail et Live ne passent plus si vos enregistrements DNS ne sont pas en ordre. Et la réalité du marché B2B, c’est que la quasi-totalité de vos cibles utilise une de ces messageries, soit en direct, soit via Google Workspace ou Microsoft 365. Voici ce qu’il faut comprendre, étape par étape, pour rester dans la course.

D’où viennent ces nouvelles exigences Gmail et Yahoo

L’annonce a été faite le 3 octobre 2023 par Neil Kumaran chez Google et Marcel Becker chez Yahoo, à quelques heures d’intervalle. Les deux fournisseurs annonçaient les mêmes règles, applicables à partir du 1er février 2024 pour tout expéditeur dépassant les 5 000 emails par jour vers leurs comptes respectifs. La coordination n’était pas un hasard. Le M3AAWG, l’organisme international de référence sur la lutte contre l’abus email, avait validé l’approche en publiant un texte resté célèbre dans le secteur : « In 2024, « No Auth, No Entry » will be the rule for bulk senders. » Pas d’authentification, pas d’entrée. La formule a fait le tour des conférences délivrabilité pendant des mois.

La motivation est avant tout sécuritaire. Les fraudes par email, le phishing ciblé, les attaques BEC qui usurpent l’identité d’un dirigeant pour détourner un virement, tout cela explosait depuis plusieurs années. Sans authentification systématique, n’importe qui pouvait écrire un message en se faisant passer pour vous. Vos clients étaient exposés. Vos prospects aussi. Et la réputation de votre domaine pouvait s’effondrer du jour au lendemain à cause d’un envoi frauduleux que vous n’aviez jamais émis.

Côté volumes, la pression sur les filtres était devenue intenable. Gmail traite environ 300 milliards de messages chaque mois selon Google. Avec 75 % à 90 % de ce trafic potentiellement non sollicité, la seule réponse viable consistait à exiger une authentification cryptographique de toute source d’envoi sérieuse. Les bulk senders, ceux qui envoient en masse, sont la première cible.

Les trois exigences imposées au-delà de 5 000 emails par jour

Les nouvelles règles tiennent en trois piliers. Aucune surprise pour qui pratique la délivrabilité depuis longtemps, mais l’application devient cette fois sans appel.

Authentification SPF, DKIM et DMARC

Tout expéditeur dépassant 5 000 emails par jour vers Gmail, Yahoo et désormais Outlook doit avoir publié dans son DNS les trois enregistrements d’authentification : SPF pour déclarer les serveurs autorisés, DKIM pour signer cryptographiquement chaque message, et DMARC pour définir la politique appliquée en cas d’échec d’une des deux vérifications. Les détails de mise en place sont décrits dans notre guide complet pour configurer SPF, DKIM, DMARC, qui détaille la syntaxe DNS, les pièges classiques comme la limite de 10 lookups SPF, et la montée progressive de la politique DMARC.

L’exigence minimale Google et Yahoo, c’est une politique DMARC à p=none. Vous n’êtes pas obligé d’aller jusqu’au rejet, mais vous devez au moins publier l’enregistrement et accepter de recevoir les rapports agrégés.

La désinscription en un clic

Deuxième exigence : un lien de désinscription doit pouvoir être activé en un seul clic, sans que le destinataire passe par une page web qui demande de saisir son adresse ou de confirmer son choix. Techniquement, cela signifie l’ajout dans les en-têtes du message du couple List-Unsubscribe et List-Unsubscribe-Post: List-Unsubscribe=One-Click, conforme à la RFC 8058. Et la désinscription doit être traitée dans les deux jours.

Le taux de plaintes spam sous le seuil

Troisième pilier, et probablement le plus délicat à maîtriser : le taux de plaintes spam dans Postmaster Tools de Google ne doit jamais dépasser 0,3 %. Au-delà, vos messages sont rejetés ou systématiquement classés en spam. Et la recommandation officielle est de rester sous 0,1 %, ce qui correspond à 1 plainte pour 1 000 messages remis. C’est strict.

Le seuil 0,3 % de plaintes spam : ce que ça change concrètement

Beaucoup d’expéditeurs B2B découvrent ce seuil au pire moment, quand leur taux de placement en boîte de réception s’effondre sans explication apparente. Le contenu n’a pas changé, la base est qualifiée, les objets sont sobres. Et pourtant, les ouvertures plongent. La cause est presque toujours la même : un dépassement chronique du seuil 0,1 % qui finit par déclencher un filtrage agressif.

Pour mesurer ce taux, un seul outil compte : Google Postmaster Tools. Vous y verrez votre taux de plaintes ventilé par jour, comparé au volume envoyé, sur 7, 30 ou 90 jours. Pour Yahoo, le suivi passe par leur Sender Hub. Et pour Outlook, le SNDS de Microsoft fournit l’équivalent, avec une granularité par IP plutôt que par domaine.

Ce qui fait grimper un taux de plaintes en B2B, c’est rarement le contenu lui-même. Ce sont les listes mal entretenues. Une base achetée en gros, importée sans nettoyage, va générer des centaines de plaintes dès le premier envoi. Un fichier de prospection qui n’a pas été segmenté par activité, par poste ou par moment dans le cycle de vente, va lasser ses destinataires en quelques campagnes. Et un opt-in flou, du genre case pré-cochée dans un formulaire de téléchargement, expose à des plaintes immédiates parce que la personne n’a aucune mémoire de vous avoir donné son consentement.

Quand les chiffres remontent, la réaction la plus efficace consiste à supprimer les inactifs profonds, ralentir la cadence d’envoi, et reprendre le warm-up depuis un volume plus modeste. Une plateforme bien dimensionnée, comme Ediware avec ses IP dédiées et son moteur Power-MTA, permet d’isoler vos envois et de mesurer précisément l’impact de chaque ajustement, ce qui est presque impossible sur un service mutualisé où vos statistiques sont diluées dans celles de centaines d’autres expéditeurs.

Calendrier d’application : du soft enforcement au durcissement de novembre 2025

L’entrée en vigueur s’est faite par paliers. Comprendre le calendrier permet d’anticiper ce qui vient, et notamment ce qui a déjà changé depuis l’automne dernier.

Le tournant de novembre 2025 mérite qu’on s’y arrête. Jusque-là, un envoi non conforme finissait au mieux dans le dossier spam. Le destinataire pouvait le récupérer s’il pensait à aller voir. Depuis novembre, le serveur SMTP de Google rejette purement et simplement le message. Vous recevez un code 550 ou 421 dans vos logs, et le destinataire ne voit jamais rien. La frontière entre filtré et rejeté a disparu, et les expéditeurs qui n’avaient pas encore migré leur configuration se sont retrouvés avec des taux de bounce explosifs du jour au lendemain.

Proofpoint a documenté le phénomène dans plusieurs alertes envoyées à ses clients fin 2025. Le message est toujours le même : la période de tolérance est terminée, et les sanctions ne sont plus progressives.

Microsoft entre dans la danse en mai 2025

Le 5 mai 2025, Microsoft a aligné Outlook, Hotmail et Live sur les exigences Google et Yahoo. Le seuil de déclenchement est identique, 5 000 emails par jour, et les trois piliers sont repris à l’identique : SPF + DKIM + DMARC, désinscription en un clic, taux de plaintes contrôlé. Le secteur a salué l’événement avec un néologisme qui résume bien la situation : Yahooglesoft. Trois acteurs, une seule grille de lecture.

Pour la prospection B2B française, Microsoft est loin d’être anecdotique. Une part significative des PME et ETI utilise Microsoft 365 et donc des boîtes Outlook professionnelles. Si votre configuration tournait correctement vers Gmail mais pas vers Outlook, jusqu’au printemps 2025 vous pouviez encore passer. Depuis l’application progressive des règles Microsoft, le manque de conformité bloque aussi cette part majeure du marché.

Ce que ça change pour les expéditeurs B2B en France

L’AFNIC publie chaque année un état des lieux de l’authentification email sur la zone .fr. Les chiffres 2025 sont parlants : SPF est présent sur 69 % des domaines actifs, DKIM sur 40,7 %, et DMARC sur seulement 19,5 %. Autrement dit, à peine un domaine sur cinq dispose d’une politique DMARC publiée. La progression est nette par rapport à 2024, mais la majorité du tissu économique français reste exposée. Et parmi les 19,5 % de domaines avec DMARC, l’écrasante majorité reste en p=none, c’est-à-dire en mode observation sans réelle protection.

Pour un expéditeur B2B sérieux, cela signifie deux choses. D’abord, vos prospects qui ont publié un DMARC en p=reject rejetteront tout email frauduleux émis sous votre identité. C’est une bonne nouvelle pour la sécurité globale du marché. Ensuite, les fournisseurs de messagerie utilisent désormais la conformité DMARC comme un signal de qualité fort dans leur scoring de réputation. Un domaine sans DMARC, même légitime, démarre avec un handicap.

L’erreur classique consiste à penser que le sujet ne concerne que les très gros envois. C’est faux pour deux raisons. D’une part, le seuil 5 000 par jour est calculé par fournisseur de messagerie, pas par votre volume total. Si vos campagnes ciblent 30 000 contacts dont 6 000 sur Gmail, vous êtes concerné. D’autre part, même sous le seuil, Gmail applique depuis 2025 un scoring renforcé sur tous les expéditeurs. Pas de SPF/DKIM/DMARC en règle, pas de placement en inbox prioritaire.

L’angle mort des plateformes mutualisées : la réputation partagée d’IP

Voici le point que les comparatifs sponsorisés et les guides des grandes plateformes mutualisées passent généralement sous silence. Quand vos campagnes sont envoyées depuis une IP partagée avec des centaines d’autres clients, la réputation que les serveurs Gmail, Yahoo et Outlook attribuent à cette IP dépend du comportement de l’ensemble du pool. Pas seulement du vôtre.

Concrètement, si l’un de vos voisins de pool envoie un emailing mal ciblé qui déclenche un pic de plaintes, votre placement en boîte de réception en pâtit le jour même. Vous n’avez rien fait de mal, vous n’êtes pas prévenu, et vos campagnes en cours subissent les conséquences d’une décision qui n’est pas la vôtre. Dans le contexte du durcissement de novembre 2025, où les filtres réagissent plus vite et plus durement, ce risque a pris une autre dimension.

C’est précisément ce que résolvent les IP dédiées. Votre réputation devient strictement la vôtre, mesurable, isolée, contrôlable. Chez Ediware, les IP dédiées sont incluses dès le plan PRO, sans surcoût et sans option à activer. Le moteur Power-MTA gère le warm-up, la régulation des cadences par destinataire et la rotation entre plusieurs IP du pool quand votre volume le justifie. Le tracking domain dédié évite par ailleurs que tous vos liens cliqués pointent vers un sous-domaine partagé avec d’autres expéditeurs, ce qui renforce la cohérence de votre signal d’authentification.

Pour bien comprendre comment ces choix d’infrastructure se traduisent en sécurité concrète pour vos données et votre image de marque, la page dédiée à la sécurité des données et conformité RGPD chez Ediware détaille l’ensemble des dispositifs en place : hébergement France, monitoring IP continu, SPF/DKIM/DMARC déjà configurés sur le tracking domain.

Checklist de mise en conformité pour un expéditeur B2B

Si vous découvrez le sujet ou si votre dernière vérification date d’avant 2024, voici la marche à suivre dans l’ordre. Comptez deux à quatre semaines pour boucler proprement, le temps de laisser propager les enregistrements et d’analyser les rapports.

1. Lister toutes les sources d’envoi pour votre domaine : plateforme emailing, CRM, helpdesk, signatures email, outil de facturation, plateforme de prospection. On en oublie toujours au moins une.
2. Publier un enregistrement SPF unique qui inclut chacune de ces sources, en restant impérativement sous la limite des 10 lookups DNS.
3. Activer DKIM chez chaque service d’envoi, avec des clés RSA 2048 bits. La plupart des plateformes fournissent les enregistrements à copier-coller dans le DNS.
4. Publier un enregistrement DMARC en p=none avec une adresse rua qui collecte les rapports agrégés. Lire ces rapports pendant deux à quatre semaines pour identifier les sources oubliées.
5. Faire monter la politique DMARC : passer à p=quarantine avec pct=25, puis 50, puis 100, puis basculer en p=reject une fois que tous les flux sont alignés.
6. Vérifier que vos campagnes intègrent List-Unsubscribe-Post au format RFC 8058. Toute plateforme emailing professionnelle le fait par défaut. Si la vôtre ne le fait pas, c’est un signal clair sur son retard technique.
7. Surveiller votre taux de plaintes dans Postmaster Tools, Yahoo Sender Hub et Microsoft SNDS. Fixez-vous un seuil d’alerte interne à 0,1 %, pas 0,3 %.
8. Documenter votre configuration dans un document partagé entre l’IT, le marketing et le support. Quand un nouveau service email arrive dans l’entreprise, le réflexe doit être de mettre à jour SPF immédiatement.

Cette discipline n’est pas négociable si vous voulez maintenir un placement en boîte de réception correct sur la durée. Et chez Ediware, chiffres à l’appui, les comptes qui suivent cette progression vers p=reject voient en général leurs taux d’ouverture remonter dans les semaines qui suivent la stabilisation.

FAQ — Nouvelles règles Gmail, Yahoo et Outlook

Les règles Gmail s’appliquent-elles aux emails B2B ?

Oui, sans exception. Les exigences Google ne distinguent pas B2B et B2C. Tout ce qui compte, c’est le volume envoyé vers des comptes Gmail, qu’ils soient personnels (@gmail.com) ou professionnels hébergés sur Google Workspace. Or la majorité des entreprises françaises utilisent Workspace pour leur messagerie professionnelle. Vos prospects @entreprise.fr passent donc presque tous par les filtres Gmail, et vos envois sont soumis aux mêmes règles d’authentification.

Comment configurer DMARC pour un domaine professionnel ?

DMARC se configure via un enregistrement DNS de type TXT placé sur _dmarc.votredomaine.fr. La syntaxe minimale recommandée est v=DMARC1; p=none; rua=mailto:rapports-dmarc@votredomaine.fr;. Cette politique en mode observation permet de collecter les rapports XML quotidiens envoyés par Gmail, Yahoo et Outlook, sans bloquer aucun envoi. Une fois les rapports analysés et toutes vos sources d’envoi identifiées, vous montez progressivement vers p=quarantine puis p=reject. Le détail technique complet est traité dans notre guide SPF, DKIM, DMARC.

Que faire si on envoie moins de 5 000 emails par jour ?

Le seuil 5 000 messages par jour vers Gmail déclenche les exigences les plus strictes, mais la réalité est nuancée. Depuis 2025, Google applique un scoring renforcé à tous les expéditeurs, y compris ceux sous le seuil. Un domaine sans SPF, sans DKIM ou sans DMARC démarre avec un handicap de réputation, indépendamment du volume. Pour un expéditeur B2B sérieux, considérer ces trois protocoles comme obligatoires dès le premier envoi est la seule approche viable.

Comment mesurer son taux de plaintes spam ?

Trois outils gratuits suffisent. Pour Gmail, Google Postmaster Tools donne le taux de plaintes par domaine, par jour, sur 7, 30 ou 90 jours. Pour Yahoo, le Yahoo Sender Hub fournit l’équivalent avec un peu moins de granularité. Pour Outlook, Microsoft propose le SNDS qui mesure par IP plutôt que par domaine, particulièrement utile si vous opérez en IP dédiée. Inscrivez-vous aux trois et vérifiez vos chiffres une fois par semaine. Au-delà de 0,1 % de plaintes, agissez sans attendre le seuil de 0,3 %.

IP mutualisée ou IP dédiée : quelle différence face aux nouvelles règles ?

Sur une IP mutualisée, votre réputation auprès de Gmail dépend du comportement de tous les expéditeurs partageant la même infrastructure. Un voisin de pool qui envoie une mauvaise campagne dégrade vos placements le jour même, sans que vous puissiez intervenir. Sur une IP dédiée, votre réputation est strictement la vôtre, ce qui devient déterminant depuis le durcissement de novembre 2025. Toutes les plateformes ne proposent pas l’IP dédiée par défaut. Chez Ediware, elle est incluse dès le plan d’entrée, ce qui constitue une vraie différence en termes de contrôle de la délivrabilité.

Microsoft Outlook applique-t-il les mêmes règles ?

Depuis le 5 mai 2025, oui. Microsoft a annoncé l’alignement de ses serveurs Outlook.com, Hotmail.com et Live.com sur les mêmes exigences que Google et Yahoo : SPF, DKIM, DMARC, désinscription en un clic, contrôle des plaintes, déclenchement à 5 000 messages par jour. La phase d’application stricte est progressive, avec d’abord un classement en spam, puis des rejets purs et simples. Si vos prospects utilisent massivement Outlook ou Microsoft 365, votre conformité doit couvrir ce trois axes simultanément.

Que change la phase de durcissement de novembre 2025 ?

Avant novembre 2025, un email non conforme finissait au mieux en spam. Le destinataire pouvait toujours le récupérer manuellement. Depuis novembre, les serveurs Gmail rejettent les messages non conformes au niveau SMTP, avec des codes de retour 4xx (rejet temporaire, retry possible) ou 5xx (rejet définitif). Le destinataire ne voit jamais le message, et votre plateforme enregistre un bounce. Pour un expéditeur dont la configuration n’était pas à jour, la transition s’est traduite par une explosion brutale du taux de bounce et un effondrement des taux de placement en boîte de réception.

En bref : SPF, DKIM et DMARC sont trois protocoles d’authentification email complémentaires. SPF déclare quels serveurs ont le droit d’envoyer pour votre domaine. DKIM ajoute une signature cryptographique à chaque message. DMARC définit la politique à appliquer quand l’un ou l’autre échoue. Configurer les trois correctement, c’est la condition minimale pour atteindre la boîte de réception en B2B.

Configuration SPF, DKIM, DMARC : guide complet pour sécuriser vos envois

Vos emails arrivent en spam alors que votre contenu est propre, votre base qualifiée, vos objets travaillés. Le problème ne vient probablement pas de votre message. Il vient de votre domaine. En clair, vos enregistrements DNS ne disent rien de convaincant au serveur en face. Il ne vous reconnaît pas comme expéditeur légitime.

Depuis février 2024, Google et Yahoo ont durci le jeu : tout expéditeur de masse doit avoir configuré SPF, DKIM et DMARC correctement. Microsoft a suivi en avril 2025 avec des exigences similaires pour Outlook.com. Ce n’est plus une recommandation. C’est un prérequis technique, et les serveurs de messagerie qui reçoivent vos campagnes B2B vérifient ces enregistrements à chaque message reçu.

Dans ce guide, on passe en revue chaque protocole, la configuration pas à pas, et surtout les erreurs qu’on voit régulièrement plomber la délivrabilité chez les expéditeurs B2B. Si vous cherchez une vision d’ensemble sur le sujet, consultez notre guide complet de la délivrabilité.

Pourquoi l’authentification email est devenue incontournable

A l’origine, dans les années 70, personne n’a pensé à intégrer un mécanisme d’authentification dans le protocole email. Résultat : n’importe qui pouvait envoyer un message en se faisant passer pour quelqu’un d’autre. Et c’est toujours techniquement possible aujourd’hui. Le phishing et le spoofing reposent exactement là-dessus.

Les fraudes par email ont explosé, et les fournisseurs de messagerie ont fini par réagir. SPF est arrivé en 2006, DKIM a suivi, DMARC est apparu en 2012. Pendant longtemps, ces protocoles restaient optionnels. Un « nice to have » que les équipes techniques configuraient quand elles avaient le temps.

La donne a changé. Gmail, Outlook, Yahoo rejettent maintenant les emails non authentifiés. Ou ils les classent en spam, ce qui revient au même. Si vous faites de l’emailing B2B sans SPF, DKIM et DMARC en place, vos messages n’arriveront tout simplement pas. Le facteur a beau être de bonne volonté, sans adresse de retour il finit par jeter le courrier.

Et puis il y a la question de la réputation de domaine. Tous les emails qui partent depuis votre domaine comptent dans votre réputation : ceux de la plateforme emailing, du CRM, du helpdesk, des postes de vos collaborateurs. Tout. Et sans authentification, impossible de savoir qui utilise votre domaine. Un type mal intentionné pourrait très bien envoyer du spam sous votre nom et détruire votre réputation. Vous ne le sauriez même pas.

SPF : déclarer les serveurs autorisés à envoyer pour votre domaine

SPF, pour Sender Policy Framework, est le plus ancien des trois et aussi le plus facile à appréhender. Vous déclarez dans votre DNS quels serveurs ont le droit d’envoyer pour votre domaine. Quand un message arrive, le serveur en face va consulter cette liste et vérifier que le serveur d’envoi y figure bien.

La syntaxe d’un enregistrement SPF

Un enregistrement SPF est un enregistrement DNS de type TXT placé sur votre domaine. Voici un exemple concret :

v=spf1 include:spf.ediware.net include:_spf.google.com ip4:203.0.113.42 -all

Décomposons :

• v=spf1 : indique qu’il s’agit d’un enregistrement SPF (obligatoire, toujours en premier)
• include:spf.ediware.net : autorise les serveurs déclarés dans le SPF d’Ediware, votre plateforme emailing
• include:_spf.google.com : autorise les serveurs Google Workspace si vous utilisez Gmail professionnel
• ip4:203.0.113.42 : autorise une adresse IP spécifique, par exemple votre serveur applicatif
• -all : refuse tout serveur non listé (politique stricte)

La différence entre ~all et -all

Le suffixe fait toute la différence :

• -all (hard fail) : tout serveur non autorisé est rejeté. C’est la politique recommandée une fois votre configuration stabilisée.
• ~all (soft fail) : le serveur non autorisé n’est pas rejeté mais marqué comme suspect. Utile en phase de test pour ne pas bloquer des envois légitimes que vous auriez oubliés.
• ?all (neutre) : aucune indication. Autant ne pas avoir de SPF.

Les limites techniques de SPF

SPF a une contrainte technique importante : la limite de 10 lookups DNS. Chaque directive « include » ou « redirect » génère un lookup. Si votre enregistrement dépasse cette limite, il est invalide. Et un SPF invalide, c’est pire que pas de SPF du tout, car certains filtres le traitent comme un échec.

En pratique, cette limite pose problème aux entreprises qui utilisent beaucoup de services tiers : plateforme emailing, CRM avec envoi d’emails, outil de signature email, helpdesk, outil de facturation. Chacun demande son « include » et on atteint vite les 10 lookups.

La parade : regrouper les IP dans un seul sous-domaine dédié ou utiliser un service de « SPF flattening » qui remplace les includes par les IP résolues. Attention cependant, le flattening nécessite une mise à jour régulière car les IP des services tiers changent.

DKIM : la signature numérique qui certifie l’intégrité du message

SPF vérifie le serveur d’envoi. DKIM, lui, va un cran plus loin : il authentifie le message lui-même. DomainKeys Identified Mail, c’est son nom complet, ajoute une signature cryptographique dans l’en-tête de chaque email. Le serveur qui reçoit le message récupère votre clé publique dans le DNS, et s’en sert pour confirmer deux choses : le contenu n’a pas bougé en transit, et l’expéditeur est bien autorisé.

Comment fonctionne DKIM

Concrètement, ça fonctionne avec une paire de clés asymétriques :

1. Votre plateforme emailing génère deux clés : une clé privée qui reste secrète sur le serveur d’envoi, et une clé publique que vous publiez dans votre DNS.
2. A chaque envoi, le serveur prend certains éléments du message, le corps, des en-têtes comme le From ou le Subject, et les signe avec la clé privée.
3. La signature obtenue est insérée dans l’en-tête DKIM-Signature.
4. En réception, le serveur va chercher votre clé publique dans le DNS pour vérifier que la signature correspond.

Si la signature correspond, le message est authentifié. Si quelqu’un a modifié le contenu en route, la vérification échoue.

Configuration DNS pour DKIM

L’enregistrement DKIM est un enregistrement TXT placé sur un sous-domaine spécifique :

selecteur._domainkey.votredomaine.fr

Le « sélecteur » est un identifiant choisi par votre service d’envoi. Ediware utilise par exemple un sélecteur spécifique à chaque compte. En pratique, la valeur de l’enregistrement a cette tête :

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ...

Où la partie après « p= » est votre clé publique encodée en base64. La plupart des plateformes emailing vous fournissent directement l’enregistrement à copier-coller dans votre gestionnaire DNS.

Rotation des clés et bonnes pratiques

En théorie, il faudrait changer vos clés DKIM tous les 6 à 12 mois. La procédure : générer une nouvelle paire, publier la clé publique fraîche dans le DNS, basculer le serveur d’envoi sur la nouvelle clé privée, et après propagation, supprimer l’ancien enregistrement.

Dans les faits, presque personne ne le fait. Mais si votre clé privée fuite un jour, un attaquant pourra signer des messages frauduleux à votre place. La rotation réduit cette fenêtre de risque. Et tant qu’on parle de clés, optez pour du RSA 2048 bits. Le 1024 bits est considéré comme trop faible depuis un bon moment déjà.

DMARC : le chef d’orchestre qui définit la politique d’authentification

DMARC, pour Domain-based Message Authentication, Reporting & Conformance, c’est la couche qui vient chapeauter les deux autres. Il ne remplace ni SPF ni DKIM. Son rôle : dire au serveur destinataire quoi faire quand un message rate les vérifications SPF et DKIM.

Sans DMARC, chaque fournisseur fait ce qu’il veut. Gmail rejette, Yahoo classe en spam, un autre laisse passer. C’est la loterie. Avec DMARC, c’est vous qui fixez les règles.

L’alignement : le concept clé de DMARC

DMARC introduit la notion d’« alignement ». Pour qu’un message soit validé par DMARC, le domaine qui apparaît dans le champ « From » doit correspondre au domaine vérifié par SPF ou DKIM. C’est là que DMARC change la donne par rapport à SPF seul : SPF vérifie le domaine de l’enveloppe SMTP, pas celui que le destinataire voit dans sa boîte de réception.

Exemple : votre email affiche « contact@votreentreprise.fr » dans le From. DMARC va vérifier que le domaine SPF ou DKIM colle bien avec « votreentreprise.fr ». En mode « relaxed », les sous-domaines passent, mail.votreentreprise.fr sera accepté. En mode « strict », il faut que ce soit exactement le même domaine, sans variante.

Syntaxe d’un enregistrement DMARC

L’enregistrement DMARC est un enregistrement TXT placé sur le sous-domaine _dmarc :

_dmarc.votredomaine.fr

Exemple de valeur :

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@votredomaine.fr; pct=100; adkim=r; aspf=r

Les paramètres :

• v=DMARC1 : identifiant du protocole
• p= : la politique à appliquer. Trois valeurs possibles :
  • none : ne rien faire, juste collecter les rapports. C’est le point de départ recommandé.
  • quarantine : placer en spam les messages non conformes.
  • reject : rejeter purement et simplement les messages non conformes.
• rua= : adresse email où envoyer les rapports agrégés (quotidiens). Ces rapports XML vous indiquent qui envoie des emails depuis votre domaine et quels messages échouent.
• pct= : pourcentage de messages soumis à la politique. Vous pouvez commencer à 10% et augmenter progressivement.
• adkim= et aspf= : mode d’alignement pour DKIM et SPF (r=relaxed, s=strict).

La montée progressive en politique DMARC

Ne passez jamais directement à « reject ». La bonne approche en trois étapes :

1. p=none pendant 2 à 4 semaines : vous collectez les rapports sans bloquer quoi que ce soit. Vous identifiez tous les services qui envoient pour votre domaine, y compris ceux que vous aviez oubliés.
2. p=quarantine avec pct=25 puis 50 puis 100 : vous montez progressivement. Les messages non conformes sont placés en spam. Vous surveillez les rapports pour vous assurer qu’aucun envoi légitime n’est affecté.
3. p=reject : une fois que tous vos flux sont authentifiés et alignés, vous passez en rejet. À ce stade, tout email non conforme est bloqué.

Comptez entre 1 et 3 mois pour cette montée progressive. Ca demande de la patience, mais le jeu en vaut la chandelle. Un DMARC en reject protège votre domaine contre le spoofing et, on l’a constaté chez nos clients, améliore nettement la délivrabilité des campagnes.

Les erreurs courantes qui sabotent votre authentification

En plus de vingt ans de support technique chez Ediware, on a vu passer les mêmes erreurs des dizaines de fois. Voici celles qui reviennent le plus souvent.

Plusieurs enregistrements SPF sur le même domaine. La norme RFC 7208 est formelle : un domaine ne doit avoir qu’un seul enregistrement SPF. Si vous en avez deux, le résultat est imprévisible. Les serveurs destinataires peuvent choisir l’un ou l’autre, ou considérer le SPF comme invalide. Quand vous ajoutez un nouveau service, il faut ajouter son « include » dans votre enregistrement existant, pas créer un second enregistrement.

Dépasser la limite des 10 lookups DNS en SPF. Chaque include génère un lookup et la norme autorise 10 lookups au maximum. Dépassez ce seuil et votre SPF est considéré comme en erreur permanente (PermError). Le pire, c’est que tout semble normal quand vous testez avec un outil basique qui ne compte pas les lookups imbriqués.

Oublier d’aligner le domaine d’envoi. Vous avez configuré SPF et DKIM sur votredomaine.fr mais votre plateforme emailing envoie depuis mail.votredomaine.fr. Si DMARC est en mode strict, l’alignement échoue. Vérifiez toujours que le domaine du champ From correspond au domaine authentifié, ou utilisez un alignement relaxed.

Ne pas surveiller les rapports DMARC. Publier un enregistrement DMARC en mode « none » sans jamais lire les rapports, c’est comme installer une caméra de surveillance sans regarder les images. Ces rapports vous révèlent les tentatives de spoofing, les services oubliés qui envoient pour votre domaine, les erreurs de configuration. Il existe des outils gratuits et payants pour les analyser : dmarcian, Postmark DMARC, URIports.

Utiliser une clé DKIM trop courte. Les clés RSA 1024 bits sont encore acceptées mais de plus en plus de filtres les pénalisent. Passez en 2048 bits. Ça ne coûte rien et ça renforce la sécurité de vos signatures.

Les outils pour vérifier votre configuration

Vous pensez que tout est bon ? Vérifiez avant de passer à autre chose. Voici les outils qu’on recommande.

MXToolbox (mxtoolbox.com) : c’est un peu le couteau suisse du diagnostic DNS. Vous entrez votre domaine, il vous sort les résultats SPF, DKIM, DMARC et pointe du doigt les erreurs de syntaxe, les lookups en trop, les incohérences. On l’utilise quotidiennement chez Ediware.

Mail-Tester (mail-tester.com) : vous envoyez un email à une adresse temporaire et vous obtenez une note sur 10. SPF, DKIM, DMARC mais aussi le contenu, les blacklists, bref un diagnostic complet en une seule manip. Pratique pour avoir une vue d’ensemble rapide.

Google Postmaster Tools : gratuit, et franchement sous-utilisé. Si vous envoyez vers Gmail, vous y verrez votre taux d’authentification SPF/DKIM/DMARC, la réputation de votre domaine et de vos IP, plus les erreurs de livraison. Pour le suivi au long cours, il n’y a pas mieux.

DMARC Analyzer ou dmarcian : parce que personne ne va lire des rapports XML à la main, ces services les transforment en tableaux de bord lisibles. Qui envoie depuis votre domaine, quels messages échouent, pourquoi. La version gratuite de dmarcian fait le travail pour commencer.

L’en-tête du message : la méthode la plus directe, et souvent oubliée. Dans Gmail, « Afficher l’original » vous donne les résultats SPF, DKIM, DMARC tels que le serveur les a vus. Pass, fail, neutral. Pas d’interprétation, juste la réalité brute de ce qui s’est passé à la réception.

Ce qu’il faut retenir pour votre configuration

Les trois protocoles fonctionnent ensemble, il ne sert pas à grand-chose d’en configurer un en laissant les deux autres de côté. SPF déclare vos serveurs autorisés. DKIM certifie que le contenu n’a pas bougé. DMARC tranche quand quelque chose cloche.

La marche à suivre pour un domaine qui part de zéro :

1. Listez tous les services qui envoient des emails pour votre domaine : plateforme emailing, CRM, helpdesk, facturation, signatures email.
2. Créez un enregistrement SPF unique qui inclut tous ces services, en restant sous la limite de 10 lookups.
3. Configurez DKIM pour chaque service d’envoi avec des clés RSA 2048 bits.
4. Publiez un enregistrement DMARC en mode « none » avec une adresse de rapport.
5. Analysez les rapports pendant 2 à 4 semaines.
6. Montez progressivement vers « quarantine » puis « reject ».
7. Vérifiez régulièrement avec MXToolbox ou Mail-Tester.

Si la sécurité des emails vous préoccupe, et franchement elle devrait préoccuper toute entreprise qui communique par email, ces trois protocoles sont le minimum syndical. Mieux vaut passer quelques heures sur la configuration maintenant que des semaines à comprendre pourquoi vos campagnes atterrissent en spam.

Chez Ediware, on accompagne nos clients sur ces sujets depuis des années. La plateforme génère automatiquement les enregistrements DKIM et SPF qu’il faut publier dans votre DNS. Vous les copiez-collez, vous configurez DMARC en suivant la méthode progressive qu’on vient de décrire, et c’est réglé.

En bref : SPF, DKIM et DMARC sont les trois protocoles qui prouvent aux serveurs de réception que vos emails sont légitimes. Depuis 2024, Google, Yahoo et Microsoft les exigent. Sans eux, vos campagnes emailing risquent tout simplement de ne pas arriver. Ce guide vous accompagne dans leur configuration, étape par étape.

L’authentification email n’est plus optionnelle

Pendant longtemps, configurer SPF, DKIM et DMARC relevait de la bonne pratique. Un « plus » que les entreprises les plus rigoureuses mettaient en place, sans urgence particulière. Ce n’est plus le cas.

Depuis février 2024, Google et Yahoo exigent que tout expéditeur envoyant plus de 5 000 emails par jour ait configuré ces trois protocoles. Microsoft a suivi en mai 2025 avec des exigences similaires. En clair : si votre domaine n’est pas correctement authentifié, vos messages n’arrivent plus en boîte de réception. Ils sont filtrés, mis en spam, ou purement rejetés.

Le contexte explique cette accélération. D’après le rapport 2024 de Cybermalveillance.gouv.fr, 60% des cyberattaques en France commencent par un email frauduleux. Le phishing reste la menace numéro un, et les chiffres continuent de grimper : selon Factoria Groupe, 43% des TPE-PME françaises ont été victimes d’hameçonnage en 2025, contre 24% un an plus tôt. Presque le double.

Face à cette réalité, les fournisseurs de messagerie ont musclé leurs règles. Gmail a réduit de 65% le volume de messages non authentifiés depuis l’entrée en vigueur de ces exigences, d’après PowerDMARC. Le signal est sans ambiguïté : l’authentification n’est plus un sujet technique qu’on remet à plus tard. C’est la condition de base pour que vos campagnes emailing atteignent leurs destinataires.

SPF : déclarer qui a le droit d’envoyer vos emails

SPF, pour Sender Policy Framework, est le premier des trois protocoles à configurer. Son principe est simple : vous publiez dans les DNS de votre domaine la liste des serveurs autorisés à envoyer des emails en votre nom.

Quand un serveur de réception reçoit un email de votre domaine, il consulte votre enregistrement SPF pour vérifier que le serveur expéditeur figure bien sur la liste. Si c’est le cas, le message passe le contrôle. Sinon, il est signalé comme suspect.

En pratique, l’enregistrement SPF est une ligne de texte ajoutée dans la zone DNS de votre domaine, sous forme d’enregistrement TXT :

v=spf1 include:spf.ediware.net include:_spf.google.com ip4:192.168.1.1 ~all

Chaque élément a un rôle précis :

• v=spf1 indique qu’il s’agit d’un enregistrement SPF
• include: autorise les serveurs d’un service tiers, votre plateforme emailing ou votre messagerie d’entreprise
• ip4: autorise une adresse IP spécifique
• ~all indique que tout serveur non listé doit être traité avec méfiance (soft fail)

Deux points méritent une attention particulière. D’abord, la limite des 10 lookups DNS. Chaque include génère une requête DNS, et certains include en appellent d’autres en cascade. Un enregistrement qui semble contenir quatre entrées peut en réalité générer douze lookups. Au-delà de dix, l’enregistrement SPF entier est invalidé. Pas partiellement. Totalement.

Ensuite, la différence entre ~all (soft fail) et -all (hard fail). Le soft fail est recommandé pendant la phase de déploiement, car il laisse passer les messages tout en les signalant. Le hard fail est plus strict mais risque de bloquer des emails légitimes si la configuration n’est pas parfaitement complète.

D’après l’Afnic, 74,4% des domaines de la zone .fr publient une politique SPF en 2025, contre 57,8% en 2023. La progression est nette. Mais cela signifie aussi qu’un quart des domaines français n’ont toujours pas fait cette configuration de base.

DKIM : prouver que vos messages n’ont pas été altérés

Si SPF vérifie qui envoie le message, DKIM vérifie que le message lui-même n’a pas été modifié en chemin. DKIM, pour DomainKeys Identified Mail, repose sur un principe de signature cryptographique.

Votre serveur d’envoi appose une signature numérique sur chaque email sortant. Cette signature est générée à partir d’une clé privée que seul votre serveur connaît. La clé publique correspondante est publiée dans vos DNS. Quand le serveur du destinataire reçoit le message, il récupère la clé publique, vérifie la signature, et s’assure que rien n’a été modifié entre l’envoi et la réception.

L’enregistrement DKIM dans vos DNS prend cette forme :

selecteur._domainkey.votredomaine.com → enregistrement TXT contenant la clé publique

Le « sélecteur » est un identifiant qui permet d’avoir plusieurs clés DKIM pour un même domaine. Chaque service d’envoi utilise généralement son propre sélecteur : votre plateforme emailing en a un, votre messagerie Google Workspace en a un autre.

Sur la taille des clés, Google recommande 2048 bits. Les clés de 1024 bits fonctionnent encore, mais elles sont considérées comme insuffisantes. Si votre configuration DKIM date de quelques années, il y a de bonnes chances que les clés soient trop courtes. Vérifiez et mettez à jour si nécessaire.

Un point souvent négligé : la rotation des clés DKIM. Comme pour un mot de passe, renouveler ses clés périodiquement est une bonne pratique. Tous les six mois à un an, c’est une fréquence raisonnable. Votre plateforme emailing gère généralement cette rotation de manière transparente, mais mieux vaut s’en assurer.

DMARC : décider du sort des emails non conformes

DMARC, pour Domain-based Message Authentication, Reporting and Conformance, est le troisième maillon de la chaîne. Son rôle : indiquer aux serveurs de réception ce qu’ils doivent faire quand un email échoue aux vérifications SPF et DKIM.

Sans DMARC, chaque fournisseur de messagerie applique ses propres règles, de manière opaque. Avec DMARC, c’est vous qui définissez la politique à suivre. Trois options :

• p=none : ne rien faire de particulier, mais recevoir les rapports. C’est le mode d’observation.
• p=quarantine : envoyer les messages suspects en spam.
• p=reject : rejeter purement et simplement les messages non conformes.

L’enregistrement DMARC se publie dans vos DNS, comme SPF :

_dmarc.votredomaine.com → v=DMARC1; p=none; rua=mailto:dmarc-rapports@votredomaine.com

Le paramètre rua indique l’adresse où recevoir les rapports agrégés. Ces rapports, envoyés au format XML par les fournisseurs de messagerie, vous montrent qui envoie des emails avec votre domaine, combien passent l’authentification, combien échouent. Une mine d’informations pour repérer les problèmes de configuration ou les tentatives d’usurpation.

Un point technique souvent mal compris : l’alignement. DMARC vérifie que le domaine visible dans le champ « From » de l’email correspond au domaine authentifié par SPF ou DKIM. Si votre email affiche « contact@votreentreprise.com » mais que le SPF authentifie un domaine différent, DMARC considère l’email comme non conforme, même si SPF passe techniquement.

Il existe aussi un second type de rapport, les rapports forensiques (paramètre ruf), qui fournissent des détails sur chaque email individuel ayant échoué. Ces rapports sont plus précis mais aussi plus sensibles en termes de données personnelles, raison pour laquelle tous les fournisseurs ne les envoient pas.

Malgré l’efficacité prouvée du protocole, l’adoption reste faible à l’échelle mondiale. Selon le rapport EasyDMARC 2025, seuls 5,2% des domaines utilisent la politique p=reject. La grande majorité en reste à p=none, ce qui revient à observer sans vraiment agir. Dans le secteur du retail français, dmarcian constate que seulement 32% des 100 principaux domaines ont une politique DMARC au niveau de l’application. Les 68% restants sont exposés.

Mettre en place SPF, DKIM et DMARC pas à pas

La configuration suit un ordre logique. Brûler les étapes expose à des blocages qu’on aurait pu éviter.

Étape 1 : inventorier tous vos flux d’envoi. Avant de toucher aux DNS, listez l’ensemble des services qui envoient des emails pour votre domaine. Votre plateforme emailing, votre messagerie d’entreprise (Google Workspace, Microsoft 365), votre CRM, votre outil de facturation, votre site web avec ses formulaires de contact et ses notifications. Chaque service oublié sera potentiellement bloqué une fois l’authentification active.

Étape 2 : configurer SPF. Créez un enregistrement TXT dans votre zone DNS qui autorise tous les services identifiés. Vérifiez que vous ne dépassez pas les 10 lookups DNS. Si c’est le cas, regroupez certaines entrées ou utilisez une technique appelée « SPF flattening » qui remplace les include par les adresses IP correspondantes.

Étape 3 : activer DKIM. Pour chaque service d’envoi, générez une paire de clés DKIM depuis son interface d’administration. Publiez la clé publique dans vos DNS. Activez la signature dans les paramètres du service. Vérifiez que la clé fait bien 2048 bits.

Étape 4 : publier DMARC en mode observation. Commencez avec p=none. C’est la recommandation de Google et de la M3AAWG, l’organisation de référence en matière de lutte contre les abus par email. À ce stade, aucun message n’est bloqué. Vous collectez simplement les données.

Étape 5 : analyser les rapports. Patientez deux à quatre semaines pour accumuler suffisamment de données. Les rapports DMARC en XML sont illisibles à l’oeil nu. Des outils gratuits comme MXToolbox ou dmarcian les transforment en tableaux compréhensibles. Identifiez les services qui échouent et corrigez leur configuration.

Étape 6 : durcir progressivement la politique. Une fois que tous vos flux légitimes passent correctement, passez à p=quarantine. Surveillez encore quelques semaines. Si tout est stable, basculez vers p=reject. Cette montée en puissance est indispensable pour ne pas couper vos propres envois.

Google recommande d’attendre 48 heures entre la mise en place de SPF/DKIM et la publication du DMARC, le temps que les enregistrements DNS se propagent correctement.

Les erreurs de configuration qui passent inaperçues

Certaines erreurs sont fréquentes et peuvent rester invisibles pendant des mois. Le temps qu’un problème de délivrabilité remonte, des campagnes entières auront été dégradées sans que personne ne s’en aperçoive.

Dépasser les 10 lookups SPF. L’erreur la plus répandue. Chaque include déclenche une requête DNS, et certains en appellent d’autres en cascade. Un enregistrement qui semble contenir quatre include peut en réalité générer douze lookups. Au-delà de dix, l’enregistrement SPF entier devient invalide. Pas partiellement, totalement. Vérifiez avec un outil comme MXToolbox SPF Checker.

Oublier un service d’envoi. Votre comptabilité envoie des factures par email, votre support technique envoie des notifications, votre site WordPress envoie des confirmations de formulaire. Si ces services ne figurent pas dans votre SPF et ne signent pas en DKIM, leurs emails échoueront systématiquement. D’où l’importance de l’inventaire initial.

Utiliser des clés DKIM obsolètes. Les clés de 512 ou 1024 bits ne sont plus considérées comme sûres. Si votre DKIM a été mis en place il y a plusieurs années, les clés sont probablement trop courtes. La mise à jour prend quelques minutes mais elle change tout.

Passer trop vite à p=reject. La tentation est forte de vouloir verrouiller rapidement. Mais si un service d’envoi légitime n’est pas correctement authentifié, ses emails seront rejetés sans préavis. Et vous ne le saurez peut-être pas tout de suite. La progression none → quarantine → reject doit se faire sur plusieurs semaines, rapports à l’appui.

Ne pas activer les rapports DMARC. Publier un enregistrement DMARC sans le paramètre rua revient à naviguer sans instruments. Sans rapports, impossible de savoir ce qui passe, ce qui échoue, ou qui tente d’usurper votre domaine.

Ignorer le forwarding. Quand un email est transféré par un intermédiaire, le SPF casse. Le serveur qui transfère n’est pas dans votre liste d’expéditeurs autorisés. DKIM résiste mieux au forwarding car la signature reste intacte. C’est une raison supplémentaire de configurer les deux protocoles et de ne pas se reposer uniquement sur SPF.

Vérifier et surveiller votre authentification

Configurer SPF, DKIM et DMARC ne suffit pas. La vérification initiale et la surveillance continue font partie du processus.

Les outils de vérification immédiate. Plusieurs services en ligne testent votre configuration en quelques secondes. MXToolbox vérifie vos enregistrements SPF, DKIM et DMARC et signale les erreurs. Mail-Tester donne un score de délivrabilité après l’envoi d’un email test. Google Admin Toolbox permet de vérifier spécifiquement les enregistrements DNS. Pour aller plus loin, consultez notre guide complet sur l’authentification email SPF, DKIM et DMARC.

Google Postmaster Tools. Si vous envoyez des volumes significatifs vers des adresses Gmail, cet outil gratuit est indispensable. Il affiche votre taux de spam, votre réputation de domaine, le taux d’authentification SPF/DKIM/DMARC, et les erreurs de livraison. C’est le tableau de bord que Google met à la disposition des expéditeurs pour surveiller leur santé d’envoi.

La lecture des rapports DMARC. Les rapports agrégés arrivent au format XML dans la boîte email configurée. Ils contiennent le volume de messages envoyés depuis votre domaine, les résultats d’authentification pour chaque source d’envoi, et les actions prises par les serveurs destinataires. Des outils comme dmarcian ou MXToolbox DMARC Report Analyzer convertissent ces fichiers en tableaux compréhensibles.

Ce qu’il faut surveiller régulièrement :

• Le taux de spam signalé, que Google recommande de maintenir sous 0,10% avec un seuil critique à 0,3%
• Les sources d’envoi non identifiées dans vos rapports DMARC, qui peuvent signaler une tentative d’usurpation
• La validité de vos enregistrements DNS après toute modification de votre infrastructure

L’authentification email n’est pas un projet ponctuel qu’on coche et qu’on oublie. C’est un processus continu. À chaque ajout de service d’envoi, changement de prestataire ou modification DNS, une vérification s’impose.

L’authentification au service de votre délivrabilité B2B

SPF, DKIM et DMARC ne sont pas que des protocoles de sécurité. Ce sont les fondations de votre réputation d’expéditeur. Et en emailing B2B, la réputation conditionne directement la délivrabilité de vos emailing B2B.

Les fournisseurs de messagerie évaluent chaque domaine expéditeur selon plusieurs critères : taux de plaintes, taux de hard bounces et soft bounces, engagement des destinataires, et authentification. Un domaine correctement authentifié part avec un avantage. Un domaine sans authentification part avec un handicap, quelle que soit la qualité de son contenu.

Pour les entreprises qui font de la prospection par email ou qui gèrent des campagnes de nurturing, l’enjeu est concret. Un email qui n’arrive pas en boîte de réception ne sera jamais lu, jamais cliqué, et ne générera jamais de lead. L’authentification est la condition préalable à tout le reste : objet travaillé, contenu pertinent, segmentation fine. Tout cela n’a de valeur que si le message arrive.

Et il ne s’agit pas seulement des grands volumes. Même une entreprise qui envoie quelques centaines d’emails par semaine bénéficie d’une authentification correcte. Les filtres anti-spam ne font pas de distinction : un domaine sans SPF ni DKIM est un domaine suspect, point. Par ailleurs, si un tiers usurpe votre domaine pour envoyer du spam, c’est votre réputation d’expéditeur qui en pâtit directement, avec des conséquences sur la délivrabilité de vos propres campagnes.

Le paysage réglementaire continue d’évoluer vers plus de rigueur. Après Google et Yahoo en 2024, Microsoft en 2025, la norme PCI DSS v4.0 rendra DMARC obligatoire en 2026 pour les organisations traitant des données de cartes bancaires. La tendance est claire et ne s’inversera pas.

Si vous n’avez pas encore configuré SPF, DKIM et DMARC sur votre domaine, c’est le moment de le faire. La mise en place prend quelques heures au plus, et les bénéfices sur votre délivrabilité sont immédiats. Et si la configuration est déjà en place, vérifiez qu’elle est à jour : clés DKIM en 2048 bits, politique DMARC qui progresse vers p=quarantine ou p=reject, tous vos flux d’envoi correctement déclarés.