← RFC Reference

RFC 6186 : Enregistrements SRV pour la découverte automatique du service de messagerie

Pourquoi cela existe

Configurer un client de messagerie nécessite de connaître plusieurs noms d'hôtes de serveur, ports et paramètres de sécurité : un serveur IMAP ou POP3 pour lire le courrier, et un serveur de soumission pour l'envoi. La plupart des utilisateurs ne peuvent pas fournir ces informations. Avant les enregistrements SRV, les clients de messagerie s'appuyaient sur :

• Deviner des noms d'hôtes communs comme mail.example.com ou imap.example.com
• Protocoles de découverte propriétaires (Microsoft Autodiscover, Mozilla ISPDB)
• Guides de configuration manuelle

La RFC 6186 fournit un mécanisme standard basé sur le DNS qui fonctionne pour n'importe quel domaine. L'administrateur de domaine publie des enregistrements SRV, et tout client de messagerie conforme peut découvrir automatiquement les serveurs corrects.

Comment cela fonctionne

Le client de messagerie extrait le domaine de l'adresse e-mail de l'utilisateur, puis interroge le DNS pour les enregistrements SRV sous des noms de service spécifiques.

Format d'enregistrement SRV

Nom :     _service._proto.domaine
Type :     SRV
Contenu :  priorité poids port cible

Enregistrements DNS requis

Pour un domaine example.com avec courrier hébergé sur mail.provider.net :

; Réception de courrier (IMAP sur TLS)
_imaps._tcp.example.com.    IN SRV  0 1 993 mail.provider.net.

; Réception de courrier (IMAP avec STARTTLS)
_imap._tcp.example.com.     IN SRV  0 1 143 mail.provider.net.

; Réception de courrier (POP3 sur TLS)
_pop3s._tcp.example.com.    IN SRV  0 1 995 mail.provider.net.

; Envoi de courrier (Soumission sur TLS)
_submissions._tcp.example.com. IN SRV  0 1 465 mail.provider.net.

; Envoi de courrier (Soumission avec STARTTLS)
_submission._tcp.example.com.  IN SRV  0 1 587 mail.provider.net.

Désactiver un service

Pour indiquer qu'un service n'est pas disponible, publiez un enregistrement SRV avec une cible de . (un seul point) :

; Nous n'offrons pas POP3
_pop3._tcp.example.com.     IN SRV  0 0 0 .
_pop3s._tcp.example.com.    IN SRV  0 0 0 .

Détails techniques clés

Noms de service définis par la RFC 6186

Priorité de découverte du client

1. Interroger d'abord _imaps._tcp (TLS implicite est préféré à STARTTLS selon la RFC 8314).
2. S'il n'y a pas d'enregistrement _imaps, revenir à _imap._tcp avec STARTTLS obligatoire.
3. Pour la soumission, préférer _submissions._tcp (port 465) à _submission._tcp (port 587).
4. Utiliser les champs de priorité et de poids SRV pour l'équilibrage de charge et le basculement entre plusieurs serveurs.

Vérification du certificat TLS

Selon la RFC 7817, le client doit vérifier le certificat TLS du serveur par rapport au nom d'hôte cible SRV (par ex., mail.provider.net), et non le domaine de l'utilisateur. Cela permet aux fournisseurs d'hébergement de servir de nombreux domaines avec un seul certificat.

Erreurs courantes

• Ne pas publier d'enregistrements SRV du tout. De nombreux domaines s'appuient sur la découverte propriétaire ou supposent que les utilisateurs configureront manuellement. Publier des enregistrements SRV prend quelques minutes et aide tous les clients de messagerie conformes aux normes.
• Publier uniquement des variantes STARTTLS. La RFC 8314 recommande TLS implicite. Publiez à la fois les enregistrements _imaps et _submissions (TLS implicite) comme option principale, avec les variantes STARTTLS en secours.
• Cible SRV pointant vers un CNAME. La cible SRV doit être un enregistrement A ou AAAA, pas un CNAME. C'est une exigence du protocole DNS (RFC 2782). Pointer SRV vers un CNAME peut causer des échecs de résolution.
• Oublier de désactiver les services inutilisés. Si vous ne supportez pas POP3, publiez un enregistrement SRV « point » pour dire explicitement aux clients. Sinon, ils peuvent passer du temps à sonder les ports qui ne répondront jamais.
• Incompatibilité de certificat avec la cible SRV. Si votre enregistrement SRV cible mail.provider.net, le certificat TLS sur ce serveur doit inclure mail.provider.net dans son SAN. Les incompatibilités causent des échecs de connexion dans les clients qui valident les certificats.

Impact sur la délivrabilité

• Réduit les erreurs de configuration utilisateur. La découverte automatique signifie que moins d'utilisateurs entrent des paramètres incorrects, ce qui signifie moins de tickets de support « impossible d'envoyer » et moins de messages coincés dans les boîtes de brouillon.
• Applique TLS dès le départ. En annonçant uniquement les services activés par TLS via SRV, vous assurez que les clients se connectent de manière sécurisée par défaut plutôt que de commencer sans chiffrement.
• Permet les migrations d'hébergement en douceur. Lors du déplacement du courrier vers un nouveau fournisseur, mettez à jour les enregistrements SRV et les clients trouveront automatiquement les nouveaux serveurs sans reconfiguration manuelle.
• Complète les meilleures pratiques de soumission. Les enregistrements SRV pour _submissions dirigent les clients vers le port de soumission authentifié correct (RFC 6409), en gardant le trafic de soumission correctement séparé du trafic de relais MX.

Related RFCs