El análisis de dominios para correo reúne datos sobre su configuración de correo, su infraestructura de red y, cuando están disponibles, su registro. Puede ayudarle a investigar el dominio de un cliente o a añadir contexto técnico a una ficha del CRM. Cada observación responde a una pregunta distinta: adónde va el correo, qué política de envío está publicada, qué red anuncia una dirección IP o cuándo se registró el dominio.
Interprete cada dato por separado antes de tomar una decisión. Una ruta de correo válida no demuestra que exista un buzón concreto, y un registro antiguo no demuestra que su usuario actual sea de confianza. Domain Intelligence de Emvero recoge datos de infraestructura sin abrir una sesión SMTP ni enviar correo.
Empiece por la ruta de correo entrante
Compruebe si el dominio tiene una ruta para recibir correo. En un perfil de Emvero, mail_routing.status puede indicar routable. Esto confirma una ruta en la configuración DNS observada; no comprueba un destinatario.
Los registros MX identifican los hosts que reciben el correo. La coincidencia con un proveedor describe al operador visible de la ruta entrante, que puede ser una pasarela de filtrado situada delante del servicio de buzones. Si mx.provider_match es unknown, conserve el proveedor como desconocido. Un nombre de host poco familiar no demuestra que la organización aloje su propio correo. La guía específica explica cómo identificar al proveedor de correo a partir de los registros MX.
Una respuesta MX vacía necesita otra comprobación: si no hay MX, SMTP permite una ruta implícita hacia la dirección del propio dominio. RFC 5321 describe esta alternativa. Los casos de diagnóstico se explican en el artículo sobre un dominio sin registro MX.
Interprete la configuración de envío y las clasificaciones
Los campos SPF y DMARC describen lo que el dominio publica sobre el envío de correo. En Domain Intelligence, not_performed significa que no se ha evaluado la autenticación de ningún mensaje. La consulta comprueba la sintaxis admitida y los campos de política publicados; no sigue los includes de SPF para evaluar un remitente ni busca claves DKIM. La comparación de SPF y DMARC explica cómo se relacionan estos mecanismos con un mensaje.
Las clasificaciones de email.classification proceden de datos de referencia. Que un dominio no aparezca en una lista de correo desechable no demuestra que sea seguro. Tampoco un indicador negativo de proveedor público demuestra que la dirección sea corporativa.
El campo email.catch_all.state muestra datos ya almacenados sobre el dominio. Esta consulta no realiza un nuevo sondeo del destinatario. El valor unknown no permite registrar ni «acepta todos los destinatarios» ni «comprueba cada buzón».
Identifique a qué corresponden los datos de red y registro
Tanto standard como extended incluyen información de red. network.mail describe las direcciones de los hosts de correo; network.web, las direcciones resueltas para el dominio consultado y la cadena CNAME seguida hasta ellas. El número de sistema autónomo, o ASN, identifica la red que anuncia una dirección.
Estos datos permiten comparar infraestructuras. Las direcciones de correo y del sitio web pueden compartir red aunque tengan funciones distintas. El campo de país indica dónde está registrado el sistema autónomo, por lo que no permite localizar un servidor. Si aparece una CDN o un proxy, sus direcciones de borde pueden ocultar el servidor de origen. Resolver una dirección tampoco demuestra que allí responda un sitio web.
La variante extended añade datos de registro obtenidos mediante RDAP, el protocolo de acceso a datos de registro. RDAP distingue eventos como el registro y los cambios posteriores, cada uno con su fecha. RFC 9083 define estos campos de eventos.
Revise registration.registered_domain antes de usar la antigüedad. Al consultar un subdominio, el registro corresponde a su dominio padre registrable. registration.age_days cuenta los días completos desde la fecha de registro indicada hasta generated_at. No dice cuándo se fundó la empresa, cuándo se publicó su web ni cuándo adquirió el dominio su titular actual. Algunos registros no facilitan la fecha. Mantenga visible esa ausencia en vez de guardar una antigüedad de cero.
Un ejemplo de lectura del perfil
Supongamos que revisa example.com antes de añadir datos técnicos a la ficha de un cliente. Los valores siguientes proceden de un ejemplo sintético, no de una consulta real. Son observaciones seleccionadas, no una respuesta completa de la API.
| Observación | Qué puede registrar |
|---|---|
mail_routing.status: routable |
La configuración observada ofrece una ruta de correo entrante. |
mx.provider_match: unknown |
No se ha identificado un único proveedor de correo entrante. |
email.catch_all.state: unknown |
No se ha determinado el comportamiento catch-all. |
| Las direcciones IP de los hosts de correo incluyen AS64500 y AS64511; las del sitio web incluyen AS64500 | Algunas direcciones de correo y del sitio web comparten red. Esto no identifica a un operador de servicio común. |
registration.age_days: 2191 |
El registro indicado tiene 2191 días completos en el momento de generar el ejemplo. |
SPF -all; DMARC reject |
Son ajustes de envío publicados, no resultados de autenticación de un mensaje. |
El perfil aporta datos de infraestructura útiles, pero no permite sacar una conclusión sobre alex@example.com. Si necesita pruebas sobre esa dirección al dar de alta al cliente, compruébela por separado. La comparación entre verificación completa y comprobación de dominio explica qué puede determinar cada profundidad. Si importa quién controla el buzón, hace falta además una confirmación del usuario. Una comprobación técnica no acredita el consentimiento para recibir sus mensajes ni garantiza que lleguen a la bandeja de entrada.
Para esta revisión, podría guardar la ruta y la antigüedad del registro, dejando como desconocidos el proveedor y el estado catch-all. Un dominio registrado hace poco podría justificar una pregunta adicional según sus propias reglas. La antigüedad del registro, por sí sola, no justifica aceptar o rechazar a un cliente.
Revise el campo que necesita aunque el perfil esté completo
complete indica que se han completado las observaciones necesarias para la variante elegida. Un perfil completo puede contener un proveedor o un estado catch-all desconocidos, o determinar que un dominio no acepta correo. Los datos de red no determinan ese estado general, así que revise sus propios metadatos.
Un perfil extended es partial cuando no está disponible la fecha de registro. Eso no elimina los datos útiles sobre la ruta de correo. En cambio, si falla la propia fuente de la ruta, el servicio puede devolver un error. Un fallo de DNS no demuestra que el dominio no reciba correo.
Antes de usar un campo, revise meta.status y reason, y después los valores disponibles de source, source_version, observed_at, expires_at y stale. Un perfil generado ahora puede contener observaciones anteriores. La documentación de Domain Intelligence describe estos campos.
Hay dos fechas de caducidad con significados distintos: registration.expires_at es la fecha de caducidad del dominio según el registro, mientras que registration.meta.expires_at indica hasta cuándo puede reutilizarse la observación de registro guardada en caché. Ninguna señala cuándo dejará de funcionar el buzón del cliente.
Guarde los datos y la decisión por separado
En una integración con el CRM, conserve el dominio consultado, los campos que usa su proceso y sus fechas de observación. Mantenga el perfil de dominio separado del resultado de verificación de la dirección de un contacto. Si varios contactos comparten dominio, el perfil aporta contexto común sin implicar que todos sus buzones funcionen.
Guarde también por separado la decisión y su motivo. Así podrá revisar una ficha cuando cambien los datos, sin convertir una etiqueta antigua de proveedor o una fecha de registro ausente en un juicio permanente sobre el cliente. Su integración escribe estos registros; la consulta no actualiza el CRM automáticamente.
Si repite una consulta API ya completada con el mismo Idempotency-Key, dominio y variante dentro del plazo de repetición, recibirá la respuesta guardada. Esto no actualiza las observaciones. Siga la guía de la API Domain Intelligence para gestionar reintentos y consultas nuevas.
Para leer un perfil sin crear una integración, consulte un dominio con Emvero. Empiece por la ruta de correo y revise después los campos que respondan a la pregunta que necesita resolver.