Adresse e-mail à son nom de domaine : création et réglages

Une adresse e-mail à son nom de domaine remplace le suffixe d’un service gratuit par celui de l’entreprise, du type [email protected]. Mettre en service un nom de domaine email tient en trois chantiers : choisir où héberger les boîtes, publier quatre enregistrements DNS (MX, SPF, DKIM, DMARC), puis régler chaque logiciel de messagerie.

Le nom lui-même est supposé acquis : les arbitrages sur l’extension et la longueur du nom comme la démarche pour vérifier qu’un nom est libre puis le réserver relèvent d’étapes antérieures. Tout part ici d’un domaine déjà enregistré au nom de l’entreprise.

Ce que désigne la partie après l’arobase

Une adresse électronique se lit en deux morceaux séparés par l’arobase. La RFC 5321 de l’IETF, référence de SMTP (le protocole de transport du courrier) depuis octobre 2008, la définit comme une partie locale suivie d’un domaine : à gauche le nom de la boîte (contact, prenom.nom), à droite le domaine de l’organisation qui répond de l’adresse. Seule la machine désignée par ce domaine interprète la partie locale ; le domaine, lui, suit les règles du DNS et ignore les majuscules.

Posséder un domaine ne crée pourtant aucune boîte. Le titulaire détient le nom ; un hébergeur de messagerie fait tourner les serveurs qui reçoivent et expédient les courriels, et la zone DNS indique où livrer. Changer d’hébergeur ne change donc pas l’adresse, tant que l’entreprise garde la maîtrise de son propre domaine.

Des adresses de rôle prévues de longue date

La RFC 2142, publiée en mai 1997, recense les noms de boîtes attendus pour les fonctions courantes, dont postmaster, abuse, webmaster, info et support, et rappelle qu’une boîte postmaster est exigée sur tout hôte doté d’un serveur SMTP. Une petite structure n’ouvre pas une boîte par rôle : elle crée des alias, adresses sans stockage propre qui renvoient vers des boîtes existantes.

• postmaster et abuse vers la personne qui gère la technique ;
• contact vers celle qui traite les demandes entrantes ;
• facturation vers la comptabilité, interne ou externe ;
• une adresse nominative par collaborateur.

Trois façons d’héberger les boîtes d’un nom de domaine email

Trois montages coexistent ; le nombre de personnes et les outils déjà en place les départagent.

L’offre de messagerie du bureau d’enregistrement

De nombreux bureaux d’enregistrement proposent quelques boîtes ou une simple redirection à côté du domaine. Domaine, zone et boîtes restent alors au même endroit, enregistrements souvent posés d’office. Contrepartie : une capacité parfois modeste et un prestataire unique, qui rend la sécurité du compte client décisive.

La suite bureautique en ligne

Une suite en ligne associe messagerie, agenda partagé, stockage de fichiers et visioconférence. L’entreprise prouve qu’elle est titulaire du domaine par un enregistrement TXT de vérification, puis fait pointer ses MX vers la suite. Le montage sert les équipes qui travaillent à plusieurs, au prix d’une administration suivie des comptes et des départs.

Les boîtes de l’hébergement mutualisé

L’hébergement qui sert le site inclut souvent des boîtes sur le même serveur. La formule dépanne un indépendant, mais site et messagerie partagent alors la même machine et la même réputation d’envoi : un site piraté qui expédie des courriels indésirables pénalise aussi les envois légitimes.

Avec une messagerie gratuite grand public, rattacher son domaine passe en général par la formule professionnelle de l’éditeur, ou par une redirection doublée d’un envoi via le serveur SMTP du domaine.

Avant de signer, quatre points se comparent mieux que le tarif affiché :

• la signature DKIM avec le domaine de l’entreprise ;
• l’accès IMAP standard, qui conditionne la récupération des archives ;
• la double authentification, boîtes et console comprises ;
• le lieu d’hébergement des données et la réversibilité prévue au contrat.

Les enregistrements DNS qui livrent et authentifient le courrier

Quatre enregistrements font fonctionner un domaine de messagerie : le premier oriente la réception, les trois autres, publiés en TXT, protègent l’envoi contre l’usurpation.

MX, la route de la réception

Côté réception, l’enregistrement MX désigne les serveurs qui acceptent le courrier du domaine. Selon la RFC 5321, la valeur de préférence la plus basse est essayée en premier, les autres servent de secours ; sans MX, l’expéditeur se rabat sur l’adresse IP du domaine, souvent celle du site. Lors d’un changement d’hébergeur, les anciens MX se retirent, sinon les courriels se dispersent entre deux boîtes.

SPF, la liste des serveurs autorisés

Défini par la RFC 7208 d’avril 2014, l’enregistrement SPF liste les serveurs habilités à expédier au nom du domaine, sous une forme comme v=spf1 mx -all. Le mécanisme final fixe le sort des autres : -all les déclare non autorisés, ~all probablement non autorisés, ?all ne se prononce pas.

Le texte impose un seul enregistrement SPF par domaine et plafonne à dix les mécanismes qui déclenchent une requête DNS, include compris : chaque outil d’envoi ajouté entame ce budget. SPF vérifie enfin l’adresse d’enveloppe de la transaction SMTP, pas l’expéditeur affiché.

DKIM, une signature dans chaque envoi

Décrite par la RFC 6376 de septembre 2011, la signature DKIM ajoute à chaque courriel sortant un en-tête signé avec une clé privée, dont la clé publique se publie sous un nom du type selecteur._domainkey.exemple.fr. Le sélecteur autorise plusieurs clés à la fois, utile pour les faire tourner. La RFC 8301 de janvier 2018 impose des clés RSA d’au moins 1 024 bits, en recommande au moins 2 048 et proscrit rsa-sha1.

Signer avec le domaine de l’hébergeur plutôt qu’avec celui de l’entreprise ne compte pas pour DMARC, faute d’alignement.

DMARC, la consigne laissée aux destinataires

DMARC relie ces contrôles au domaine visible dans le champ « De ». La RFC 9989, publiée en mai 2026, a remplacé la RFC 7489. Un courriel passe quand SPF ou DKIM réussit avec un domaine aligné sur celui de l’expéditeur affiché, identique (alignement strict) ou rattaché au même domaine d’organisation (alignement relâché). Publiée en TXT sous _dmarc.exemple.fr, la politique DMARC indique le sort d’un échec :

• p=none : aucune préférence exprimée, phase d’observation ;
• p=quarantine : courriel tenu pour suspect ;
• p=reject : échec traité comme une utilisation illégitime du domaine.

La balise rua désigne l’adresse des rapports agrégés. L’ordre prudent : p=none avec rua, lecture des rapports, correction des services oubliés, puis durcissement. La nouvelle version remplace l’ancienne balise pct par une balise t de mode test.

Redirection simple ou boîte complète, puis réglage du logiciel

Rediriger vers une boîte déjà utilisée

Avec une redirection de courriels, tout ce qui arrive sur [email protected] part vers une boîte existante. La formule convient à un démarrage ou à une adresse de rôle peu sollicitée, avec trois limites :

• les réponses partent de l’adresse de destination, sauf envoi réglé sur le serveur SMTP du domaine ;
• SPF échoue sur un courriel redirigé sans réécriture de l’enveloppe, cas décrit par la RFC 7208 dans son annexe sur les intermédiaires, et seule une signature DKIM intacte le fait alors passer DMARC ;
• aucune copie ne reste sur le domaine.

Les paramètres IMAP et SMTP à relever

IMAP, dans sa version 4rev2 décrite par la RFC 9051 en 2021, laisse le courrier sur le serveur et synchronise les dossiers entre appareils ; POP rapatrie les courriels sur un seul poste. La RFC 8314 de janvier 2018 déclare obsolètes les connexions en clair et privilégie le TLS dès l’ouverture de la session. Valeurs à relever dans l’aide de l’hébergeur :

• IMAP, port 993 en TLS implicite (POP : port 995) ;
• SMTP de soumission, port 465 en TLS implicite, ou 587 avec STARTTLS ;
• identifiant, le plus souvent l’adresse complète ;
• authentification à l’envoi, exigée par défaut selon la RFC 6409 ;
• mot de passe d’application, si le service l’exige avec la double authentification.

Domaine expiré, SPF en double, boîte partagée : les pannes évitables

Le domaine arrive à échéance sans renouvellement

Un domaine non renouvelé coupe à la fois le site et le courrier. Le guide de l’ANSSI « Bonnes pratiques pour l’acquisition et l’exploitation de noms de domaine », publié le 10 novembre 2017, rappelle que la compromission des prestataires du DNS peut entraîner l’interception de courriers électroniques. Il décrit aussi le risque d’un nom non renouvelé avant son expiration, dont un attaquant devient le nouveau titulaire. Celui-ci recevrait tout ce qui part encore vers les anciennes adresses.

Deux parades : le renouvellement automatique, et une adresse de contact du compte client placée hors du domaine concerné, pour que les avis d’échéance arrivent même si la messagerie tombe.

Deux enregistrements SPF pour un seul domaine

Un enregistrement posé par l’hébergeur du site, un second ajouté pour la suite bureautique. Résultat ? Une erreur permanente au sens de la RFC 7208, et des envois déclassés chez les destinataires stricts. La correction fusionne les deux en un seul TXT v=spf1, terminé par un unique mécanisme all.

Une adresse générique partagée par toute l’équipe

Quand son mot de passe circule entre plusieurs personnes, une adresse générique comme contact@ cumule les défauts : aucune trace de qui a répondu, un mot de passe à changer à chaque départ, une double authentification rattachée à personne. Mieux vaut en faire un alias ou une liste de diffusion vers des boîtes nominatives.

Dernier piège : un changement de serveurs de noms qui recrée la zone sans recopier MX et TXT. Le guide de l’ANSSI recommande d’effectuer des sauvegardes du contenu des zones ; un relevé avant toute migration en tient lieu.

Une adresse professionnelle cohérente avec le site

Le domaine du courriel et celui du site se répondent. Sur ce domaine, une adresse e-mail professionnelle relie chaque échange à l’entreprise, de la page de contact aux devis et aux factures, alors qu’une adresse de webmail gratuite brouille ce lien. Une politique DMARC durcie complique aussi la livraison des faux courriels envoyés au nom du domaine.

Les alertes techniques du site arrivent elles aussi par courriel : celles des premiers réglages de la Search Console supposent une adresse professionnelle réellement relevée, pas la boîte d’un ancien prestataire.

Prochaine étape : exporter la zone DNS actuelle, vérifier qu’elle ne contient qu’un seul SPF, puis publier un DMARC en p=none avec une adresse de rapports. Les premiers rapports montreront quels services envoient réellement au nom de l’entreprise.