Sécurité des e‑mails en pratique : mise en place de DMARC, DKIM et SPF avec Postfix et workflow de test

Lorsque vous implémentez DMARC DKIM SPF, c’est plus que des modifications DNS : il s’agit d’un projet opérationnel qui nécessite un inventaire, la conception du MTA, une stratégie de signature, la gestion des rapports et des retours en arrière sécurisés. Ce runbook s’adresse aux administrateurs, aux ingénieurs système et aux exploitants : procédures pragmatiques, commandes de vérification, pièges typiques et une stratégie de retour claire.

Implémenter DMARC DKIM SPF : brève clarification des termes : SPF, DKIM, DMARC en pratique

SPF (Sender Policy Framework) est un enregistrement DNS TXT qui indique quels serveurs sont autorisés à envoyer pour le domaine de l’Envelope‑From ; il protège principalement contre l’usurpation directe du Return‑Path. DKIM (DomainKeys Identified Mail) signe cryptographiquement les messages ; le destinataire vérifie la signature à l’aide d’une clé publique dans le DNS. DMARC (Domain-based Message Authentication, Reporting & Conformance) relie SPF et DKIM et vérifie en plus l’alignement (Alignment), c’est‑à‑dire si les domaines vérifiés correspondent au domaine visible dans le champ From:. Sans alignement, l’effet de protection contre la falsification de l’affichage est limité.

Conditions préalables et préparation organisationnelle

Avant de modifier des enregistrements, établissez un inventaire complet de tous les émetteurs de mail : relais Postfix centraux, applications (p. ex. instances Zammad), services cloud (M365, Google, outils marketing), monitoring, alertes de sauvegarde et prestataires externes. Clarifiez les droits d’écriture DNS, la politique de TTL (réduire temporairement le TTL avant les modifications) ainsi que d’éventuels setups Split‑Horizon DNS pouvant fournir des réponses différentes en interne/extérieur.

Ordre recommandé pour le déploiement

1. Activer DMARC avec p=none et RUA pour rendre visibles les émetteurs réels.
2. Consolider SPF : un enregistrement propre par domaine, respecter la limite de recherches DNS.
3. Activer DKIM à grande échelle, idéalement signer au niveau du relais central (OpenDKIM).
4. Surveiller puis durcir progressivement DMARC : quarantine (éventuellement avec pct) → reject.

SPF : règles pratiques et erreurs typiques

SPF est techniquement simple, mais devient rapidement complexe dans de grands environnements. Règles importantes :

• Un seul enregistrement SPF‑TXT par domaine (plusieurs provoquent une PermError).
• Limitez les requêtes DNS (max. 10) ; évitez les chaînes d’include profondes.
• Documentez chaque include et vérifiez les émetteurs tiers (newsletters, scanners).

SPF‑Beispiel

; SPF für example.tld
example.tld. 3600 IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.mailerprovider.net ~all"

SPF prüfen

dig +short TXT example.tld
# oder für vollständige Ausgabe
dig TXT example.tld +noall +answer

Si vous avez de nombreux includes, n’envisagez le SPF‑flattening qu’avec prudence ou créez des sous‑domaines d’envoi (p. ex. mailer.example.tld) avec leurs propres enregistrements SPF.

DKIM avec Postfix : OpenDKIM en tant que milter

Dans Postfix, DKIM est typiquement réalisé via un milter. OpenDKIM est un outil répandu et stable. Décidez : signature centralisée au niveau du relais (uniformise les clés/rotations) ou décentralisée par hôte (meilleure répartition des responsabilités).

Stratégie des clés

Recommandation : RSA 2048 comme minimum ; 1024 est considéré obsolète. Utilisez un schéma de sélecteur avec composante temporelle (p. ex. s2026q3) pour la rotation. Stockez les clés privées de façon sécurisée (permissions de fichiers, restrictions d’accès) et fixez des calendriers de rotation réguliers.

OpenDKIM : Installation und Basiskonfiguration

sudo apt-get update
sudo apt-get install -y opendkim opendkim-tools

; /etc/opendkim.conf (Auszug)
Syslog                  yes
SyslogSuccess           yes
Canonicalization        relaxed/simple
Mode                    sv
Socket                  local:/run/opendkim/opendkim.sock
KeyTable                /etc/opendkim/key.table
SigningTable            refile:/etc/opendkim/signing.table
InternalHosts           /etc/opendkim/trusted.hosts

sudo install -d -m 0750 -o opendkim -g opendkim /etc/opendkim/keys/example.tld
cd /etc/opendkim/keys/example.tld
sudo -u opendkim opendkim-genkey -b 2048 -s s2026q3 -d example.tld
sudo chown -R opendkim:opendkim /etc/opendkim/keys/example.tld
sudo chmod 0640 /etc/opendkim/keys/example.tld/s2026q3.private
# DNS prüfen
dig @1.1.1.1 +short TXT s2026q3._domainkey.example.tld

Intégration Postfix

# /etc/postfix/main.cf (Ausschnitt)
milter_default_action = accept
milter_protocol = 6
smtpd_milters = unix:/run/opendkim/opendkim.sock
non_smtpd_milters = unix:/run/opendkim/opendkim.sock

Important : Pendant la phase de déploiement, réglez milter_default_action=accept afin que des pannes du milter n’empêchent pas la livraison.

DMARC : activer le reporting, durcir la politique ultérieurement

Publiez DMARC en tant que TXT sous _dmarc.example.tld. Commencez avec p=none et un destinataire rua pour collecter des rapports agrégés et rendre les problèmes visibles.

Enregistrement initial

_dmarc.example.tld. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.tld; adkim=r; aspf=r; fo=1; pct=100"

Les rapports RUA sont des fichiers XML (souvent au format ZIP) qui contiennent des informations sur les résultats SPF/DKIM, les adresses IP et le volume. Utilisez un parseur (p. ex. des outils open source comme pydmarc) ou un collecteur externe ; veillez au stockage, à la rétention et à la protection des données concernant les adresses IP contenues.

Comprendre l’alignement

DMARC exige que soit SPF, soit DKIM soit aligné avec le domaine affiché dans le champ From:. Les causes fréquentes d’échecs DMARC sont :

• L’Envelope-From appartient à un tiers (fournisseur), le champ From: utilise le domaine de l’entreprise.
• DKIM signe avec une valeur d= différente du domaine visible dans le champ From:.

Solutions : adapter l’Envelope-From (p. ex. via un relais), signer DKIM de sorte que d= corresponde au domaine indiqué dans le champ From:, ou envoyer via des sous-domaines avec un DMARC spécifique.

Workflow de test : mesurable et contrôlé

Une démarche itérative évite la mise hors service de systèmes légitimes. Modèle de déroulement recommandé :

1) Baseline : DMARC p=none, rapports sur 48–72 heures

Collectez les données RUA, cataloguez les adresses IP émettrices et les services. Identifiez les sources non identifiées et priorisez leur investigation selon le volume et la criticité.

2) Assainissement du SPF

Réduisez les directives include, créez si nécessaire des sous-domaines d’envoi et testez chaque modification avec des résolveurs publics.

3) Activer DKIM partout

Assurez-vous que tous les flux de production passent par le saut signataire. Envoyez des mails de test depuis chaque application et vérifiez les en-têtes côté destinataire.

4) Quarantine avec contrôle du paramètre pct

_dmarc.example.tld. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@example.tld; adkim=r; aspf=r; pct=50"

Augmentez progressivement la sévérité de la politique et surveillez des boîtes canary (Gmail, M365) ainsi que le backlog du support.

5) Reject

Ne définissez p=reject qu’une fois que tous les émetteurs légitimes sont stablement alignés et que vous pouvez répondre rapidement aux tickets de support. Planifiez des SLA clairs pour l’analyse et le rollback.

Commandes pratiques de test et de diagnostic

Pour l’envoi de mails de test, swaks (Swiss Army Knife SMTP) est utile ; il permet de vérifier si des signatures sont générées :

# Beispiel: Testmail via lokalen Relay
swaks --to test@example.org --from zammad@example.tld --server localhost:25 --header "Subject: DKIM Test"

# DKIM/Header prüfen (auf Empfänger oder lokalen Mailbox-Store)
grep -i "DKIM-Signature|Authentication-Results" /var/mail/testuser | sed -n '1,80p'

Vérifications DNS :

dig @1.1.1.1 TXT s2026q3._domainkey.example.tld
dig @8.8.8.8 TXT _dmarc.example.tld +noall +answer
# Über TCP testen, falls große TXT-Records Probleme machen
dig @1.1.1.1 TXT s2026q3._domainkey.example.tld +noall +answer +tcp

Vérifier le rapport RUA (décompresser le ZIP et formater) :

unzip -p report-12345.zip | xmllint --format - | sed -n '1,200p'

Règles d’exploitation spécifiques à Zammad

Les instances Zammad envoient souvent des e-mails critiques pour le système (notifications de tickets, alertes SLA). Vérifiez les points suivants :

• Configurez Zammad pour que les e-mails sortants transitent par le relais Postfix central (UI d’administration ou systemsendmail). Cela garantit la signature DKIM centralisée et l’alignement DMARC.
• Vérifiez From: vs Envelope‑From: Zammad peut, par défaut, utiliser des expéditeurs différents ; configurez des domaines expéditeurs cohérents ou utilisez un sous‑domaine d’envoi.
• Effectuez des envois de tickets de test et vérifiez complètement les en‑têtes chez le destinataire (Received, DKIM‑Signature, Authentication‑Results).
• Automatisez des contrôles par sondage : un job de monitoring qui envoie régulièrement des e‑mails de test et vérifie la signature/Authentication‑Results réduit les risques opérationnels.

Cas problématiques et dépannage

DMARC échoue alors que SPF/DKIM passent

Souvent, c’est dû à un manque d’alignement. Vérifiez si DKIM d= correspond au domaine From ou si le Return‑Path appartient au même domaine organisationnel.

DKIM passe chez certains Fournisseurs, échoue chez d’autres

La distribution DNS est souvent la cause : split‑horizon, troncation des enregistrements TXT ou cache. Testez avec différents résolveurs publics et en TCP pour identifier des problèmes de fragmentation.

Défaillance du milter

sudo systemctl status opendkim --no-pager
sudo ss -xlpn | grep opendkim
journalctl -u opendkim -n 200 --no-pager
journalctl -u postfix -n 200 --no-pager

Pendant la phase de déploiement, les erreurs du milter ne doivent pas empêcher la livraison (milter_default_action=accept), mais en phase d’exploitation elles doivent être surveillées et corrigées.

Transferts, listes de diffusion et ARC

SPF échoue souvent lors d’un simple transfert, car le forwarder n’est pas dans votre SPF. Deux options pratiques :

• Utiliser DKIM — les signatures survivent généralement mieux au transfert.
• Prendre en charge Authenticated Received Chain (ARC) — ARC est un mécanisme d’en‑têtes qui documente l’authenticité à travers les listes de diffusion/serveurs de transfert et aide les destinataires à accepter des messages légitimes malgré des résultats SPF/DKIM brisés.

ARC est particulièrement utile dans des environnements avec de nombreuses listes de diffusion ou des redirections internes.

Sécurité, gestion des clés et hygiène d’exploitation

Les clés privées DKIM sont des secrets opérationnels : sécurisez les fichiers, restreignez les droits d’accès et protégez les sauvegardes. Documentez les dates de rotation et testez les changements de clés dans une zone de staging. Mettez en place un contrôle des changements pour les modifications DNS (Git + CI pour les fichiers de zone ou un déploiement DNS piloté par tickets).

Plan de retour arrière (court et opérationnel)

1. En cas d’échecs critiques de livraison, réglez rapidement DMARC sur p=none :

# Beispiel: neuer DMARC-Record
_dmarc.example.tld. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.tld; adkim=r; aspf=r; pct=100"

# DNS-Änderung prüfen
dig @1.1.1.1 TXT _dmarc.example.tld +noall +answer
# Postfix/OpenDKIM Status prüfen
sudo systemctl status postfix opendkim --no-pager

Lancez ensuite l’analyse des causes : quels expéditeurs ont échoué, quels services ont été affectés, et documentez les leçons apprises dans votre Change‑Log.

Maintenance à long terme et surveillance

Planifiez des revues régulières : analyser les rapports RUA (p. ex. hebdomadairement), rotation des clés DKIM semestrielle, inventaire SPF trimestriel. Automatisez des alertes pour les augmentations soudaines de volume ou de taux d’erreurs dans les rapports DMARC.

Conclusion

La mise en place de DMARC, DKIM et SPF est un projet opérationnel : inventaire, gouvernance DNS, stratégie centrale de signature, workflow de tests et chemins de secours clairs sont décisifs. Commencez par le reporting DMARC, nettoyez le SPF, activez DKIM au niveau du relay, et durcissez DMARC par étapes. La documentation, la supervision et un entretien régulier rendent la mesure durablement efficace — en particulier pour des applications comme Zammad qui envoient des notifications critiques.

DMARC, DKIM & SPF : exploitation, surveillance et automatisation

Une fois la technique de base en place, c’est l’exploitation continue qui détermine le succès. Changez la perspective d’un projet ponctuel vers un service permanent : gouvernance DNS, haute disponibilité du Milter, pipeline RUA, cycle de vie des clés et automatisation des retours arrière sont des chantiers opérationnels à planifier tôt.

Fournisseurs DNS et gestion des modifications

• Faites attention aux limites des fournisseurs pour les appels API et au rate limiting lors des uploads de zone ; sinon les déploiements automatisés peuvent échouer ou provoquer des incohérences de TTL.
• Avant des modifications majeures, utilisez des TTL courts (p. ex. 300 s) et réaugmentez-les après stabilisation.
• Testez la délivrance des enregistrements TXT via plusieurs résolveurs publics et via TCP pour détecter la troncature.

Haute disponibilité et gestion des clés

Exploitez le signataire DKIM comme composant à haute disponibilité : découplez les sauts Postfix via un milter TCP/inet ou via un proxy central. Les clés privées doivent être stockées dans un coffre-fort de clés sécurisé ou un HSM ; établissez un playbook documenté de rotation d’urgence (publier un nouveau sélecteur, basculer les signatures, ne retirer l’ancienne clé qu’après une fenêtre de test).

Pipeline RUA & intégration SIEM

Les rapports RUA sont des données brutes — construisez une pipeline automatisée : collecteur (e‑mail ou API) → parser/normalizer → base de données de séries temporelles & SIEM. Règles devant déclencher des alertes immédiates : augmentation soudaine des échecs DMARC, nouvelles IP émettrices avec un volume élevé, ou échecs récurrents pour des sous‑domaines critiques. Veillez à la protection des données : les adresses IP dans les rapports sont des données à caractère personnel et nécessitent des politiques de conservation appropriées.

Filets de sécurité opérationnels

• Récepteurs canary : un petit ensemble de fournisseurs différents (Gmail, M365) comme système d’alerte précoce.
• Milter‑Circuit‑Breaker: alerte automatique en cas de timeouts Milter répétés ; tant que milter_default_action=accept assure une phase de repli sûre.
• Infrastructure as Code: les modifications DNS via GitOps (Pull‑Request, Review, CI) réduisent les erreurs humaines et permettent un revert rapide.

Ces composants opérationnels rendent le projet résilient : ils réduisent les tickets de support, préviennent les incidents de production pour des logiciels d’entreprise sur mesure comme Zammad et créent un historique de modifications clairement auditable.

Pour ce sujet, Postfix, DKIM et les enregistrements SPF sont également importants. L’article replace ces aspects de manière compréhensible et montre ce qui importe au quotidien.