Table des matières

DNS, SPF, DKIM, DMARC et autres choses à configurer sur le mail

Qu'on délègue une grande partie ou qu'on fasse tout soi-même, il faut paramétrer diverses choses dans le DNS afin que les mails puissent être envoyés, reçus, et passer les filtres antispam.

Relai et domaine, deux choses différentes

Il y a un concept important à bien comprendre, la différence entre le nom de domaine associé au mail (pour l'exemple, mondomaine.org, qui sera associé à l'adresse mail moi@mondomaine.org) et le domaine lié à la machine autorisée à gérer réellement les envois et réceptions de mail (ici, relai.org). Certaines choses sont à paramétrer sur le domaine associé au mail, d'autres concernent uniquement le relai.

Tout ce qui concerne la vérification de l'identité dans le DNS (mesures anti-spoofing) est toujours associé au domaine du mail (mondomaine.org) et non au relai ! Donc, SPF, DKIM, DMARC entre autre (mais il y en a d'autres et je complèterais à mesure…).

Bien configurer SPF, DKIM, DMARC va nous donner une bonne déliverabilité chez la majorité des acteurs (oui, même les gros). Cela ne suffit pas pour tout, mais ça aide vraiment. Accessoirement cela rend plus difficile à un acteur malveillant de se faire passer pour “nous”, alors pas de raison de s'en priver.

Et puis c'est vraiment faisable quand on gère soi-même toute la chaîne. Ça va bien se passer… tant que je ne perds pas la doc !

DNS, la base

Concernant les déclarations dans le DNS, il faut obligatoirement déclarer les divers relais mail autorisés à gérer l'envoi de nos mails. Et oui, pour éviter les soucis, mieux vaut en avoir au moins deux.

À compléter, là je bouge juste les infos de place

SPF

On peut indique des ip, des noms de domaine… Je trouve le nom de domaine plus versatile et ça suffit.

@ IN TXT 10800 "v=spf1 mx a include:relai.org -all"

Si l'option initiale ne suffit pas, dans ce que j'ai ici et là qui semble valide…

"v=spf1 include:_mailcust.gandi.net ?all"
"v=spf1 include:_mailcust.gandi.net a:moi.mondomain.com include:autremail.com ?all"
"v=spf1 mx -all"
example.org.             IN  TXT  "v=spf1 a mx ip6:2001:db8::/32 -all"

Attention, c'est des exemples, une seule de ces lignes dans votre zone DNS ou ça va créer des soucis !

Plus de doc chez Google : Définir votre enregistrement SPF (configuration avancée).

DKIM

DKIM est LE point compliqué : cela demande de générer une clé sur le serveur de relai. Donc, DKIM dépend entièrement du bon vouloir du service.

Gandi et Infomaniak permettent de gérer DKIM très simplement. Par contre, en 2023, OVH a toujours du mal avec le concept. Donc OVH n'est pas un bon choix pour le relai de mail !

En passant par le relai des autres

infos à transférer

Quand on a son propre relai

DKIM m'aura filé des boutons… Espérons que tout est noté proprement.

Je préfère passer par Opendkim plutôt que Rspamd. Ce dernier gère trop de choses, plante, a une configuration bien touffue, bref j'ai eu vraiment des soucis, donc on va séparer un peu ; ce serait abusé de dire qu'on va vers du KISS vu la complexité des bouzins mais… on essaie un peu.

Pour la génération de la clé, comme indiqué ici, si on s'amuse à faire plus grand que 1024 bit, il faudra faire deux enregistrements MX et prendre le risque que certains gros fournisseurs de mails ne sachent pas quoi en faire. (Info à vérifier en 2023, mais dans le doute…)

Il est aussi possible de générer une clé ed25519, mais elle n'est pas prise en compte chez plein de fournisseurs mails et fera donc échouer la vérification DKIM (source).

Oui, c'est ridicule, mais… L'objectif de paramétrer DKIM est que notre courrier soit distribué au mieux, alors on ne cherche pas. Avec la trinité SPF/DKIM/DMARC ce n'est quand même pas si simple de se faire usurper, même avec une clé faible sur DKIM. On peut espérer qu'avant que ça devienne un vrai souci, les fournisseurs passeront à des clés plus correctes.

Au passage, il faudra que je vérifie, de mon côté, que j'accepte bien les clefs RSA en deux parties et les clés ed25519…

Avant tout : on va mettre toute la configuration dans un dossier.

sudo mkdir -p /etc/opendkim/dkimkeys

On créera autant de dossier que de domaines. Oui c'est un peu lourd mais ça simplifiera la gestion plus tard.

sudo mkdir /etc/opendkim/dkimkeys/mondomaine.org

Et s'assurer des bons droits sinon ça ne va pas aller.

sudo chown -R opendkim: /etc/opendkim/

On va commencer par générer la clé, en tant qu'user opendkim.

sudo -u opendkim opendkim-genkey -D /etc/opendkim/dkimkeys/mondomaine.org -d mondomaine.org -s dkim23 -b 1024

Générez autant de clés que de domaines autorisés à envoyer des mails en leur nom.

S'assurer aussi qu'elles ont les bons droits :

sudo chmod 640 /etc/opendkim/dkimkeys/example.org/default.private
sudo chmod 644 /etc/opendkim/dkimkeys/example.org/default.txt

On va ensuite modifier /etc/opendkim.conf et s'assurer que certains paramètres sont bien renseignés.

Là je vais copier ma version, commentée, ne me souvenant plus de ce que c'était par défaut.

/etc/opendkim.conf
# Active les logs. L'option LogWhy permet plus de verbosité, à réserver au débugage.
Syslog                  yes
SyslogSuccess           yes
#LogWhy                 no
 
# Comment les mails sont signés. Ma politique n'est pas des plus strictes mais dans mon cas ça devrait être adapté.
Canonicalization        relaxed/simple
Mode                    sv
SubDomains              yes
OversignHeaders         From
 
# La partie à adapter et modifier ! La plus importante ! Mais... On va avoir du multidomaine, donc ici c'est juste en backup (ou si vous n'avez qu'un domaine). Décommentez Keyfile dans ce cas.
Domain                  mondomain.org
Selector                dkim23
#KeyFile         /etc/opendkim/dkimkeys/dkim23.private
 
# Permissions et user ; ne pas bidouiller sans savoir
UserID                  opendkim
UMask                   007
 
# Cette partie est si on a plusieurs domaines. On va avoir des fichiers à parser pour voir la concordance clé/domaine.
# L'option "refile" plutôt que "file" indique que les expressions régulières doivent être interprétées.
# Fichier qui indiquera où sont les clés
KeyTable                 refile:/etc/opendkim/KeyTable
# Fichier pour dire comment utiliser ces clés
SigningTable                 refile:/etc/opendkim/SigningTable
 
# Hôtes pour qui les mails seront signés. Là, il y a une subtilité ; on va donc les déclarer dans un fichier annexe.
InternalHosts           refile:/etc/opendkim/TrustedHosts
 
# Pour qu'on ne signe pas des trucs qui ne viennent pas du bon endroit ?
ExternalIgnoreList      refile:/etc/opendkim/TrustedHosts
 
# Socket pour le MTA, Postfix dans notre cas, qui marche avec celui-ci.
Socket                  inet:8891@localhost
PidFile                 /run/opendkim/opendkim.pid
 
# The trust anchor enables DNSSEC. In Debian, the trust anchor file is provided
# by the package dns-root-data.
TrustAnchorFile         /usr/share/dns/root.key
 
# permettre un redémarrage automatique, mais pas trop vite non plus pour ne pas se bloquer
AutoRestart             Yes
AutoRestartRate         10/1h

Par défaut Opendkim a sans doute généré /etc/opendkim-trustedhosts.conf. On va copier ça dans /etc/opendkim/TrustedHosts et déclarer le localhost (en principe par défaut mais ça va mieux en le disant ?), l'ip sur le réseau local et l'ip publique du serveur. Si on oublie la dernière, les mails envoyés par le système seront signés, mais pas ceux envoyés depuis Thunderbird… potentiellement c'est aussi là qu'il faudrait mettre l'ipv6 ?

Chez moi ça ressemble à ça (j'ai gardé les ip locales par défaut aussi…) :

127.0.0.1
192.168.0.0/16
10.0.0.0/8
172.16.0.0/12
# IP sur le réseau local
192.168.1.85/24
# IP publique
109.190.XXX.XXX

Multidomain

Si on a déclaré quelques fichiers… il va falloir les remplir.

/etc/opendkim/KeyTable
dkim23._dkim.example.org example.com:dkim23:/etc/opendkim/dkimkeys/example.org/dkim23.private

Ajouter autant de ligne que de domaines, potentiellement en adaptant la partie selector (et évidement le nom de domaine).

Puis l'autre fichier sur comment utiliser les clés. Cela permet plus précisément de dire “tel domaine doit utiliser tel type de sélecteur”. On peut même affiner par utilisateur.

/etc/opendkim/SigningTable
*@example.org dkim23._dkim.example.org
bob@example2.com dkim23._dkim.example2.com

Enfin, dans ce cas, mieux vaut encore affiner TrustedHosts. Les domaines déclarés ici, puisqu'ils sont référencés à la fois avec InternalHosts et ExternalIgnoreList, seront donc considérés comme interne et DKIM signera leur courrier sortant.

Un petit doute si c'est pertinent… Je sens qu'on va avoir des trucs bizarres avec ça.

Finitions

On recharge :

service opendkim restart

Et on configure postfix en ajoutant ceci :

/etc/postfix/main.cf
#Antispam et DKIM
milter_default_action = accept
smtpd_milters = inet:localhost:8891
non_smtpd_milters = $smtpd_milters
milter_protocol = 6
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}
internal_mail_filter_classes = bounce

On recharge :

service postfix restart

Ensuite, la zone DNS. Toutes les infos sont avec cat /etc/opendkim/dkimkeys/mondomaine.org/dkim23.txt, il suffit de copier ce qu'il faut dans un champ txt. Sur OVH, restez bien en txt, en essayant d'ajouter un champ “DKIM” je n'ai pas rencontré un franc succès.

La clé publique devrait renvoyer quelque chose comme ça : dkim23._domainkey IN TXT ( “v=DKIM1; h=sha256; k=rsa; ”

  "p=MIIBIouquecestlongcetteclé" )  ; ----- DKIM key 2023 for mondomaine.org

Et l'enregistrement DNS ressemblera à quelque chose comme ça :

dkim23._domainkey IN TXT "v=DKIM1; h=sha256; k=rsa; "p=MIIBIouquecestlongcetteclé"

On peut déclarer plus de choses dans le DKIM. Et ça serait sans doute mieux. Mais, là, ça me gonfle, alors ça ira jusqu'à ce que les mails soient refusés.

Bien attendre la propagation du DNS avant de s'inquiéter. Je conseille https://dnschecker.org/dkim-record-checker.php ; attention les tests sur le DNS ne prennent pas tous DKIM en compte, pas besoin de s'inquiéter trop vite, suffit de prendre le bon outil ou sa bonne option !

Et on s'envoie quelques mails pour tester.

Sources :

DMARC

Après les options compliquées à comprendre avec SPF et DKIM, DMARC parait facile. Oui mais… pour qu'il marche bien, il faut que les deux autres soient fonctionnels, sinon certains fournisseurs (dont Google) vont le classer en non valide.

Les autres fournisseurs de mail envoient un rapport quotidien de vos échanges avec eux. Cela fait pas mal de bruit et on pourrait être tenté d'envoyer ça dans le vide, mais en cas de souci de distribution, cela peut donner quelques indices.

Le champ dmarc va ressembler à ça si on est strict :

_dmarc 10800 IN TXT "v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:admin@mondomaine.org "

Et ceci si on ne veux pas trop de soucis dans un premier temps :

_dmarc 10800 IN TXT "v=DMARC1; p=quarantine; adkim=r; aspf=r; rua=mailto:admin@mondomaine.org "

Voir https://support.google.com/a/answer/2466563#dmarc-record-tags pour plus de détails.

Lire les rapports

C'est du xml et un peu obtus, comme ça.

Je teste https://github.com/gene-git/dmarc_report pour une analyse en local. C'est plutôt lisible, effectivement. Mais ça serait intéressant de voir comment automatiser la lecture des rapports et avoir des stats au fil du temps (bref, ce que propose des acteurs pros… sauf que je ne veux pas confier ça à des externes).

Champs DNS en plus

Google entre autre veut un enregistrement txt rien que pour lui

 Ce texte est placé sous licence CC0