Has creado una lista y enviado una campaña. Bajaron las aperturas y aumentaron los rebotes. Días después, parte del correo acaba en spam sin una causa clara. Tener una arroba y un dominio no basta, y una dirección que funcionaba hace tres meses puede haber cambiado. La fuente estima un deterioro del 2 al 3 por ciento mensual, pero no es una tasa universal. Lo que funcionaba en enero merece revisión en abril.
La verificación de listas de correo comprueba las direcciones antes del envío. Va más allá de la sintaxis y de la existencia del dominio. La fuente describe un proceso de 25 señales, con consultas MX, información SPF, heurísticas de trampas de spam y sondeos SMTP. Los registros del destinatario no verifican la alineación de tus mensajes, y las trampas no pueden identificarse de forma fiable. La puntuación ayuda a revisar riesgos, no demuestra identidad, consentimiento ni entrega.
Verificar puede formar parte de la gestión de entregabilidad, junto con consentimiento, relevancia, autenticación y seguimiento de incidencias. No sustituye esas medidas ni garantiza la reputación del dominio.
Cómo puede afectar una lista desactualizada
Google, Microsoft, Yahoo y Apple pueden evaluar rebotes, quejas y señales de interacción según sus políticas. Una lista con direcciones obsoletas puede perjudicar esos indicadores, aunque ninguna métrica explica por sí sola el filtrado.
En primer lugar, pueden aumentar los rebotes permanentes. Una respuesta 5xx no significa siempre que la dirección sea inexistente: puede expresar una restricción o un rechazo por política. Las referencias del 2 por ciento y del 5 por ciento de rebotes son orientativas, no límites universales. Clasifica los motivos y suspende nuevos intentos cuando corresponda.
En segundo lugar, existe el riesgo de trampas de spam. Operadores de redes y listas de bloqueo pueden utilizar direcciones para detectar prácticas problemáticas. Algunas son antiguas cuentas reutilizadas y otras nunca pertenecieron a una persona. Pueden aparecer en datos comprados o recopilados sin permiso, pero un verificador no puede descartarlas con certeza. El impacto depende de la trampa y del receptor; no hay una consecuencia única ni una clasificación infalible.
En tercer lugar, pueden empeorar las métricas de interacción. Las direcciones que no reciben o no desean el correo no aportan la interacción esperada. Los proveedores pueden valorar esas señales junto con otras, y las aperturas tampoco son una medida perfecta. Revisar la lista ayuda, pero no demuestra que el envío sea relevante ni elimina todo riesgo de filtrado.
Qué comprueba la verificación de listas
Una verificación puede combinar comprobaciones y señales de riesgo en lugar de limitarse a válido o inválido. La fuente presenta TrekMail con 25 controles en dos fases. Comprueba el alcance de la implementación actual antes de basarte en estos ejemplos.
Fase 1: comprobaciones básicas
En el modelo descrito, estos controles pueden marcar una dirección como inválida y asignarle puntuación cero. Se trata de una clasificación del sistema, no de una prueba universal de que ningún mensaje pueda llegar.
| Control | Qué hace | Qué considerar |
|---|---|---|
| Sintaxis | Valida según las reglas admitidas de RFC 5321 | Detecta ciertos errores de formato; comprueba qué direcciones acepta la implementación |
| Punycode y caracteres similares | Señala dominios internacionalizados y posibles confusiones visuales | Un IDN no es necesariamente malicioso y la señal no impide todo phishing |
| Dominios temporales | Compara con la referencia de 5,300+ proveedores conocidos | Guerrilla Mail, Temp Mail y Mailinator requieren evaluación según uso y política, no un juicio automático sobre la persona |
| Lista de bloqueo administrativa | Consulta los bloqueos de tu cuenta | Aplica decisiones previas que conviene revisar y documentar |
| Registros MX | Consulta DNS para localizar la ruta de correo | Sin MX explícito puede existir un MX implícito por A/AAAA; null MX indica que el dominio no acepta correo |
| IP del MX enrutable | Comprueba si la dirección es pública y utilizable | Algunos MX apuntan a 127.0.0.1 o espacio RFC 1918; valora el contexto de red |
| Supresión por rebotes | Consulta rebotes permanentes anteriores en tu cuenta | Ayuda a evitar reintentos inadecuados; no implica que el daño reputacional se duplique |
Según el modelo de la fuente, superar los siete controles lleva a la fase 2 con una puntuación inicial de 100.
Fase 2: señales y puntuación de riesgo
Los controles adicionales restan puntos o añaden indicadores informativos. La puntuación final clasifica el resultado del sistema, no identifica a una persona real.
| Control | Qué hace | Efecto descrito |
|---|---|---|
| Direcciones funcionales | Señala ejemplos como info@, support@ y admin@ | Informativo, sin penalización |
| Cadenas aparentemente aleatorias | Señala patrones como xk7q9z@, que también pueden ser legítimos | -15 puntos |
| Posibles erratas | Sugiere revisar gmial.com, outlok.com y yaho.com | -10 puntos; confirmar antes de corregir |
| Subdireccionamiento con signo más | Detecta user+tag@, un uso legítimo en servicios compatibles | -5 puntos en el modelo, no prueba de riesgo por sí mismo |
| DNSBL | Consulta Spamhaus y otras listas según disponibilidad | -30 puntos en el modelo; interpretar el alcance de cada lista |
| Antigüedad del dominio por RDAP | Consulta la fecha de registro disponible | -10 si tiene menos de 1 año, sin demostrar abuso |
| Gravatar | Comprueba si hay un perfil asociado | Informativo; no acredita identidad ni consentimiento |
| Posibles nombres | Busca nombres reconocibles en la parte local | Informativo; no demuestra que exista una persona concreta |
| Lenguaje ofensivo | Señala términos en la parte local según sus reglas | Informativo, sujeto a contexto |
| Sitio web del dominio | Comprueba si responde una web | Informativo; no demuestra legitimidad de la dirección |
| Heurística de trampas de spam | Evalúa características potencialmente sospechosas | Deducción variable, sin detección fiable de todas las trampas |
| Registro SPF | Busca el SPF publicado por el dominio | Informativo; no evalúa la alineación de tu envío |
| Registro DMARC | Busca una política publicada | Informativo; no predice la aceptación de mensajes |
| Proveedor gratuito | Señala Gmail, Yahoo y Outlook | Informativo, no un defecto de la dirección |
| Dominio en filtraciones conocidas | Contrasta con bases de datos disponibles | Informativo; no demuestra compromiso actual del buzón |
| Sondeo SMTP | Observa la respuesta del servidor al destinatario | Aceptación, rechazo o resultado incierto; catch-all y greylisting limitan la interpretación |
| Bonificación por dominio propio | Dominios no gratuitos con MX + SPF + DMARC según el modelo | +5 puntos, sin garantía de recepción ni identidad |
Categorías de puntuación
El modelo de referencia distribuye los resultados en cuatro categorías. Las etiquetas expresan una evaluación heurística, no permiso para enviar.
| Categoría | Puntuación | Interpretación | Acción que evaluar |
|---|---|---|---|
| Safe | 90 a 100 | Pocas advertencias según el modelo; no prueba un buzón real y activo | Enviar solo con permiso, relevancia, límites adecuados y seguimiento |
| Valid | 60 a 89 | Resultado favorable con señales que revisar | Comprobar permiso y monitorizar incidencias |
| Risky | 20 a 59 | Varias advertencias, no diagnóstico definitivo | Revisar o excluir según contexto |
| Invalid | 0 a 19 | Controles fallidos o penalizaciones según las reglas | Suspender el envío y revisar el motivo |
Una puntuación aporta más contexto que una etiqueta binaria, pero no decide sola el uso adecuado. Un resultado de 62 requiere revisar el motivo antes de usarlo en un boletín o en correo transaccional. Un 85 con dirección funcional tampoco demuestra permiso para una campaña B2B. Aplica consentimiento, finalidad, relevancia y las necesidades del flujo concreto.
Modo Quick y modo Deep
La fuente describe dos niveles de comprobación. Confirma su alcance actual y elige según el contexto, sin interpretar mayor profundidad como certeza.
Quick incluye los controles de la fase 1 y algunas señales de la fase 2: sintaxis, dominios temporales, MX, direcciones funcionales, patrones aleatorios, erratas, signo más y supresión por rebotes. Las consultas MX sí requieren DNS en red. La referencia indica 1 crédito por dirección y respuestas en milisegundos, pero la latencia depende del servicio. Puede servir para formularios, webhooks y revisión de listas recientes.
Deep aplica los 25 controles descritos, incluidos SMTP, DNSBL, RDAP, Gravatar, heurísticas de trampas y filtraciones conocidas, por 2 créditos según la fuente. Puede ayudar a revisar campañas y datos antiguos. Verificar una lista comprada o recopilada no aporta consentimiento ni una base legítima para usarla.
| Característica | Quick | Deep |
|---|---|---|
| Créditos por dirección | 1 según la fuente | 2 según la fuente |
| Controles descritos | Básicos y señales seleccionadas | Los 25 controles del modelo |
| Sondeo SMTP | No según el alcance descrito | Sí, con posibles resultados inciertos |
| Consulta DNSBL | No según el alcance descrito | Sí según disponibilidad |
| Antigüedad por RDAP | No según el alcance descrito | Sí según disponibilidad |
| Heurística de trampas | No según el alcance descrito | Sí, sin detección garantizada |
| Tiempo de referencia | Milisegundos, no garantizados | 1 a 3 segundos, no garantizados |
| Uso que evaluar | Formularios y revisiones rápidas | Campañas autorizadas, importaciones y auditorías |
Verificación masiva de listas
La consulta individual puede encajar en formularios e integraciones API. Para revisar 10,000 o 50,000 direcciones antes de una campaña autorizada, considera el procesamiento por lotes.
La fuente describe trabajos de hasta 50,000 direcciones mediante CSV o XLSX en el panel, o por API. También menciona deduplicación para no cobrar varias veces la misma dirección dentro del trabajo. Confirma límites, formatos y reglas de créditos actuales.
El diseño descrito utiliza tres etapas: analiza el archivo y precarga DNS por dominio único, reparte lotes mediante planificación round-robin y ejecuta comprobaciones en paralelo. Este reparto busca distribuir la capacidad entre cuentas; no garantiza tiempos iguales ni ausencia de espera.
El panel muestra progreso y distribución entre safe, valid, risky e invalid según la implementación. Al terminar, puedes exportar CSV filtrados por categoría, por ejemplo para revisar advertencias. Ningún segmento queda autorizado para envío únicamente por su etiqueta.
La fuente indica conservación de resultados durante 15 días y eliminación posterior. Verifica la política actual: esto no significa que todas las copias de seguridad, registros u otros datos se borren al mismo tiempo.
Integración por API
La API REST descrita permite consultar y solicitar verificaciones con un token bearer. Usa el alcance mínimo necesario: verify:read para resultados y verify:write para solicitudes. Comprueba permisos, plan y endpoints actuales. Los ejemplos siguientes conservan el formato de la fuente, incluido un literal de comillas dañado; no son comandos listos para ejecutar.
Verificar una dirección
curl -X POST https://trekmail.net/api/v1/verify -H "Authorization: Bearer tm_live_your_token" -H "Content-Type: application/json" -d \x27{"email": "user@example.com", "mode": "deep"}\x27La respuesta ilustrativa incluye puntuación, categoría y controles ejecutados. Una aceptación SMTP no acredita existencia del buzón ni entrega posterior:
{
"status": "safe",
"score": 95,
"mode": "deep",
"checks": {
"syntax": true,
"mx": true,
"disposable": false,
"role_based": false,
"gibberish": false,
"dnsbl_listed": false,
"domain_age_days": 365,
"smtp_status": "accepted"
}
}Enviar un trabajo masivo
curl -X POST https://trekmail.net/api/v1/verify/bulk -H "Authorization: Bearer tm_live_your_token" -H "Content-Type: application/json" -d \x27{
"emails": ["a@example.com", "b@test.com"],
"name": "March campaign cleanup",
"mode": "deep"
}\x27Según la API descrita, la solicitud devuelve un identificador de trabajo. Consulta su estado o configura un webhook compatible para conocer la finalización. Los resultados paginados y exportaciones filtradas dependen del endpoint y los permisos disponibles.
La fuente cita límites de 60 verificaciones individuales por minuto, 10 solicitudes masivas por minuto y 120 consultas de estado por minuto. Confirma los límites actuales y gestiona las respuestas de restricción.
La fuente también describe ocho herramientas MCP (Model Context Protocol) para verificar, enviar trabajos, consultar créditos y descargar resultados. El uso en Claude Desktop, Claude Code, Cursor u otros clientes depende de compatibilidad, autorización y funciones disponibles.
Cuándo revisar la lista
Una revisión puntual no garantiza que una lista siga vigente. Las personas cambian de empleo y los dominios pueden caducar. Pasar de un 95 por ciento de direcciones sin advertencias en enero a un 85 por ciento en junio es un ejemplo de la fuente, no una evolución universal.
Antes de una campaña importante. Para listas extensas y autorizadas, evalúa una revisión adecuada y el historial de envíos. La referencia del 5 por ciento de rebotes es orientativa; clasifica los motivos en lugar de atribuir automáticamente una consecuencia reputacional.
Después de un periodo sin envíos. La fuente propone revisar segmentos tras 90 días o más. Es una pauta, no un plazo universal. Confirma que el consentimiento y la relación siguen vigentes, además de la dirección.
Al importar datos externos. Compras, inscripciones en eventos, datos de socios o recopilación automática requieren revisar procedencia, autorización y finalidad. Deep no convierte una lista comprada o extraída en una lista apta para enviar correo sin consentimiento.
Al recoger la dirección. Puedes añadir una consulta a formularios o flujos de compra para detectar posibles erratas. Prueba latencia, fallos y privacidad; Quick no evita todos los datos incorrectos y un resultado incierto no debe bloquear automáticamente a una persona legítima.
De forma periódica. Ajusta la revisión mensual o trimestral a la actividad, el historial y el riesgo. Combínala con bajas, supresión y seguimiento de quejas.
Créditos y precios
La fuente describe créditos mensuales incluidos con reinicio periódico. La tabla contiene precios dañados o incompletos: se conservan para señalar el problema, no como tarifas válidas. Consulta la oferta actual.
| Plan | Precio mensual | Créditos mensuales de referencia | Funciones descritas |
|---|---|---|---|
| Free | -bash, precio dañado en la fuente | 10 | Cuenta de alojamiento de correo, según condiciones |
| Starter | Precio ausente en la fuente; verificar | 100 | Alojamiento y lectura API, según oferta |
| Pro | 0, dato no fiable como precio | 300 | API y reenvío según oferta |
| Agency | 3.25, dato no fiable como precio | 1,000 | API y referencia de 1,000 dominios; verificar condiciones |
Si necesitas más créditos, consulta las opciones del panel y la calculadora de la página del verificador de correo. El coste por volumen y los descuentos dependen de los precios vigentes.
La fuente asigna 1 crédito a Quick y 2 a Deep, con deduplicación dentro del trabajo masivo y devolución de créditos no procesados al cancelarlo. Confirma cómo se calculan y cuándo se reflejan los ajustes actuales.
Verificación dentro del alojamiento de correo
Algunos servicios de verificación de correo funcionan por separado del envío. También pueden integrarse con otros productos e incorporar historial de rebotes cuando se les facilita.
La integración del verificador en TrekMail puede simplificar el uso de datos de la cuenta. No implica que otros servicios sean incapaces de ofrecer integraciones similares.
Supresión automática por rebotes. La fuente describe incorporación de rebotes permanentes a una lista de supresión y consulta durante la fase 1. Verifica clasificación, actualización y alcance. Otros proveedores también pueden usar historial de envío mediante integraciones autorizadas.
Protección en Postfix. La fuente indica sincronización de la lista cada 5 minutos. La aplicación depende del momento y de la configuración; no es un bloqueo instantáneo de todo destinatario problemático ni garantiza mantener la reputación intacta.
El panel, la cuenta y los permisos compartidos pueden simplificar el acceso a alojamiento y verificación. Comprueba requisitos de plan, facturación y tokens; usa privilegios mínimos en cada integración.
Seguridad y privacidad
Verificar supone tratar direcciones de otras personas. Evalúa finalidad, minimización de datos, controles y condiciones del servicio.
- Cifrado TLS para API y panel según la configuración; verifica la conexión y protege los tokens.
- Eliminación automática de resultados masivos tras 15 días según la fuente; revisar registros y copias por separado.
- Eliminación bajo petición mediante API (
DELETE /api/v1/verify/bulk/{jobId}) según permisos; esta función no garantiza por sí sola cumplimiento del RGPD. - Sin almacenamiento de contenido de mensajes según el alcance descrito. El verificador analiza direcciones; revisa los demás datos tratados y las políticas actuales.
- Mitigación de señales temporales. La fuente cita un mínimo de 200ms en respuestas individuales; ese relleno no elimina todos los ataques por tiempo.
Probar el verificador
La fuente describe una demostración del verificador de TrekMail sin registro ni tarjeta. Utiliza una dirección propia o autorizada y revisa puntuación y controles. Disponibilidad y tiempo de respuesta varían; el resultado no garantiza un buzón real ni entrega.
Para una lista autorizada, consulta los créditos y planes actuales. La fuente cita 10 créditos mensuales gratuitos y Pro a 0/month con 300 créditos; el precio está dañado y no debe usarse como tarifa. Verifica API, Deep y demás funciones antes de contratar.
Revisa procedencia, permiso y vigencia de tu lista. Evalúa las direcciones antes del próximo envío.
