Configurer SPF, DKIM et DMARC avec Postfix et OpenDKIM

Quand un serveur Postfix envoie des emails sans authentification correcte, les fournisseurs comme Gmail, Outlook ou Yahoo deviennent vite soupçonneux. Et franchement, ils n’ont pas complètement tort.

Un email peut techniquement prétendre venir de n’importe quel domaine. C’est pratique pour les spammeurs, beaucoup moins pour votre délivrabilité. Pour éviter cela, vous devez configurer trois briques DNS et serveur : SPF, DKIM et DMARC.

Cet article modernise l’ancienne approche SPF, Sender ID et DKIM. Sender ID n’a plus vraiment sa place aujourd’hui. On part donc sur une configuration propre avec Postfix, OpenDKIM, des enregistrements DNS fiables et une politique DMARC progressive.

SPF, DKIM, DMARC : qui fait quoi ?

Avant de modifier Postfix ou vos DNS, il faut comprendre le rôle de chaque mécanisme.

• SPF indique quels serveurs ont le droit d’envoyer des emails pour votre domaine.
• DKIM ajoute une signature cryptographique aux messages sortants.
• DMARC dit aux serveurs destinataires quoi faire quand SPF ou DKIM échoue.

SPF répond donc à la question : “cette adresse IP peut-elle envoyer pour ce domaine ?”. DKIM répond : “ce message a-t-il été signé par un domaine autorisé ?”. DMARC répond : “le domaine visible dans le From est-il aligné avec SPF ou DKIM, et que fait-on en cas d’échec ?”.

Les trois sont complémentaires. SPF seul ne suffit pas. DKIM seul ne suffit pas toujours. DMARC donne une politique exploitable aux fournisseurs email. C’est le trio qui compte.

Pourquoi Sender ID ne mérite plus une section dédiée

Sender ID était une ancienne tentative, surtout poussée par Microsoft, pour vérifier l’identité de l’expéditeur. Le problème : le protocole n’a jamais gagné l’adoption durable de SPF, DKIM et DMARC.

Aujourd’hui, ne perdez pas de temps à publier des enregistrements Sender ID. Configurez plutôt correctement SPF, DKIM et DMARC. Votre serveur, vos logs et votre patience vous remercieront.

Pré-requis serveur

Ce guide suppose que vous avez déjà :

• un serveur Debian ou Ubuntu ;
• Postfix installé et capable d’envoyer des emails ;
• un nom de domaine configuré ;
• un accès root ou sudo ;
• la main sur la zone DNS du domaine ;
• un reverse DNS correct sur l’adresse IP du serveur.

Si votre serveur mail Postfix n’est pas encore en place, relisez d’abord ce guide : configurer un serveur mail avec Postfix et des domaines virtuels.

Si vous utilisez WordPress, gardez aussi une règle simple : les emails applicatifs importants doivent partir via un vrai SMTP authentifié. La fonction PHP mail() peut fonctionner, mais elle offre rarement une délivrabilité propre sur la durée.

Étape 1 : vérifier le nom d’hôte et le reverse DNS

Avant SPF, DKIM et DMARC, vérifiez déjà l’identité SMTP du serveur. Un serveur qui dit s’appeler localhost ou vps123456, c’est rarement rassurant.

Affichez le nom d’hôte :

hostnamectl
hostname -f

Vous devriez obtenir un FQDN cohérent, par exemple :

mail.example.comCode language: CSS (css)

Ensuite, vérifiez l’adresse IP publique utilisée par le serveur :

curl -4 ifconfig.me
curl -6 ifconfig.meCode language: CSS (css)

Puis vérifiez le reverse DNS :

dig -x 203.0.113.10 +shortCode language: CSS (css)

Le reverse DNS doit pointer vers un nom cohérent, idéalement mail.example.com. Ensuite, ce nom doit lui-même pointer vers l’adresse IP du serveur.

dig A mail.example.com +short
dig AAAA mail.example.com +shortCode language: CSS (css)

Si le reverse DNS est faux, corrigez-le chez votre hébergeur. Ce réglage ne se fait généralement pas dans la zone DNS classique du domaine.

Étape 2 : publier un enregistrement SPF

SPF se publie dans un enregistrement DNS de type TXT, à la racine du domaine.

Pour un domaine qui envoie uniquement depuis son serveur MX, vous pouvez commencer par :

example.com.  IN  TXT  "v=spf1 mx -all"Code language: JavaScript (javascript)

Si votre serveur d’envoi est une adresse IPv4 précise :

example.com.  IN  TXT  "v=spf1 ip4:203.0.113.10 -all"Code language: JavaScript (javascript)

Avec IPv4 et IPv6 :

example.com.  IN  TXT  "v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 -all"Code language: JavaScript (javascript)

Si vous utilisez aussi un prestataire SMTP, ajoutez son mécanisme include. Exemple fictif :

example.com.  IN  TXT  "v=spf1 ip4:203.0.113.10 include:spf.provider.example -all"Code language: JavaScript (javascript)

Attention : un domaine ne doit avoir qu’un seul enregistrement SPF. Si vous avez plusieurs lignes v=spf1, SPF échouera. Fusionnez-les dans un seul TXT.

Pour vérifier SPF :

dig TXT example.com +shortCode language: CSS (css)

Une fois la configuration validée, préférez -all à ~all. Le softfail ~all sert surtout pendant la phase de transition.

Étape 3 : installer OpenDKIM

DKIM demande une clé privée sur le serveur et une clé publique dans le DNS. OpenDKIM va signer les messages sortants, puis les serveurs destinataires vérifieront la signature avec la clé publique DNS.

Installez les paquets nécessaires :

sudo apt update
sudo apt install opendkim opendkim-tools

Créez ensuite les dossiers de configuration :

sudo mkdir -p /etc/opendkim/keys/example.com
sudo chown -R opendkim:opendkim /etc/opendkim
sudo chmod 750 /etc/opendkim
sudo chmod 750 /etc/opendkim/keys

Dans les exemples suivants, remplacez example.com par votre domaine réel.

Étape 4 : générer la clé DKIM

Choisissez un sélecteur DKIM. Le sélecteur permet de changer de clé sans casser l’ancien enregistrement. J’utilise souvent une date, par exemple 2026, ou un nom simple comme mail.

Générez une clé DKIM RSA 2048 bits :

sudo opendkim-genkey \
  --bits=2048 \
  --domain=example.com \
  --selector=mail \
  --directory=/etc/opendkim/keys/example.comCode language: JavaScript (javascript)

Corrigez ensuite les permissions :

sudo chown opendkim:opendkim /etc/opendkim/keys/example.com/mail.private
sudo chmod 600 /etc/opendkim/keys/example.com/mail.privateCode language: PHP (php)

La commande crée deux fichiers :

• mail.private : la clé privée, à garder sur le serveur ;
• mail.txt : l’enregistrement DNS DKIM à publier.

Affichez l’enregistrement DNS :

sudo cat /etc/opendkim/keys/example.com/mail.txt

Vous obtiendrez un enregistrement TXT à publier sur :

mail._domainkey.example.comCode language: CSS (css)

Le contenu ressemblera à ceci :

v=DKIM1; h=sha256; k=rsa; p=VOTRE_CLE_PUBLIQUE_ICI

Ne publiez jamais la clé privée. Oui, ça paraît évident. Oui, quelqu’un l’a déjà fait. Internet n’oublie jamais.

Étape 5 : configurer OpenDKIM

Éditez le fichier principal :

sudo nano /etc/opendkim.conf

Voici une base propre pour signer les emails sortants avec Postfix :

Syslog                  yes
SyslogSuccess           yes
LogWhy                  yes

Canonicalization        relaxed/simple
Mode                    sv
SubDomains              no
OversignHeaders         From

UserID                  opendkim
UMask                   007

Socket                  local:/run/opendkim/opendkim.sock
PidFile                 /run/opendkim/opendkim.pid

KeyTable                refile:/etc/opendkim/key.table
SigningTable            refile:/etc/opendkim/signing.table
ExternalIgnoreList      refile:/etc/opendkim/trusted.hosts
InternalHosts           refile:/etc/opendkim/trusted.hosts

TrustAnchorFile         /usr/share/dns/root.keyCode language: JavaScript (javascript)

Le réglage Mode sv signifie qu’OpenDKIM signe les emails sortants et peut aussi vérifier les signatures entrantes. Pour un serveur d’envoi, c’est généralement ce que vous voulez.

Étape 6 : créer KeyTable, SigningTable et TrustedHosts

Créez la table des clés :

sudo nano /etc/opendkim/key.table

Ajoutez :

mail._domainkey.example.com example.com:mail:/etc/opendkim/keys/example.com/mail.privateCode language: JavaScript (javascript)

Créez ensuite la table de signature :

sudo nano /etc/opendkim/signing.table

Ajoutez :

*@example.com mail._domainkey.example.comCode language: CSS (css)

Puis créez la liste des hôtes de confiance :

sudo nano /etc/opendkim/trusted.hosts

Ajoutez :

127.0.0.1
::1
localhost
mail.example.com
example.comCode language: CSS (css)

Corrigez les permissions :

sudo chown -R opendkim:opendkim /etc/opendkim
sudo chmod 640 /etc/opendkim/key.table
sudo chmod 640 /etc/opendkim/signing.table
sudo chmod 640 /etc/opendkim/trusted.hosts

Étape 7 : préparer le socket OpenDKIM

Postfix doit pouvoir communiquer avec OpenDKIM via un milter. Le plus propre consiste à utiliser un socket local.

Créez un override systemd pour OpenDKIM :

sudo systemctl edit opendkim

Ajoutez :

[Service]
RuntimeDirectory=opendkim
RuntimeDirectoryMode=0750

Ajoutez ensuite l’utilisateur postfix au groupe opendkim :

sudo usermod -aG opendkim postfix

Rechargez systemd et redémarrez OpenDKIM :

sudo systemctl daemon-reload
sudo systemctl restart opendkim
sudo systemctl status opendkim --no-pager

Vérifiez que le socket existe :

ls -la /run/opendkim/

Vous devriez voir :

opendkim.sockCode language: CSS (css)

Étape 8 : connecter OpenDKIM à Postfix

Postfix utilise les paramètres smtpd_milters et non_smtpd_milters pour brancher des filtres comme OpenDKIM.

Ajoutez la configuration avec postconf :

sudo postconf -e "milter_protocol = 6"
sudo postconf -e "milter_default_action = accept"
sudo postconf -e "smtpd_milters = local:/run/opendkim/opendkim.sock"
sudo postconf -e "non_smtpd_milters = local:/run/opendkim/opendkim.sock"Code language: JavaScript (javascript)

Le paramètre milter_default_action = accept évite de bloquer tous les emails si OpenDKIM tombe temporairement. Sur un serveur très strict, vous pouvez durcir ce comportement plus tard, mais commencez stable.

Redémarrez Postfix :

sudo systemctl restart postfix
sudo systemctl status postfix --no-pager

Surveillez les logs :

sudo journalctl -u opendkim -u postfix -f

Vous pouvez aussi consulter les logs mail classiques selon votre distribution :

sudo tail -f /var/log/mail.logCode language: JavaScript (javascript)

Étape 9 : publier la clé DKIM dans le DNS

Dans votre zone DNS, créez un enregistrement TXT avec ce nom :

mail._domainkey.example.comCode language: CSS (css)

Et comme valeur :

v=DKIM1; h=sha256; k=rsa; p=VOTRE_CLE_PUBLIQUE_ICI

Chez certains hébergeurs DNS, il faut renseigner seulement mail._domainkey comme nom, car le domaine est ajouté automatiquement. Chez d’autres, il faut mettre le nom complet. Oui, c’est pénible. Non, ce n’est pas standardisé dans les interfaces.

Après propagation, vérifiez :

dig TXT mail._domainkey.example.com +shortCode language: CSS (css)

Puis testez la clé DKIM avec OpenDKIM :

sudo opendkim-testkey -d example.com -s mail -vvvCode language: CSS (css)

Si tout va bien, la commande ne doit pas retourner d’erreur grave. Si elle signale que la clé n’est pas sécurisée à cause de DNSSEC absent, ce n’est pas forcément bloquant. Vérifiez surtout que la clé publique est trouvée et correspond à la clé privée.

Étape 10 : publier une politique DMARC progressive

DMARC se publie aussi en TXT, mais sur un sous-domaine spécial :

_dmarc.example.comCode language: CSS (css)

Commencez avec une politique d’observation :

v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s

Cette politique ne rejette rien. Elle vous permet de recevoir des rapports agrégés et de vérifier quels serveurs envoient réellement pour votre domaine.

Une fois SPF et DKIM validés, passez progressivement à quarantine :

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com; adkim=s; aspf=s

Puis augmentez le pourcentage :

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com; adkim=s; aspf=s

Enfin, quand tout est maîtrisé, vous pouvez passer à reject :

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s

Ne commencez pas directement par p=reject si vous ne connaissez pas tous vos flux email. C’est le meilleur moyen de casser une newsletter, un CRM, une boutique WooCommerce ou un outil métier dans un silence très professionnel.

Étape 11 : tester un email complet

Envoyez un email depuis le serveur vers une adresse externe, par exemple Gmail, puis affichez les en-têtes complets du message reçu.

Vous devez chercher des lignes de ce type :

spf=pass
dkim=pass
dmarc=pass

Vous pouvez aussi envoyer un message de test en ligne de commande :

echo "Test SPF DKIM DMARC" | mail -s "Test email authentication" contact@example.netCode language: PHP (php)

Si vous utilisez WordPress, envoyez aussi un email depuis l’application : réinitialisation de mot de passe, formulaire de contact, notification WooCommerce ou test SMTP. L’objectif est de vérifier le chemin réel, pas seulement un email envoyé à la main depuis le shell.

Configurer plusieurs domaines avec OpenDKIM

Si votre serveur Postfix envoie pour plusieurs domaines, créez une clé DKIM par domaine. Ne signez pas tout avec le même domaine par paresse. La paresse, en email, finit souvent dans le spam.

Exemple pour example.net :

sudo mkdir -p /etc/opendkim/keys/example.net

sudo opendkim-genkey \
  --bits=2048 \
  --domain=example.net \
  --selector=mail \
  --directory=/etc/opendkim/keys/example.net

sudo chown -R opendkim:opendkim /etc/opendkim/keys/example.net
sudo chmod 600 /etc/opendkim/keys/example.net/mail.privateCode language: JavaScript (javascript)

Ajoutez la clé dans /etc/opendkim/key.table :

mail._domainkey.example.net example.net:mail:/etc/opendkim/keys/example.net/mail.privateCode language: JavaScript (javascript)

Ajoutez la signature dans /etc/opendkim/signing.table :

*@example.net mail._domainkey.example.netCode language: CSS (css)

Puis ajoutez le domaine dans /etc/opendkim/trusted.hosts :

example.netCode language: CSS (css)

Redémarrez OpenDKIM et Postfix :

sudo systemctl restart opendkim postfix

Enfin, publiez la clé DKIM, SPF et DMARC pour chaque domaine. L’email multi-domaines fonctionne bien seulement si chaque domaine a sa propre authentification.

Cas WordPress : le piège du From incohérent

WordPress envoie souvent des emails depuis une adresse comme wordpress@example.com ou noreply@example.com. Cela fonctionne seulement si le domaine du From est aligné avec votre infrastructure d’envoi.

Pour un site WordPress hébergé sur example.com, évitez d’envoyer depuis une adresse Gmail, Outlook ou un autre domaine que vous ne contrôlez pas. Vous risquez de casser DMARC.

Utilisez plutôt :

• contact@example.com ;
• noreply@example.com ;
• boutique@example.com ;
• ou une adresse SMTP gérée par votre prestataire d’envoi.

Pour WooCommerce, formulaires de contact, newsletters et emails transactionnels, préférez un SMTP dédié si le volume devient sérieux. Un serveur Postfix personnel peut très bien envoyer, mais la délivrabilité dépend aussi de la réputation IP, du reverse DNS, du volume, des plaintes spam et de la qualité des listes.

Erreurs fréquentes SPF, DKIM et DMARC

Avoir plusieurs enregistrements SPF

Erreur classique : publier deux lignes TXT qui commencent par v=spf1. SPF n’aime pas ça. Fusionnez tous les mécanismes dans un seul enregistrement.

Oublier un prestataire d’envoi

Si votre CRM, votre plugin SMTP, votre solution newsletter ou votre outil de facturation envoie pour le domaine, il doit être inclus dans SPF ou signer avec DKIM aligné.

Publier DKIM au mauvais nom DNS

Le nom doit être exactement selecteur._domainkey.domaine. Si votre sélecteur est mail, le nom complet est mail._domainkey.example.com.

Confondre clé publique et clé privée

La clé publique va dans le DNS. La clé privée reste sur le serveur, lisible uniquement par OpenDKIM. Toute autre approche est une invitation à l’usurpation.

Passer DMARC en reject trop vite

Commencez par p=none, analysez les rapports, puis montez progressivement. DMARC doit accompagner votre inventaire des flux email, pas le remplacer.

Ignorer IPv6

Si Postfix envoie en IPv6, ajoutez l’IPv6 dans SPF et configurez aussi le reverse DNS IPv6. Sinon, forcez ou maîtrisez le transport IPv4. L’entre-deux bancal finit rarement bien.

Commandes de diagnostic utiles

Vérifier les DNS principaux :

dig MX example.com +short
dig TXT example.com +short
dig TXT mail._domainkey.example.com +short
dig TXT _dmarc.example.com +shortCode language: CSS (css)

Vérifier le reverse DNS :

dig -x 203.0.113.10 +shortCode language: CSS (css)

Vérifier la configuration Postfix :

postconf -n | grep -E 'milter|myhostname|mydomain|myorigin'Code language: JavaScript (javascript)

Vérifier OpenDKIM :

sudo systemctl status opendkim --no-pager
sudo journalctl -u opendkim -n 100 --no-pager
sudo opendkim-testkey -d example.com -s mail -vvvCode language: CSS (css)

Suivre les logs mail :

sudo tail -f /var/log/mail.logCode language: JavaScript (javascript)

Sur certaines distributions, les logs passent surtout par journald :

sudo journalctl -u postfix -u opendkim -f

Faut-il installer OpenDMARC ?

OpenDKIM signe vos emails sortants avec DKIM. OpenDMARC, lui, sert surtout à vérifier et appliquer des politiques DMARC sur les emails entrants.

Si votre serveur reçoit du courrier pour des boîtes utilisateurs, OpenDMARC peut être utile. Si votre serveur ne fait qu’envoyer des emails transactionnels ou applicatifs, la priorité est plutôt :

• SPF propre ;
• DKIM valide ;
• DMARC publié ;
• reverse DNS correct ;
• alignement du domaine From ;
• réputation IP surveillée.

Ne mélangez pas tout. Pour sortir proprement, OpenDKIM suffit côté signature. Pour filtrer proprement l’entrant, OpenDMARC peut compléter la pile.

Checklist finale

• Le serveur Postfix utilise un hostname propre.
• Le reverse DNS pointe vers le hostname du serveur mail.
• Le domaine a un SPF unique et complet.
• OpenDKIM signe les emails sortants.
• La clé DKIM publique est publiée au bon sélecteur DNS.
• DMARC existe en p=none, puis évolue progressivement.
• Les emails WordPress utilisent un From aligné avec le domaine.
• Les prestataires tiers sont inclus dans SPF ou signent avec DKIM.
• Les tests affichent spf=pass, dkim=pass et dmarc=pass.

FAQ

SPF suffit-il pour éviter le spam ?

Non. SPF aide à autoriser les serveurs d’envoi, mais il ne signe pas le contenu du message. Ajoutez DKIM et DMARC pour une authentification complète.

DKIM améliore-t-il directement la délivrabilité ?

DKIM ne garantit pas l’arrivée en boîte de réception, mais il améliore la confiance technique. Sans DKIM, vous partez déjà avec un handicap.

Puis-je utiliser le même sélecteur DKIM partout ?

Oui, mais ce n’est pas toujours idéal. Pour plusieurs domaines, gardez une clé par domaine. Pour les rotations, utilisez un nouveau sélecteur.

DMARC doit-il être en reject ?

À terme, oui, si tous vos flux email sont maîtrisés. Commencez par p=none, analysez, puis passez progressivement à quarantine et reject.

Pourquoi Gmail affiche encore un échec DMARC ?

Le plus souvent, le domaine visible dans le From n’est pas aligné avec SPF ou DKIM. Vérifiez le domaine From, le Return-Path, la signature DKIM et le prestataire d’envoi réel.

Faut-il DKIM pour chaque sous-domaine ?

Si le sous-domaine envoie des emails, oui. Par exemple, news.example.com doit avoir sa propre stratégie SPF, DKIM et DMARC si vous l’utilisez comme domaine d’envoi.

Conclusion

Pour un serveur Postfix actuel, la bonne base repose sur SPF, DKIM et DMARC.

SPF autorise vos serveurs. DKIM signe vos messages. DMARC aligne le domaine visible et applique une politique. Avec un reverse DNS propre et des en-têtes cohérents, votre serveur part sur des bases solides.

La délivrabilité n’est jamais garantie à 100 %. Mais sans SPF, DKIM et DMARC, vous demandez gentiment aux fournisseurs email de vous faire confiance les yeux fermés. Spoiler : ils ne le feront pas.

Sources

• RFC 7208 : Sender Policy Framework SPF
• RFC 6376 : DomainKeys Identified Mail DKIM
• RFC 7489 : DMARC
• Google Workspace Admin Help : Email sender guidelines
• Postfix : before-queue Milter support
• OpenDKIM Project
• Debian Wiki : OpenDKIM
• SkyMinds : serveur mail Postfix et domaines virtuels

Report a typo