Consulte la configuración de correo de un dominio.

En el ejemplo, los registros MX indican adónde se dirige el correo entrante, aunque el proveedor no está identificado. Algunas IP de los servidores de correo y web pertenecen a la misma red, AS64500; otra IP de correo pertenece a AS64511. La antigüedad del registro es de 2191 días en la fecha del ejemplo. El registro SPF contiene -all y la política DMARC es reject. Estos valores describen la configuración publicada; la consulta no ha autenticado ningún mensaje.

El perfil permite añadir el proveedor de correo a una ficha del CRM cuando esté identificado, comparar la infraestructura del correo y la web o consultar la antigüedad del registro al dar de alta a un cliente. Estos datos aportan contexto, pero por sí solos no demuestran que el dominio sea fiable.

Compruebe adónde se dirige el correo entrante

La ruta de correo indica qué servidores deben recibir los mensajes destinados al dominio. Los registros MX muestran sus nombres y prioridades: cuanto menor sea el número, mayor será la preferencia. Si no hay registros MX, puede existir una ruta implícita a través de las direcciones IP del propio dominio. El resultado también distingue los dominios que declaran que no aceptan correo, los que no existen y los que tienen problemas de configuración.

Emvero identifica al proveedor cuando todos los servidores MX de mayor preferencia corresponden al mismo operador conocido. Si pertenecen a operadores distintos o alguno no se reconoce, no se puede identificar un único proveedor. Además, el operador que recibe el correo puede ser una pasarela que filtra los mensajes antes de enviarlos al servidor donde se alojan los buzones.

Qué indican las clasificaciones, SPF y DMARC

Las clasificaciones indican si el dominio figura en los datos de referencia como proveedor de correo temporal o de buzones públicos. No aparecer en esas listas no demuestra que sea seguro ni que corresponda a una empresa.

El campo catch-all recoge lo que Emvero ya sabe sobre si el servidor acepta correo para cualquier destinatario del dominio. La consulta no contacta con el servidor para probar nuevos destinatarios. En este ejemplo, el comportamiento catch-all no está determinado.

SPF declara qué servidores están autorizados a enviar correo en nombre del dominio. DMARC publica cómo tratar los mensajes que no cumplen sus requisitos de autenticación. Domain Intelligence lee esos registros y comprueba su sintaxis dentro de las reglas que admite. No autentica un mensaje concreto ni sigue los includes de SPF para evaluar un remitente. El artículo sobre SPF y DMARC explica cómo interpretar estos registros junto con los MX.

La información del perfil se refiere al dominio. No confirma que exista un buzón concreto, que su titular quiera recibir correo ni que un mensaje llegue a la bandeja de entrada. Domain Intelligence no abre sesiones SMTP ni envía mensajes.

Consulte las redes del correo y la web

Las consultas estándar y ampliada muestran las direcciones IP públicas de los servidores de correo y del dominio solicitado. También incluyen los alias DNS que se han seguido para resolver el dominio, conocidos como cadena CNAME. Cada IP se asocia, cuando es posible, con un sistema autónomo: una red identificada por un número ASN. Puede consultar el nombre, el país de registro y el tipo de red, como alojamiento o proveedor de internet, y comparar la infraestructura del correo con la de la web.

Si Emvero reconoce una red de distribución de contenidos (CDN) o un proxy, lo indica en el perfil. Las IP pueden pertenecer a ese intermediario y ocultar el servidor de origen. El país mostrado es el de registro del sistema autónomo; no permite localizar el servidor. La consulta obtiene las IP del DNS, pero no comprueba si la web responde.

Añada datos de registro con la consulta ampliada

La consulta ampliada añade los datos que el registro del dominio facilita mediante RDAP, un protocolo de consulta de datos de registro. Cuando están disponibles, muestra la fecha de registro, la antigüedad en días, la caducidad, el registrador y los estados del dominio en el registro. Si consulta un subdominio, estos datos corresponden al dominio principal que lo contiene, es decir, al dominio registrable.

La antigüedad se calcula a partir de la fecha de registro. No indica cuánto tiempo llevan existiendo la empresa o la web, ni desde cuándo el dominio pertenece a su titular actual. Algunos registros no ofrecen RDAP o no facilitan la fecha. Cuando falta un dato, el perfil muestra el motivo.

Distinga un perfil completo de un dato conocido

Cada parte del perfil muestra su fuente, su estado y las fechas de observación disponibles. Un valor puede ser desconocido, no estar disponible o haber quedado desactualizado. Revise el campo que vaya a utilizar: los datos de un mismo perfil no tienen por qué haberse obtenido al mismo tiempo.

Un perfil completo significa que se han completado las observaciones necesarias para la modalidad elegida. El proveedor o el comportamiento catch-all pueden seguir siendo desconocidos, y la ruta puede indicar que el dominio no acepta correo. El estado «completo» no es una valoración de la fiabilidad del dominio.

Los datos de red tienen su propio estado y no determinan si el perfil está completo ni cuánto cuesta. En la consulta ampliada, la falta de la fecha de registro da lugar a un perfil parcial. Si falla la fuente necesaria para establecer la ruta de correo, el servicio devuelve un error en lugar de concluir que el dominio no recibe correo.

La guía sobre cómo interpretar un perfil de dominio recorre un ejemplo y explica qué información aporta cada campo al revisar el dominio de un cliente.

Haga una consulta desde su cuenta

Cree una cuenta o inicie sesión y abra Domain Intelligence. Introduzca el dominio que quiera consultar; example.com se usa aquí solo como ejemplo. Elija la modalidad estándar para consultar la configuración de correo y las redes, o la ampliada para añadir los datos de registro.

Ambas modalidades consumen créditos del mismo saldo que la verificación de correo. Al repetir una operación ya guardada, no se añade otro cargo; el coste que figura en el perfil sigue siendo el de la operación original. Si el servicio no puede confirmar un cargo, su importe queda pendiente de confirmar: no debe interpretarse como cero.

Para obtener estos datos desde su backend, use la API Domain Intelligence. La página de la API describe el mismo perfil, los campos de facturación y cómo reintentar una consulta de forma segura.