Explication de SPF, DKIM, DMARC et MX

Quatre familles d’enregistrements DNS définissent une grande partie de la politique opérationnelle d’un domaine de messagerie personnalisé. MX dirige les e-mails entrants. SPF autorise l’infrastructure d’envoi. DKIM ajoute aux messages une signature de domaine vérifiable. DMARC vérifie si SPF ou DKIM est aligné avec le domaine visible par le destinataire et publie une politique d’application.

Ils fonctionnent ensemble, mais chacun résout un problème distinct. Un administrateur de domaine doit comprendre ces limites avant de connecter un fournisseur ou de migrer la messagerie.

Le service de messagerie privée sur domaine personnalisé de Thelemail génère et vérifie les enregistrements nécessaires. Ce guide explique leur signification afin que vous puissiez examiner la configuration obtenue en toute connaissance de cause.

MX sélectionne les serveurs de messagerie entrants

Un enregistrement MX indique quel hôte accepte les e-mails pour un domaine. Chaque enregistrement possède une valeur de priorité et un nom d’hôte cible. Les valeurs de priorité les plus faibles sont essayées en premier. Plusieurs enregistrements ayant la même priorité peuvent répartir les tentatives entre des serveurs équivalents, tandis que les enregistrements avec un nombre plus élevé fournissent généralement d’autres chemins d’acheminement.

La cible est un nom d’hôte qui se résout en une adresse. Saisissez les valeurs exactement comme le fournisseur de messagerie les fournit. Les interfaces DNS ne gèrent pas toutes de la même manière le nom de la zone et le point final ; considérez donc le résultat publié comme la référence définitive.

MX agit sur l’acheminement entrant. Il ne précise pas quels systèmes peuvent envoyer au nom du domaine. Cette autorisation provient de SPF et DKIM, tandis que DMARC évalue l’alignement des identités.

Lors d’une migration vers un autre fournisseur, préparez le nouveau service avant de remplacer les enregistrements MX. Créez d’abord chaque boîte mail, alias et adresse partagée. Le guide du basculement MX par étapes traite de la planification du TTL, de la surveillance pendant le chevauchement et du retour en arrière.

SPF autorise l’expéditeur de l’enveloppe

Sender Policy Framework, ou SPF, publie une politique TXT qui identifie les systèmes autorisés à envoyer en utilisant un domaine dans l’enveloppe SMTP. Les serveurs destinataires comparent l’adresse IP qui se connecte aux mécanismes de cette politique.

L’identité d’enveloppe est souvent appelée chemin de retour ou adresse MAIL FROM. Elle reçoit les rebonds et peut différer de l’adresse From visible dans un client de messagerie. Un résultat SPF brut positif peut donc utiliser un domaine sans rapport avec l’expéditeur visible.

Une politique SPF peut autoriser des plages d’adresses IP directes et des politiques maintenues par les fournisseurs. Parmi les mécanismes courants figurent ip4, ip6, a, mx et include. Le qualificatif final couvre les sources qui ne correspondent à aucun mécanisme. Votre fournisseur doit vous fournir les éléments de politique nécessaires.

Conserver une seule politique SPF par domaine

Un domaine doit publier un seul enregistrement SPF commençant par v=spf1. Plusieurs enregistrements SPF distincts créent une erreur d’évaluation permanente. Lorsqu’une plateforme web, un système de facturation et un fournisseur de boîtes mail envoient tous des e-mails pour le domaine, rassemblez leurs mécanismes autorisés dans une seule politique.

L’évaluation SPF autorise au maximum dix mécanismes et modificateurs qui interrogent le DNS. Les politiques include imbriquées sont prises en compte dans cette limite. Son dépassement produit une erreur permanente. Supprimez les expéditeurs qui ne sont plus utilisés et envisagez des sous-domaines dédiés pour les différents usages de la messagerie.

Le transfert peut perturber SPF, car le serveur de transfert se connecte depuis une nouvelle adresse IP tout en conservant un domaine d’enveloppe antérieur. Sender Rewriting Scheme peut fournir une nouvelle identité d’enveloppe autorisée. DKIM peut survivre au transfert lorsque le contenu signé reste intact.

DKIM signe le message avec une clé de domaine

DomainKeys Identified Mail, ou DKIM, fournit à un système d’envoi une clé de signature privée. Son en-tête DKIM-Signature contient le domaine signataire, le sélecteur, les en-têtes signés et une empreinte du corps du message. Le destinataire récupère la clé publique dans le DNS et vérifie la signature.

Le nom DNS associe le sélecteur à _domainkey et au domaine signataire. Un fournisseur fournit l’enregistrement de clé publique ou un CNAME qui pointe vers celui-ci. Plusieurs sélecteurs peuvent coexister pour permettre la rotation des clés et l’utilisation de plusieurs services d’envoi.

Une vérification DKIM réussie montre que le contenu signé n’a pas été modifié pendant le transit et qu’un détenteur de la clé privée a créé la signature. DMARC vérifie ensuite l’alignement entre le domaine signataire et le domaine From visible.

Les listes de diffusion, les passerelles et les produits de sécurité peuvent modifier le contenu signé et invalider une signature DKIM. Examinez l’en-tête Authentication-Results et le chemin du message avant de modifier la clé DNS.

Effectuer une rotation délibérée des sélecteurs

Pour effectuer une rotation DKIM sûre, publiez la nouvelle clé, signez avec le nouveau sélecteur, vérifiez les résultats et conservez l’ancienne clé publique pendant la fenêtre de transition. Limitez l’accès aux clés privées aux systèmes d’envoi autorisés.

DMARC relie l’authentification au domaine From visible

Domain-based Message Authentication, Reporting and Conformance, ou DMARC, est publié sous _dmarc dans le domaine. Il compare le domaine de l’en-tête From visible aux résultats SPF et DKIM.

DMARC réussit lorsqu’au moins l’un de ces chemins aboutit :

• SPF réussit et son domaine d’enveloppe authentifié est aligné avec le domaine From visible.
• DKIM réussit et son domaine signataire est aligné avec le domaine From visible.

L’alignement souple autorise les sous-domaines appartenant à la même organisation, tandis que l’alignement strict exige une correspondance exacte du domaine. L’alignement souple est utilisé par défaut. La politique décrit également le traitement demandé en cas d’échec.

Les principaux modes de politique sont les suivants :

• p=none demande une surveillance pendant la collecte des rapports.
• p=quarantine demande aux destinataires de traiter les e-mails en échec comme suspects.
• p=reject demande aux destinataires de refuser les e-mails en échec.

Les destinataires conservent le contrôle final du traitement local ; la politique est donc une demande publiée. Les rapports agrégés envoyés aux destinations rua résument les résultats par source et révèlent les problèmes d’alignement avant un renforcement de l’application.

Passez de la surveillance à l’application après avoir recensé chaque expéditeur légitime. Un outil de facturation ou un formulaire web oublié peut perdre en délivrabilité avec une politique stricte, même si les e-mails du fournisseur de boîtes mail sont configurés correctement.

L’authentification et le chiffrement protègent des éléments différents

SPF, DKIM et DMARC aident les systèmes destinataires à évaluer l’identité du domaine et l’usurpation, tandis que MX achemine les e-mails entrants. Le chiffrement du contenu nécessite des contrôles ailleurs sur le chemin du message.

TLS protège le trafic SMTP entre les serveurs qui le prennent en charge. Le chiffrement de bout en bout protège le contenu lisible sur l’intégralité du chemin lorsque les deux parties utilisent des clés compatibles. Le chiffrement du stockage protège les données des boîtes mail détenues par le service.

Thelemail fournit un chiffrement sans accès au contenu stocké des boîtes mail et un chiffrement de bout en bout entre les comptes Thelemail. Pour les e-mails externes, le client web utilise WKD/OpenPGP lorsqu’une clé de destinataire compatible est disponible, et Thelemail publie les clés des utilisateurs via WKD afin de permettre les e-mails entrants chiffrés compatibles. Les autres e-mails externes utilisent le protocole SMTP standard avec TLS lorsque celui-ci est pris en charge. Les objets des messages externes et les métadonnées d’enveloppe restent visibles pour l’acheminement. Le modèle de sécurité et de menaces décrit précisément ces garanties.

Suivre un ordre de configuration par étapes

Une nouvelle configuration de domaine personnalisé est plus facile à examiner dans l’ordre suivant :

1. Vérifier la propriété du domaine au moyen de l’enregistrement TXT du fournisseur.
2. Publier DKIM pour le nouveau service d’envoi.
3. Créer une politique SPF unique qui couvre chaque expéditeur légitime.
4. Publier DMARC avec des rapports et une politique initiale appropriée.
5. Créer chaque boîte mail, alias et adresse partagée.
6. Tester l’authentification des e-mails sortants depuis chaque service d’envoi.
7. Modifier les enregistrements MX une fois tous les destinataires entrants prêts.
8. Examiner les rapports et renforcer l’application de DMARC en fonction des éléments recueillis.

C’est l’ordre utilisé dans le guide de configuration du domaine de Thelemail. Les offres et capacités en vigueur déterminent les limites relatives aux boîtes mail, au stockage et aux domaines. Les offres payantes incluent des alias illimités, sous réserve d’un garde-fou anti-abus par espace de travail ; les alias ne sont pas inclus dans l’offre Free.

Une personne peut utiliser une adresse @temail.org sans administrer de DNS. Un foyer ou une équipe dirigée par ses fondateurs bénéficie de la portabilité des adresses sur domaine personnalisé lorsqu’un administrateur technique prend en charge ce processus de configuration.

Diagnostiquer les échecs à partir de l’en-tête du message

Commencez par l’en-tête Authentication-Results du système destinataire. Il consigne généralement les résultats SPF, DKIM et DMARC, ainsi que les domaines évalués.

SPF réussit alors que DMARC échoue

Comparez le domaine d’enveloppe authentifié au domaine From visible. Configurez un chemin de retour aligné ou utilisez une signature DKIM alignée.

DKIM signale une clé manquante

Interrogez le sélecteur et le domaine signataire indiqués dans l’en-tête DKIM-Signature. Vérifiez les champs d’hôte copiés, une éventuelle configuration expirée chez le fournisseur et la suppression prématurée d’une clé.

La vérification DKIM échoue malgré une clé publiée

Vérifiez la clé DNS actuelle et déterminez si un service de transfert, une liste de diffusion ou une passerelle a modifié le contenu signé. Testez un chemin direct afin d’isoler la modification.

SPF renvoie une erreur permanente

Recherchez plusieurs enregistrements SPF, des erreurs de syntaxe, des inclusions récursives et plus de dix termes qui interrogent le DNS. Retirez les services inutilisés ou séparez les flux de messagerie.

Certains expéditeurs atteignent encore l’ancien hébergeur

Interrogez le DNS faisant autorité et examinez le TTL des enregistrements MX. Maintenez les deux fournisseurs disponibles pendant la période de chevauchement planifiée et rapprochez les messages reçus par l’ancien hébergeur.

Maintenir les enregistrements après le lancement

Le DNS de messagerie doit être examiné régulièrement. Supprimez les autorisations des plateformes qui ne sont plus utilisées, effectuez la rotation des sélecteurs DKIM, lisez les rapports agrégés DMARC et vérifiez les enregistrements MX après un changement de fournisseur DNS. Ajoutez chaque nouveau service d’envoi à l’inventaire avant qu’il n’envoie des e-mails en production.

Utilisez les tableaux de bord des fournisseurs comme un indicateur et les requêtes DNS indépendantes comme un autre. Les messages de test envoyés vers des systèmes externes révèlent les résultats d’authentification que voient réellement les destinataires. Documentez les moyens de récupération du bureau d’enregistrement du domaine, du fournisseur DNS et de l’hébergeur de messagerie en dehors de la boîte mail qu’ils protègent.

Pour les domaines familiaux, le guide de configuration de la messagerie familiale transforme ces enregistrements en un plan complet pour le foyer. Les administrateurs de homelabs peuvent utiliser l’évaluation de l’auto-hébergement afin d’évaluer le réseau, la réputation et le travail opérationnel qui se cachent derrière le DNS.

Lorsque les quatre familles d’enregistrements sont comprises séparément, la résolution des problèmes devient beaucoup plus directe : MX indique où vont les e-mails entrants, SPF indique quelle infrastructure peut envoyer, DKIM prouve une signature de domaine et DMARC vérifie l’alignement avec l’identité visible par le destinataire.