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.

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 !

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

Si on passe par un relai de son fournisseur de domaine (OVH par exemple) c'est généralement déjà rempli par défaut.

Ça va ressembler à ça :

@	
        IN MX     5 mx2.mail.ovh.net.
        IN MX     100 mx3.mail.ovh.net.
        IN MX     1 mx1.mail.ovh.net.

• Source pour OVH : https://help.ovhcloud.com/csm/fr-dns-configure-mx-dns-zone?id=kb_article_view&sysparm_article=KB0051707

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"

• @ : ça va concerner l'ensemble du domaine, mais attention pas les sous-domaines. Sinon il faut déclarer un sous-domaine précis.
• TXT : type d'enregistrement DNS (obligatoirement ça)
• v=spf1 indique qu'on va parler de SPF
• mx : autorise les enregistrement MX du domaine sur lequel SPF est paramétré
• a : autorise les serveurs de messagerie du nom de domaine. On peut indiquer un nom de domaine spécifique
• include:… : là autant mettre son relai SMTP pour être sûr que ce soit pris en compte ? On peut en indiquer plusieurs et donc déléguer sa confiance aux enregistrements SPF de ces autres serveurs. Ça donne ce genre d'option : v=spf1 include:relai.domain1.net include:mail.domain2.org ~all
• all : indique quelle correspondance les messages doivent avoir . Ce paramètre est forcément à la fin.
  • ? : neutre : on n'approuve ni ne refuse rien, c'est juste déclaratif.
  • ~ : échec partiel possible : les serveurs de réceptions peuvent accepter les mails d'expéditeurs qui ne sont pas dans l'enregistrement SPF mais les noter comme suspects. En plus clair : peut-être qu'on s'est fait spoofer ou peut-être qu'on a pas été doué en envoyant un mail légitime d'un endroit mal paramétré.
  • - : échec, les mails en question risquent plus de finir dans le spam car ils ne sont définitivement pas authentifiés.
  • + : c'est la fête du slip, si je comprends bien ? On évite cette option, autant ne rien mettre. C'est d'ailleurs le truc “par défaut” : on dit que “dans le doute, toutes les ip sont légitimes à envoyer des mails”. Ça fait désordre.
  • Le mieux est de commencer avec ~ et de voir comment ça passe, puis de mettre - si les retours sont bons.

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

"v=spf1 include:_mailcust.gandi.net ?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 !

Sur OVH, par défaut :

"v=spf1 include:mx.ovh.com ~all"

Sur Gandi :

"v=spf1 include:_mailcust.gandi.net ?all"

Si on utilise le mail sur le domaine principal (exemple.com) et des sous-domaine (moi.exemple.com), et OVH, et un service tiers (autremail.com). Oui, on peut… “v=spf1 include:mx.ovh.com a:moi.mondomain.com include:autremail.com ~all”

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 avait toujours du mal avec le concept.

Chez Gandi c'était¹⁾ tout automatique, suffit de cliquer sur le bon bouton : Protégez la réputation de votre nom de domaine avec DKIM.

Chez OVH, je vous laisse survivre à la doc sur le sujet : https://help.ovhcloud.com/csm/fr-dns-zone-dkim?id=kb_article_view&sysparm_article=KB0058101 mais visiblement c'est possible à présent ?

• Doc Google : Authentifier les e-mails avec DKIM

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.

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

• sudo -u opendkim : la clé sera créée directement avec les bons droits.
• opendkim-genkey : c'est la commande ; man opendkim-genkey donne plus d'options :)
• -D /etc/opendkim/dkimkeys/mondomaine.org : dossier où les clés seront stockées. Sur /etc/ c'est bien vu qu'on sauve tout dans les backups.
• -d mondomaine.org : à adapter à son domaine (de premier niveau ! pas le sous-domaine du relai !)
• -s dkim23 : le “sélecteur” (selector in english). En fait, si j'ai bien compris, le petit surnom donné à la clé pour pouvoir les repérer entre elles. Du coup c'est pertinent de mettre par exemple la date (sous une forme ou une autre) pour pouvoir repérer la plus vieille si on change. Ce nom va apparaître dans le champ DNS. On peut bien mettre n'importe quoi en fait ; la plupart des sysadmins ne se prennent pas la tête et mettent “dkim” (option par défaut sur rspamd).
• -b 1024 : la taille de la clé, en bit. Debian met par défaut en 2048 (bien qu'upstream, opendkim reste en 1024). Les deux options sont fonctionnelles, voir la note plus haut. C'est vraiment un choix à faire, suivant où on place le risque (se faire distribuer/se faire usurper).

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.

/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

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.

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é"

Et on s'envoie quelques mails pour tester.

Sources :

• https://wiki.debian.org/opendkim
• https://www.malekal.com/installer-configurer-postfix-spf-dkim-dmarc/
• https://serverfault.com/questions/966176/opendkim-postfix-sign-console-sent-mail-but-not-from-a-mail-client-smtp
• https://www.stevejenkins.com/blog/2011/08/installing-opendkim-rpm-via-yum-with-postfix-or-sendmail-for-rhel-centos-fedora/

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 "

• v= : indique qu'on utilise DMARC, faut pas chercher. Paramètre obligatoire.
• p : indique la politique à appliquer si DMARC n'est pas bon. Paramètre obligatoire.
  • none : ne rien faire. C'est souvent la première option à mettre le temps de vérifier que tout roule.
  • quarantine : sera envoyé au dossier “spam” du destinataire. Il aura quand même les messages au besoin.
  • reject : les messages ne seront pas distribués. À faire quand on est sûr de soi.
• adkim : précise s'il faut vérifier la concordance avec DKIM, de façon plus ou moins strict
  • s : strict. Le nom de domaine de l'expéditeur doit correspondre exactement à ce qui est déclaré dans DKIM sinon le message doit être rejeté.
  • r : “relaxed” (souple). Permet que ça corresponde “mais pas exactement”, c'est à dire si ça vient d'un des sous-domaine, le message peut être accepté (mais classé dans les spams ?).
• aspf : idem avec SPF.
  • s : strict. L'en-tête De du message doit correspondre exactement au nom de domaine de la commande SMTP “MAIL FROM”.
  • r : “relaxed” . Autorise les correspondances partielles et tous les sous-domaines sont acceptés.
  • rua=mailto : le mail à qui envoyer les rapports. Ayez une adresse dédiée pour ce genre de bordel de sysadmin, avec de bons filtres et des règles pour vider les messages trop vieux. On peut envoyer à plusieurs adresses mais qui veut faire ça ?

Un exemple simple avec Gandi (modifiez mail@mondomain.com par l'adresse sur laquelle recevoir les rapports) :

"v=DMARC1; p=reject; rua=mailto:mail@mondomain.com"

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

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).

C'est plus “facultatif” mais comme dit en introduction, ce genre de détail contribue à avoir un mail bien délivré.

Là, on va rentrer surtout chez les acteurs vers qui on envoie. Chercher “postmaster Nom_du_Service” permet parfois de trouver le lien vers le service en question !

Il faut souvent leur déclarer nos serveurs mails, les relais utilisés suivant les noms de domaines.

Google utilise un outil (https://postmaster.google.com) qui va offrir des rapports sur la façon dont nos mails sont géré par eux. Au passage, les petits sagouins en profitent pour ajouter une validation, ils donnent un champ TXT à ajouter dans le DNS pour valider que le domaine est à nous.

Nul doute que ce genre de détail aide aussi à la délivrance des mails.

https://sender.office.com si on est en spam, mais il semblerait qu'au delà de ça, ça permette de se faire reconnaitre aussi par eux, même en amont ?

https://sendersupport.olc.protection.outlook.com/pm/Postmaster a d'autres infos.

Ils semblent avoir un truc, mais faut un compte Yahoo, et vu qu'ils banissent même les vieux comptes, et bien je ne sais pas comment je testerais. Mais cet acteur n'étant pas trop utilisé en France, j'imagine que c'est secondaire.

Idem, vos correspondants communiquent-ils avec le géant russe ? Si non, on peut donc s'en passer. Si oui il semblerait que l'adresse soit https://postmaster.mail.ru.

Leur doc/outil est ici : https://postmaster.orange.fr

J'ai un doute. Pas essayé :P

https://postmaster.laposte.net

https://postmaster.free.fr

• https://en.wikipedia.org/wiki/Category:Email_authentication
• MTA-STS (Mail Transfer Agent Strict Transport Security) : impose un chiffrement pour la transmission entre les serveurs mails.
  • TLS-RPT (TLS Reporting) : envoie des rapports s'il y a échec de connexion TLS avec le protocole précédent
• Brand Indicators for Message Identification (BIMI) : ça semble super gadget mais c'est potentiellement un truc que les GAFAM regardent et classent comme “plus sérieux” si c'est présent. Demande à bien vérifier quand même…
  • Mais ça va rapidement avec le fait d'avoir une marque “enregistrée” et… comment dire… https://bimigroup.org/verified-mark-certificates-vmc-and-bimi/
• Enregistrement CAA ? Pour préciser qui a le droit d'émettre un certificat SSL/TLS pour le domaine, mais comme de toute façon j'utilise Let's Encrypt, pas sûr que la contrainte soit énorme.
• Enregistrement Autodiscover : ça faut vraiment que je creuse… permet à Thunderbird de remplir tout seul la partie du relai quand on ajoute un compte.
• DANE (alternative/complément à MTA-STS), s'appuie sur DNSSEC (un autre truc qu'il faut que je creuse).

Par ailleurs, faut aussi creuser “ARC”, mais ça ne se joue pas côté DNS, c'est sur le relai.

• Empêcher le blocage ou le placement dans le dossier "Spam" des messages envoyés aux utilisateurs Gmail : la doc de google est étonnamment bien.
• Google :
  • https://toolbox.googleapps.com/apps/checkmx/ : test du nom de domaine par Google
  • https://transparencyreport.google.com/safe-browsing/overview : État des soucis sur le nom de domaine répertorié par Google (la réputation de notre nom de domaine chez eux)
• https://www.mail-tester.com/ : envoyer un email à une adresse qui va vérifier sa conformité face à plein de paramètres
• https://mxtoolbox.com : divers outils de vérification de la qualité du mail