SPF, DKIM et DMARC : le guide complet pour authentifier vos emails

Pour authentifier vos emails et empêcher qu'on usurpe votre nom de domaine, il faut publier trois enregistrements DNS complémentaires : SPF, DKIM et DMARC. SPF déclare quels serveurs ont le droit d'envoyer en votre nom, DKIM signe chaque message, et DMARC relie les deux à l'adresse que voit le destinataire tout en indiquant quoi faire en cas d'échec.

Ces trois sigles font peur, mais le principe est simple : ils prouvent au serveur qui reçoit votre email que vous êtes bien vous. Sans eux, un fraudeur peut envoyer un message signé de votre domaine, et vos propres emails légitimes risquent de tomber en spam. Ce guide complet vous explique à quoi sert chacun, comment ils s'articulent, et comment les mettre en place dans le bon ordre, sans jargon inutile.

À quoi servent SPF, DKIM et DMARC

Quand vous envoyez un email, rien n'empêche techniquement un inconnu d'écrire à votre place en affichant votre adresse dans le champ « De ». Le protocole d'envoi d'origine n'a jamais été conçu pour vérifier l'identité de l'expéditeur. C'est exactement cette faille qu'exploitent l'usurpation d'identité (le « spoofing ») et une grande partie des campagnes de phishing.

SPF, DKIM et DMARC sont trois mécanismes qui comblent ce manque, chacun à sa manière. Ils répondent à deux besoins concrets :

• Protéger votre nom de domaine. Empêcher qu'un escroc envoie une fausse facture ou un faux message de direction en se faisant passer pour votre entreprise.
• Améliorer votre délivrabilité. Un email correctement authentifié inspire confiance aux serveurs qui le reçoivent. À l'inverse, un domaine sans authentification voit ses messages légitimes plus facilement classés en courrier indésirable.

Retenez une image simple pour la suite : SPF est la liste des invités, DKIM est le sceau sur l'enveloppe, et DMARC est le videur qui vérifie que les deux correspondent et décide de laisser entrer ou non.

SPF : déclarer vos serveurs autorisés

Le SPF (Sender Policy Framework) est un enregistrement que vous publiez dans la zone DNS de votre domaine pour lister les serveurs autorisés à envoyer des emails en votre nom. Quand un serveur reçoit un message prétendant venir de chez vous, il consulte cet enregistrement et vérifie que le serveur expéditeur y figure bien.

Concrètement, SPF prend la forme d'un unique enregistrement TXT à la racine de votre domaine :

Décortiquons cette ligne : v=spf1 annonce la version, include:_spf.google.com autorise les serveurs de Google, et ~all indique comment traiter tout serveur non listé. Ce dernier élément, le qualificateur final, mérite une explication :

• ~all (softfail) : les emails d'un serveur non autorisé sont acceptés mais marqués comme suspects. C'est le réglage recommandé au début.
• -all (hardfail) : ils sont rejetés. Plus strict, à n'activer qu'une fois sûr d'avoir listé tous vos expéditeurs légitimes.
• ?all (neutre) : aucune position. À éviter, car cela revient à ne rien protéger.

Attention aussi à la limite de dix requêtes DNS : au-delà, SPF renvoie une erreur de type « too many DNS lookups » et cesse de fonctionner. Nous consacrerons un guide dédié à ce problème précis et à sa correction.

DKIM : signer vos messages

Le DKIM (DomainKeys Identified Mail) ajoute à chaque email une signature cryptographique invisible pour le lecteur, mais vérifiable par le serveur destinataire. Cette signature garantit deux choses : que le message vient bien de votre domaine, et qu'il n'a pas été altéré en route.

Le principe repose sur une paire de clés. Votre serveur d'envoi signe chaque message avec une clé privée qu'il garde secrète. Vous publiez la clé publique correspondante dans votre DNS. Le destinataire récupère cette clé publique pour vérifier la signature.

L'enregistrement DKIM se place à un emplacement particulier, construit à partir d'un « sélecteur » fourni par votre messagerie :

Contrairement à SPF, vous ne rédigez pas la valeur vous-même : votre fournisseur de messagerie (Google Workspace, Microsoft 365, ou l'interface de votre hébergeur) génère la clé et vous indique le sélecteur et la valeur exacts à recopier. Votre travail se limite à activer la signature côté messagerie puis à publier la clé publique côté DNS.

DMARC : la politique qui relie le tout

SPF et DKIM vérifient chacun un aspect technique, mais ni l'un ni l'autre ne regarde l'adresse que voit réellement le destinataire dans le champ « De ». C'est le rôle du DMARC (Domain-based Message Authentication, Reporting and Conformance). Il vérifie que l'adresse visible correspond bien au domaine authentifié par SPF ou DKIM, ce qu'on appelle l'alignement, puis il indique au serveur destinataire quoi faire quand ce n'est pas le cas.

DMARC se publie lui aussi en enregistrement TXT, à un emplacement dédié :

Le paramètre p= définit la politique appliquée aux messages qui échouent :

• p=none : on observe seulement. Aucun email n'est bloqué, mais vous recevez des rapports. C'est le point de départ obligatoire.
• p=quarantine : les messages non conformes sont placés en spam.
• p=reject : ils sont purement refusés. C'est l'objectif final, une fois vos flux légitimes bien identifiés.

Le paramètre rua indique l'adresse qui recevra les rapports agrégés. Ces rapports, envoyés par les serveurs destinataires, vous disent qui envoie des emails en votre nom : vos outils légitimes… et les éventuels usurpateurs. C'est ce qui vous permet de passer sereinement de l'observation au blocage.

Comment les trois fonctionnent ensemble

SPF, DKIM et DMARC ne se remplaçent pas : ils se complètent. Chacun couvre un angle que les autres laissent ouvert. Voici leur répartition des rôles :

Un email est considéré comme pleinement authentifié lorsqu'il passe SPF ou DKIM, et que le domaine correspondant est aligné avec l'adresse affichée, selon la règle fixée par DMARC. C'est cette combinaison qui ferme la porte à l'usurpation tout en préservant vos envois légitimes.

Mettre en place l'authentification, étape par étape

La bonne démarche consiste à avancer dans l'ordre et à ne durcir DMARC qu'une fois sûr de vos flux. Voici la marche à suivre.

Ces trois enregistrements se posent dans la zone DNS de votre domaine, au même endroit que vos enregistrements MX. Si la manipulation de ces enregistrements ne vous est pas familière, notre pilier consacré au sujet détaille comment intervenir en sécurité.

Vérifier que tout fonctionne

Une fois vos enregistrements publiés, la propagation DNS prend de quelques minutes à quelques heures selon la valeur du TTL. Plusieurs méthodes gratuites permettent ensuite de contrôler que l'authentification est bien en place :

• Envoyez-vous un email de test vers une adresse Gmail, puis affichez la source du message : vous y verrez les mentions spf=pass, dkim=pass et dmarc=pass.
• Utilisez un outil d'analyse en ligne qui interroge votre domaine et affiche l'état de chaque enregistrement.
• Lisez vos premiers rapports DMARC : ils confirment que les serveurs distants voient bien votre configuration.

Les erreurs fréquentes

La plupart des échecs d'authentification viennent d'un petit nombre de causes récurrentes. Les connaître à l'avance vous fait gagner un temps considérable.

Aller plus loin

SPF, DKIM et DMARC se configurent dans la même zone DNS que vos enregistrements MX. Si vous devez d'abord maîtriser cette zone, commencez par notre guide pour changer ses enregistrements MX sans perdre un seul email.

Premier guide de ce silo : à quoi sert un enregistrement MX et comment le lire. Suivront d'autres guides détaillés : vérifier votre configuration SPF, DKIM et DMARC, choisir votre politique DMARC et corriger l'erreur SPF « too many DNS lookups ». Ils seront reliés ici au fur et à mesure de leur publication.

Questions fréquentes

SPF, DKIM et DMARC protègent les emails que vous envoyez. Pour filtrer ceux que vous recevez, découvrez comment fonctionne le filtrage d'AntiSpammeur.