Configurer SPF, DKIM et DMARC pour une meilleure délivrabilité

SPF, DKIM et DMARC configurer pour une meilleure délivrabilité

Depuis février 2024, Google et Yahoo exigent des expéditeurs en masse — plus de 5.000 messages par jour vers des adresses Gmail — que DKIM et DMARC soient configurés. Ce ne sont pas des suggestions. Les destinataires qui ne peuvent pas authentifier votre domaine rejettent le courrier ou le mettent en spam. Cet article explique comment mettre en place les trois protocoles, dans le bon ordre, sans casser votre propre trafic mail.

Prérequis

• Accès aux paramètres DNS de votre domaine.
• Accès root à votre serveur mail (Postfix, Exim ou une autre plateforme qui prend en charge la signature DKIM).
• Un certificat TLS valide pour votre serveur mail — pas strictement nécessaire pour l'authentification, mais sans chiffrement, votre courrier n'atteindra pas la boîte de réception des grands fournisseurs.
• Connaissance des systèmes qui envoient du courrier au nom de votre domaine. Faites une liste avant de commencer : serveur propre, plateforme marketing, système de tickets, tout.

Étape 1 : Inventoriez tous les systèmes d'envoi

Chaque service qui envoie des e-mails avec votre domaine dans l'en-tête `From:` doit être inclus dans l'authentification. N'oubliez pas les messages transactionnels : réinitialisation de mot de passe, factures, notifications. Ceux-là sont souvent négligés et ce sont précisément ceux que les fournisseurs contrôlent strictement.

Faites un aperçu de :

• Adresses IP de vos propres serveurs mail
• Services externes (Mailchimp, SendGrid, Google Workspace, Microsoft 365)
• Éventuels sous-domaines qui envoient du courrier séparément

Sans cet aperçu, vous allez configurer DMARC et découvrir que vos propres factures tombent en spam.

Étape 2 : Configurez SPF

Sender Policy Framework est un enregistrement TXT dans votre DNS qui indique quelles adresses IP et quels services sont autorisés à envoyer au nom de votre domaine. Un seul enregistrement par domaine — plusieurs enregistrements entraînent une erreur permanente.

Créez un enregistrement comme celui-ci, remplacez les valeurs par les vôtres :

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com include:sendgrid.net ~all

`ip4` spécifie une plage d'adresses IP, `include` fait référence à un domaine externe qui est également autorisé à envoyer, `~all` signifie que les autres sources doivent être mises en quarantaine, `-all` qu'elles doivent être refusées fermement.

SPF a une limite stricte de 10 requêtes DNS par contrôle. Chaque `include` compte, et certains includes de grands fournisseurs comptent plusieurs fois. Si vous dépassez la limite, le contrôle SPF échoue automatiquement — même pour les expéditeurs légitimes. Gardez donc l'enregistrement aussi court que possible. Supprimez les services que vous n'utilisez plus. Utilisez un seul `include` pour un fournisseur plutôt que plusieurs adresses IP séparées.

Étape 3 : Configurez DKIM

DKIM ajoute une signature cryptographique à l'en-tête de chaque message. Le destinataire récupère la clé publique correspondante dans votre DNS et valide ainsi à la fois l'expéditeur et l'intégrité du contenu. Si le courrier a été modifié en cours de route, la signature échoue.

Générez une paire de clés sur votre serveur mail. Sur un système avec OpenDKIM :

opendkim-genkey -s default -d example.com -b 2048

Cela crée deux fichiers : `default.private` et `default.txt`. La clé publique dans `default.txt` se place comme enregistrement TXT dans votre DNS sous le sélecteur `default._domainkey.example.com`.

Configurez votre serveur mail pour signer avec la clé privée. Pour Postfix avec OpenDKIM, ajoutez à `/etc/opendkim.conf` :

Mode                sv
KeyFile             /etc/opendkim/keys/example.com/default.private
Selector            default
Canonicalization    relaxed/simple

Redémarrez ensuite les services :

systemctl restart opendkim postfix

Utilisez des clés de 2048 bits. Les plus courtes sont considérées comme insuffisamment sûres par de plus en plus de fournisseurs. Faites pivoter vos sélecteurs périodiquement — si une clé fuit, vous limitez ainsi les dégâts.

Il est important que DKIM soit présent sur tout le courrier sortant, pas seulement sur vos newsletters. Les messages transactionnels doivent être tout aussi bien signés.

Étape 4 : Publiez un enregistrement DMARC avec p=none

DMARC s'appuie sur SPF et DKIM et ajoute deux choses : une politique pour les messages qui échouent aux contrôles, et une exigence d'alignement. Le domaine dans l'en-tête `From:` doit correspondre au domaine validé par SPF (via `Return-Path`) ou par DKIM (via le tag `d=`). Sans alignement, DMARC échoue, même si SPF et DKIM réussissent séparément.

DMARC s'écrit comme enregistrement TXT sur `_dmarc.example.com`. Commencez toujours par `p=none` :

v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-failures@example.com; fo=1

`p=none` signifie que rien n'est encore fait des messages en échec — vous ne recevez que des rapports. `rua` reçoit les résumés des fournisseurs, `ruf` les rapports d'échec individuels.

Sans enregistrement DMARC, les destinataires décident eux-mêmes quoi faire du courrier non reconnu. Avec un enregistrement — même avec `p=none` — vous indiquez que vous gérez le domaine et vous obtenez une visibilité sur qui envoie en votre nom.

Étape 5 : Analysez les rapports

Laissez `p=none` en place pendant deux à quatre semaines. Les rapports qui arrivent via `rua` et `ruf` montrent quels systèmes envoient du courrier au nom de votre domaine — y compris des sources que vous ne connaissez pas. Vous devez soit les ajouter à SPF et DKIM, soit les considérer comme un abus.

Vérifiez par source :

• Est-ce que l'adresse IP correspond à un système que vous gérez ?
• La signature DKIM est-elle valide ?
• Y a-t-il un alignement SPF ?

Les systèmes légitimes qui échouent doivent être réparés avant de renforcer la politique. Un tiers qui envoie en votre nom sans configuration correcte fait en sorte que votre domaine soit considéré comme la source de courriers non reconnaissables.

Étape 6 : Renforcer vers p=quarantine et p=reject

Lorsque toutes les sources légitimes sont correctement configurées, passez à `p=quarantine` :

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-failures@example.com; fo=1

Les messages en échec arrivent maintenant dans le dossier spam au lieu de la boîte de réception. Laissez cela encore quelques semaines et vérifiez si des plaintes arrivent concernant des messages manqués.

La dernière étape est `p=reject` :

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-failures@example.com; fo=1

Maintenant, les messages en échec sont complètement rejetés. Cette étape est irréversible en pratique : un système que vous avez négligé perd immédiatement sa capacité à livrer du courrier. Le passage à `p=reject` ne peut se faire qu'après avoir vu pendant des semaines dans les rapports que seules des sources non autorisées échouent.

Vérification

Vérifiez vos enregistrements avec `dig` :

dig TXT example.com
dig TXT default._domainkey.example.com
dig TXT _dmarc.example.com

Envoyez ensuite un message de test à une adresse que vous avez créée chez Google et Yahoo et examinez les en-têtes :

grep -E "spf|dkim|dmarc" /path/to/raw-message.txt

Vous cherchez `spf=pass`, `dkim=pass` et `dmarc=pass`. Tout autre résultat signifie qu'une des étapes n'a pas été réalisée correctement.

Erreurs fréquentes

Plusieurs enregistrements SPF. Le DNS n'autorise qu'un seul enregistrement SPF par domaine. Plusieurs enregistrements font échouer le contrôle. Regroupez tout dans un seul enregistrement TXT.

Limite de lookups SPF dépassée. Chaque `include` compte pour la limite de 10 lookups. Vérifiez avec :

dig TXT example.com | grep -o "include:" | wc -l

Restez sous la limite, sinon SPF échoue structurellement.

DKIM uniquement sur les courriels marketing. Les messages transactionnels sans signature DKIM échouent DMARC dès que vous passez à `p=reject`. Signez tous les courriels sortants, pas seulement les campagnes.

De quoi cela dépend

Les trois protocoles font chacun quelque chose de différent. SPF vérifie quel serveur est autorisé à envoyer, DKIM vérifie si le contenu a été modifié en cours de route, et DMARC détermine ce qui se passe si l'un des deux échoue. C'est une chaîne : retirez un maillon et le reste signifie moins.

La plus grande erreur est la précipitation. Celui qui passe de rien à `p=reject` en une seule nuit découvre en une semaine quel tiers envoyait encore secrètement au nom du domaine. L'approche progressive — `none`, puis `quarantine`, puis `reject` — n'existe pas pour rien. Les rapports de la phase `none` représentent la moitié du travail ; celui qui les saute configure à l'aveugle.

Les fournisseurs rendent les exigences de plus en plus strictes. Ce qui valait en 2024 pour les envois en masse vers Google et Yahoo devient la norme pour tout le monde. Celui qui met en place les protocoles maintenant a déjà les rapports avant la prochaine exigence. Celui qui attend que cela tourne mal n'a pas de rapports — seulement une boîte de réception vide.