Enregistrement TXT — Texte libre

L’enregistrement TXT stocke du texte arbitraire dans le DNS. Il est massivement utilisé pour authentifier les emails (SPF, DKIM, DMARC) et prouver la propriété d’un domaine auprès de services tiers.

Voir Enregistrements DNS pour la liste complète des types.


Les 4 usages principaux

UsageEnregistrementRôle
SPFmonentreprise.fr TXT "v=spf1 ..."Quels serveurs peuvent envoyer des emails en ton nom
DKIMselecteur._domainkey.domaine TXT "v=DKIM1 ..."Clé publique pour vérifier la signature des emails
DMARC_dmarc.domaine TXT "v=DMARC1 ..."Quoi faire si SPF ou DKIM échoue
Vérificationdomaine TXT "google-site-verification=..."Prouver la propriété du domaine à un service tiers

SPF — Sender Policy Framework

Problème résolu : sans SPF, n’importe qui peut envoyer un email avec From: alice@monentreprise.fr. SPF liste les serveurs autorisés à envoyer au nom de ton domaine.

monentreprise.fr.  3600  IN  TXT  "v=spf1 include:_spf.google.com ip4:203.0.113.5 -all"

Décodage token par token :

v=spf1                     → version du protocole SPF (toujours spf1)
include:_spf.google.com    → inclure la liste d'IPs autorisées de Google
                             (Google Workspace envoie depuis ces IPs)
ip4:203.0.113.5            → ton serveur de mailing transactionnel est aussi autorisé
-all                       → tout le reste → REJETÉ (hardfail)
                             (~all = marqué suspect mais accepté / softfail)

Ce qui se passe à la réception :

Email reçu : From: alice@monentreprise.fr
             Envoyé depuis : smtp.google.com (IP 209.85.220.41)
  │
  ▼  Serveur destinataire vérifie
  dig monentreprise.fr TXT → "v=spf1 include:_spf.google.com ..."
  dig _spf.google.com TXT  → "ip4:209.85.220.0/19 ..."
  → 209.85.220.41 est dans la plage → SPF PASS ✅ → email accepté

Email reçu : From: alice@monentreprise.fr
             Envoyé depuis : serveur-spam.ru (IP 185.234.1.5)
  → 185.234.1.5 n'est pas dans les plages autorisées → -all → SPF FAIL ❌ → email rejeté

DKIM — DomainKeys Identified Mail

Problème résolu : SPF vérifie l’IP d’envoi, mais pas le contenu de l’email. Un attaquant sur le même réseau pourrait modifier l’email en transit. DKIM signe cryptographiquement chaque email.

Principe clé privée / clé publique :

┌──────────────────────────────────────────────────────────────┐
│  Côté serveur d'envoi (Google Workspace)                     │
│                                                              │
│  Chaque email est signé avec la clé PRIVÉE                   │
│  → une signature est ajoutée dans le header de l'email :     │
│                                                              │
│  DKIM-Signature: v=1; a=rsa-sha256;                          │
│    d=monentreprise.fr; s=google;                             │
│    h=from:to:subject:date;                                   │
│    bh=2jUSOH9NhtIAm47xd0QlDQ==;                             │
│    b=AuUoFEfDxTDkHlLXSZEpZj...                              │
└──────────────────────────────────────────────────────────────┘
                           │
                           ▼  Le destinataire vérifie avec la clé PUBLIQUE (dans le DNS)
┌──────────────────────────────────────────────────────────────┐
│  Enregistrement DNS TXT DKIM :                               │
│                                                              │
│  google._domainkey.monentreprise.fr.  TXT                    │
│  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN..."       │
│            ↑ sélecteur      ↑ clé publique RSA               │
└──────────────────────────────────────────────────────────────┘
; Google te donne le nom exact à créer dans ton DNS :
google._domainkey.monentreprise.fr.  3600  IN  TXT
  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAAUAAmIBCgKCAQEA2a7..."
# Vérifier que le DKIM est bien publié
dig google._domainkey.monentreprise.fr TXT
 
# Vérifier la signature DKIM d'un email reçu
# → ouvrir un email dans Gmail → "Afficher l'original" → chercher "DKIM=pass"

La clé privée reste chez Google (ou ton serveur mail). Seule la clé publique est dans le DNS. Compromettre le DNS ne donne pas accès à la clé privée.

Le sélecteur (google dans google._domainkey) est un identifiant qui permet d’avoir plusieurs paires de clés DKIM actives simultanément (rotation de clés, plusieurs prestataires d’envoi).


DMARC — Domain-based Message Authentication Reporting & Conformance

Problème résolu : SPF et DKIM vérifient chacun une chose, mais aucun des deux ne dit au serveur destinataire quoi faire si la vérification échoue. De plus, tu n’as aucun moyen de savoir si quelqu’un usurpe ton domaine. DMARC résout les deux.

_dmarc.monentreprise.fr.  3600  IN  TXT
  "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@monentreprise.fr; adkim=s; aspf=s"

Décodage :

v=DMARC1                                  → version DMARC
p=reject                                  → politique : rejeter les emails qui échouent
pct=100                                   → appliquer à 100% des emails (75 = 75%)
rua=mailto:dmarc@monentreprise.fr         → envoyer les rapports agrégés quotidiens ici
adkim=s                                   → alignement DKIM strict
aspf=s                                    → alignement SPF strict

Les 3 politiques :

p=Ce qui se passe en cas d’échecQuand l’utiliser
noneEmail livré normalement, tu reçois juste un rapportPhase de démarrage — observer sans bloquer
quarantineEmail mis en dossier spamPhase intermédiaire — penaliser sans bloquer totalement
rejectEmail rejeté avant livraisonProduction — protection maximale

Stratégie de déploiement recommandée :

Semaine 1-2 : p=none; pct=100
  → Analyse les rapports : quels serveurs envoient en ton nom ?
  → Ajoute les serveurs légitimes manquants dans le SPF

Semaine 3-4 : p=quarantine; pct=10
  → 10% du trafic suspect va en spam
  → Surveille les faux positifs

Semaine 5+ : p=quarantine; pct=100
  → Puis p=reject; pct=100 quand confiant

Rapport DMARC (extrait) :

<record>
  <row>
    <source_ip>209.85.220.41</source_ip>   <!-- IP d'envoi -->
    <count>1523</count>                     <!-- nb d'emails -->
    <policy_evaluated>
      <dkim>pass</dkim>                     <!-- DKIM OK -->
      <spf>pass</spf>                       <!-- SPF OK -->
    </policy_evaluated>
  </row>
  <row>
    <source_ip>185.234.1.5</source_ip>     <!-- IP inconnue = tentative d'usurpation -->
    <count>47</count>
    <policy_evaluated>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
</record>

Vérification de propriété de domaine

Les services tiers demandent de créer un TXT pour prouver que tu contrôles le domaine :

; Google Search Console
monentreprise.fr.  3600  IN  TXT  "google-site-verification=dBw5CvburDg-A8d-..."
 
; Microsoft 365 / Azure
monentreprise.fr.  3600  IN  TXT  "MS=ms73829104"
 
; GitHub Pages / Organizations
_github-challenge-monorg.monentreprise.fr.  TXT  "a1b2c3d4e5"
 
; Cloudflare (lors du transfert de zone)
monentreprise.fr.  TXT  "cloudflare-verify=abc123"

En relation avec

  • Enregistrements DNS — hub des types d’enregistrements
  • DNS - MX — le MX indique qui reçoit les emails ; SPF/DKIM/DMARC les sécurisent
  • Requêtes HTTP et HTTPS — TLS pour le web, SPF/DKIM/DMARC pour les emails
  • cert-manager — gère les certificats TLS (côté web, pas email)
  • DNS — fonctionnement de la résolution DNS