Vos e-mails partent en spam ou sont imités ? SPF, DKIM et DMARC expliqués simplement

N'importe qui peut envoyer un e-mail qui affiche votre adresse comme expéditeur, et vos vrais devis peuvent finir dans les indésirables de vos clients. Trois réglages de votre nom de domaine, SPF, DKIM et DMARC, répondent à ces deux problèmes. Voici ce que fait chacun, ce qu'exigent les grandes messageries et comment les mettre en place sans bloquer vos propres e-mails.

01Pourquoi votre nom de domaine est en jeu

L'ANSSI le rappelle : l'adresse source d'un courriel « est laissée à la discrétion de l'expéditeur », et le protocole d'envoi permet « par construction » d'usurper un domaine (recommandations relatives à l'interconnexion d'un SI à Internet, version 3.0, juin 2020). Un escroc peut donc écrire à vos clients avec votre adresse exacte, par exemple pour annoncer un faux changement de RIB.

Second risque, inverse : sans ces réglages, prévient Google, il est possible que vos e-mails « ne soient pas distribués comme prévu ou soient marqués comme spam » (consignes pour les expéditeurs, consultées le 30 octobre 2026).

02Trois réglages, trois images

Tous trois se configurent dans la zone DNS de votre domaine, l'annuaire public qui indique où trouver votre site et votre messagerie.

SPF : la liste des expéditeurs autorisés

SPF (Sender Policy Framework, RFC 7208) revient à afficher la liste des transporteurs autorisés à livrer en votre nom : le serveur qui reçoit l'e-mail vérifie que le serveur d'envoi y figure. Limite : SPF contrôle l'adresse technique d'envoi, dite « d'enveloppe », pas forcément celle que lit le destinataire.

DKIM : le cachet de cire

DKIM (DomainKeys Identified Mail, RFC 6376) appose sur chaque message une signature cryptographique, comme un cachet de cire. Grâce à la clé publiée dans votre zone DNS, le destinataire vérifie que le message a été signé pour votre domaine et que les parties signées n'ont pas été modifiées.

DMARC : la consigne laissée au gardien

DMARC vérifie que le domaine validé par SPF ou par DKIM correspond à l'expéditeur affiché (on parle d'alignement) ; un des deux suffit. Il indique ensuite quoi faire des messages qui échouent, comme une consigne laissée au gardien pour les visiteurs sans badge, et demande des rapports.

Bon à savoir

La norme DMARC a été révisée en mai 2026. La RFC 9989 remplace la RFC 7489, et la version indiquée dans l'enregistrement reste v=DMARC1.

03Ce qu'exigent Gmail, Yahoo et Outlook

Les trois acceptent une politique DMARC en p=none. Chez Google, le statut de gros expéditeur est définitif dès que le seuil a été atteint une fois, et Gmail renforce depuis novembre 2025 l'application des règles, avec des rejets temporaires et permanents (FAQ Google). Chez Microsoft, les messages non conformes vont dans les indésirables, puis peuvent être rejetés si le problème persiste (pages consultées le 30 octobre 2026).

04Les trois politiques DMARC, à durcir progressivement

• p=none : aucune action, vous observez grâce aux rapports ;
• p=quarantine : le message est jugé suspect, en pratique classé en indésirables ;
• p=reject : le message est refusé.

L'ANSSI recommande d'analyser d'abord les statistiques en p=none, « avant d'activer une politique plus stricte » (recommandation R48). Google demande d'attendre 48 heures après avoir configuré SPF ou DKIM (aide Google Workspace, mise à jour le 28 octobre 2026). Avant reject, la RFC 9989 suggère au moins un mois en none, puis autant en quarantine, et prévient que reject peut faire rejeter des messages légitimes passés par une liste de diffusion.

Un premier enregistrement, publié sous le nom _dmarc.votre-domaine.fr, peut être v=DMARC1; p=none; rua=mailto:dmarc@votre-domaine.fr : v signale un enregistrement DMARC, p=none n'applique aucune sanction, rua donne l'adresse des rapports.

En 2025, 19,5 % des noms de domaine en .fr publiaient une politique DMARC, et 49,7 % de ces politiques étaient en p=none sans adresse de rapports (Afnic, 30 septembre 2025) : aucune action, aucun rapport.

Les rapports DMARC

Les messageries envoient des rapports agrégés, en général une fois par jour, en fichier XML souvent compressé (Microsoft Learn, mise à jour le 3 juillet 2026). Ils listent les sources qui envoient avec votre domaine et leurs résultats : l'outil de facturation oublié y apparaît, comme l'usurpateur. Google conseille une boîte dédiée, le volume pouvant être important, et Microsoft un service d'analyse.

05Les pièges fréquents

• Deux enregistrements SPF : un domaine ne doit en avoir qu'un, sinon la vérification échoue (RFC 7208, sections 3.2 et 4.5). Un nouveau service s'ajoute dans l'enregistrement existant (aide Google).
• Plus de 10 consultations DNS : chaque service ajouté par un include en coûte au moins une. Au-delà de 10, SPF échoue (section 4.6.4). Microsoft conseille de placer les envois en masse sur un sous-domaine (Microsoft Learn, mise à jour le 5 août 2026).
• Les logiciels qui écrivent en votre nom : facturation, lettre d'information, formulaire du site web. Chacun doit être autorisé par SPF ou signer avec DKIM pour votre domaine, sinon DMARC bloquera ses messages.
• DKIM jamais activé : Microsoft 365 ne signe pas les messages de votre propre domaine tant que vous n'avez pas créé deux enregistrements DNS puis activé DKIM (Microsoft Learn). Google Workspace demande de générer une clé, de la publier dans la zone DNS, puis de cliquer sur « Lancer l'authentification » (aide Google).
• Les domaines qui n'envoient rien : Microsoft recommande d'y publier un SPF qui n'autorise personne (v=spf1 -all) et un DMARC en p=reject.

Attention

L'ANSSI rappelle que ces réglages ne protègent ni du « typosquattage » (un domaine qui ressemble au vôtre), ni d'un courriel piégé, ni d'une usurpation en amont du serveur d'envoi. Un message parti d'une vraie boîte piratée passe ces contrôles. Voyez nos 10 signes d'hameçonnage et messagerie piratée : que faire.

06Qui s'en occupe, et comment vérifier

Les enregistrements se créent chez le bureau d'enregistrement du domaine ou chez l'hébergeur DNS, « souvent la même société », précise Microsoft. Votre prestataire informatique peut s'en charger, mais l'entreprise doit garder l'accès à ce compte : voyez notre article sur le changement de prestataire informatique.

Pour vérifier :

• Envoyez-vous un e-mail sur Gmail, ouvrez Plus > Afficher l'original (aide Gmail) et cherchez la ligne « Authentication-Results » : vous visez spf=pass, dkim=pass et dmarc=pass.
• Testez le domaine : le test de messagerie d'Internet.nl, initiative de la communauté Internet et du gouvernement néerlandais (en anglais), contrôle SPF, DKIM et DMARC ; Check MX, de Google, contrôle MX et SPF.
• Suivez la documentation de votre messagerie : les pages Microsoft et Google citées plus haut donnent les valeurs à saisir.

07La checklist

1. Listez tous les services qui envoient des e-mails avec votre domaine.
2. Gardez un seul enregistrement SPF qui les couvre, sans dépasser 10 consultations DNS.
3. Activez DKIM partout où c'est possible.
4. Attendez 48 heures, puis publiez DMARC en p=none avec une adresse de rapports dédiée.
5. Lisez les rapports au moins un mois et corrigez les oublis.
6. Passez en p=quarantine, puis en p=reject.
7. Protégez les domaines qui n'envoient rien.
8. Revoyez l'ensemble à chaque nouvel outil.

À retenir

Commencez toujours par p=none. Passer directement en p=reject peut bloquer vos propres factures si un outil a été oublié.

En résumé

• SPF liste les serveurs autorisés, DKIM signe les messages, DMARC vérifie le domaine affiché et dit quoi faire des échecs.
• Google et Yahoo exigent au moins SPF ou DKIM de tous ; Gmail, Yahoo et Outlook.com exigent DMARC des gros expéditeurs.
• Durcissez DMARC par étapes, rapports à l'appui.
• Un seul SPF, 10 consultations DNS au plus, aucun logiciel tiers oublié.

Pour un audit de la sécurité de votre informatique, découvrez nos solutions de cybersécurité. Vous pouvez aussi nous contacter du lundi au vendredi, de 9 h à 18 h.