Resumen

  • Un dominio de correo dejó de ser una orden de conexión al host con ese nombre. Sus MX podían señalar una o varias máquinas distintas, permitiendo cambiar infraestructura sin cambiar las direcciones de los usuarios.
  • El remitente consultaba y ejecutaba la lista: menor preference numérico primero, valores iguales como pares y descarte de rutas que regresaran hacia sí mismo. El MX de un exchanger no prolongaba automáticamente la responsabilidad.
  • DNS aportó una superficie de control, no un certificado de verdad. Sus cambios pueden redirigir correo, los caches conservan rutas antiguas y varios nombres pueden compartir la misma avería; MX no autentica ni cifra mensajes.

Una abreviatura que ya no alcanzaba

RFC 974 recordó la vieja práctica con LOKI.BBN.COM: si la dirección nombraba allí una mailbox, el mailer normalmente abría SMTP contra esa misma máquina. La identidad pública y el punto de entrega coincidían.

Había excepciones. Hosts UUCP y CSNET sin conexión directa se alcanzaban mediante reglas privadas; un ejemplo enviaba correo CSNET a CSNET-RELAY.ARPA. RFC 821 ya contemplaba relay, gateway y source route. La innovación de MX no fue inventar el intermediario.

La dificultad era que cada excepción residía en el remitente. El destinatario no podía actualizar miles de archivos de configuración. Al crecer los dominios, se hizo necesario publicar separadamente qué host aceptaba hoy el correo de un nombre estable.

De MD y MF a una lista ordenada

Los RFC 882 y 883 crearon resource records tipados para el sistema de dominios. El correo usaba MD como destino y MF como forwarder. Eran papeles fijos; representaban mal más de dos opciones o prioridades graduadas.

RFC 973 sustituyó ambos por MX. El nuevo registro llevaba un preference sin signo de 16 bits y el hostname del exchanger. El número menor se intentaba antes; números iguales indicaban la misma prioridad.

La unificación transformó roles en alternativas. Un host directo, un relay y un backup podían publicarse con la misma gramática. RFC 1035 conservó la forma compacta. DNS no describía cada salto ni el estado del servidor: entregaba el mínimo común para que el código remoto eligiera.

El dominio permanece, la máquina cambia

La frase decisiva de RFC 974 fue que un domain name suele ser host, pero no siempre. El mailer debía preguntar al DNS dónde entregar. La respuesta podía ser una máquina completamente distinta o un conjunto de posibilidades.

Una organización podía conservar su dominio mientras migraba buzones, reemplazaba equipos, incorporaba filtro, contrataba servicio o abría otra sede. Quienes enviaban no necesitaban conocer la mudanza; necesitaban el MX vigente y las direcciones de sus targets.

La separación también asignó poder. Quien controla la zona autoritativa puede cambiar el destino de mensajes futuros. MX no prueba propiedad ni identidad legal. Su logro fue más modesto: hacer diferente la vida útil del nombre público y la del aparato que lo atiende.

La ruta se publica; cada MTA decide

RFC 974 recomendó consultar MX en cada intento. Si fallaba un receptor, el administrador podía cambiar el DNS y los mensajes ya en cola aprenderían la ruta nueva cuando volvieran a consultar, conforme expirasen sus caches.

El MTA intentaba primero el menor preference y avanzaba por la lista. Debía probar todos los destinos con el mismo valor mínimo antes de concluir que no había entrega. RFC 5321 mantuvo esa estructura y exige capacidad para intentar y reintentar las direcciones pertinentes. Entre exchangers de igual preference sin otra razón para elegir, randomiza y reparte carga.

Preference no significa velocidad, cercanía, carga ni rango institucional. Diez va antes que veinte porque el dominio declaró ese orden. El backup de veinte puede estar más cerca y seguir siendo backup.

No hay un despachador mundial. El estado común es una lista pequeña; cada MTA administra consulta, cola, retry y la frontera entre fallo temporal y bounce.

Una jerarquía de responsabilidad contra el bucle

El failover puede crear círculos. Cuando el host local figuraba como MX, RFC 974 le ordenaba eliminar su propia entrada y todas las de valor igual o mayor. Solo podía entregar hacia un valor menor, situado por delante.

Así, un backup 20 puede volver al primary 10, pero no pasar a otro 20 o 30 y permitir que el mensaje regrese. La lista no solo indica disponibilidad; orienta el traspaso de responsabilidad.

Tampoco existe una cadena recursiva. La consulta corresponde al dominio original, no al MX del exchanger hallado. Que un host acepte correo para un relay no lo vuelve responsable de todos los dominios del relay. El consentimiento operativo debe ser explícito para el destino; no se hereda por relación DNS.

La demora deliberada del cache

DNS escaló mediante caches. Tras un cambio de MX, algunos remitentes veían lo nuevo y otros conservaban lo anterior. RFC 974 admitió que esa diferencia podía causar bucles o falsos fallos hasta el vencimiento.

Consultar siempre al autoritativo habría evitado cache stale a un costo inaceptable. El documento prefirió precauciones: acordar la incorporación de un exchanger, recibir respuestas completas y repetir por circuito confiable una respuesta UDP truncada.

El cache no es un accidente que bloquea la política. Es el precio de distribuir lectura. Un cambio seguro controla TTL, solapa servicios y conserva rollback; no finge poseer un interruptor simultáneo para todo Internet.

La ausencia que aún pedía un intento

RFC 974 trataba una respuesta sin MX como un MX implícito de preference cero apuntando al propio dominio. RFC 5321 conserva la regla: el emisor busca A o AAAA y prueba SMTP.

La compatibilidad permitió funcionar a dominios antiguos, pero dejó tres estados indistinguibles: configuración tradicional, descuido y rechazo deliberado del correo. Silencio no quería decir “sin servicio”. Remitentes podían reintentar durante días contra la dirección de un sitio web.

Los datos explícitos sí tienen fuerza: si hay MX pero ninguno sirve, no se permite ignorarlos y volver al A/AAAA del dominio. El target del MX debe resolver directamente a direcciones; un CNAME queda fuera de la norma SMTP moderna.

El punto que dice que no existe buzón

RFC 7505 creó null MX en 2015. Un dominio sin recepción publica un solo MX de preference cero cuyo exchange es la raíz DNS, escrita .. No puede convivir con otros MX.

El punto no representa servidor averiado. Declara que no hay exchanger. El MTA falla de inmediato en vez de usar A/AAAA y mantener retries durante un periodo descrito como típicamente una semana. El remitente recibe antes el error y puede corregir la dirección.

Fue una corrección, no una función oculta de 1986. El antiguo fallback favorecía adopción; null MX devolvió al operador una forma explícita de no participar. Tampoco equivale al null reverse-path de SMTP, y un dominio que envía correo debe considerar la necesidad de recibir errores.

El control que esconde una capa pequeña

Cambiar infraestructura sin cambiar usuarios es libertad frente a una máquina, pero dependencia de la zona. Capturar DNS permite desviar correo futuro. Múltiples MX pueden usar el mismo provider, facility, account o network. Un backup amplía continuidad y también el conjunto de actores con acceso a contenido y metadata.

DNSSEC protege integridad del registro, no identidad jurídica ni conducta interna. Que un exchanger acepte SMTP demuestra un traspaso en esa frontera, no almacenamiento final, lectura o confidencialidad.

MX es legítimo cuando se interpreta estrechamente: publica dónde acepta responsabilidad un dominio, en qué orden, o que no presta el servicio. No convierte al operador DNS en soberano sobre el destinatario.

El mapa mínimo de entrega

La dirección, la infraestructura y el conocimiento cacheado adquirieron ritmos distintos. El nombre pudo durar; el servidor, cambiar; la ruta, converger al vencer TTL. Los corresponsales no participaron en cada migración porque la asociación era pública y reemplazable.

La capa común quedó reducida a dominio, exchangers, preference, TTL y reglas de loop y fallback. Colas, seguridad, buzones y contratos permanecieron locales.

La dirección sobrevivió al servidor no porque DNS descubriera su hogar eterno, sino porque el hogar pasó a ser un estado actualizable. Un registro mínimo describió suficiente realidad para que cada sistema actuara sin confundir máquina e identidad.

Fuentes y límites de evidencia

El contexto de SMTP y dominios procede de RFC 821, RFC 882 y RFC 883. El reemplazo de MD/MF está en RFC 973. El algoritmo, cache, loop y responsabilidad no transitiva de 1986 están en RFC 974.

El formato aparece en RFC 1035, los requisitos en RFC 1123, la búsqueda madura y MX implícito en RFC 5321, y el estado sin servicio en RFC 7505.

Son etapas distintas. Las reglas tardías explican evolución y corrección; no se atribuyen a mailers de 1986. Las consecuencias operativas más allá de la especificación son inferencias delimitadas.