La migration semblait simple. Déplacer le DNS vers un nouveau fournisseur, mettre à jour les serveurs de noms, et c’est tout. Sauf que quelqu’un a oublié de recréer l’enregistrement SPF. Pendant trois jours, chaque email de l’entreprise a échoué à l’authentification. La délivrabilité s’est effondrée. Les plaintes clients se sont accumulées. Tout ça à cause d’un enregistrement TXT manquant.
L’email et le DNS sont profondément imbriqués. Les enregistrements MX indiquent au monde où délivrer votre courrier. Les enregistrements TXT gèrent l’authentification. Les enregistrements CNAME activent le tracking et les domaines personnalisés. Si vous en oubliez un, l’email se met à dysfonctionner de façons pas toujours évidentes.
Cette checklist couvre tous les enregistrements DNS qui impactent l’email, des essentiels aux optionnels mais recommandés.
Enregistrements essentiels
MX records. Les enregistrements Mail Exchanger indiquent aux serveurs expéditeurs où délivrer les emails pour votre domaine. Sans enregistrements MX, vous ne pouvez pas recevoir d’email. La plupart des configurations ont plusieurs enregistrements MX avec des priorités différentes pour la redondance.
example.com. MX 10 mail1.example.com.
example.com. MX 20 mail2.example.com.
Le nombre est la priorité — les valeurs les plus basses sont tentées en premier. Si mail1 est indisponible, les expéditeurs essaient mail2.
SPF record (TXT). Sender Policy Framework déclare quels serveurs peuvent envoyer des emails au nom de votre domaine. C’est un enregistrement TXT qui liste des adresses IP autorisées et des includes pour des services tiers.
example.com. TXT "v=spf1 include:_spf.google.com include:amazonses.com -all"
Le -all à la fin signifie « rejeter tout ce qui n’est pas listé ». Utilisez ~all (soft fail) uniquement pendant la mise en place initiale.
DKIM records (TXT or CNAME). DomainKeys Identified Mail utilise la cryptographie à clé publique pour signer les emails. La clé publique est publiée dans le DNS afin que les destinataires puissent vérifier les signatures. Le nom de l’enregistrement inclut un sélecteur qui identifie quelle clé utiliser.
selector._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."
Certains fournisseurs utilisent des enregistrements CNAME qui pointent vers leurs clés hébergées au lieu de publier la clé directement.
DMARC record (TXT). Domain-based Message Authentication, Reporting, and Conformance relie SPF et DKIM et indique aux destinataires quoi faire en cas d’échec.
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
La valeur p= est votre politique : none (surveillance uniquement), quarantine (envoyer en spam) ou reject (bloquer complètement).
Enregistrements recommandés
Reverse DNS (PTR). Les enregistrements PTR associent des adresses IP à des noms d’hôte. De nombreux serveurs destinataires vérifient que votre IP d’envoi possède un enregistrement PTR et que le nom d’hôte retourné se résout bien vers l’IP. Sans reverse DNS correct, vos emails peuvent être rejetés ou marqués comme spam.
Les enregistrements PTR sont configurés par le détenteur de l’adresse IP — généralement votre hébergeur ou votre FAI — et non dans le DNS de votre domaine.
MTA-STS records. Mail Transfer Agent Strict Transport Security ordonne aux serveurs expéditeurs d’exiger TLS lors de la délivrance à votre domaine. Cela empêche les attaques de rétrogradation où des attaquants forcent une livraison non chiffrée.
_mta-sts.example.com. TXT "v=STSv1; id=20240115"
Vous devez également héberger un fichier de politique à https://mta-sts.example.com/.well-known/mta-sts.txt.
TLS-RPT record (TXT). TLS Reporting indique aux expéditeurs où envoyer des rapports sur les échecs de connexion TLS. Cela vous aide à identifier des problèmes de délivrance causés par TLS.
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:[email protected]"
BIMI record (TXT). Brand Indicators for Message Identification affiche votre logo dans les clients email compatibles. Cela nécessite une politique DMARC appliquée et, pour une prise en charge complète, un Verified Mark Certificate.
default._bimi.example.com. TXT "v=BIMI1; l=https://example.com/logo.svg"
Enregistrements spécifiques aux services
Email provider verification. La plupart des fournisseurs d’email vous demandent d’ajouter des enregistrements TXT ou CNAME pour vérifier la propriété du domaine. Google Workspace, Microsoft 365, et d’autres ont chacun leurs enregistrements de vérification.
Tracking domain CNAMEs. Les services d’email qui suivent les ouvertures et les clics utilisent souvent des enregistrements CNAME pour activer des domaines de tracking personnalisés. Au lieu de liens pointant vers track.emailprovider.com, ils pointent vers click.yourdomain.com.
click.example.com. CNAME track.emailprovider.com.
Custom return path. Certains fournisseurs utilisent des enregistrements CNAME pour des domaines return-path personnalisés, ce qui aide à l’alignement SPF et à la délivrabilité.
Enregistrements de sécurité
DANE records (TLSA). DNS-based Authentication of Named Entities fournit du certificate pinning pour l’email. C’est plus complexe que MTA-STS mais offre des garanties de sécurité plus fortes. Nécessite DNSSEC.
_25._tcp.mail.example.com. TLSA 3 1 1 abc123...
CAA records. Certificate Authority Authorization spécifie quelles autorités de certification peuvent émettre des certificats pour votre domaine. Bien que non spécifique à l’email, cela protège les certificats utilisés par vos serveurs de messagerie.
example.com. CAA 0 issue "letsencrypt.org"
Checklist de vérification
Après avoir configuré ou modifié des enregistrements DNS, vérifiez que tout fonctionne :
MX records resolve. Utilisez dig MX example.com ou MXToolbox pour vérifier que les enregistrements MX existent et pointent vers des serveurs valides et joignables.
SPF is valid. Utilisez un vérificateur SPF pour confirmer la syntaxe, le nombre de lookups et que tous vos expéditeurs sont inclus. Envoyez un email de test et vérifiez l’en-tête Authentication-Results.
DKIM keys are published. Utilisez un vérificateur DKIM avec votre sélecteur pour vérifier que la clé publique est accessible. Envoyez un email de test et vérifiez que la signature DKIM est valide.
DMARC is published. Utilisez un vérificateur DMARC pour confirmer que l’enregistrement existe et est syntaxiquement valide. Vérifiez que vous recevez des rapports agrégés à l’adresse spécifiée.
Reverse DNS is configured. Utilisez dig -x [your-ip] pour vérifier les enregistrements PTR. Assurez-vous que le nom d’hôte retourné se résout vers votre IP.
TLS is working. Utilisez CheckTLS ou équivalent pour vérifier que votre serveur de mail accepte les connexions TLS et possède un certificat valide.
Erreurs courantes
TTL trop élevé pendant les changements. Si vous effectuez des modifications DNS, baissez d’abord le TTL (à 300 secondes ou moins), attendez l’expiration de l’ancien TTL, faites les changements, puis remontez le TTL. Un TTL élevé pendant les changements signifie de longs délais de propagation.
Oublier les points finaux. Dans les fichiers de zone, les noms d’hôte doivent se terminer par un point (ex. mail.example.com.). Sans le point, le nom de la zone est ajouté, ce qui crée des enregistrements invalides.
Enregistrements en conflit. Vous ne pouvez avoir qu’un seul enregistrement SPF par domaine. Des enregistrements SPF multiples provoquent des échecs. Si vous devez autoriser plusieurs services, combinez-les dans un seul enregistrement.
Enregistrements obsolètes après des migrations. Lors du changement de fournisseur d’email, les anciens enregistrements (MX, includes SPF, clés DKIM) doivent être supprimés. Des enregistrements obsolètes entraînent des échecs d’authentification ou dirigent l’email vers des serveurs mis hors service.
Frequently asked questions
Combien de temps les changements DNS mettent-ils à se propager ?
Cela dépend du TTL (Time To Live). Les enregistrements sont mis en cache pendant la durée de leur TTL. Si le TTL est de 3600 (1 heure), les changements peuvent prendre jusqu’à une heure pour se propager globalement. Baissez le TTL avant de faire des changements pour accélérer la propagation.
Ai-je besoin de tous ces enregistrements ?
MX, SPF, DKIM et DMARC sont essentiels pour l’email moderne. MTA-STS et BIMI sont recommandés mais non obligatoires. DANE est optionnel et nécessite DNSSEC. Les enregistrements spécifiques aux services dépendent des services que vous utilisez.
Que se passe-t-il si je me trompe sur un enregistrement DNS ?
Cela dépend de l’enregistrement. Des MX incorrects signifient que vous ne pouvez pas recevoir d’email. Des SPF/DKIM incorrects entraînent des échecs d’authentification et un risque de filtrage spam. Testez toujours les changements dans un environnement de préproduction ou avec un TTL bas pour pouvoir revenir rapidement en arrière.
Dois-je utiliser le DNS de mon bureau d’enregistrement ou un fournisseur DNS dédié ?
Les fournisseurs DNS dédiés (Cloudflare, Route 53, etc.) offrent généralement de meilleures performances, plus de fonctionnalités et de meilleures interfaces de gestion. Pour une infrastructure email critique, la fiabilité et les fonctionnalités d’un DNS dédié valent la complexité.