Authentification des e-mails avec SPF, DKIM et DMARC

Ce que c'est

SPF est un enregistrement TXT du nom de domaine qui commence par v=spf1 et énumère les hôtes autorisés à envoyer, par exemple v=spf1 include:mail.example.net -all. La RFC 7208 limite à dix par vérification le nombre de termes qui déclenchent des requêtes DNS (include, a, mx, ptr, exists, redirect) ; au-delà, la vérification renvoie « permerror ». DKIM ajoute à chaque message un en-tête DKIM-Signature ; la clé publique se trouve sous selektor._domainkey.example.ch, ce qui permet à plusieurs services de signer côte à côte avec leurs propres sélecteurs. DMARC publie sous _dmarc.example.ch une politique (p=none, p=quarantine ou p=reject) qui s'applique lorsque ni SPF ni DKIM ne correspondent au domaine d'expéditeur visible (« alignement »), et indique avec rua= une adresse pour les rapports agrégés.

Pourquoi c'est important

Les grands destinataires conditionnent de plus en plus, selon des rapports répandus, l'acceptation du courrier à ces enregistrements, et des attaquants usurpent des domaines d'expéditeur non protégés à des fins de phishing. À l'inverse, une modification DNS inconsidérée – un enregistrement TXT écrasé, un sélecteur supprimé – interrompt silencieusement l'envoi : les messages quittent le serveur et sont rejetés ou écartés chez le destinataire.

Comment l'appliquer

• Recenser tous les services d'envoi légitimes (serveur de messagerie propre, newsletter, e-mails transactionnels, CRM) et les regrouper dans exactement un enregistrement SPF ; commencer par ~all et passer à -all après vérification des rapports. Les dix requêtes comptent y compris les chaînes include des services.
• Activer DKIM pour chaque service et publier l'enregistrement du sélecteur ; lors d'un changement de clé, créer un nouveau sélecteur plutôt que d'écraser l'ancien, afin que le courrier encore en transit reste vérifiable.
• Démarrer DMARC avec p=none et une adresse de rapport, analyser les rapports pendant quelques semaines, puis passer à quarantine, enfin à reject ; définir avec le tag sp une politique propre pour les sous-domaines qui n'envoient jamais.
• Avant chaque changement DNS (changement de fournisseur, nouveau site web), exporter les enregistrements TXT, MX et CAA et les comparer ensuite.

Pièges

Deux enregistrements SPF au même nom sont invalides, et non additifs. Les redirections cassent SPF, car le serveur qui redirige ne figure pas dans l'enregistrement ; DKIM y survit – d'où la nécessité des deux. Les listes de diffusion qui modifient l'objet ou le pied de page cassent de ce fait les signatures DKIM. Les sous-domaines n'héritent d'aucun enregistrement SPF. Les rapports envoyés à une adresse d'un domaine tiers exigent là-bas un enregistrement d'autorisation (RFC 7489, « Verifying External Destinations »). Les rapports DMARC sont au format XML et restent illisibles sans outil d'analyse.

~all ou -all sous DMARC

Dès que DMARC applique p=quarantine ou p=reject, passer de ~all à -all n'apporte aucun gain : DMARC ne distingue que « SPF pass » de « non pass », l'échec souple (softfail) et l'échec strict (hardfail) menant au même résultat, la politique p= décidant seule du traitement. -all, en revanche, coûte du courrier transféré, car les destinataires qui rejettent déjà un hardfail SPF au cours du dialogue SMTP le font avant d'avoir vérifié la signature DKIM – cette même signature qui, sinon, sauve le transfert. Recommandation : garder ~all en permanence pour les domaines qui envoient, et piloter la rigueur via la politique DMARC ; réserver v=spf1 -all combiné à p=reject aux domaines et sous-domaines qui n'envoient jamais.