La configuration DNS est le fondement invisible de la délivrabilité du cold email. Alors que la plupart des praticiens du cold email se concentrent sur les objets, le contenu et les calendriers d'envoi, c'est l'infrastructure technique sous-jacente qui détermine si vos emails atteignent réellement la boîte de réception. Les enregistrements DNS mal configurés sont responsables de plus d'échecs de délivrabilité que tout autre facteur isolé, et pourtant ils restent mal compris par la majorité des expéditeurs de cold email.
Ce guide technique propose une plongée approfondie et complète dans la configuration DNS pour le cold email. Nous examinerons chaque type d'enregistrement en détail, explorerons les protocoles d'authentification qui protègent votre réputation d'expéditeur, résoudrons les problèmes de propagation courants et présenterons des méthodes de vérification qui garantissent que votre infrastructure est prête pour la production. Que vous configuriez votre premier domaine de cold email ou que vous gériez des centaines de domaines à grande échelle, ce guide vous donnera les connaissances techniques nécessaires pour obtenir un placement en boîte de réception constant.
Le système de noms de domaine (DNS) fonctionne comme le carnet d'adresses d'Internet, traduisant les noms de domaine lisibles par l'humain en adresses IP lisibles par la machine. Pour l'email, le DNS remplit une fonction critique supplémentaire : il indique aux serveurs de messagerie destinataires quels serveurs sont autorisés à envoyer des emails au nom de votre domaine et comment authentifier ces messages. Comprendre les quatre principaux types d'enregistrements essentiels au cold email est la première étape vers une configuration correcte.
Les enregistrements MX précisent quels serveurs de messagerie sont responsables de la réception des emails pour votre domaine. Bien qu'ils soient principalement utilisés pour le courrier entrant, les enregistrements MX sont essentiels à la crédibilité en cold email. Les filtres anti-spam vérifient systématiquement si un domaine expéditeur possède des enregistrements MX valides, car les domaines qui en sont dépourvus ne peuvent pas recevoir de réponses et sont souvent associés à des opérations de spam.
Un enregistrement MX comporte deux composants : une valeur de priorité et un nom d'hôte de serveur de messagerie. Les valeurs de priorité les plus basses indiquent une préférence plus élevée, ce qui vous permet de configurer des serveurs de messagerie principaux et de secours.
# Exemple d'enregistrement MX example.com. IN MX 10 mail.example.com. example.com. IN MX 20 mail-backup.example.com. # Enregistrements MX de Google Workspace example.com. IN MX 1 ASPMX.L.GOOGLE.COM. example.com. IN MX 5 ALT1.ASPMX.L.GOOGLE.COM. example.com. IN MX 5 ALT2.ASPMX.L.GOOGLE.COM. example.com. IN MX 10 ALT3.ASPMX.L.GOOGLE.COM. example.com. IN MX 10 ALT4.ASPMX.L.GOOGLE.COM.
Les enregistrements SPF définissent quelles adresses IP et serveurs de messagerie sont autorisés à envoyer des emails au nom de votre domaine. Lorsqu'un serveur destinataire reçoit un email prétendant provenir de votre domaine, il consulte votre enregistrement SPF pour vérifier que le serveur d'envoi est légitime. Cela empêche les spammeurs d'usurper votre domaine dans leur adresse « From ».
Les enregistrements SPF sont publiés sous forme d'enregistrements TXT dans votre DNS. Ils utilisent une syntaxe spécifique qui comprend des mécanismes (comme « ip4 », « include » et « a ») et des qualificateurs qui déterminent la manière de traiter les expéditeurs correspondants et non correspondants.
# Structure de base d'un enregistrement SPF v=spf1 [mechanisms] [qualifier]all # Enregistrement SPF pour Google Workspace v=spf1 include:_spf.google.com ~all # Enregistrement SPF avec plusieurs sources d'envoi v=spf1 include:_spf.google.com include:sendgrid.net ip4:192.168.1.1 ~all # Qualificateurs SPF : # +all = Pass (autoriser tout - non recommandé) # -all = Hard Fail (rejeter les expéditeurs non autorisés) # ~all = Soft Fail (accepter mais marquer comme suspect) # ?all = Neutral (aucune politique)
DKIM ajoute une signature cryptographique à vos emails sortants, prouvant que le message a bien été envoyé depuis votre domaine et n'a pas été modifié en transit. Le serveur d'envoi signe l'email avec une clé privée, et les serveurs destinataires vérifient la signature à l'aide d'une clé publique publiée dans votre DNS.
Les enregistrements DKIM sont publiés sous forme d'enregistrements TXT sur un sous-domaine spécifique qui inclut un sélecteur (un identifiant arbitraire pour la paire de clés). Ce système de sélecteur vous permet de faire tourner les clés sans perturber la distribution des emails et d'utiliser différentes clés pour différents services d'envoi.
# Emplacement de l'enregistrement DKIM [selector]._domainkey.example.com # Exemple d'enregistrement DKIM Google Workspace google._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..." # Composants d'un enregistrement DKIM : # v=DKIM1 - Version DKIM # k=rsa - Type de clé (RSA est le standard) # p=... - Clé publique (encodée en base64) # t=s - Facultatif : mode strict (signature de sous-domaine) # t=y - Facultatif : mode test
DMARC s'appuie sur SPF et DKIM en ajoutant une couche de politique qui indique aux serveurs destinataires quoi faire lorsque les emails échouent à l'authentification. Il fournit également un mécanisme de reporting qui vous envoie des données sur les emails prétendant provenir de votre domaine, qu'ils soient légitimes ou frauduleux.
DMARC est essentiel car il introduit la notion d'« alignement », exigeant que le domaine visible dans l'en-tête « From » corresponde au domaine authentifié par SPF ou DKIM. Cela comble une faille qui permettait aux spammeurs de réussir SPF/DKIM tout en usurpant l'adresse d'expéditeur affichée.
# Emplacement de l'enregistrement DMARC _dmarc.example.com # Enregistrement DMARC de base (mode surveillance) v=DMARC1; p=none; rua=mailto:dmarc@example.com # Enregistrement DMARC recommandé pour le cold email v=DMARC1; p=quarantine; sp=quarantine; pct=100; rua=mailto:dmarc@example.com # Enregistrement DMARC strict (protection complète) v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@example.com # Options de politique DMARC : # p=none - Surveiller uniquement (aucune action en cas d'échec) # p=quarantine - Envoyer dans le dossier spam # p=reject - Rejeter entièrement l'email # Balises supplémentaires : # sp= - Politique de sous-domaine # pct= - Pourcentage de messages auxquels appliquer la politique # adkim= - Mode d'alignement DKIM (s=strict, r=relaxed) # aspf= - Mode d'alignement SPF (s=strict, r=relaxed) # rua= - Destination des rapports agrégés # ruf= - Destination des rapports forensiques
Comprendre comment SPF, DKIM et DMARC fonctionnent ensemble est crucial pour diagnostiquer les problèmes de délivrabilité. Lorsque vous envoyez un cold email, le serveur destinataire effectue une série de vérifications dans un ordre précis, et les résultats de chaque vérification alimentent la décision globale d'authentification.
Le serveur destinataire extrait le domaine de l'adresse MAIL FROM (expéditeur d'enveloppe) et interroge l'enregistrement SPF de ce domaine. Il vérifie ensuite si l'adresse IP de connexion est autorisée par l'enregistrement SPF. Le résultat est l'un des suivants : pass, fail, softfail, neutral, none, temperror ou permerror.
Le serveur destinataire examine l'en-tête DKIM-Signature de l'email, extrait le sélecteur et le domaine signataire, récupère la clé publique correspondante depuis le DNS et vérifie la signature cryptographique. Si la signature correspond au contenu et aux en-têtes de l'email, DKIM réussit.
DMARC évalue à la fois les résultats SPF et DKIM, mais ajoute une exigence d'alignement. Le domaine visible dans l'en-tête « From » doit correspondre soit au domaine authentifié par SPF, soit au domaine signataire DKIM (selon les réglages du mode d'alignement). Si au moins l'un des deux réussit avec un alignement correct, DMARC réussit. La politique DMARC détermine ensuite ce qu'il advient des emails qui échouent à cette évaluation.
« Les échecs d'authentification sont des tueurs silencieux en cold email. Vos emails disparaissent dans les dossiers spam sans notification de rebond, sans message d'erreur, sans aucune indication qu'il y a un problème. Le temps que vous remarquiez la baisse des taux de réponse, des semaines de prospection auront pu être gaspillées. »
La propagation DNS est le processus par lequel les modifications des enregistrements DNS se répandent à travers le réseau des résolveurs récursifs d'Internet. Lorsque vous mettez à jour un enregistrement DNS, il n'apparaît pas instantanément partout. Différents serveurs à travers le monde verront les anciens et les nouveaux enregistrements à des moments différents, ce qui peut provoquer des échecs d'authentification temporaires pendant la période de transition.
Le TTL est la valeur (en secondes) qui indique aux résolveurs DNS combien de temps mettre un enregistrement en cache avant de vérifier les mises à jour. Un TTL de 3600 signifie que les résolveurs mettront l'enregistrement en cache pendant une heure. Des valeurs TTL plus basses accélèrent la propagation des changements mais entraînent davantage de requêtes DNS. Des valeurs TTL plus élevées réduisent le trafic DNS mais ralentissent la propagation.
Pour les enregistrements d'authentification email, nous recommandons les valeurs TTL suivantes :
Problème 1 : les changements n'apparaissent pas après le délai attendu Vérifiez d'abord que les changements ont été correctement enregistrés chez votre fournisseur DNS. Ensuite, contrôlez à l'aide de plusieurs outils de recherche DNS depuis différentes localisations géographiques. Si les serveurs de noms faisant autorité affichent les bons enregistrements mais que les autres résolveurs ne le font pas, il s'agit d'un délai de propagation normal.
Problème 2 : résultats incohérents entre résolveurs Pendant la propagation, différents résolveurs auront différentes versions en cache. C'est un comportement attendu. Évitez d'envoyer des campagnes importantes immédiatement après des changements DNS. Attendez au moins 2 fois la valeur TTL précédente pour garantir une propagation large.
Problème 3 : limites de débit de l'API du fournisseur DNS Lorsque vous configurez plusieurs domaines de manière programmatique, vous pouvez atteindre les limites de débit de l'API. Espacez vos requêtes et implémentez un backoff exponentiel. InboxOne gère cela automatiquement grâce à une mise en file d'attente intelligente des requêtes.
# Vérifier la propagation DNS en ligne de commande # Interroger les enregistrements MX dig MX example.com +short nslookup -type=mx example.com # Interroger l'enregistrement SPF (TXT) dig TXT example.com +short nslookup -type=txt example.com # Interroger l'enregistrement DKIM dig TXT selector._domainkey.example.com +short # Interroger l'enregistrement DMARC dig TXT _dmarc.example.com +short # Interroger un serveur de noms spécifique (contourner le cache local) dig @8.8.8.8 TXT example.com +short # Vérifier le TTL restant dig example.com +noall +answer
Avant d'envoyer le moindre cold email depuis un domaine nouvellement configuré, vous devez vérifier que tous les enregistrements d'authentification sont correctement configurés et propagés. Sauter cette étape est l'une des causes les plus fréquentes de désastres de délivrabilité. Un seul enregistrement mal configuré peut anéantir le taux de placement en boîte de réception de toute votre campagne.
Plusieurs outils gratuits en ligne peuvent vérifier votre configuration DNS :
La méthode de vérification la plus fiable consiste à envoyer un email de test et à analyser les résultats d'authentification dans les en-têtes de l'email. Gmail, par exemple, affiche les résultats d'authentification directement dans l'email lorsque vous cliquez sur « Afficher l'original ». Recherchez ces en-têtes :
# En-têtes d'authentification email à vérifier Authentication-Results: mx.google.com; dkim=pass header.i=@example.com header.s=selector header.b=abc123; spf=pass (google.com: domain of sender@example.com designates 192.168.1.1 as permitted sender) smtp.mailfrom=sender@example.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com # Ce qu'il faut rechercher : # dkim=pass - Signature DKIM vérifiée avec succès # spf=pass - L'IP d'envoi est autorisée par l'enregistrement SPF # dmarc=pass - Évaluation DMARC réussie (SPF/DKIM alignés) # Indicateurs d'échec courants : # dkim=fail (échec de la vérification de la signature) # spf=softfail (IP absente du SPF, mais politique de soft fail) # dmarc=fail (échec d'alignement ou violation de politique)
La vérification manuelle convient à la configuration initiale, mais une surveillance continue est essentielle pour maintenir la délivrabilité. Les enregistrements DNS peuvent être accidentellement supprimés, expirer ou devenir invalides à la suite de changements de fournisseur. La surveillance automatisée détecte ces problèmes avant qu'ils n'affectent vos campagnes.
Les indicateurs clés à surveiller incluent la validité de l'enregistrement SPF et le nombre de recherches (maximum 10 recherches), la présence et la validité cryptographique de la clé DKIM, la cohérence de la politique DMARC et la remise des rapports, ainsi que la disponibilité des enregistrements MX et les temps de réponse.
Même les administrateurs système expérimentés commettent des erreurs de configuration DNS. Ces erreurs passent souvent inaperçues pendant des semaines ou des mois car l'email « fonctionne à peu près » - les messages sont distribués, mais à des taux réduits. Voici les erreurs les plus courantes et comment les éviter.
Avoir plus d'un enregistrement SPF sur un domaine provoque un échec d'authentification immédiat. La spécification SPF stipule qu'un domaine NE DOIT PAS avoir plusieurs enregistrements SPF. Si vous devez autoriser des sources d'envoi supplémentaires, ajoutez-les à votre enregistrement SPF existant à l'aide du mécanisme « include ».
Les enregistrements SPF peuvent inclure des références à d'autres enregistrements (via « include », « redirect », « a », « mx », etc.), mais le nombre total de recherches DNS lors de l'évaluation SPF ne doit pas dépasser 10. Chaque mécanisme « include » compte comme une recherche, et les includes imbriqués comptent dans le total. Dépasser cette limite provoque un renvoi d'erreur permanente par SPF.
Les clés DKIM inférieures à 1024 bits sont considérées comme non sécurisées et peuvent provoquer des échecs d'authentification chez certains destinataires. Utilisez des clés de 2048 bits pour une sécurité et une compatibilité optimales. Certains fournisseurs DNS plus anciens ont des problèmes avec les clés de 2048 bits en raison des limites de longueur des enregistrements TXT ; dans ces cas, la clé doit être répartie sur plusieurs chaînes.
Commencer avec une politique DMARC « reject » avant d'avoir vérifié vos flux d'emails est une recette pour le désastre. Débutez avec « none » pour collecter des rapports et identifier toute source d'envoi légitime que vous auriez pu oublier. Passez à « quarantine » pour les tests, puis à « reject » une fois que vous êtes sûr que tous les emails légitimes sont correctement authentifiés.
Les politiques SPF et DMARC de votre domaine racine ne s'appliquent pas automatiquement aux sous-domaines. Si vous envoyez depuis des sous-domaines (comme mail.example.com), chaque sous-domaine a besoin de son propre enregistrement SPF. Pour DMARC, vous pouvez utiliser la balise « sp » pour définir une politique de sous-domaine, ou créer des enregistrements DMARC distincts pour chaque sous-domaine.
Bien que comprendre la configuration DNS soit précieux, la réalité est que la gestion manuelle du DNS ne passe pas à l'échelle. Les agences qui gèrent des dizaines ou des centaines de domaines de cold email ne peuvent pas se permettre de configurer et de surveiller manuellement les enregistrements d'authentification de chacun. C'est là que la gestion DNS automatisée d'InboxOne devient essentielle.
Lorsque vous achetez un domaine via InboxOne ou connectez un domaine existant, notre système configure automatiquement tous les enregistrements DNS requis. Les enregistrements SPF, DKIM, DMARC et MX sont créés avec des réglages optimaux en quelques minutes. Aucune modification manuelle n'est requise et aucune supposition n'est nécessaire quant au délai de propagation.
InboxOne prend en charge Cloudflare et ClouDNS pour la gestion DNS. Nos intégrations d'API avec ces fournisseurs garantissent que les enregistrements sont créés correctement, que les valeurs TTL sont optimisées et que toutes les particularités propres à chaque fournisseur sont gérées automatiquement.
InboxOne Protect surveille la santé DNS de votre domaine 24 h/24 et 7 j/7. Si un enregistrement est accidentellement supprimé, modifié incorrectement ou échoue à la validation, notre système détecte le problème en quelques minutes et le répare automatiquement. Vous recevez des notifications concernant tout problème, mais dans la plupart des cas, le problème est résolu avant même que vous ne voyiez l'alerte.
Pour les agences opérant à grande échelle, InboxOne propose des opérations en masse qui configurent le DNS pour des dizaines de domaines simultanément. Notre système de mise en file d'attente intelligent gère les limites de débit des API, suit l'état de propagation sur tous les domaines et signale quand chaque domaine est prêt à l'emploi. Cela transforme ce qui prendrait des heures de travail manuel en quelques minutes de supervision.
« La configuration DNS était autrefois la partie la plus fastidieuse du lancement de nouveaux domaines de cold email. Avec InboxOne, je n'y pense littéralement jamais. Les domaines sont prêts à être préchauffés en quelques minutes après l'achat, avec une authentification parfaite à chaque fois. »
- Propriétaire d'une agence de cold email
Que vous configuriez le DNS manuellement ou à l'aide d'outils automatisés, suivre ces bonnes pratiques garantira une délivrabilité optimale pour vos campagnes de cold email.
La configuration DNS est le fondement technique qui détermine si vos cold emails atteignent la boîte de réception ou disparaissent dans le spam. Comprendre comment les enregistrements MX, SPF, DKIM et DMARC fonctionnent ensemble vous donne les connaissances nécessaires pour diagnostiquer les problèmes de délivrabilité et garantir que votre infrastructure est correctement configurée.
Cependant, la gestion manuelle du DNS devient de plus en plus impraticable à mesure que vous passez à l'échelle. Le temps passé à configurer des enregistrements, à résoudre les problèmes de propagation et à surveiller les problèmes est du temps qui n'est pas consacré à l'exécution réelle de vos campagnes. C'est pourquoi des plateformes comme InboxOne existent : pour gérer la complexité technique afin que vous puissiez vous concentrer sur l'essentiel - rédiger d'excellents messages de prospection et développer votre entreprise.
Que vous choisissiez de gérer le DNS manuellement ou de tirer parti de l'automatisation, les principes de ce guide vous aideront à maintenir l'infrastructure d'authentification qu'exige la délivrabilité email moderne. Vos cold emails méritent d'atteindre la boîte de réception. Une configuration DNS correcte garantit qu'ils y parviennent.
La propagation DNS prend généralement entre 15 minutes et 48 heures, selon les réglages du TTL (Time to Live) et le fournisseur DNS. Avec des fournisseurs comme Cloudflare, les changements se propagent souvent en 5 à 15 minutes. La configuration automatique d'InboxOne garantit des réglages TTL optimaux pour une propagation plus rapide.
Non, vous ne devriez avoir qu'un seul enregistrement SPF par domaine. Avoir plusieurs enregistrements SPF provoque des échecs d'authentification, car les serveurs destinataires ne sauront pas lequel utiliser. Si vous devez autoriser plusieurs sources d'envoi, combinez-les en un seul enregistrement SPF à l'aide du mécanisme « include ».
DMARC exige un alignement, c'est-à-dire que le domaine de l'en-tête « From » doit correspondre soit au domaine authentifié par SPF, soit au domaine signataire DKIM. Si l'alignement échoue même lorsque SPF ou DKIM réussit individuellement, DMARC échouera. C'est pourquoi une configuration correcte des trois protocoles est essentielle.
Bien que les enregistrements MX servent principalement à recevoir des emails, leur configuration est importante pour la crédibilité en cold email. De nombreux filtres anti-spam vérifient la présence d'enregistrements MX comme signe d'un domaine légitime. Un domaine sans enregistrements MX peut être signalé comme suspect puisqu'il ne peut pas recevoir de réponses.
InboxOne configure automatiquement les enregistrements SPF, DKIM, DMARC et MX pour tous les domaines achetés ou connectés via la plateforme. Grâce à l'intégration de l'API Cloudflare ou ClouDNS, les enregistrements sont créés en quelques minutes sans aucune intervention manuelle. Notre système surveille également la santé DNS 24 h/24 et 7 j/7 et corrige automatiquement les problèmes.
Un soft fail (~all) indique aux serveurs destinataires d'accepter les emails qui échouent au SPF tout en les marquant comme suspects, tandis qu'un hard fail (-all) demande aux serveurs de rejeter purement et simplement les emails. Pour le cold email, il est recommandé de commencer par un soft fail pendant le préchauffage, puis de passer au hard fail une fois votre réputation d'expéditeur établie.
Vous pouvez vérifier les enregistrements DNS à l'aide d'outils comme MXToolbox, Google Admin Toolbox, ou des utilitaires en ligne de commande comme dig et nslookup. InboxOne propose une vérification DNS intégrée qui contrôle automatiquement tous les enregistrements d'authentification et vous alerte de tout problème avant qu'il n'affecte la délivrabilité.