Délivrabilité e-mail : SPF, DKIM et DMARC expliqués simplement

« Le client dit qu'il n'a jamais reçu sa confirmation de commande. » « On n'a plus aucune demande par le formulaire de contact depuis un mois. » Ces phrases, nous les entendons régulièrement, et dans la grande majorité des cas le site fonctionne très bien : c'est l'e-mail qui se perd en route. Il part, mais il n'arrive pas, ou il arrive directement dans les indésirables, parfois avec un bandeau d'avertissement qui le fait passer pour une tentative de fraude.

Ce guide explique, sans jargon inutile, ce qui décide du sort d'un e-mail et comment le configurer correctement pour votre domaine.

Qu'est-ce que la délivrabilité e-mail ?

La délivrabilité, c'est la capacité de vos e-mails à arriver dans la boîte de réception de leur destinataire. Ce n'est pas la même chose qu'un envoi réussi : votre serveur peut très bien indiquer « message envoyé » alors que Gmail ou Outlook l'a classé en spam, mis de côté ou refusé sans prévenir personne.

Les fournisseurs de messagerie reçoivent chaque jour des milliards d'e-mails, dont une bonne partie sont frauduleux. Avant d'accepter un message, ils vérifient donc deux choses : que l'expéditeur est bien celui qu'il prétend être (c'est le rôle de SPF, DKIM et DMARC), et qu'il a une réputation correcte. Si l'un des deux manque, le message part au mieux dans les indésirables.

Ce que ça coûte quand ça ne marche pas

Le problème des e-mails perdus, c'est qu'ils ne font aucun bruit. Personne ne se plaint d'un message qu'il n'a pas reçu. Voici les cas que nous rencontrons le plus souvent :

• Les formulaires de contact : les demandes de devis ou de renseignements partent vers une boîte qui ne les reçoit jamais. On s'en aperçoit des semaines plus tard, quand un prospect relance par téléphone ou ne relance pas du tout. Ce sont des opportunités perdues sans même le savoir.
• Les sites e-commerce : confirmation de commande, facture, suivi de livraison, réinitialisation de mot de passe. Pour une boutique en ligne, ces e-mails font partie de la relation client. S'ils tombent en spam ou s'affichent comme suspects, le client doute, appelle le service client, voire annule.
• Les notifications d'applications : invitations, alertes, validations de compte. Un utilisateur qui ne reçoit pas son lien d'activation abandonne simplement l'inscription.
• L'usurpation de votre domaine : sans protection, n'importe qui peut envoyer un e-mail qui semble venir de votre adresse. C'est la base de nombreuses arnaques au faux fournisseur ou à la fausse facture, et c'est votre nom qui en pâtit.

Le parcours d'un e-mail

Entre le clic sur « Envoyer » et l'arrivée dans la boîte du destinataire, le message passe par plusieurs intermédiaires. Le serveur qui le reçoit (celui de Gmail, d'Outlook, d'Orange…) va consulter la zone DNS de votre domaine pour savoir si l'expéditeur est légitime. C'est dans cette zone DNS que se trouvent les trois enregistrements SPF, DKIM et DMARC.

Les trois mécanismes sont complémentaires. Aucun ne suffit seul, et c'est leur combinaison que les grands fournisseurs exigent aujourd'hui.

SPF : qui a le droit d'envoyer pour votre domaine

L'enregistrement SPF est une liste des serveurs autorisés à envoyer des e-mails au nom de votre domaine. Quand un message arrive, le serveur de réception regarde d'où il vient et vérifie que cette origine figure bien dans la liste.

Exemple pour un domaine qui utilise Google Workspace pour la messagerie et Brevo pour les envois du site :

; Enregistrement TXT à la racine du domaine
exemple.fr.  IN  TXT  "v=spf1 include:_spf.google.com include:spf.brevo.com ~all"

; v=spf1                  : c'est un enregistrement SPF
; include:...             : on autorise les serveurs de chaque prestataire
; ~all                    : tout le reste est suspect (-all : tout le reste est refusé)

Les erreurs que nous corrigeons le plus souvent

• Deux enregistrements SPF sur le même domaine, souvent parce qu'un prestataire en a ajouté un sans regarder ce qui existait. Il ne doit y en avoir qu'un seul : avec deux, le contrôle échoue purement et simplement.
• Un SPF trop long. La norme limite à 10 le nombre de consultations DNS nécessaires pour évaluer l'enregistrement. Chaque include en consomme au moins une, parfois plusieurs. Au-delà de cette limite, le SPF est considéré comme invalide.
• Des restes d'anciens prestataires : l'hébergeur d'il y a cinq ans, un outil d'e-mailing abandonné… Ces autorisations inutiles alourdissent l'enregistrement et laissent des portes ouvertes.
• Un serveur oublié : le site est hébergé à un endroit, la messagerie à un autre, la facturation passe par un troisième service. Celui qu'on a oublié de déclarer voit ses e-mails partir en spam.

DKIM : une signature qui prouve l'authenticité

DKIM ajoute une signature numérique à chaque e-mail envoyé. Le service d'envoi signe le message avec une clé privée qu'il est seul à connaître, et publie la clé publique correspondante dans votre zone DNS. Le serveur de réception utilise cette clé publique pour vérifier deux choses : que le message vient bien de votre domaine, et qu'il n'a pas été modifié en chemin.

; La clé publique est publiée sous un « sélecteur » choisi par le service d'envoi
s1._domainkey.exemple.fr.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…"

Chaque service qui envoie pour vous (messagerie, newsletter, boutique, CRM…) a sa propre clé DKIM, avec son propre sélecteur. Il faut donc autant d'enregistrements que de services.

Piège fréquent : chez certains fournisseurs, la signature DKIM n'est pas active par défaut. L'enregistrement est bien publié dans le DNS, mais il faut encore l'activer dans l'interface du service. Autre classique : certaines interfaces DNS coupent les valeurs trop longues, et une clé tronquée ne fonctionne plus.

DMARC : la règle du jeu et les rapports

DMARC fait deux choses. D'abord, il indique au serveur de réception quoi faire d'un e-mail qui échoue aux contrôles : le laisser passer, le mettre en indésirables ou le refuser. Ensuite, il demande aux grands fournisseurs de vous envoyer des rapports réguliers sur tous les e-mails qu'ils ont reçus à votre nom.

DMARC ajoute aussi une exigence souvent méconnue, l'alignement : il ne suffit pas qu'un e-mail passe SPF ou DKIM, il faut que le domaine vérifié corresponde au domaine affiché dans le champ « De » que voit le destinataire. Un service d'envoi peut très bien passer SPF avec son propre domaine, ce qui ne prouve rien pour le vôtre. C'est souvent à cet endroit que tout se joue.

; Étape 1 : observer sans rien bloquer
_dmarc.exemple.fr.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@exemple.fr"

; Étape 2 : les e-mails non conformes vont en indésirables
_dmarc.exemple.fr.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@exemple.fr"

; Étape 3 : les e-mails non conformes sont refusés
_dmarc.exemple.fr.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@exemple.fr"

Pourquoi ne pas passer directement en « reject »

C'est tentant, mais c'est le meilleur moyen de bloquer des e-mails légitimes. Dans presque toutes les entreprises, il existe un outil qui envoie au nom du domaine et que personne n'a en tête : le logiciel de facturation, l'outil de prise de rendez-vous, un ancien site encore en ligne, le copieur qui envoie les numérisations par e-mail… Avec une politique stricte, tous ces envois sont refusés du jour au lendemain.

La politique p=none sert justement à observer. Les rapports DMARC montrent qui envoie réellement au nom de votre domaine, et lesquels de ces envois échouent. On corrige, on attend d'avoir une vision claire, puis on durcit la politique par étapes. Les rapports sont des fichiers techniques peu lisibles en l'état : il faut les analyser, à la main ou avec un outil dédié, pour en tirer quelque chose.

Et les domaines qui n'envoient jamais d'e-mail ?

Ils sont souvent oubliés, et c'est une erreur : un domaine sans protection est idéal pour l'usurpation. Pour un domaine secondaire, une ancienne marque ou un nom réservé pour plus tard, deux lignes suffisent à déclarer qu'aucun e-mail légitime n'en partira jamais :

exemple-marque.fr.         IN  TXT  "v=spf1 -all"
_dmarc.exemple-marque.fr.  IN  TXT  "v=DMARC1; p=reject"

Les exigences de Gmail, Yahoo et Microsoft

Depuis février 2024, Gmail et Yahoo imposent des règles plus strictes aux expéditeurs, et Microsoft a suivi en 2025 pour ses messageries Outlook.com et Hotmail. Pour tous les expéditeurs, un minimum d'authentification (SPF ou DKIM) est désormais attendu. Pour ceux qui envoient en volume (plus de 5 000 e-mails par jour vers ces messageries), la barre est plus haute :

• SPF et DKIM configurés ;
• un enregistrement DMARC publié, au minimum en p=none, avec un domaine aligné sur l'adresse d'expédition ;
• un lien de désinscription en un clic dans les e-mails marketing ;
• un taux de signalement comme spam maintenu très bas.

Même si vous n'atteignez pas ces volumes, ces règles sont devenues la référence. Un domaine qui les respecte part avec un avantage, et l'exigence ne fait que monter d'année en année.

La réputation : l'authentification ne fait pas tout

SPF, DKIM et DMARC prouvent que vous êtes bien vous. Ils ne prouvent pas que vos e-mails sont désirés. Pour cela, les fournisseurs tiennent compte de la réputation de votre domaine et des serveurs qui envoient pour vous, construite au fil des envois.

• Le serveur d'envoi compte. Sur un hébergement mutualisé, votre site partage souvent son adresse IP avec des centaines d'autres. Si l'un d'eux envoie du spam, l'adresse peut finir sur une liste noire, et vos e-mails avec.
• Les signalements comptent. Un destinataire qui clique sur « Signaler comme spam » pèse lourd. Écrire à des personnes qui ne l'ont pas demandé, ou rendre la désinscription difficile, finit toujours par se payer.
• Séparer les usages aide. Envoyer les newsletters depuis un sous-domaine (par exemple news.exemple.fr) protège les e-mails importants : si une campagne est mal reçue, les confirmations de commande et les échanges courants ne sont pas pénalisés.
• Les adresses invalides comptent aussi. Une liste de contacts ancienne, pleine d'adresses qui n'existent plus, envoie un mauvais signal à chaque campagne.

E-mails transactionnels : le cas des sites web et des CMS

C'est le sujet que nous traitons le plus souvent. Les e-mails envoyés automatiquement par un site (formulaire de contact, commande, création de compte) sont appelés transactionnels, et ce sont généralement les plus importants. Ce sont aussi ceux qui sont le plus souvent mal configurés.

Le piège de l'envoi « par défaut »

Par défaut, un site WordPress ou une application PHP confie ses e-mails directement au serveur qui l'héberge, via la fonction mail(). Ce serveur n'est généralement déclaré nulle part : pas dans le SPF, pas de signature DKIM. Pour Gmail ou Outlook, c'est un inconnu qui prétend écrire au nom de votre domaine. Sur un serveur dédié, une machine virtuelle ou un conteneur Docker, c'est encore pire : il n'y a parfois aucun service d'envoi configuré, et les e-mails ne partent tout simplement pas.

La solution consiste à faire passer les envois par un service authentifié : soit le serveur SMTP de votre messagerie, soit un service d'envoi spécialisé (Brevo, par exemple) via SMTP ou via son API. Ce service est ensuite déclaré dans le SPF et signe les e-mails avec DKIM. Les services spécialisés apportent aussi un historique des envois, bien utile pour vérifier qu'un e-mail est bien parti. Sur WordPress, des extensions comme WP Mail SMTP ou FluentSMTP font très bien ce travail.

L'adresse de l'expéditeur dans les formulaires

Erreur classique : le formulaire de contact envoie l'e-mail « de la part » de l'adresse saisie par le visiteur, par exemple jean.dupont@gmail.com, pour pouvoir lui répondre directement. Sauf que votre serveur n'a aucun droit d'envoyer au nom de Gmail : le message échoue à DMARC et il est rejeté. La bonne pratique est d'envoyer depuis une adresse de votre domaine (formulaire@exemple.fr) et de placer l'adresse du visiteur dans le champ « Répondre à » (Reply-To). Le bouton « Répondre » fonctionne exactement de la même façon.

Notre méthode

On imagine souvent que configurer DMARC suffit. En pratique, c'est la dernière étape. Tout le travail se fait avant :

1. Faire l'inventaire de tout ce qui envoie des e-mails au nom du domaine : messagerie, site, boutique, outils métier, newsletter, services tiers.
2. Analyser la zone DNS et les serveurs : ce qui est déclaré, ce qui manque, ce qui ne sert plus. Nous travaillons avec tous types d'infrastructures, de l'hébergeur grand public au serveur dédié, en passant par Docker, AWS ou Cloudflare.
3. Mettre en place un service d'envoi si besoin, pour que les sites et applications n'envoient plus « par défaut », et le déclarer correctement.
4. Nettoyer et corriger SPF et DKIM pour chaque service légitime.
5. Publier DMARC en observation, analyser les rapports pendant quelques semaines et corriger les envois qui échouent.
6. Durcir la politique par étapes, puis continuer à surveiller les rapports : un nouvel outil ajouté l'année suivante peut tout remettre en cause.

La délivrabilité est aussi une question de sécurité web : protéger son domaine contre l'usurpation, c'est protéger ses clients. Pour les sites que nous suivons, elle fait partie de la maintenance.