El punto de partida son los registros MX del dominio. Indican qué hosts reciben el correo entrante, y un nombre de servidor reconocible suele revelar qué proveedor opera esa ruta. A veces la respuesta es clara. Otras veces, DNS solo muestra una pasarela de filtrado, un nombre privado o una mezcla de proveedores. En esos casos no se puede identificar el servicio de buzones que hay detrás.
Ese límite evita atribuciones falsas. Una consulta MX puede aportar evidencia sobre la ruta entrante visible. No identifica a la empresa propietaria del dominio, a la persona que usa una dirección ni al servicio empleado para enviar correo.
Empezar por el dominio
Para alex@company.example, hay que consultar company.example. La parte anterior a @ designa el buzón y no interviene en la consulta MX.
Conviene usar una herramienta DNS que muestre todas las respuestas MX y sus valores de preferencia:
dig MX company.example
La salida siguiente es un ejemplo creado para esta explicación. Los nombres bajo .example están reservados para documentación y no describen a un proveedor real:
company.example. 3600 IN MX 10 inbound-a.mailhost.example.
company.example. 3600 IN MX 20 inbound-b.mailhost.example.
Cada registro MX contiene una preferencia y el nombre del servidor de destino. Los servidores remitentes prueban primero los valores más bajos. Por tanto, la ruta con preferencia 10 precede a la de 20. Los valores iguales tienen la misma prioridad. RFC 1035 define los dos campos de un registro MX y RFC 5321 explica cómo SMTP elige el destino.
Hay que revisar el conjunto completo. Un servidor de respaldo con un valor más alto puede pertenecer a otro operador. Varios registros con la misma preferencia pueden formar parte del mismo servicio. El glosario sobre registros MX explica con más detalle las reglas de enrutamiento.
Relacionar cada servidor con un proveedor
El siguiente paso consiste en comparar los sufijos de los servidores de destino con los nombres documentados o controlados por proveedores conocidos. Si varios registros terminan en el espacio de nombres de un mismo proveedor, normalmente corresponden a un solo servicio con varios servidores de entrada.
En el ejemplo, ambos hosts terminan en mailhost.example. Si ese espacio de nombres perteneciera a un perfil conocido, los dos registros respaldarían la misma atribución. Un servicio de consulta puede mantener este mapa y devolver un identificador estable. Así no hace falta reconocer cada nombre a simple vista.
El resultado describe la evidencia sobre la ruta entrante:
- Un proveedor conocido en todas las rutas preferidas respalda una coincidencia única.
- Varios proveedores conocidos con el mismo nivel preferido producen un resultado mixto.
- Un nombre propio o un sufijo desconocido deja el proveedor como desconocido.
- Si el dominio declara que no recibe correo, no hay un proveedor aplicable.
La preferencia cambia la interpretación. Una ruta de respaldo con menor prioridad quizá no procese correo durante el funcionamiento normal. Pero ignorarla por completo puede ocultar a un segundo operador que entra en servicio durante una incidencia.
Una pasarela puede ocultar el servicio de buzones
Muchas organizaciones colocan un servicio de filtrado o seguridad delante de sus buzones. Los registros MX apuntan a esa pasarela porque es quien acepta primero la conexión SMTP. Después, la pasarela retransmite los mensajes aceptados a una plataforma cuyo nombre no aparece en DNS.
En esta configuración, una consulta basada en MX debe identificar la pasarela. Presentarla como el servicio de buzones excedería la evidencia disponible. La misma cautela se aplica a relés alojados y dispositivos propios.
Los nombres personalizados complican aún más la atribución. Una empresa puede publicar mx1.company.example aunque el host dependa de un servicio externo. Sin datos verificados que respalden la relación, el proveedor queda desconocido. Inferirlo por la marca o por una dirección IP puede convertir una relación de alojamiento en una identificación incorrecta.
Separar los servicios relacionados
Un dominio puede recurrir a empresas distintas para tareas distintas. El operador de la ruta MX puede no tener relación con el registrador, el servicio DNS autoritativo o el alojamiento web. La plataforma que envía boletines y mensajes transaccionales también puede ser otra.
SPF no responde a la pregunta sobre el correo entrante. Sus reglas indican qué hosts están autorizados para enviar mensajes con una identidad del dominio, según RFC 7208. DMARC publica información sobre alineación, política e informes para mensajes autenticados; RFC 9989 define ese ámbito. Ninguno sustituye a la ruta MX para saber quién recibe el correo.
Este ejemplo explica por qué un mensaje puede pasar SPF y fallar DMARC.
Los datos de registro del dominio contestan otra pregunta. El registrador gestiona el registro y los datos del titular se refieren al control del dominio. No identifican al operador del correo entrante.
Para usar la identificación del proveedor junto con los datos de red y registro, consulte la guía para interpretar un perfil de dominio.
Algunas consultas MX no permiten identificar al proveedor
No encontrar una coincidencia también es un resultado válido. Antes de interpretarlo, hay que comprobar el estado de DNS:
- Si la respuesta MX está vacía, SMTP puede usar una ruta implícita hacia el propio dominio. Un host personalizado suele aportar pocos datos para identificar a un proveedor.
- Un único
MX 0 .es un MX nulo. Declara que el dominio no acepta correo, por lo que no hay proveedor entrante que identificar. RFC 7505 define esta declaración. - Si existen destinos MX publicados pero no se pueden resolver, no se aplica la ruta implícita. La ruta explícita está rota o no está disponible de forma temporal.
- Un
SERVFAILo un tiempo de espera agotado deja la consulta sin resolver. Conviene repetirla o investigar el fallo de DNS antes de atribuir un proveedor. NXDOMAINindica que, según la respuesta DNS, el dominio consultado no existe. No hay una ruta que se pueda atribuir.
La guía sobre un dominio sin registro MX explica el enrutamiento implícito, el MX nulo y los destinos inutilizables. Una respuesta vacía, una declaración expresa de no recibir correo y una consulta fallida requieren conclusiones diferentes.
La identificación del proveedor es evidencia de dominio
Una coincidencia indica quién parece operar la ruta entrante visible en el momento de la consulta. No demuestra que alex@company.example exista. Tampoco permite prometer la entrega ni la llegada a la bandeja de entrada.
Para obtener evidencia sobre un buzón hace falta verificar la dirección completa. El resultado depende de lo que el servidor receptor permita observar. Un dominio catch-all y las respuestas temporales pueden mantener la incertidumbre. La comparación entre verificación completa y comprobación de dominio explica esta diferencia.
Los mapas de proveedores también envejecen. Los servicios añaden nombres, los clientes migran y las rutas cambian. Si la atribución influye en una decisión, conviene conservar la observación DNS con la fecha y hora. Una etiqueta antigua no debe prevalecer sobre una respuesta MX más reciente.
Comprobar la ruta y el perfil conocido
El comprobador de dominios de Emvero indica si un dominio puede recibir correo. Si el destino coincide con un perfil conocido, el resultado puede incluir su identificador. La herramienta no muestra los nombres MX ni los valores de preferencia. Para revisar los registros sin procesar, se puede usar dig.
La ausencia de un perfil significa que los datos actuales no contienen una coincidencia reconocida. No demuestra que el dominio tenga servidores propios ni que sea empresarial. La consulta es gratuita y no requiere una cuenta.