Les enregistrements DNS d'un domaine d'envoi

La liste complète des enregistrements d'un domaine d'envoi, lesquels sont obligatoires, lesquels sont optionnels, et où chacun se place.

La liste complète

Ce qui suit explique à quoi sert chacun. Le détail des trois premiers vit dans leur propre guide.

SPF, obligatoire

Un enregistrement TXT à la racine de votre domaine listant qui peut envoyer pour lui. Un seul, fusionné si vous avez déjà une autre plateforme. Détail complet dans le guide SPF.

DKIM, obligatoire

Un enregistrement TXT contenant votre clé publique de signature, sur un hôte sélecteur sous _domainkey. C’est l’enregistrement qui continue d’authentifier quand votre courrier est transféré. Détail complet dans le guide DKIM.

DMARC, recommandé

Un enregistrement TXT à _dmarc qui indique aux serveurs de réception quoi faire quand l’authentification échoue, et où envoyer les rapports. Sans lui, le SPF et le DKIM ne protègent pas l’adresse From: que voient vos destinataires. Détail complet dans le guide DMARC.

Return-path des bounces, optionnel

Un CNAME à bounces.votredomaine.com pointant vers la plateforme. Il déplace l’expéditeur d’enveloppe sur votre propre domaine. La gestion des bounces semble donc venir de vous, et le SPF s’aligne sur votre domaine plutôt que sur celui de la plateforme. Utile, non obligatoire.

Liens de tracking, optionnel

Un CNAME à links.votredomaine.com. Le suivi des clics réécrit les liens, et sans cet enregistrement ils pointent vers l’hôte de redirection de la plateforme. Avec lui, vos destinataires voient votre domaine dans l’URL. C’est une question de marque et de confiance, pas de délivrabilité.

MX, seulement pour recevoir

Les enregistrements MX indiquent où livrer le courrier adressé à votre domaine. L’envoi ne les utilise pas. Vous pouvez envoyer depuis un domaine sans aucun MX. Cela reste une mauvaise expérience, puisque les réponses n’arrivent nulle part, et certains filtres voient un MX absent comme un léger signal négatif.

Domaine racine ou sous-domaine ?

Vous pouvez envoyer depuis votredomaine.com directement, ou depuis un sous-domaine comme mail.votredomaine.com. Deux points à connaître :

• Le SPF et le DKIM ne s’héritent pas. Un sous-domaine expéditeur a besoin de ses propres enregistrements. Le SPF du domaine racine ne couvre pas mail.votredomaine.com.
• Le DMARC, lui, s’hérite, via le domaine organisationnel et la balise sp= : une politique sur la racine s’applique aux sous-domaines sauf si vous la surchargez.

Envoyer depuis un sous-domaine isole la réputation, ce qui est utile quand plusieurs types de courrier sortent de votre organisation. Ce n’est pas nécessaire pour un seul flux transactionnel.

Si un domaine n’envoie jamais d’emails, publiez v=spf1 -all et un enregistrement DMARC avec p=reject dessus. Cela empêche l’usurpation d’un domaine que personne ne surveille.

Avec Mailverick

Ajoutez un domaine dans la section Domaines du portail et tous les enregistrements ci-dessus sont générés pour vous avec les valeurs exactes, avec la procédure dans Démarrage. Vérifier le DNS les valide et remonte un statut par enregistrement (valide, avertissement, invalide ou absent), en indiquant ce qui a été trouvé face à ce qui était attendu.

Le SPF et le DKIM doivent tous deux être valides avant que le domaine puisse envoyer. Le DMARC et les deux CNAME peuvent être ajoutés plus tard, à tout moment.

Erreurs fréquentes

Se tromper sur le nom d’hôte. Les hébergeurs diffèrent : certains attendent @ pour la racine, d’autres le domaine nu, et d’autres ajoutent la zone à ce que vous saisissez. Saisir un nom complet dans une interface qui ajoute la zone produit _dmarc.votredomaine.com.votredomaine.com. Relisez l’enregistrement après enregistrement.

Créer le mauvais type d’enregistrement. Le SPF, le DKIM et le DMARC sont tous des TXT. Les enregistrements de bounce et de tracking sont des CNAME. Une clé DKIM créée en CNAME ne se vérifiera jamais.

Publier deux enregistrements SPF. En ajouter un second est une erreur permanente qui invalide les deux. Fusionnez plutôt.

Croire qu’un sous-domaine est couvert. La cause la plus courante d’un échec d’authentification soudain après le passage du From: sur un sous-domaine.

Attendre la mauvaise chose. Les changements DNS se propagent à mesure que les caches expirent, selon le TTL de l’enregistrement. Vérifier quelques secondes après avoir enregistré revient à tester le cache de votre résolveur, pas votre zone.

Questions fréquentes

Ai-je besoin d’un MX pour envoyer ?

Non. Le MX ne sert qu’à recevoir. En ajouter un reste raisonnable pour que les réponses ne disparaissent pas.

Puis-je utiliser le même domaine pour le transactionnel et le marketing ?

Vous pouvez, mais la réputation est partagée : une campagne qui génère des plaintes dégrade vos réinitialisations de mot de passe. Des sous-domaines séparés sont la réponse habituelle. Voir transactionnel et marketing.

Et le PTR, le reverse DNS ?

Cet enregistrement appartient au propriétaire de l’IP d’envoi : chez Mailverick, c’est à nous de le maintenir, pas à vous. Il compte, et vous n’avez rien à faire.

Et le BIMI ?

Le BIMI affiche votre logo dans les boîtes compatibles, et il exige un DMARC en quarantine ou reject plus un Verified Mark Certificate. Réglez d’abord l’authentification : le BIMI est la dernière étape, pas une des premières.

Combien de temps avant que les enregistrements soient pris en compte ?

Généralement quelques minutes, parfois quelques heures. Abaissez le TTL d’un enregistrement avant un changement planifié pour une bascule plus rapide.

Dernière mise à jour : avril 2026