Cómo validar dominios de empresas antes de enriquecer una lista B2B

El dominio corporativo suele ser una llave más estable que el nombre escrito de la empresa. Ayuda a deduplicar cuentas, buscar personas y relacionar señales. Pero una URL bien formada no demuestra que la marca siga operando, que el sitio le pertenezca o que el dominio reciba correo.

Antes de pagar enriquecimiento, separa tres preguntas. ¿Cuál es el dominio registrable correcto? ¿La identidad web coincide con la compañía de la lista? ¿El dominio tiene una ruta técnicamente plausible para recibir email? Cada pregunta necesita evidencia distinta.

Este gate ocurre antes de validar una dirección individual. Resolverlo reduce dos errores caros: enriquecer a la empresa equivocada y descartar una cuenta correcta por interpretar mal DNS. La limpieza de strings ayuda; la validación exige contexto.

Guarda source_url exactamente como llegó y extrae source_hostname con un parser de URL, no cortando texto por puntos o diagonales. Deriva hostname_normalized en otro campo: convierte mayúsculas a minúsculas, elimina un punto final de DNS cuando exista y aplica manejo IDNA. No borres www del hostname; el dominio registrable calculado después permite agruparlo sin perder esa evidencia.

No sobrescribas el origen. Si una fila llegó como https://mx.ejemplo.com/contacto?ref=expo, la evidencia original permite entender por qué elegiste ejemplo.com y revisar el dato cuando algo cambia. Una columna limpia sin procedencia es cómoda hasta que dos proveedores discrepan.

Elimina de esta etapa correos, perfiles sociales, URLs de mapas y marketplaces. linkedin.com o instagram.com describen dónde viste a la empresa, no su dominio corporativo. Conserva esas URLs como fuentes, nunca como account key.

La regla de tomar las últimas dos etiquetas falla en dominios como empresa.com.mx o firma.co.uk. Public Suffix List define la parte que no controla el registrante y permite calcular el eTLD+1, una aproximación operativa al dominio registrable. Sirve como llave de agrupación; no prueba propiedad jurídica. Para ventas en México, confundir com.mx con una empresa fusionaría cuentas que no tienen relación.

Usa una librería mantenida que consuma la lista, en lugar de copiar una tabla fija. El proyecto Public Suffix List indica que su copia se actualiza con frecuencia desde GitHub. Tu pipeline no necesita descargarla en cada fila; sí necesita una versión identificable y actualización periódica.

Conserva también el hostname completo. app.empresa.com y www.empresa.com pueden compartir cuenta, mientras una plataforma alojada bajo un sufijo privado podría requerir otra interpretación. Domain_registered sirve para agrupar; hostname sirve para investigar la ruta exacta.

Abre la página final después de redirects y registra final_url, código HTTP, título, nombre visible, idioma y fecha. Busca coincidencias con razón social, marca, producto, país, teléfono, dirección o perfiles oficiales ya presentes en la fuente. Una sola coincidencia débil no debería aprobar una cuenta estratégica.

Los redirects necesitan clasificación. Un dominio antiguo que redirige a la nueva marca puede ser valid_redirect si el sitio explica continuidad. Un redirect hacia un marketplace, una agencia que diseñó la página o una holding sin relación explícita queda en needs_review. La redirección prueba una configuración web, no la relación corporativa que te gustaría encontrar.

Marca parked_or_for_sale cuando la página sea de estacionamiento, venta o publicidad genérica. Marca inactive_web si no responde después de reintentos controlados. Ninguno de esos estados demuestra por sí mismo que la empresa dejó de existir; sí impide tratar la URL como evidencia suficiente para enriquecer automáticamente.

Consulta el estado DNS del dominio y conserva la respuesta con timestamp. NXDOMAIN indica que el nombre consultado no existe en DNS en ese momento. Un timeout o SERVFAIL es unknown_temporary: puede ser un problema transitorio del resolver o de la zona y no justifica borrar la cuenta.

Si existe un MX ordinario, hay una ruta declarada para correo entrante, aunque eso no valida ninguna dirección. Si aparece un único registro MX con preferencia 0 y destino punto —null MX—, RFC 7505 define que el dominio no acepta email. Esa es una señal explícita para no generar mailboxes en ese dominio.

La ausencia de registros MX no equivale automáticamente a dominio sin correo. RFC 5321 establece un fallback a A o AAAA cuando no existe MX, conocido como implicit MX. En la práctica puede fallar porque no haya servidor SMTP escuchando, pero el precheck debe clasificarlo como no_mx_with_address o unresolved_mail, no como dirección inválida confirmada.

Un sitio puede ser auténtico y publicar null MX porque la marca no usa ese dominio para email. Otra empresa puede recibir correo en un dominio distinto del sitio. Y un dominio con MX puede tener deshabilitada la dirección exacta que encontraste. No comprimas esas realidades en un booleano valid=true.

Después del gate de cuenta, busca direcciones públicas permitidas o enriquece mediante proveedores autorizados. Ejecuta validación de mailbox con una herramienta adecuada y conserva resultado, proveedor y fecha. No inventes patrones firstname.lastname, no envíes correos de prueba a personas para confirmar existencia y no trates catch-all como validación individual.

Si el email usa un dominio distinto, exige evidencia: una página oficial de contacto, documentación corporativa, relación de grupo o respuesta pública del proveedor. Guarda email_domain y website_domain por separado. Forzarlos a coincidir puede eliminar contactos legítimos; ignorar la diferencia puede enviar a una empresa homónima.

Para identidad de cuenta, usa estados como verified_match, verified_redirect, ambiguous_brand, marketplace_only, parked_or_for_sale, inactive_web y needs_review. Para DNS de correo, usa mx_present, null_mx, no_mx_with_address, nxdomain y dns_temporary_error. Mantener dos columnas evita declarar que una empresa es inválida solo porque su dominio no recibe email.

Añade evidence_url, evidence_type, checked_at, resolver, http_final_url y una nota breve de decisión. Conserva alias_domain cuando una marca migra y parent_account_id cuando existe una relación corporativa demostrada. El dominio ayuda a resolver identidades; no sustituye un account ID persistente. Después vincula cada estado con una acción: verified_match más mx_present puede avanzar; verified_redirect conserva el alias; null_mx detiene emails en ese dominio; ambiguous_brand o dns_temporary_error entra a revisión; parked_or_for_sale no se envía sin evidencia adicional.

Caso uno: `https://www.norte-industrial.com.mx/catalogo` resuelve a norte-industrial.com.mx, el sitio muestra la misma marca y razón social, y publica MX. Pasa a enriquecimiento. Caso dos: norteindustrial.mx redirige a la primera URL y el sitio documenta el rebranding. Se conserva como alias, no como cuenta nueva. Caso tres: una URL de marketplace tiene el nombre correcto, pero no enlaza un sitio oficial. Queda marketplace_only.

Caso cuatro: el sitio coincide con la empresa y publica un único `MX 0 .`. La cuenta puede seguir en investigación, pero ese dominio queda bloqueado para generar destinatarios. Caso cinco: el dominio no tiene MX, sí A, y el sitio coincide. Queda no_mx_with_address hasta una validación separada. Afirmar que recibe correo sería prematuro; descartarlo por completo también.

Ejecuta el gate antes del waterfall de enriquecimiento. La tabla base entrega company_name_original y source_url; una función normaliza; un servicio DNS devuelve estados; una revisión web confirma identidad; solo después los proveedores buscan personas. Esto evita pagar varias consultas sobre un dominio aparcado o una marca equivocada.

Usa domain_registered verificado para deduplicación inicial, pero conserva aliases y relaciones matriz-filial. El artículo de deduplicación enlazado al final explica por qué no conviene fusionar automáticamente marcas distintas de un grupo. Comparte account_id con todas las herramientas para que una corrección se propague sin recrear la cuenta.

Aplica TTL. DNS, redirects y sitios cambian. Revalida antes de enviar si el dato superó la ventana definida para su riesgo o si aparece una señal contradictoria. La guía de frescura enlazada propone reglas por campo; un dominio revisado hace meses no merece inmunidad por antigüedad.

Reporta cuentas recibidas, dominios registrables únicos, verified_match, redirects, marcas ambiguas, dominios aparcados, null MX, errores temporales y cuentas que avanzaron a enriquecimiento. Usa conteos y tasas con denominador visible. En un ejemplo hipotético, 8% de redirects podría ser esperable en una fuente histórica y alarmante en una lista supuestamente recién construida.

Después conecta el estado inicial con costo por cuenta enriquecida, cobertura de contactos, hard bounce rate, positive reply rate y oportunidades. No concluyas que MX causó una reunión. La utilidad del gate se prueba principalmente reduciendo desperdicio, errores de identidad y rebotes evitables.

Audita falsos positivos y falsos negativos sobre una muestra manual estratificada. Revisa casos aprobados y rechazados. Un filtro que elimina todo lo difícil puede presumir cero rebotes mientras también elimina las cuentas más valiosas. La calidad no consiste en dejar la lista impecablemente vacía.

Conserva URL original; extrae hostname; calcula dominio registrable con Public Suffix List; separa perfiles sociales; sigue redirects; confirma identidad corporativa; clasifica página aparcada; consulta DNS; detecta null MX; trata timeout como temporal; separa website_domain de email_domain; asigna account_id; guarda evidencia y timestamp; y envía ambigüedades a revisión.

Prueba la automatización con casos controlados: com.mx, co.uk, subdominio, redirect válido, redirect ajeno, null MX, sin MX con A, NXDOMAIN, IDN y timeout. Verifica que un reintento no cree otra cuenta ni cobre dos veces el mismo proveedor. Si el workflow no conserva el input original, corrígelo antes de conectarlo al CRM.

En picos.Ai construimos pipelines de listas que separan identidad, enriquecimiento, validación y envío. Si hoy tu equipo compra contactos antes de saber a qué empresa pertenece cada dominio, usa el enlace Hablemos al final de esta página. Podemos convertir una muestra real en reglas auditables y medir cuánto costo evitan antes de escalar.