Configurer et corriger SPF, DKIM et DMARC : le guide pas à pas

Si l'on vous disait que vos e-mails ne sont pas délivrés parce que votre « enregistrement SPF fait trop de requêtes DNS » ou que votre « signature DKIM n'est pas alignée avec votre domaine RFC5322.From », on comprendrait que vous ayez envie de jeter votre ordinateur par la fenêtre.

Pourtant, configurer SPF, DKIM et DMARC est bien plus simple que ces sigles ne le laissent croire. La plupart des gens corrigent leur authentification e-mail en moins d'une heure. Et en 2026, c'est obligatoire.

Ce guide vous accompagne à chaque étape, sans jargon.

Pourquoi l'authentification e-mail est obligatoire en 2026

Ce qui relevait des bonnes pratiques est devenu une exigence ferme.

En février 2024, Gmail et Yahoo ont commencé à imposer l'authentification e-mail aux expéditeurs en masse. En novembre 2025, Gmail est passé au rejet pur et simple des messages non conformes. Microsoft a suivi en mai 2025, en rejetant les e-mails des expéditeurs à fort volume sans SPF, DKIM et alignement DMARC corrects.

Les domaines entièrement authentifiés obtiennent un bien meilleur inbox placement (placement en boîte de réception). Sans authentification, une bonne partie de vos e-mails n'atteint même pas le dossier spam, car ils sont refusés avant d'arriver dans une boîte mail.

SPF, DKIM et DMARC, c'est quoi ? (la version simple)

Voyez l'authentification e-mail comme le contrôle de sécurité d'un aéroport :

SPF, c'est votre billet. Il indique aux serveurs destinataires quels serveurs de messagerie ont le droit d'envoyer des e-mails pour votre domaine. Comme une liste d'invités qui dit « ces personnes peuvent entrer ».

DKIM, c'est votre passeport. Il ajoute une signature cryptographique à chaque e-mail, qui prouve que le message n'a pas été modifié en route et qu'il vient bien de votre domaine.

DMARC, c'est l'agent de sécurité. Il vérifie si SPF ou DKIM a réussi, décide quoi faire des échecs (rien, quarantaine ou rejet) et vous envoie des rapports sur qui utilise votre domaine pour envoyer des e-mails.

Il vous faut les trois. Voici comment configurer chacun.

Configurer SPF (Sender Policy Framework)

Ce que fait SPF

SPF est un enregistrement DNS TXT qui liste tous les serveurs autorisés à envoyer des e-mails au nom de votre domaine. Quand Gmail reçoit un e-mail qui prétend venir de yourdomain.com, il consulte votre enregistrement SPF pour voir si le serveur d'envoi figure sur la liste.

Étape 1 : vérifiez si vous avez déjà un enregistrement SPF

Ouvrez un vérificateur SPF et saisissez votre domaine. Vous obtiendrez l'un de ces trois résultats : aucun enregistrement trouvé, enregistrement trouvé avec des erreurs, ou enregistrement trouvé et valide.

Important : vous ne pouvez avoir qu'UN SEUL enregistrement SPF par domaine. Plusieurs enregistrements cassent complètement l'authentification.

Étape 2 : recensez tous vos services d'envoi

Listez toutes les plateformes qui envoient des e-mails depuis votre domaine. Les plus courantes :

• Votre fournisseur de messagerie (Google Workspace, Microsoft 365)
• Les plateformes marketing (Mailchimp, HubSpot, ActiveCampaign)
• Les services d'e-mails transactionnels (SendGrid, Postmark, Mailgun)
• Les CRM (Salesforce, HubSpot)
• Les outils de support (Zendesk, Intercom, Freshdesk)

Étape 3 : créez ou mettez à jour votre enregistrement SPF

Chaque service publie sa valeur include SPF dans sa documentation. Votre enregistrement ressemble à ceci :

v=spf1 include:_spf.google.com include:sendgrid.net include:mail.zendesk.com ~all

• v=spf1 indique qu'il s'agit d'un enregistrement SPF
• Chaque include: autorise les serveurs du service concerné
• ~all applique un échec souple (soft fail) à tout ce qui n'est pas sur la liste (la bonne pratique, car DMARC se charge alors de l'application)

Étape 4 : ajoutez-le à votre DNS

Connectez-vous chez votre registraire de domaine (GoDaddy, Cloudflare, Namecheap, etc.), ouvrez les paramètres DNS et ajoutez ou modifiez l'enregistrement TXT.

Les erreurs SPF courantes à éviter

Trop de requêtes DNS. SPF a une limite stricte de 10 requêtes DNS. Chaque include: compte pour au moins une, et certains en déclenchent d'autres. Au-delà de 10, toute la vérification SPF renvoie permerror (RFC 7208, section 4.6.4), et rien ne vous prévient quand cela arrive. Utilisez un outil d'aplatissement SPF si vous atteignez cette limite.

Utiliser -all au lieu de ~all. L'échec strict (-all) demande aux serveurs de rejeter immédiatement les e-mails qui ne correspondent pas, avant même de vérifier DKIM ou DMARC. Utilisez l'échec souple (~all) et laissez DMARC se charger de l'application.

Oublier un service d'envoi. Ce CRM ajouté il y a six mois ? Cet outil de facturation ? S'ils envoient des e-mails depuis votre domaine sans figurer dans votre enregistrement SPF, ces messages échouent à l'authentification.

Configurer DKIM (DomainKeys Identified Mail)

Ce que fait DKIM

DKIM ajoute une signature cryptographique à chaque e-mail sortant. Le serveur destinataire compare cette signature à une clé publique publiée dans votre DNS pour vérifier que l'e-mail est authentique et n'a pas été modifié.

Étape 1 : générez les clés DKIM chez votre fournisseur de messagerie

Contrairement à SPF, la configuration de DKIM commence dans le tableau de bord de votre plateforme d'envoi. Chaque grand fournisseur a un guide de configuration DKIM. Cherchez « DKIM setup » ou « email authentication » dans sa documentation.

Le fournisseur génère deux éléments :

• Une clé publique (un enregistrement DNS TXT que vous ajouterez à votre domaine)
• Une clé privée (utilisée par le serveur pour signer vos e-mails sortants)

Étape 2 : ajoutez la clé publique à votre DNS

L'enregistrement porte un sélecteur précis (comme google._domainkey.yourdomain.com) et une longue chaîne de caractères. Ajoutez-le comme enregistrement TXT dans vos paramètres DNS.

Étape 3 : activez la signature DKIM

Retournez chez votre fournisseur de messagerie et activez la signature DKIM. Cette étape est essentielle : beaucoup de gens ajoutent l'enregistrement DNS et pensent avoir terminé. Ajouter la clé publique ne représente que la moitié du travail.

Étape 4 : recommencez pour chaque service d'envoi

Chaque plateforme qui envoie des e-mails depuis votre domaine a besoin de sa propre configuration DKIM. Toutes : votre outil marketing, votre service d'e-mails transactionnels, votre CRM.

Vérifier que DKIM fonctionne

Envoyez un e-mail de test à un compte Gmail. Ouvrez-le, cliquez sur les trois points → « Afficher l'original ». Cherchez DKIM: PASS dans les résultats d'authentification.

Les erreurs DKIM courantes

Ne pas activer la signature après avoir ajouté l'enregistrement DNS. C'est particulièrement fréquent avec Google Workspace, où l'on ajoute l'enregistrement DNS sans jamais activer DKIM dans la console d'administration.

Utiliser des clés de 1024 bits. Utilisez des clés de 2048 bits pour une meilleure sécurité. La plupart des fournisseurs le font désormais par défaut, mais vérifiez avec la recherche DKIM.

Oublier DKIM sur les expéditeurs secondaires. Si votre plateforme marketing signe avec DKIM mais pas votre service transactionnel, ces messages transactionnels partent sans signature.

Configurer DMARC (Domain-based Message Authentication, Reporting and Conformance)

Ce que fait DMARC

DMARC se place au-dessus de SPF et de DKIM. Il vérifie si l'un des deux protocoles a réussi et si le domaine est aligné avec votre adresse « From » visible. Il indique ensuite aux serveurs destinataires quoi faire des échecs. Il vous envoie aussi des rapports sur chaque e-mail envoyé avec votre domaine, y compris ceux que vous n'avez pas envoyés.

Étape 1 : assurez-vous d'abord que SPF et DKIM fonctionnent

DMARC dépend des deux. Ne configurez pas DMARC avant d'avoir confirmé que SPF et DKIM réussissent. Google recommande d'attendre au moins 48 heures après la configuration de SPF et DKIM avant d'activer DMARC.

Étape 2 : commencez en mode surveillance

Ajoutez cet enregistrement TXT à votre DNS sur _dmarc.yourdomain.com :

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

• p=none demande aux destinataires de ne pas encore agir sur les échecs, seulement d'envoyer des rapports
• rua=mailto:... indique où envoyer les rapports agrégés

Étape 3 : analysez les rapports DMARC pendant 2 à 4 semaines

Les rapports DMARC vous montrent toutes les adresses IP qui envoient des e-mails au nom de votre domaine, celles qui réussissent l'authentification et celles qui échouent.

Cherchez : des services d'envoi légitimes qui échouent à l'authentification (corrigez leur SPF ou leur DKIM), des expéditeurs non autorisés qui tentent d'usurper votre domaine (c'est pour cela qu'il vous faut DMARC), et des problèmes d'alignement entre votre domaine From et vos domaines SPF ou DKIM.

Étape 4 : passez à l'application

Une fois que vous avez confirmé que tous vos e-mails légitimes réussissent l'authentification :

Quarantaine (envoie les échecs en spam) :

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

Rejet (bloque entièrement les échecs ; c'est la référence) :

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

Les erreurs DMARC courantes

Passer directement à p=reject. Si vous imposez le rejet avant d'avoir confirmé que tous vos expéditeurs légitimes réussissent, vous bloquerez vos propres e-mails. Commencez toujours par p=none.

Ne jamais dépasser p=none. À l'inverse, beaucoup d'organisations publient une politique de simple surveillance et ne l'appliquent jamais. Une politique p=none se contente d'observer ; elle ne vous protège pas de l'usurpation. Tout l'intérêt est d'arriver à quarantine ou reject.

Les échecs d'alignement. DMARC exige que le domaine utilisé par SPF ou DKIM soit aligné avec votre adresse From visible. Si votre outil marketing envoie avec un return-path bounce.marketingtool.com alors que votre From est you@yourdomain.com, SPF ne sera pas aligné, comme le montre le vérificateur d'alignement DMARC sur n'importe quel message que vous y collez. Il vous faut alors l'alignement DKIM.

Le bon ordre des opérations

Si vous partez de zéro :

1. SPF d'abord : le plus simple à configurer, avec l'effet le plus immédiat
2. DKIM ensuite : plus de travail (configuration dans chaque plateforme d'envoi), mais essentiel
3. DMARC en dernier : seulement une fois SPF et DKIM fonctionnels. Commencez en p=none, puis passez à l'application en 2 à 4 semaines

La propagation DNS peut prendre jusqu'à 48 heures : pas de panique si vos modifications n'apparaissent pas tout de suite.

Ne configurez pas pour oublier ensuite

C'est là que la plupart des gens échouent. Ils configurent l'authentification une fois et ne la vérifient plus jamais. Puis quelqu'un dans l'équipe ajoute un nouvel outil d'e-mailing, l'enregistrement SPF n'est pas mis à jour, et soudain la moitié de leurs e-mails échouent à l'authentification pendant des semaines avant que quelqu'un s'en aperçoive.

L'authentification e-mail demande un entretien régulier :

• Revoyez vos enregistrements chaque mois quand votre infrastructure est stable
• Faites un audit immédiat après tout changement (nouveau domaine, nouvel ESP, nouveau CRM)
• Surveillez en continu les dérives de configuration

MailVitals automatise cette surveillance. Il vérifie en continu votre configuration SPF, DKIM et DMARC sur tous vos domaines et vous alerte immédiatement quand quelque chose casse, avant que votre délivrabilité n'en souffre.

👉 À lire aussi : Pourquoi mes e-mails arrivent-ils en spam ?

Sources

• RFC 7208: Sender Policy Framework (SPF), la syntaxe de l'enregistrement SPF, ~all et -all, la règle de l'enregistrement unique et la limite de 10 requêtes.
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures, le fonctionnement des signatures DKIM, des sélecteurs et des clés publiques dans le DNS.
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), la norme DMARC actuelle : l'alignement, les politiques p=none/quarantine/reject et les rapports agrégés.
• Set up DMARC (aide Google Workspace), les conseils de Google pour déployer DMARC, dont l'attente de 48 heures après SPF et DKIM.
• Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders (Microsoft Tech Community), les règles SPF, DKIM et DMARC qu'Outlook.com applique aux domaines qui envoient plus de 5 000 messages par jour.