SPF, DKIM et DMARC : empêcher les e-mails de votre serveur de finir en spam

Vous déplacez vos sites sur votre propre serveur, tout se charge vite, puis un client appelle : « Nous n'avons pas reçu une seule demande via le formulaire de contact depuis deux semaines. » Le formulaire fonctionne. Le mail part. Il atterrit simplement en spam — ou il est supprimé sans bruit. C'est la surprise la plus fréquente de l'auto-hébergement, et elle n'a rien à voir avec votre contenu. Gmail, Outlook et Yahoo décident où va votre courrier selon deux critères : pouvez-vous prouver que vous avez le droit d'envoyer pour ce domaine, et l'IP d'envoi a-t-elle une bonne réputation ? Un serveur tout neuf ne coche aucune des deux cases. Voici comment régler la première et protéger la seconde.

Pourquoi le courrier de votre serveur finit en spam

N'importe qui peut mettre n'importe quelle adresse dans la ligne From: d'un e-mail ; le protocole ne l'a jamais vérifié. Les spammeurs en ont profité pendant des décennies, alors les destinataires exigent désormais des preuves. Depuis 2024, Google et Yahoo l'imposent formellement : tout expéditeur a besoin de SPF ou de DKIM ainsi que d'un DNS direct et inverse valide, et quiconque envoie en volume (environ 5 000 messages par jour vers Gmail) a besoin de SPF, de DKIM et de DMARC. En pratique, un serveur sans les trois est traité comme suspect dès le premier message.

Il y a quatre pièces, et toutes vivent dans le DNS :

• SPF — quels serveurs ont le droit d'envoyer du courrier pour votre domaine.
• DKIM — une signature cryptographique qui prouve que le message n'a été ni falsifié ni modifié.
• DMARC — la politique qui relie les deux à l'adresse From: visible, avec des rapports.
• DNS inverse (PTR) — le nom propre de l'IP, qui doit correspondre au nom d'hôte du serveur.

SPF : la liste des expéditeurs autorisés

SPF est un enregistrement TXT sur votre domaine qui liste les IP et services autorisés à envoyer pour lui :

example.com.  TXT  "v=spf1 a mx include:_spf.google.com ~all"

a et mx autorisent les IP vers lesquelles pointent les enregistrements A et MX de votre domaine ; include: intègre la liste d'un expéditeur tiers ; ~all signifie « tout le reste est suspect » (softfail), tandis que -all signifie « rejetez-le » (hardfail). Commencez par ~all tant que vous n'êtes pas sûr que la liste est complète.

Trois règles que l'on enfreint sans arrêt :

• Un seul enregistrement SPF par domaine. Deux enregistrements TXT v=spf1 ne fusionnent pas ; ils font échouer SPF complètement. Ajoutez les nouveaux expéditeurs à l'enregistrement existant.
• 10 requêtes DNS au maximum. Chaque include, a, mx et redirect compte, y compris ceux imbriqués dans chaque include. Au-delà de 10, SPF renvoie une erreur permanente. Supprimez les expéditeurs que vous n'utilisez plus.
• SPF vérifie l'expéditeur d'enveloppe, pas la ligne From:. C'est pourquoi il ne suffit pas à lui seul, et pourquoi DMARC existe.

DKIM : une signature sur chaque message

Avec DKIM, votre serveur de messagerie signe chaque message sortant avec une clé privée. La clé publique correspondante est publiée dans le DNS sous un sélecteur :

mail._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

Le destinataire récupère la clé, vérifie la signature et sait deux choses : le message a été envoyé par quelqu'un qui détient votre clé, et les en-têtes et le corps signés n'ont pas été modifiés en route. Sous Linux, OpenDKIM branché sur Postfix en tant que milter est la configuration classique.

• Utilisez des clés de 2048 bits. 1024 bits est le strict minimum, et de moins en moins bien vu.
• Les clés longues doivent être découpées. Une clé de 2048 bits dépasse la limite de 255 caractères d'une chaîne TXT unique ; elle doit donc être publiée en plusieurs chaînes entre guillemets dans un seul enregistrement. Beaucoup d'interfaces DNS le font pour vous ; les fichiers de zone écrits à la main, non.
• Les sélecteurs permettent la rotation. Publiez une nouvelle clé sous un nouveau sélecteur, basculez la signature, puis retirez l'ancienne plus tard — sans aucun trou de couverture.

DMARC : la politique qui relie le tout

DMARC vérifie que SPF ou DKIM a réussi et que le domaine authentifié est aligné avec le domaine de l'adresse From: visible. C'est ce qui empêche quelqu'un d'envoyer en tant que ceo@example.com depuis son propre serveur avec un SPF valide pour son domaine.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

La politique p= indique aux destinataires quoi faire du courrier qui échoue : none (simple rapport), quarantine (dossier spam) ou reject. rua= est l'adresse où les destinataires envoient des rapports agrégés quotidiens — des résumés XML de qui a envoyé du courrier en se faisant passer pour vous, et si cela a réussi.

Déployez-le par étapes :

1. Commencez avec p=none et lisez les rapports pendant deux à quatre semaines. Vous découvrirez des expéditeurs oubliés : l'outil de newsletter, le logiciel de facturation, le CRM.
2. Corrigez chaque expéditeur légitime (ajoutez-le à SPF, activez la signature DKIM dans ses réglages).
3. Passez à p=quarantine, puis à p=reject une fois les rapports propres.

DNS inverse, HELO et l'IP elle-même

Le serveur destinataire examine aussi la connexion. L'IP de votre serveur devrait avoir un enregistrement PTR (DNS inverse) qui résout vers un nom d'hôte — disons mail.example.com — lequel résout à son tour vers la même IP. Le nom que le serveur annonce dans son salut SMTP (HELO) devrait être ce même nom d'hôte. Les enregistrements PTR se configurent chez votre hébergeur, généralement dans la console cloud à côté de l'IP, pas dans le DNS de votre domaine.

Deux vérifications de plus avant d'accuser vos enregistrements :

• Le port 25 est-il ouvert ? Beaucoup de fournisseurs cloud, Hetzner compris, bloquent le port 25 sortant sur les nouveaux comptes jusqu'à ce que vous demandiez son ouverture. Le courrier s'accumule alors en file d'attente et ne part jamais.
• L'IP figure-t-elle sur une liste noire ? Les IP cloud recyclées traînent parfois l'historique d'un ancien locataire. Vérifiez-la auprès de Spamhaus et de listes similaires avant la mise en ligne.

Comment tester correctement

Ne devinez pas — vérifiez ce que le monde voit :

dig +short TXT example.com
dig +short TXT mail._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short -x 203.0.113.10

Envoyez ensuite un vrai message vers une adresse Gmail et ouvrez Afficher l'original. Vous voulez trois lignes indiquant SPF: PASS, DKIM: PASS et DMARC: PASS. L'en-tête Authentication-Results donne les détails quand quelque chose échoue. Un service de score comme mail-tester.com vérifie contenu, listes noires et authentification d'un coup, et swaks permet d'envoyer des messages de test en ligne de commande sans toucher à votre application.

Les erreurs qui cassent la distribution sans bruit

• Deux enregistrements SPF après l'ajout d'un nouveau service. SPF échoue pour tout.
• L'application envoie avec le mauvais domaine. WordPress utilise par défaut wordpress@votredomaine, et beaucoup de scripts envoient en tant que www-data@nomdhote. Le From: doit être un domaine que vous avez authentifié.
• Oublier les expéditeurs tiers — newsletters et services d'e-mail transactionnel ont chacun besoin de leur propre include SPF et de leur configuration DKIM.
• Passer directement à p=reject sans lire les rapports. Vos factures disparaissent avec le spam.
• DKIM non aligné. Un service qui signe avec son domaine réussit DKIM mais échoue à DMARC. Configurez la signature avec votre propre domaine dans son tableau de bord.
• Le transfert casse SPF. Quand un message est transféré, le serveur de transfert ne figure pas dans le SPF de l'expéditeur d'origine. DKIM survit au transfert — raison de plus pour ne jamais s'en passer.
• Envoyer une rafale depuis une IP froide. Une nouvelle IP qui envoie soudain des milliers de messages ressemble à une machine compromise. Augmentez progressivement.

Comment ShadowPanel automatise la partie DNS

ShadowPanel est un panneau de contrôle d'hébergement auto-hébergé avec messagerie intégrée (Postfix avec un milter OpenDKIM), et la configuration de la délivrabilité tient en un bouton au lieu d'une soirée de génération de clés et de copier-coller d'enregistrements TXT.

• DKIM en un clic. La page e-mail comporte une section délivrabilité par domaine. Un clic génère une clé DKIM de 2048 bits, l'enregistre dans les tables de signature d'OpenDKIM et lance la signature du courrier sortant pour ce domaine.
• Enregistrements SPF et DMARC ajoutés pour vous. Si la zone DNS du domaine est gérée par le panel — sur son propre serveur de noms, ou via un compte Hetzner DNS ou Cloudflare connecté — le panel insère l'enregistrement DKIM, un enregistrement SPF (v=spf1 a mx ~all) et une politique DMARC de départ (p=none, rapports vers postmaster@ votre domaine). Les enregistrements SPF et DMARC existants sont détectés et laissés tels quels : le piège du double SPF ne peut pas se produire. Les longues clés DKIM sont correctement découpées pour le serveur de noms local.
• DNS externe ? Copier-coller. Si la zone est hébergée ailleurs, le panel affiche les enregistrements exacts à ajouter chez votre fournisseur DNS, et une vérification d'état montre lesquels sont présents.
• Boîtes mail et alias. Créez des boîtes et des redirections/alias par domaine ; le panel refuse un alias qui masquerait sans bruit une boîte existante.

Ce qui reste à votre charge : configurer l'enregistrement PTR chez votre hébergeur, faire ouvrir le port 25 si besoin, et durcir DMARC de p=none vers quarantine ou reject une fois les rapports propres. Si vous déplacez le courrier d'un hébergement mutualisé en même temps, migrer de cPanel vers un VPS sans interruption couvre la partie boîtes mail, et installer un panneau d'hébergement sur un VPS Hetzner couvre le serveur.

En résumé

Le courrier d'un nouveau serveur finit en spam parce que les destinataires ne peuvent pas le vérifier, pas parce que c'est du mauvais courrier. Publiez un seul enregistrement SPF propre, signez tout avec une clé DKIM de 2048 bits, démarrez DMARC à p=none et durcissez-le une fois les rapports propres, définissez un PTR cohérent, et testez avec de vrais en-têtes plutôt qu'avec de l'espoir. ShadowPanel transforme la partie DKIM, SPF et DMARC en un seul clic pour les domaines qu'il gère, et vous fournit des enregistrements prêts à copier pour les autres.

curl -fsSL https://shadowpanel.de/install.sh | bash

Voir les tarifs et télécharger →