MX, SPF, DKIM, DMARC, MTA-STS et les enregistrements de configuration automatique que presque personne ne pose à la main. Le rôle de chacun, les deux familles que nous écartons volontairement, et pourquoi notre vérification fusionne votre enregistrement SPF existant au lieu de vous dire de le remplacer.
Configurer la messagerie sur votre propre domaine suppose de publier des enregistrements DNS, et le DNS est précisément l'endroit où les migrations échouent en silence. Non parce que ces enregistrements sont difficiles, mais parce qu'il y en a plus que quiconque ne l'imagine, parce que plusieurs d'entre eux sont de longues chaînes de matériel cryptographique, et parce qu'une seule erreur subtile signifie que votre courrier continue de fonctionner jusqu'au jour exact où il cesse de le faire.
Notre position est donc que vous n'avez jamais à faire cette recherche vous-même. Quand vous ajoutez un domaine à email.eu, nous générons exactement les enregistrements dont il a besoin, nous vous montrons ce qui est publié aujourd'hui, et nous vous disons lesquels ne sont pas encore corrects. Cet article explique quels enregistrements, ce que nous écartons volontairement, et comment fonctionne la vérification.
Réponse courte : une vingtaine d'enregistrements, en six familles. À quoi ils servent, en clair.
| Enregistrement | Son rôle |
|---|---|
| MX | Indique à Internet quels serveurs acceptent le courrier pour votre domaine. Sans lui, rien n'arrive. |
| SPF | Énumère qui peut envoyer en votre nom. Les destinataires s'en servent pour rejeter les falsifications. |
| DKIM | Publie la moitié publique d'une clé de signature, pour que les destinataires vérifient que votre courrier n'a pas été modifié en route. |
| DMARC | Dit aux destinataires quoi faire quand SPF et DKIM se contredisent, et où envoyer les rapports. |
| MTA-STS et TLS-RPT | Imposent que le courrier vers votre domaine soit remis en TLS, et indiquent où le signaler quand ce n'est pas possible. |
| SRV et CNAME | Permettent aux logiciels de messagerie de trouver seuls vos réglages, au lieu de faire saisir des numéros de port à vos équipes. |
Cette dernière famille, presque personne ne la configure à la main, et c'est elle qui fait la différence entre une collègue qui saisit son adresse et a terminé, et une collègue qui saisit son adresse puis part à la chasse aux numéros de port.
Le serveur de messagerie sait lui-même ce dont il a besoin. Stalwart, le serveur derrière email.eu, peut produire une zone complète pour un domaine dès que ce domaine existe, y compris la clé DKIM qui vient d'être créée pour vous. Nous lisons cette zone et en tirons deux choses : un tableau lisible dans votre tableau de bord, et un fichier de zone que la plupart des hébergeurs DNS importent d'un seul coup.
Ce que nous ne faisons pas : entrer dans votre DNS et écrire les enregistrements nous-mêmes. Il nous faudrait pour cela un accès API à votre registrar, et c'est beaucoup d'accès pour vous épargner un seul collage. Votre domaine reste le vôtre. Nous disons exactement quoi publier, puis nous vérifions que c'est bien là.
La zone brute produite par le serveur contient environ cinquante-huit enregistrements. Nous vous en montrons une vingtaine. La différence tient à deux familles que nous écartons délibérément, et les deux décisions méritent une explication, car « notre système l'a généré » n'est pas une raison de vous remettre quelque chose qui vous nuira plus tard.
Les enregistrements DANE (TLSA). DANE fige dans le DNS le certificat exact de votre serveur de messagerie. C'est une vraie bonne sécurité, et c'est un piège pour un DNS tenu à la main, car cette empreinte doit être republiée chaque fois que le certificat se renouvelle. Avec des certificats renouvelés environ tous les soixante jours, un enregistrement DANE collé une fois puis oublié est un enregistrement qui finira par rejeter votre courrier sans bruit. Nous ne vous remettons pas une bombe à retardement avec une mèche de deux mois, donc ces enregistrements sont écartés.
Les enregistrements CAA. Un enregistrement CAA indique quelle autorité de certification peut délivrer des certificats pour votre domaine, et il s'applique à tout votre domaine, pas seulement à sa messagerie. La version qu'un serveur de messagerie génère pointe vers le compte de certificats de ce serveur. La publier revient à annoncer discrètement au monde que seul ce compte peut délivrer des certificats pour votre entreprise, ce qui inclut le certificat de votre site web, lequel n'a rien à voir avec nous. La politique de certificats de votre domaine est une décision que vous prenez sciemment, pas un effet de bord de la configuration de la messagerie. Nous ne touchons donc pas au CAA.
C'est la règle générale que nous appliquons : l'ensemble que nous recommandons est celui qui fonctionne, qui continue de fonctionner sans entretien, et qui ne concerne que le courrier.
Dès que vous avez publié, nous vérifions. Chaque enregistrement reçoit l'un de quelques verdicts honnêtes : correctement publié, absent, ou présent mais différent de ce que nous attendons. Absent et différent sont volontairement deux réponses distinctes, parce qu'elles demandent de vous des réactions différentes.
C'est sur SPF qu'une telle vérification gagne son salaire. Un domaine ne peut avoir qu'un seul enregistrement SPF, donc si vous envoyez déjà vos factures via votre logiciel de comptabilité et votre infolettre via un outil d'emailing, votre enregistrement SPF existe déjà et les mentionne déjà. Une vérification naïve constate que notre enregistrement suggéré est absent, vous signale qu'il manque, et vous voilà conseillé de casser vos factures.
La nôtre fait ce qu'il faut. Elle lit ce que vous avez publié, regarde si cela nous autorise déjà, et sinon construit l'enregistrement fusionné que vous devriez réellement publier : vos expéditeurs actuels, plus nous, avec votre propre politique à la fin. Si vous avez choisi le softfail plutôt que l'échec strict, nous gardons votre choix. C'est votre décision sur votre domaine, pas la nôtre.
Avant tout cela vient un petit enregistrement qui fait autre chose : un code de vérification sur _email-eu-verify de votre domaine. Il existe pour que personne ne puisse ajouter votre domaine à son propre espace de travail et recevoir votre courrier. Publiez-le, nous le consultons, et le domaine est le vôtre dans notre système.
Ensuite, toute la séquence ressemble à ceci.
Sur cette dernière étape, nous restons particulièrement honnêtes. Cliquer sur « passer en production » ne fait pas dire à votre tableau de bord que vous y êtes. Il indique en production dès qu'une vérification DNS a réellement vu l'enregistrement MX du monde extérieur pointer vers nous. L'intention et la réalité sont deux choses différentes, et un affichage d'état qui les confond vaut moins que pas d'affichage du tout.
Un autre détail qui compte sur la durée : vos enregistrements sont relus depuis le serveur de messagerie chaque fois que vous ouvrez la page du domaine, et non figés au moment de votre inscription. Si le cluster de messagerie gagne un deuxième hôte MX, ou si l'un des enregistrements de configuration automatique change, la page depuis laquelle vous copiez montre déjà la nouvelle vérité. Personne n'a besoin de vous envoyer un correctif.
Rien de tout cela n'est spectaculaire. C'est la partie du départ de votre ancien fournisseur où les gens abandonnent, ou pire, s'arrêtent à mi-chemin et passent un an avec un courrier qui arrive la plupart du temps. En faire un tableau, un collage et une vérification transforme un projet de recherche en un après-midi.
Si vous voulez voir les enregistrements réels de votre propre domaine avant de vous engager, ils se trouvent derrière la première étape de l'inscription, et le guide de migration en un week-end parcourt tout le basculement du début à la fin.