Configurer le DNS d'authentification des e-mails

Les enregistrements DNS d’authentification des e-mails aident les systèmes de réception à distinguer les messages envoyés par vos systèmes autorisés de ceux qui prétendent seulement utiliser votre domaine. Ce tutoriel configure des ensembles d’enregistrements DKIM et DMARC dédiés dans une zone DNS ZCP existante. Il explique aussi comment gérer SPF de façon sûre.

Choisissez un seul responsable pour chaque ensemble d’enregistrements : la CLI zcp ou Terraform/OpenTofu. N’utilisez pas les deux outils pour gérer le même nom et le même type. La CLI accepte une valeur de contenu à chaque création et supprime les enregistrements selon leur nom et leur type complets. Terraform modélise les enregistrements comme des ensembles nommés et typés.

À la fin, vous aurez :

Un inventaire de la zone DNS et des systèmes autorisés à envoyer des e-mails
Un enregistrement DKIM ou CNAME publié au sélecteur fourni par le prestataire
Un enregistrement DMARC en mode surveillance, dont les rapports sont envoyés à une boîte que vous contrôlez
Une routine de vérification du DNS et des e-mails authentifiés de chaque expéditeur

Ce guide suppose que ZCP héberge déjà la zone faisant autorité. Pour créer une zone et la déléguer chez votre registraire, suivez Héberger un domaine sur ZCP (CLI).

Avant de commencer

Vous avez besoin de :

Une zone DNS ZCP pour un domaine que vous contrôlez
La CLI zcp authentifiée avec un jeton, ou Terraform ou OpenTofu avec ZCP_BEARER_TOKEN défini dans votre shell
L’accès à chaque système qui envoie des e-mails avec le domaine, notamment les livraisons d’applications, notifications, assistance, facturation, marketing et alertes d’appareils ou de services
Une boîte aux lettres réservée aux rapports agrégés DMARC, par exemple dmarc-reports@example.ca
Les instructions DKIM et SPF exactes de chaque système émetteur

Les noms example.ca de ce guide sont des espaces réservés. Remplacez-les par un domaine que vous contrôlez. Ne collez jamais de clé DKIM privée dans DNS. DNS publie seulement une clé publique ou une cible CNAME fournie par le prestataire.

Inventorier la zone et les expéditeurs

Commencez par enregistrer l’état actuel. Conservez la sortie dans votre suivi de changement. Elle vous donne le slug de zone, les serveurs de noms et les ensembles d’enregistrements à préserver.

zcp dns list
zcp dns show <domain-slug> --output json

Interrogez les deux serveurs de noms ZCP faisant autorité pour les enregistrements concernés. Remplacez example.ca par votre domaine.

for ns in ns1.zsoftly.ca ns2.zsoftly.ca; do
  dig TXT example.ca "@$ns" +short
  dig TXT _dmarc.example.ca "@$ns" +short
  dig TXT selector._domainkey.example.ca "@$ns" +short
  dig CNAME selector._domainkey.example.ca "@$ns" +short
done

Répertoriez chaque expéditeur légitime, le domaine utilisé dans l’adresse From visible, le domaine d’expéditeur d’enveloppe et son sélecteur DKIM ou ses instructions CNAME. Incluez les systèmes qui n’envoient qu’occasionnellement. Désignez un responsable qui approuve les changements et examine les rapports DMARC. Conservez cet inventaire avec les valeurs d’enregistrement et la date du dernier test.

La CLI ZCP actuelle crée ou supprime un ensemble complet d’enregistrements défini par nom et type. Elle ne dispose pas de commande de mise à jour sur place. Le fournisseur Terraform actuel remplace aussi un zcp_dns_record lorsque son contenu, nom, type ou TTL change. Pour un SPF existant ou un autre ensemble TXT à plusieurs valeurs, utilisez le processus DNS établi qui préserve l’ensemble complet. Ne créez pas une seconde ressource TXT racine et ne supprimez pas puis recréez pendant une livraison normale.

Comprendre les noms d’enregistrement

SPF, DKIM et DMARC utilisent des noms DNS différents et répondent à des questions distinctes.

SPF est une politique TXT au domaine de l’expéditeur d’enveloppe. Quand ce domaine est l’apex de la zone, le nom d’enregistrement est @. Il peut aussi être un sous-domaine, comme bounce.example.ca. Conservez une politique unique et complète, et tenez compte des recherches DNS dans toutes les inclusions autorisées.
DKIM est un enregistrement TXT ou CNAME à <selector>._domainkey.example.ca. Il permet aux destinataires de récupérer les éléments publics nécessaires pour valider une signature de message.
DMARC est un enregistrement TXT à _dmarc.example.ca. Il indique aux destinataires la politique à appliquer quand le domaine From visible n’a pas d’e-mails authentifiés et alignés, et demande des rapports.

Le système destinataire a besoin de SPF ou de DKIM pour authentifier et aligner l’e-mail avec le domaine From visible afin que DMARC réussisse. La configuration DNS seule ne suffit pas. Configurez chaque système expéditeur avec le bon domaine, activez sa signature DKIM et envoyez un message de test après la publication.

Pour la norme sur la sélection des enregistrements SPF et les limites de recherche, consultez RFC 7208.

Choisir une méthode de gestion

Utilisez la CLI pour une petite modification examinée sur un nom d’enregistrement dédié et inutilisé. Utilisez Terraform ou OpenTofu quand votre équipe gère déjà cette zone comme du code et examine les plans. Les exemples ci-dessous créent uniquement les ensembles d’enregistrements DKIM et DMARC dédiés après confirmation que chaque nom est absent.

N’appliquez pas les commandes CLI si Terraform ou OpenTofu possède le même ensemble d’enregistrements. N’appliquez pas la configuration Terraform si une personne modifie le même ensemble par la CLI ou la console. Consignez le responsable avec votre inventaire des expéditeurs.

Si l’apex de la zone est le domaine de l’expéditeur d’enveloppe et qu’il n’a aucun ensemble d’enregistrements TXT, utilisez une seule méthode de gestion pour créer une politique SPF unique avec la valeur complète fournie par tous les expéditeurs autorisés. Faites-le seulement après avoir vérifié chaque expéditeur et les recherches DNS de cette valeur. Un domaine d’envoi actif avec un ensemble TXT racine existant exige un changement distinct et examiné, car ce tutoriel ne peut pas fusionner ni mettre à jour cet ensemble partagé de façon sûre.

Publier DKIM et DMARC avec la CLI

Définissez les variables de votre zone et les instructions fournies par un système expéditeur. La valeur DKIM ci-dessous est lue depuis votre terminal pour éviter son inscription dans l’historique du shell. Saisissez la présentation DNS complète : une chaîne entre guillemets pour une courte valeur TXT, ou la présentation complète, entre guillemets et découpée, du prestataire pour une longue clé. Saisissez la cible CNAME exacte quand l’expéditeur demande un CNAME.

export DOMAIN_SLUG="exampleca"
export DOMAIN_NAME="example.ca"
export DKIM_SELECTOR="mailer1"
read -r DKIM_CONTENT

Confirmez que le nom du sélecteur et _dmarc ne possèdent pas déjà un ensemble d’enregistrements. Interrogez les véritables serveurs de noms faisant autorité affichés par zcp dns show <domain-slug>. Exigez une réponse faisant autorité réussie de la part des deux serveurs. Un délai d’attente, une réponse SERVFAIL ou REFUSED ne donne pas l’autorisation de créer un enregistrement.

for ns in ns1.zsoftly.ca ns2.zsoftly.ca; do
  dig TXT "$DKIM_SELECTOR._domainkey.$DOMAIN_NAME" "@$ns" +norecurse +noall +comments +answer
  dig CNAME "$DKIM_SELECTOR._domainkey.$DOMAIN_NAME" "@$ns" +norecurse +noall +comments +answer
  dig TXT "_dmarc.$DOMAIN_NAME" "@$ns" +norecurse +noall +comments +answer
done

Remplacez les valeurs d’exemple ns1.zsoftly.ca et ns2.zsoftly.ca par les serveurs faisant autorité indiqués pour votre zone. Si une section de réponse contient un enregistrement, arrêtez-vous et examinez son responsable actuel.

Créez l’enregistrement DKIM TXT uniquement lorsque l’expéditeur a fourni une valeur TXT. ZCP ajoute la zone au nom relatif. Utilisez donc mailer1._domainkey, et non le nom de domaine complet.

zcp dns record-create \
  --domain "$DOMAIN_SLUG" \
  --name "$DKIM_SELECTOR._domainkey" \
  --type TXT \
  --content "$DKIM_CONTENT" \
  --ttl 3600

Si le système expéditeur a plutôt fourni un CNAME, créez un CNAME avec sa cible exacte et ne créez pas l’enregistrement TXT.

zcp dns record-create \
  --domain "$DOMAIN_SLUG" \
  --name "$DKIM_SELECTOR._domainkey" \
  --type CNAME \
  --content "<provider-issued-target>." \
  --ttl 3600

Créez d’abord DMARC en mode surveillance. La boîte de réception des rapports doit exister et son responsable doit examiner les rapports.

zcp dns record-create \
  --domain "$DOMAIN_SLUG" \
  --name _dmarc \
  --type TXT \
  --content '"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.ca"' \
  --ttl 3600

Si, et seulement si, les requêtes faisant autorité confirment qu’il n’existe pas d’ensemble d’enregistrements TXT racine, vous pouvez publier l’unique politique SPF complète fournie par tous les expéditeurs autorisés. Saisissez sa présentation DNS complète à l’invite. N’utilisez pas v=spf1 -all pour un domaine d’envoi actif, sauf si aucun système n’est autorisé à envoyer avec lui.

dig TXT "$DOMAIN_NAME" @ns1.zsoftly.ca +norecurse +noall +comments +answer
dig TXT "$DOMAIN_NAME" @ns2.zsoftly.ca +norecurse +noall +comments +answer
read -r SPF_CONTENT

zcp dns record-create \
  --domain "$DOMAIN_SLUG" \
  --name @ \
  --type TXT \
  --content "$SPF_CONTENT" \
  --ttl 3600

Les données TXT doivent parvenir au DNS comme des chaînes de caractères entre guillemets. La page de configuration d’un expéditeur peut afficher une valeur non entre guillemets à copier-coller. Dans ce cas, obtenez sa présentation DNS avant de créer l’enregistrement. Une chaîne unique exige des guillemets. Une valeur longue peut exiger des segments entre guillemets de 255 octets au plus, que les résolveurs concatènent en une valeur TXT. Conservez intacts les segments fournis par le prestataire. Ne divisez pas une clé publique dans des enregistrements DNS distincts et n’inventez pas de clé. Vérifiez la réponse publiée par rapport aux instructions de l’expéditeur avant d’activer la signature.

Publier DKIM et DMARC avec Terraform ou OpenTofu

Utilisez cette méthode uniquement lorsque l’infrastructure sous forme de code gère les enregistrements dédiés. Définissez le jeton dans votre shell. Ne le placez pas dans main.tf et ne le validez pas.

export ZCP_BEARER_TOKEN="<your-token>"

Créez main.tf. Cette configuration référence une zone existante par son slug. Elle ne déclare pas la zone elle-même, afin qu’une application ne puisse pas la remplacer.

terraform {
  required_providers {
    zcp = {
      source  = "zsoftly/zcp"
      version = "~> 0.2.0"
    }
  }
}

variable "domain_slug" {
  type = string
}

variable "dkim_selector" {
  type = string
}

variable "dkim_txt_content" {
  type = string
}

provider "zcp" {}

resource "zcp_dns_record" "dkim" {
  domain  = var.domain_slug
  name    = "${var.dkim_selector}._domainkey"
  type    = "TXT"
  content = var.dkim_txt_content
  ttl     = 3600

  lifecycle {
    prevent_destroy = true
  }
}

resource "zcp_dns_record" "dmarc" {
  domain  = var.domain_slug
  name    = "_dmarc"
  type    = "TXT"
  content = "\"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.ca\""
  ttl     = 3600

  lifecycle {
    prevent_destroy = true
  }
}

Si l’ensemble d’enregistrements TXT racine est absent, vous pouvez ajouter cette troisième ressource après avoir validé la politique complète auprès de chaque expéditeur autorisé. Ne l’ajoutez pas à une configuration d’ensemble TXT racine déjà existant.

variable "spf_txt_content" {
  type = string
}

resource "zcp_dns_record" "spf" {
  domain  = var.domain_slug
  name    = "@"
  type    = "TXT"
  content = var.spf_txt_content
  ttl     = 3600

  lifecycle {
    prevent_destroy = true
  }
}

Si l’expéditeur a fourni un sélecteur CNAME, remplacez à la fois la variable dkim_txt_content et la ressource zcp_dns_record.dkim ci-dessus par la variable et la ressource suivantes. Ne déclarez pas les deux ressources DKIM avec le même nom de sélecteur.

variable "dkim_cname_target" {
  type = string
}

resource "zcp_dns_record" "dkim_cname" {
  domain  = var.domain_slug
  name    = "${var.dkim_selector}._domainkey"
  type    = "CNAME"
  content = var.dkim_cname_target
  ttl     = 3600

  lifecycle {
    prevent_destroy = true
  }
}

Définissez dkim_cname_target avec le nom d’hôte complet fourni par le prestataire et un point final, par exemple selector.provider.example.ca.. Une cible sans point final peut être considérée comme relative à votre zone.

Conservez les valeurs des variables avec votre configuration DNS. Une valeur DKIM TXT contient une clé publique. Une valeur DKIM CNAME contient une cible DNS fournie par le prestataire. Gardez le jeton Bearer dans l’environnement et hors du contrôle de code source.

terraform init
terraform plan -var='domain_slug=exampleca' -var='dkim_selector=mailer1'
terraform apply -var='domain_slug=exampleca' -var='dkim_selector=mailer1'

OpenTofu utilise la même configuration et les mêmes sous-commandes avec tofu à la place de terraform. Lisez le plan avant de l’approuver. Un zcp_dns_record représente l’ensemble complet identifié par domain, name et type. Son contenu est accessible en écriture seulement. Le fournisseur ne détecte donc pas les changements de contenu hors bande. Un changement de configuration force le remplacement. La protection prevent_destroy bloque une suppression planifiée tant que le bloc de ressource reste dans la configuration. Supprimer ce bloc supprime aussi la protection. Ce n’est donc pas une méthode de restauration. Lisez chaque plan. Retirez la protection seulement lors d’une modification de maintenance approuvée, après examen du plan de remplacement et de restauration.

Pour placer un ensemble d’enregistrements DKIM TXT dédié existant sous Terraform, configurez la ressource zcp_dns_record.dkim ci-dessus pour correspondre à ses valeurs actuelles, puis importez-la :

terraform import zcp_dns_record.dkim exampleca/TXT/mailer1._domainkey

Le format d’importation d’enregistrement est <domain-slug>/<type>/<relative-name>. Le fournisseur ne peut pas relire le contenu dans une forme comparable. L’importation initialise donc seulement l’identité. Exécutez terraform plan après l’importation et n’approuvez pas le remplacement d’un ensemble d’enregistrements actif avant d’avoir confirmé la valeur complète planifiée et le plan de restauration.

Vérifier le DNS et les e-mails reçus

Interrogez d’abord les deux serveurs faisant autorité. Obtenez leurs noms pour votre zone avec zcp dns show <domain-slug>. Les noms ci-dessous sont des exemples. Interrogez ensuite un résolveur récursif public après la délégation et l’actualisation des caches.

for ns in ns1.zsoftly.ca ns2.zsoftly.ca; do
  dig TXT mailer1._domainkey.example.ca "@$ns" +short
  dig TXT _dmarc.example.ca "@$ns" +short
done

dig TXT mailer1._domainkey.example.ca @1.1.1.1 +short
dig TXT _dmarc.example.ca @1.1.1.1 +short

Pour un sélecteur basé sur CNAME, remplacez la première requête TXT par CNAME. Comparez la réponse aux instructions exactes du système expéditeur. Une recherche DNS réussie ne prouve pas que l’expéditeur signe les messages. Ce n’est donc que la première vérification.

Envoyez un message de chaque source légitime vers une boîte de test que vous contrôlez. Examinez les en-têtes du message reçu par un destinataire fiable. Son en-tête Authentication-Results doit afficher les résultats d’authentification du message. Confirmez que le domaine From visible s’aligne avec un résultat SPF ou DKIM réussi. Testez les réponses, avis d’application, messages transférés et toute voie d’envoi qui utilise un expéditeur d’enveloppe ou un sélecteur différent.

Faire passer DMARC de la surveillance à l’application

Commencez avec p=none et recueillez les rapports. Rapprochez chaque source de rapport de votre inventaire d’expéditeurs. Corrigez les signatures DKIM absentes, les autorisations SPF manquantes ou l’alignement de domaine avant de modifier la politique.

Lorsque les rapports et les tests de livraison montrent que le trafic légitime s’authentifie correctement, passez à p=quarantine. Continuez l’examen durant ce changement. Passez à p=reject seulement lorsque les échecs restants sont compris et acceptés. Les messages signés peuvent être transférés ou modifiés par des systèmes intermédiaires. Incluez donc ces chemins dans votre examen avant de resserrer la politique.

Utilisez la même méthode de gestion qui possède _dmarc pour chaque changement. Avec la CLI, consignez le contenu précédent de l’enregistrement avant la modification de maintenance approuvée, puis restaurez exactement ce contenu si les tests de livraison échouent. Avec Terraform ou OpenTofu, conservez la configuration précédente examinée et utilisez un plan examiné pour y revenir. N’exécutez pas de destroy global pour des changements DNS.

Intégrer le DNS à votre programme de sécurité des e-mails

Examinez régulièrement les rapports DMARC, l’inventaire des expéditeurs, les changements DNS et les preuves de test. Soumettez les nouveaux systèmes à un examen d’expéditeur avant qu’ils utilisent votre domaine. Retirez les expéditeurs abandonnés de SPF et désactivez les sélecteurs DKIM et configurations de signature inutilisés lorsque les files d’attente d’e-mails et les besoins de vérification sont connus.

Le DNS ne remplace pas les contrôles hors DNS :

Exigez l’authentification multifacteur pour l’accès administrateur et DNS.
Appliquez le moindre privilège et examinez l’accès de récupération, le transfert, la délégation et le départ des utilisateurs.
Ajustez le filtrage entrant et les contrôles d’usurpation, puis examinez les résultats de quarantaine et réduisez les exceptions.
Examinez l’appartenance aux groupes externes et les paramètres de partage de données.
Traitez les certificats de chiffrement des messages et les fonctions d’e-mails connectées à l’IA comme des décisions distinctes sur les destinataires, la récupération de clés, l’accès aux données et le coût.

Pour les décisions de politique et de responsabilité qui sous-tendent ce travail technique, lisez La sécurité des e-mails a besoin d’un responsable.

Prochaines étapes

Héberger un domaine sur ZCP (CLI) pour créer et déléguer une zone.
Gérer le DNS avec la CLI pour les commandes DNS prises en charge.
Enregistrements TXT pour les exemples de guillemets et de recherche directe.
Dépannage DNS pour les vérifications DNS faisant autorité et récursives.