Una aplicación de envío y un buzón de recepción pueden usar dominios distintos. Los registros que dirigen las respuestas no tienen que estar en cada subdominio que usas para enviar.
¿Cómo usa un servidor de envío los registros MX?
El servidor de envío consulta el dominio del destinatario para encontrar los servidores que aceptan su correo entrante.
Para person@example.org, consulta los registros MX de example.org. Cada registro nombra un servidor de destino cuyo nombre de host se resuelve a una dirección IP.
RFC 5321 define este proceso de consulta para SMTP.
El servidor de envío reporta un error cuando el dominio del destinatario no existe. Tras un fallo de consulta temporal, encola el mensaje para un intento posterior.
¿Qué ocurre cuando un dominio no tiene registro MX?
Si no existen registros MX, SMTP trata el dominio como el destino e intenta sus registros de dirección.
Este MX implícito tiene preferencia cero. No hay una lista MX explícita que lo supere, así que la entrega procede a la dirección propia del dominio cuando es utilizable.
Este respaldo aplica a una lista MX vacía. No rescata un dominio cuyos registros MX publicados son inutilizables.
Un MX nulo es una instrucción diferente: RFC 7505 define un registro explícito que declara que el dominio no acepta correo. Un registro ausente permite el respaldo. Un MX nulo rechaza la entrega.
¿Qué significan los números de preferencia MX?
Los valores de preferencia más bajos identifican los destinos que un remitente debe intentar primero.
Con valores 10, 20 y 30, el destino con 10 es el preferido. Los demás proporcionan alternativas si la entrega no puede proceder allí. Asignar a todos los destinos el mismo valor permite la distribución entre opciones de igual preferencia.
Según RFC 5321, los servidores de envío deben aleatorizar los destinos con igual preferencia a menos que haya una razón clara para favorecer uno. Preferencias iguales no garantizan una división exacta del tráfico.
Apunta tu registro MX a un nombre de host cuya dirección publiques para que los remitentes puedan conectarse. Usa un registro A para su dirección IPv4 o un registro AAAA para IPv6. No uses un alias CNAME como destino. El alias impide que DNS incluya la dirección con su respuesta MX. Eso añade consultas, como explica RFC 2181.
Los clientes SMTP deben soportar intentar destinos alternativos. La especificación recomienda intentar al menos dos direcciones cuando estén disponibles. Un fallo en la primera no tiene por qué terminar los intentos de entrega.
¿Necesitas un registro MX para enviar?
SMTP no requiere un registro MX explícito en tu dominio solo para originar un mensaje.
La consulta de entrega usa el dominio del destinatario. Tu dominio de envío aún necesita DNS válido y autenticación adecuada a los requisitos del receptor. Un receptor puede aplicar sus propias verificaciones al dominio del remitente.
Un registro MX ausente, por tanto, no significa que un dominio de remitente inalcanzable sea aceptable para todos los receptores.
¿A dónde van los fallos de entrega?
Los fallos de entrega van al remitente del sobre, la dirección proporcionada para avisos de fallo durante la entrega SMTP.
¿A dónde van las respuestas?
Las respuestas normalmente usan Reply-To cuando está presente; de lo contrario, la dirección From visible.
Un subdominio de envío no necesita alojar todos los buzones de la empresa. Por ejemplo, news.example.com puede enviar mientras las respuestas van a una dirección funcional en example.com. Haz esa elección de enrutamiento explícita en las direcciones del mensaje.
¿A dónde van los reportes operativos?
Las direcciones operativas como postmaster@ y abuse@ dan a otros operadores una forma de reportar problemas de entrega o abuso.
Según RFC 5321, un servidor SMTP que retransmite o entrega correo debe aceptar postmaster@ para sus dominios servidos. Esto proporciona un contacto para problemas del servicio de correo.
RFC 2142 requiere que las organizaciones mantengan buzones de rol donde exista la función correspondiente. Por ejemplo, un proveedor de servicios de Internet debe mantener abuse@ en su dominio organizativo. Esto dirige las quejas al equipo responsable.
¿Cómo recibes correo con Bird?
Activas la recepción para un dominio y publicas los registros MX que Bird devuelve.
El campo inbound.enabled de API acepta true para activar la recepción o false para desactivarla. Publicar los registros por sí solo no activa la capacidad.
Tras la verificación, el correo dirigido a ese dominio se convierte en mensajes entrantes. Usa un subdominio de recepción dedicado porque reemplazar los registros MX del dominio de tu empresa cambia a dónde llega su correo existente.
El registro de return-path de Bird gestiona los avisos de fallo de entrega de forma separada a esos registros MX entrantes. La guía de recepción explica la configuración del dominio. La guía de dominio de rebotes explica la gestión de fallos.
En resumen
Los registros MX dirigen el correo entrante.
El servidor de envío consulta el dominio del destinatario para encontrar un destino.
Los registros MX ausentes pueden recurrir a registros de dirección.
Cuando no existen registros MX, el servidor de envío puede usar los registros de dirección del dominio.
Los valores de preferencia más bajos se intentan primero.
Los destinos con la misma preferencia se distribuyen aleatoriamente cuando no hay razón para favorecer uno.
El envío y la recepción requieren decisiones separadas.
El correo saliente aún necesita gestión adecuada de fallos de entrega, respuestas y direcciones de contacto operativo.