← RFC Reference

RFC 6186: Registros SRV para Autodescubrimiento de Servicio de Correo Electrónico

Por Qué Existe

Configurar un cliente de correo requiere conocer múltiples nombres de servidores, puertos y configuraciones de seguridad: un servidor IMAP o POP3 para leer correo y un servidor de envío para enviar. La mayoría de los usuarios no pueden proporcionar esta información. Antes de los registros SRV, los clientes de correo se basaban en:

• Adivinar nombres de host comunes como mail.example.com o imap.example.com
• Protocolos de autodescubrimiento propietarios (Microsoft Autodiscover, Mozilla ISPDB)
• Guías de configuración manual

RFC 6186 proporciona un mecanismo estándar basado en DNS que funciona para cualquier dominio. El administrador del dominio publica registros SRV y cualquier cliente de correo compatible puede descubrir automáticamente los servidores correctos.

Cómo Funciona

El cliente de correo extrae el dominio de la dirección de correo del usuario y luego consulta DNS para registros SRV bajo nombres de servicio específicos.

Formato de Registro SRV

Nombre:     _service._proto.domain
Tipo:     SRV
Contenido:  priority weight port target

Registros DNS Requeridos

Para un dominio example.com con correo alojado en mail.provider.net:

; Recibir correo (IMAP sobre TLS)
_imaps._tcp.example.com.    IN SRV  0 1 993 mail.provider.net.

; Recibir correo (IMAP con STARTTLS)
_imap._tcp.example.com.     IN SRV  0 1 143 mail.provider.net.

; Recibir correo (POP3 sobre TLS)
_pop3s._tcp.example.com.    IN SRV  0 1 995 mail.provider.net.

; Enviar correo (Envío sobre TLS)
_submissions._tcp.example.com. IN SRV  0 1 465 mail.provider.net.

; Enviar correo (Envío con STARTTLS)
_submission._tcp.example.com.  IN SRV  0 1 587 mail.provider.net.

Deshabilitación de un Servicio

Para indicar que un servicio no está disponible, publica un registro SRV con un destino de . (un único punto):

; No ofrecemos POP3
_pop3._tcp.example.com.     IN SRV  0 0 0 .
_pop3s._tcp.example.com.    IN SRV  0 0 0 .

Detalles Técnicos Clave

Nombres de Servicio Definidos por RFC 6186

Prioridad de Descubrimiento del Cliente

1. Consultar _imaps._tcp primero (TLS implícito es preferido sobre STARTTLS según RFC 8314).
2. Si no hay registro _imaps, volver a _imap._tcp con STARTTLS obligatorio.
3. Para envío, preferir _submissions._tcp (puerto 465) sobre _submission._tcp (puerto 587).
4. Usar los campos de prioridad y peso de SRV para equilibrio de carga y conmutación por error entre múltiples servidores.

Verificación de Certificado TLS

Según RFC 7817, el cliente debe verificar el certificado TLS del servidor contra el nombre de host de destino SRV (por ejemplo, mail.provider.net), no contra el dominio de correo del usuario. Esto permite a los proveedores de alojamiento servir muchos dominios con un único certificado.

Errores Comunes

• No publicar registros SRV en absoluto. Muchos dominios se basan en autodescubrimiento propietario o asumen que los usuarios configurarán manualmente. Publicar registros SRV toma minutos y ayuda a todos los clientes de correo compatibles con estándares.
• Publicar solo variantes STARTTLS. RFC 8314 recomienda TLS implícito. Publica registros _imaps y _submissions (TLS implícito) como opción principal, con variantes STARTTLS como alternativa.
• Destino SRV apuntando a un CNAME. El destino SRV debe ser un registro A o AAAA, no un CNAME. Este es un requisito del protocolo DNS (RFC 2782). Apuntar SRV a un CNAME puede causar fallos de resolución.
• Olvidar deshabilitación de servicios no utilizados. Si no admites POP3, publica un registro SRV de "punto" para indicar explícitamente a los clientes. De lo contrario, pueden pasar tiempo sondeando puertos que nunca responderán.
• Incompatibilidad de certificado con destino SRV. Si tu registro SRV apunta a mail.provider.net, el certificado TLS en ese servidor debe incluir mail.provider.net en su SAN. Las incompatibilidades causan fallos de conexión en clientes que validan certificados.

Impacto en la Entrega

• Reduce la configuración errónea del usuario. El autodescubrimiento significa que menos usuarios ingresan configuraciones incorrectas, lo que significa menos incidencias de "no se puede enviar" y menos mensajes atrapados en bandejas de salida.
• Requiere TLS desde el inicio. Al anunciar solo servicios habilitados para TLS a través de SRV, aseguras que los clientes se conecten de forma segura de forma predeterminada en lugar de comenzar sin cifrar.
• Habilita migraciones de alojamiento sin problemas. Cuando se mueve correo a un nuevo proveedor, actualiza los registros SRV y los clientes encontrarán automáticamente los nuevos servidores sin reconfiguración manual.
• Complementa mejores prácticas de envío. Los registros SRV para _submissions dirigen a los clientes al puerto de envío autenticado correcto (RFC 6409), manteniendo el tráfico de envío correctamente separado del tráfico de relé MX.

Related RFCs