SPF, DKIM & DMARC : ce qu'ils sont, comment les configurer et pourquoi c'est important

Vos e-mails sont bien rediges. Votre liste est propre. Votre calendrier d'envoi est regulier. Mais vos taux d'ouverture baissent et Gmail vous envoie constamment dans le spam. Le probleme n'est peut-etre pas ce que vous envoyez -- le probleme pourrait etre que vous n'avez pas prouve que c'est vraiment vous.

L'authentification e-mail est le moyen de prouver aux fournisseurs de messagerie qu'un e-mail pretendant provenir de votre domaine provient reellement de votre domaine. Sans elle, n'importe qui peut usurper votre adresse "De" et envoyer des e-mails de phishing en se faisant passer pour votre marque. Les fournisseurs de messagerie le savent -- c'est pourquoi les e-mails non authentifies sont consideres comme suspects par defaut.

Trois protocoles forment l'epine dorsale de l'authentification e-mail : SPF, DKIM et DMARC. Ensemble, ils indiquent aux serveurs destinataires qui est autorise a envoyer en votre nom, que les messages n'ont pas ete modifies et quoi faire en cas d'echec. Dans ce guide, nous expliquerons les trois en langage clair, montrerons exactement comment configurer chacun et aborderons les erreurs qui trompent meme les expediteurs experimentes.

Qu'est-ce que l'authentification e-mail ?

Quand vous envoyez une lettre par la poste, le destinataire peut voir l'adresse de retour -- mais n'importe qui peut ecrire n'importe quelle adresse de retour sur l'enveloppe. L'e-mail fonctionne de la meme maniere. Le champ "De" dans un e-mail est juste du texte. Sans authentification, rien n'empeche un spammeur d'envoyer un e-mail qui semble provenir de vous@votredomaine.com.

L'authentification e-mail resout ce probleme en ajoutant des preuves verifiables a vos messages. Elle consiste en un ensemble d'enregistrements DNS et de techniques cryptographiques qui permettent aux serveurs de messagerie destinataires de repondre a trois questions :

• Ce serveur est-il autorise a envoyer des e-mails pour ce domaine ? (SPF)
• Ce message a-t-il ete modifie apres son envoi ? (DKIM)
• Que dois-je faire si l'authentification echoue ? (DMARC)

Pensez-y comme montrer une piece d'identite a la porte. SPF est la liste des invites. DKIM est le bracelet qui prouve que vous avez ete verifie a l'entree. DMARC est les instructions du gardien sur ce qu'il faut faire quand quelqu'un ne correspond pas.

SPF explique

Qu'est-ce que SPF

SPF (Sender Policy Framework) est un enregistrement DNS TXT qui liste chaque adresse IP et serveur de messagerie autorise a envoyer des e-mails au nom de votre domaine. Quand un serveur destinataire recoit un e-mail de votre domaine, il consulte votre enregistrement SPF pour verifier si l'IP du serveur expediteur figure sur la liste autorisee.

Si l'IP correspond, SPF passe. Si elle ne correspond pas, SPF echoue -- et le serveur destinataire comprend que l'e-mail pourrait etre falsifie.

Comment fonctionne SPF (etape par etape)

1. Vous envoyez un e-mail depuis hello@votredomaine.com via votre fournisseur de services e-mail (ESP).
2. Le serveur destinataire voit que l'e-mail pretend provenir de votredomaine.com.
3. Il recherche l'enregistrement SPF dans le DNS de votredomaine.com.
4. L'enregistrement SPF dit quelque chose comme : "Seuls ces serveurs peuvent envoyer en mon nom : 192.0.2.1 et tout ce qui est liste dans l'enregistrement SPF de Mailchimp."
5. Le serveur destinataire verifie si l'IP qui a reellement envoye l'e-mail correspond a l'enregistrement SPF.
6. Si elle correspond : SPF passe. Si elle ne correspond pas : SPF echoue.

Comment configurer SPF

Configurer SPF necessite d'ajouter un seul enregistrement TXT au DNS de votre domaine. Un enregistrement SPF typique ressemble a ceci :

v=spf1 include:_spf.google.com include:servers.mcsv.net -all

Decomposons-le :

• v=spf1 -- indique qu'il s'agit d'un enregistrement SPF
• include:_spf.google.com -- autorise Google Workspace a envoyer pour votre domaine
• include:servers.mcsv.net -- autorise Mailchimp a envoyer pour votre domaine
• -all -- dit aux destinataires de rejeter tout e-mail provenant d'un serveur non liste ci-dessus

Pour le configurer : connectez-vous a votre fournisseur DNS (GoDaddy, Cloudflare, Namecheap, etc.), allez dans les enregistrements DNS, ajoutez un nouvel enregistrement TXT avec l'hote defini sur @ (votre domaine racine) et collez votre valeur SPF. Votre ESP vous dira exactement quoi ajouter -- consultez leur documentation.

Erreurs SPF courantes

• Plusieurs enregistrements SPF. Votre domaine ne peut avoir qu'un seul enregistrement SPF. Si vous en ajoutez un deuxieme (par ex. un pour Google, un pour Mailchimp), les deux sont invalides. Combinez-les en un seul enregistrement en utilisant plusieurs instructions include:.
• Trop de requetes DNS. SPF a une limite de 10 requetes DNS. Chaque include: compte comme une requete, et les includes imbriques comptent aussi. Si vous depassez 10, SPF echoue automatiquement pour chaque e-mail que vous envoyez. Utilisez un outil d'aplatissement SPF si vous atteignez la limite.
• Utiliser +all au lieu de -all. Le drapeau +all signifie "autoriser tout le monde a envoyer en tant que mon domaine" -- ce qui annule tout l'objectif de SPF. Utilisez toujours -all (rejet strict) ou au minimum ~all (rejet souple).
• Oublier les expediteurs tiers. Si vous utilisez un CRM, un helpdesk ou un service d'e-mails transactionnels, leurs serveurs doivent aussi etre dans votre enregistrement SPF. Scenario courant : les e-mails marketing passent SPF, mais les e-mails transactionnels de votre helpdesk echouent parce que vous avez oublie de les ajouter.

DKIM explique

Qu'est-ce que DKIM

DKIM (DomainKeys Identified Mail) ajoute une signature numerique cryptographique a chaque e-mail que vous envoyez. Cette signature est generee a l'aide d'une cle privee que seul votre serveur d'envoi possede. La cle publique correspondante est publiee dans votre DNS pour que quiconque puisse verifier la signature.

Contrairement a SPF qui ne verifie que le serveur d'envoi, DKIM verifie que le contenu de l'e-mail n'a pas ete modifie apres l'envoi. Si quelqu'un intercepte votre e-mail et le modifie, la signature DKIM sera cassee et le serveur destinataire saura que le message a ete altere.

Comment fonctionne DKIM (etape par etape)

1. Votre serveur de messagerie cree un hash cryptographique unique des en-tetes et du corps de l'e-mail.
2. Il signe ce hash avec votre cle privee et ajoute la signature a l'en-tete de l'e-mail en tant que champ DKIM-Signature.
3. Le serveur destinataire voit la signature DKIM et en extrait le selecteur et le domaine.
4. Il utilise le selecteur pour rechercher la cle publique dans votre DNS (par ex. selector1._domainkey.votredomaine.com).
5. Il utilise la cle publique pour verifier la signature par rapport au contenu de l'e-mail.
6. Si la signature correspond : DKIM passe. Si elle ne correspond pas : DKIM echoue (le message a ete modifie ou la cle ne correspond pas).

Comment configurer DKIM

La configuration DKIM est un peu plus complexe que SPF car elle necessite que votre fournisseur de messagerie genere une paire de cles. Voici le processus general :

1. Generez les cles DKIM dans votre ESP. Allez dans les parametres de votre fournisseur de messagerie et cherchez la section "DKIM" ou "Authentification e-mail". La plupart des fournisseurs (Google Workspace, Mailchimp, SendGrid, etc.) genereront les cles pour vous et vous donneront un enregistrement DNS a ajouter.
2. Ajoutez l'enregistrement DKIM a votre DNS. Vous recevrez un enregistrement TXT ou CNAME avec un hote comme google._domainkey et une longue valeur contenant la cle publique. Ajoutez-le a votre fournisseur DNS.
3. Activez DKIM dans votre ESP. Certains fournisseurs necessitent que vous cliquiez sur "Demarrer l'authentification" ou un bouton similaire apres avoir ajoute l'enregistrement DNS. Ne sautez pas cette etape.
4. Verifiez que cela fonctionne. Envoyez un e-mail de test et verifiez dans les en-tetes si dkim=pass apparait. La plupart des ESP affichent egalement le statut DKIM dans leur tableau de bord.

Un enregistrement DNS DKIM ressemble approximativement a ceci :

Host: google._domainkey.yourdomain.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

Erreurs DKIM courantes

• Ne pas configurer DKIM pour tous les expediteurs. Chaque service de messagerie que vous utilisez a besoin de sa propre cle DKIM. Si vous avez configure DKIM pour Google Workspace mais pas pour Mailchimp, les e-mails provenant de Mailchimp echoueront au controle DKIM.
• Longueur de cle trop courte. Utilisez au minimum des cles de 1024 bits, mais le standard en 2026 est de 2048 bits. Certains fournisseurs utilisent encore 1024 par defaut -- passez a 2048 si possible.
• Ne pas faire de rotation des cles. Bien qu'il n'y ait pas de calendrier de rotation obligatoire, faire une rotation annuelle des cles DKIM est une meilleure pratique de securite. Si une cle privee est compromise, quelqu'un pourrait signer des e-mails en se faisant passer pour votre domaine.
• Enregistrement DNS trop long pour une seule entree TXT. Certains fournisseurs DNS ont une limite de 255 caracteres par enregistrement TXT. Si votre cle 2048 bits depasse cela, vous devrez peut-etre la diviser en plusieurs chaines entre guillemets. La documentation de votre ESP vous montrera comment faire.

DMARC explique

Qu'est-ce que DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) est le protocole qui reunit SPF et DKIM et ajoute une piece critique manquante : une politique. DMARC indique aux serveurs destinataires quoi faire quand un e-mail provenant de votre domaine echoue a l'authentification.

Sans DMARC, les serveurs destinataires doivent deviner. Doivent-ils quand meme delivrer l'e-mail ? Le mettre dans le dossier spam ? Le rejeter completement ? Chaque serveur prend sa propre decision. DMARC vous donne le controle en publiant une politique claire dans votre DNS.

DMARC introduit egalement le concept d'alignement. SPF et DKIM verifient differentes parties de l'en-tete de l'e-mail. DMARC exige qu'au moins l'un d'entre eux "s'aligne" avec le domaine de l'adresse "De" visible -- l'adresse que vos destinataires voient reellement. Cela comble une faille ou un attaquant pourrait passer SPF avec un domaine tout en affichant un domaine completement different au destinataire.

Les politiques DMARC : none, quarantine et reject

DMARC offre trois niveaux de politique :

Comment configurer DMARC

DMARC est un seul enregistrement TXT dans votre DNS. Voici l'approche recommandee :

Etape 1 : Commencez par la surveillance. Ajoutez cet enregistrement TXT a votre DNS :

Host: _dmarc.yourdomain.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

• v=DMARC1 -- indique qu'il s'agit d'un enregistrement DMARC
• p=none -- surveillance uniquement, aucune action sur les echecs
• rua=mailto:... -- adresse ou les rapports agriges seront envoyes (rapports XML montrant qui envoie en utilisant votre domaine et s'ils passent l'authentification)

Etape 2 : Examinez les rapports pendant 2 a 4 semaines. Vous recevrez des rapports XML des principaux fournisseurs de messagerie. Ces rapports montrent chaque adresse IP envoyant des e-mails en utilisant votre domaine et si SPF/DKIM passent. Utilisez un outil d'analyse de rapports DMARC (comme dmarcian ou EasyDMARC) pour rendre les donnees lisibles. Votre objectif : vous assurer que tous vos expediteurs legitimes passent a la fois SPF et DKIM.

Etape 3 : Passez a quarantine. Une fois que vous etes certain que tous les e-mails legitimes passent :

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

Etape 4 : Passez a reject. Apres quelques semaines supplementaires de rapports propres :

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

Ne passez jamais directement a p=reject sans avoir d'abord fait de la surveillance. Si un expediteur legitime n'est pas correctement authentifie, ses e-mails seront silencieusement supprimes -- et vous ne le saurez pas jusqu'a ce que quelqu'un se plaigne de ne jamais avoir recu votre message.

Erreurs DMARC courantes

• Passer directement a p=reject. C'est l'erreur la plus dangereuse. Si vous avez un expediteur tiers oublie qui n'est pas authentifie (ancien CRM, helpdesk, service d'e-mails transactionnels), ses e-mails seront bloques sans aucun avertissement.
• Ne pas configurer d'adresse de rapport (rua). Sans rapports, vous volez a l'aveugle. Vous ne pouvez pas savoir si des e-mails legitimes echouent ou si quelqu'un usurpe votre domaine.
• Ignorer les rapports DMARC. Configurer p=none et ne jamais regarder les rapports annule tout l'objectif. L'interet de la surveillance est de trouver les problemes avant d'appliquer une politique.
• Problemes d'alignement. DMARC exige que le domaine dans SPF ou DKIM corresponde (s'aligne avec) le domaine "De" visible. Si votre ESP envoie depuis un domaine different et ne signe pas avec le DKIM de votre domaine, DMARC echouera meme si SPF passe.

SPF vs. DKIM vs. DMARC : comparaison

Voici un apercu cote a cote de ce que fait chaque protocole et contre quoi il protege :

Le point cle : chaque protocole comble une lacune differente. SPF seul ne verifie pas l'adresse "De" visible. DKIM seul ne dit pas aux destinataires quoi faire en cas d'echec d'authentification. DMARC seul ne fonctionne pas sans SPF ou DKIM pour le soutenir. Vous avez besoin des trois ensemble.

Comment l'authentification affecte la delivrabilite

L'authentification e-mail est l'un des piliers fondamentaux de la reputation d'expediteur. Les fournisseurs de messagerie utilisent l'authentification comme signal de confiance de base. Ce n'est pas une garantie de placement en boite de reception -- vous avez toujours besoin de listes propres, de faibles plaintes et d'un bon engagement -- mais sans authentification, tout ce que vous faites d'autre est compromis.

Voici ce qui se passe a chaque niveau d'authentification :

• Aucune authentification : La plupart des grands fournisseurs enverront vos e-mails dans le dossier spam ou les rejetteront directement. Gmail est de plus en plus agressif sur ce point depuis la mise a jour des exigences pour les expediteurs en 2024.
• SPF seul : Mieux que rien, mais vous laissez des lacunes. Les e-mails rediriges casseront SPF, et il n'y a aucune protection contre l'usurpation du domaine dans le champ De visible.
• SPF + DKIM : Nettement mieux. Vous prouvez a la fois l'autorisation du serveur et l'integrite du message. Mais sans DMARC, pas de politique ni de rapports -- vous ne pouvez pas savoir quand des echecs se produisent.
• SPF + DKIM + DMARC (reject) : Le standard de reference. Authentification complete, protection complete, visibilite complete. C'est ce que Gmail et Yahoo exigent des expediteurs en masse, et c'est ce que chaque domaine devrait viser.

L'authentification est particulierement critique si vous utilisez plusieurs services d'envoi. Chaque ESP, CRM, helpdesk et systeme d'e-mails transactionnels qui envoie au nom de votre domaine doit etre correctement authentifie. Un seul expediteur non authentifie peut degrader la reputation de votre domaine entier. Utilisez le Kit de delivrabilite ClearBounce pour surveiller votre statut d'authentification et detecter les problemes avant qu'ils n'affectent votre placement en boite de reception.

Erreurs d'authentification courantes

Meme les expediteurs qui pensent avoir correctement configure l'authentification ont souvent des problemes caches. Voici les problemes que nous rencontrons le plus frequemment :

Checklist d'authentification e-mail

Utilisez cette checklist pour verifier que votre authentification est correctement configuree. Verifier chaque element prend quelques minutes mais peut prevenir des semaines de problemes de delivrabilite :

Conclusion

L'authentification e-mail n'est plus optionnelle. Gmail, Yahoo et Microsoft utilisent SPF, DKIM et DMARC comme signal fondamental pour decider si vos e-mails appartiennent a la boite de reception ou au dossier spam. Depuis 2024, Gmail et Yahoo exigent explicitement les trois pour les expediteurs en masse -- et la tendance est claire : les exigences d'authentification ne feront que devenir plus strictes.

La bonne nouvelle est que configurer l'authentification est un effort ponctuel avec des benefices permanents. Une fois vos enregistrements SPF, DKIM et DMARC correctement configures, chaque e-mail que vous envoyez beneficie de la confiance qu'ils etablissent. Vous n'ameliorez pas seulement la delivrabilite -- vous protegez votre marque contre les attaques de phishing et d'usurpation qui pourraient nuire a votre reputation et a la confiance de vos clients.

Cependant, l'authentification n'est qu'une piece du puzzle de la delivrabilite. Un e-mail parfaitement authentifie envoye a une adresse invalide rebondira quand meme. Un e-mail parfaitement signe envoye a un spam trap nuira quand meme a votre reputation. L'authentification dit aux fournisseurs de messagerie que vous etes bien qui vous pretendez etre. La verification d'e-mails garantit que vous envoyez a des personnes qui existent reellement et veulent avoir de vos nouvelles. Ensemble, ils forment le fondement pour atteindre constamment la boite de reception.

Si vous n'avez pas encore configure les trois protocoles, commencez aujourd'hui. Commencez par SPF, puis DKIM, puis DMARC en mode surveillance. Utilisez la checklist ci-dessus. Votre reputation d'expediteur -- et votre placement en boite de reception -- vous en remercieront.