Preguntas frecuentes

echo.email analiza un correo por dirección y explica el resultado. Las respuestas de abajo explican cómo funciona el servicio y qué significa cada comprobación del informe.

¿Cómo funciona echo.email?

La página de inicio te da una dirección nueva formada por tres palabras, como power.file.tube@echo.email. Un mensaje enviado a esa dirección llega al servidor de correo de echo.email, que registra la conversación SMTP y pasa el mensaje al análisis. Unos segundos después, la página muestra un informe sobre autenticación, contenido, cumplimiento y entrega. No hay nada que instalar y no existen cuentas.

¿Cuánto tiempo sigue siendo válida la dirección?

La dirección sigue activa mientras la página esté abierta. La página se comunica con el servidor cada dos segundos, y si recargas en menos de 10 minutos, conservas la misma dirección en la misma pestaña. Cuando la página lleva cerrada más de 10 minutos, el servidor de correo rechaza el correo nuevo para esa dirección con un error permanente.

Solo cuenta el primer mensaje que llega. Los mensajes posteriores a la misma dirección se rechazan, así que cada informe corresponde a un solo correo. Los mensajes de más de 10 MB se rechazan durante la conversación SMTP.

¿Cuánto tiempo se guardan los informes?

Cada informe, el mensaje guardado y los datos de imagen descargados se eliminan automáticamente 24 horas después de que llegue el mensaje. Durante esas 24 horas, el enlace al informe funciona para cualquiera que lo tenga. Después, el enlace deja de funcionar. La única excepción es el informe de ejemplo, porque procede de un mensaje de prueba enviado para ese fin.

¿Qué pasa con el contenido del mensaje?

echo.email guarda el mensaje completo, es decir, cabeceras, cuerpo y adjuntos, junto con los datos de la sesión SMTP, como la dirección IP de envío, el nombre HELO y la versión de TLS. Los datos se almacenan en la UE, y el servidor de correo funciona en Falkenstein, Alemania. Cualquier persona con el enlace al informe ve el mensaje completo, así que para las pruebas conviene usar contenido que puedas compartir. Los boletines suelen llevar enlaces de seguimiento y un enlace para darse de baja ligado a un destinatario. Si envías una copia a una lista de prueba, esos enlaces siguen siendo privados.

Dos direcciones llegan directamente al responsable del servicio: contact@echo.email para preguntas y avisos, y privacy@echo.email para solicitudes sobre datos. La política de privacidad tiene todos los detalles.

¿Qué comprueba la verificación SPF?

SPF enumera los servidores autorizados a enviar correo con un dominio en el return path. echo.email toma el dominio del remitente del sobre (la dirección MAIL FROM, también llamada return path) y evalúa el registro SPF de ese dominio frente a la dirección IP del servidor que entrega el mensaje. Solo un pass cuenta como buen resultado. Con softfail, neutral o none, el receptor no tiene prueba SPF del remitente.

El nombre HELO no se comprueba, igual que hacen los grandes proveedores de correo al evaluar SPF en el correo masivo. El informe muestra cada registro y cada mecanismo del recorrido, para que el camino hasta el resultado final quede a la vista.

¿Por qué importa el número de consultas DNS?

Una evaluación SPF admite como máximo 10 consultas DNS. Los mecanismos include, a, mx, ptr, exists y redirect cuentan cada uno para el límite, también los que están dentro de includes anidados. Si se supera el límite, el resultado pasa a ser un error permanente, y los receptores tratan el mensaje como si no tuviera ningún SPF válido. Las consultas vacías, es decir, las que no devuelven ningún registro, tienen un límite propio de dos. La causa habitual son las cadenas largas de includes de terceros, y reducir la lista de servicios resuelve el problema.

¿Qué demuestra DKIM?

DKIM añade una firma criptográfica a las cabeceras del mensaje. El dominio firmante publica la clave pública en el DNS bajo un selector. echo.email obtiene la clave y verifica la firma frente a las cabeceras y el cuerpo tal como llegaron. Un pass significa que las partes firmadas llegaron sin cambios y que el dominio firmante responde por ellas.

El informe muestra el dominio firmante (d=), el selector (s=), las cabeceras firmadas (h=) y el tipo y tamaño de la clave. Un límite de longitud del cuerpo (l=) se marca, porque permite añadir contenido después de la firma.

¿Qué es DMARC?

DMARC vincula SPF y DKIM al dominio de la dirección From visible. El dominio From publica una política en _dmarc.<domain> que indica a los receptores cómo tratar el correo que falla la autenticación: none, quarantine o reject. Un mensaje pasa DMARC cuando SPF o DKIM pasan para un dominio alineado con el dominio From.

DMARC no añade ninguna autenticación propia. Su valor está en el requisito de alineación y en los informes agregados (rua=) que los receptores envían al propietario del dominio.

¿Qué significa alineado?

La alineación compara un dominio autenticado con el dominio From. La alineación flexible exige el mismo dominio organizativo, así que mail.example.com está alineado con example.com. La alineación estricta exige exactamente el mismo nombre de host. El dominio organizativo sale de la Public Suffix List, que sabe que nombres como example.co.uk cuentan como un único dominio registrable. Cuando el informe dice alineado sin más detalle, la comparación es con el dominio From.

¿Qué es BIMI?

BIMI publica un logotipo de marca para que los proveedores de correo lo muestren junto al correo autenticado. El registro está en default._bimi.<domain> y apunta a un logotipo SVG (l=) y, para la mayoría de los proveedores, a un Verified Mark Certificate (a=). BIMI solo se aplica a dominios con una política DMARC aplicada, es decir, quarantine o reject al 100 por ciento. echo.email muestra el registro y si la política DMARC cumple el requisito.

¿Por qué importa el DNS inverso?

Cada dirección IP que envía correo necesita un registro PTR que apunte a un nombre de host, y ese nombre necesita un registro A o AAAA que apunte de vuelta a la misma dirección IP. Este recorrido de ida y vuelta se llama forward-confirmed reverse DNS, o FCrDNS. Los grandes proveedores de correo consideran el FCrDNS el mínimo para un servidor de envío, y el correo de una dirección IP sin registro PTR a menudo se rechaza directamente.

¿Qué es un DNS inverso genérico?

Algunos registros PTR siguen un patrón de nombres del proveedor de acceso, como 192-0-2-10.dynamic.example.net. Estos nombres sugieren una conexión doméstica o un servidor que nadie configuró para el correo, y los filtros desconfían de ellos. Un nombre propio en el dominio del remitente, como mail.example.com, indica un servidor de correo configurado a propósito.

¿Qué nombre HELO funciona mejor?

El servidor de envío se presenta con un nombre HELO o EHLO al empezar la conversación SMTP. Un buen nombre pertenece al servidor de envío, se resuelve en el DNS y coincide con el registro PTR de la dirección IP de envío. Las direcciones IP sin nombre, los nombres como localhost y las cadenas aleatorias son típicos del malware y del spam snowshoe, y los filtros los valoran en consecuencia.

¿Por qué comprobar TLS?

El TLS oportunista cifra la conversación SMTP cuando el servidor receptor ofrece STARTTLS. echo.email ofrece STARTTLS en cada conexión y registra la versión de TLS y el cifrado que eligió el remitente. El correo enviado sin TLS viaja en texto plano entre los dos servidores, y Google y Yahoo exigen TLS a los remitentes masivos. El informe también cuenta los enlaces e imágenes cargados por http simple, porque esas solicitudes también viajan sin cifrar.

¿Por qué comprobar IPv6?

Dos preguntas deciden si un mensaje está preparado para IPv6. La primera es si el remitente llega a servidores de correo que solo tienen IPv6. Un mensaje que llega por IPv6 responde que sí directamente. Un mensaje que llega por IPv4 cuenta igualmente como compatible con IPv6 cuando el host de envío tiene un registro AAAA, el DNS inverso de esa dirección IPv6 nombra al mismo host y SPF pasa para esa dirección. La mayoría de los servidores de correo eligen IPv4 o IPv6 en cada conexión, así que el siguiente mensaje del mismo host suele llegar por IPv6. La segunda pregunta es si cada host que sirve imágenes y enlaces del mensaje tiene un registro AAAA, para que un lector en una red solo IPv6 o detrás de un NAT de operador (CGNAT) pueda cargar el contenido. El informe marca el mensaje como preparado para IPv6 cuando las dos respuestas son sí.

¿Cómo se mide el tamaño del correo?

El tamaño del correo es el número de bytes tal como se transmitieron: todas las cabeceras, cada parte MIME, los adjuntos y el exceso que añade la codificación base64 o quoted-printable. Gmail recorta los mensajes con más de unos 102 KB de HTML y oculta el resto tras un enlace. La parte recortada suele contener el enlace para darse de baja y el píxel de seguimiento.

¿Qué es el peso de las imágenes?

El peso de las imágenes es el tamaño total de las imágenes remotas referenciadas en etiquetas <img>, medido descargando cada imagen una vez. La cifra es un mínimo, porque no cuenta las imágenes de los atributos srcset ni los fondos CSS. Un mensaje pesado carga despacio en conexiones móviles y consume datos del lector.

¿Qué es el exceso en las imágenes?

El exceso en las imágenes estima los bytes que un remitente ahorraría sirviendo cada imagen más cerca del tamaño con el que se muestra en el mensaje. Una imagen de hasta el doble de su tamaño mostrado cuenta como exceso cero, porque las pantallas de alta densidad aprovechan esos píxeles extra. Por encima del doble, los píxeles extra añaden bytes sin añadir detalle. Las imágenes de menos de 1 KB, como los espaciadores, no entran en la cifra.

¿Cómo trata echo.email las imágenes?

El análisis descarga una vez cada imagen remota y registra el estado HTTP, las redirecciones, el tamaño, el tipo de contenido y las dimensiones en píxeles. Después compara esas dimensiones con el tamaño declarado en el HTML. Descargar una imagen es lo que hace un cliente de correo cuando un lector abre el mensaje, así que el seguimiento de aperturas registra una apertura. Las descargas salen de la red de Cloudflare, y las solicitudes a direcciones privadas o internas se rechazan.

Los enlaces se extraen del HTML y se agrupan por host, con los parámetros de la consulta decodificados para leerlos mejor. echo.email nunca sigue los enlaces normales, porque seguir un enlace puede confirmar una suscripción, activar una acción o registrar un clic. La única excepción es la URL de cancelación con un clic que se describe más abajo.

¿Qué es List-Unsubscribe?

List-Unsubscribe es una cabecera definida en la RFC 2369. La cabecera contiene una o varias formas de salir de la lista, como una dirección mailto:, una URL https: o ambas. Los proveedores de correo usan la cabecera para mostrar su propio botón para darse de baja junto al nombre del remitente. Las URL con http simple están anticuadas, y lo esperado es https.

¿Qué es la cancelación de suscripción con un clic?

La RFC 8058 añade una segunda cabecera, List-Unsubscribe-Post, con el valor fijo List-Unsubscribe=One-Click. Con las dos cabeceras presentes, el proveedor de correo envía una solicitud POST a la URL https y el destinatario sale de la lista sin visitar ninguna página web. Google y Yahoo exigen la cancelación de suscripción con un clic a los remitentes masivos.

echo.email envía la misma solicitud POST y muestra la respuesta. Cualquier estado 2xx cuenta como éxito. La solicitud solo da de baja la dirección temporal de echo.email.

¿Qué significa cancelar la suscripción sin interacción?

Una cancelación sin interacción se completa sin que el destinatario abra un navegador ni confirme nada. El one-click de la RFC 8058 es el método preferido. Una dirección mailto: en List-Unsubscribe también cuenta, aunque darse de baja por correo es más lento y no da confirmación al destinatario, así que los proveedores tratan mailto como una alternativa de reserva.

¿Por qué sigue haciendo falta un enlace para darse de baja dentro del mensaje?

Las leyes de marketing de la mayoría de los países exigen una forma visible de salir de la lista dentro del propio mensaje, normalmente un enlace en el pie. Las cabeceras sirven al proveedor de correo, y el enlace del pie sirve al lector. echo.email busca un enlace con un texto para darse de baja o una URL que lo parezca. La detección es heurística y a veces elige el enlace equivocado. Un parámetro de seguimiento propio en el enlace del pie permite distinguir en las estadísticas del remitente las cancelaciones desde el pie y desde la cabecera.

¿Qué es List-Id?

List-Id (RFC 2919) da nombre a la lista de correo a la que pertenece un mensaje, por ejemplo News <news.example.com>. Google y Yahoo no exigen esta cabecera. Los servidores receptores y los destinatarios la usan para ordenar y filtrar el correo por flujo de envío, así que añadirla es una buena práctica.

¿Qué es la lista de buenas prácticas?

La lista sigue los requisitos que Google y Yahoo publicaron en 2024 para los remitentes masivos: SPF alineado, DKIM alineado, DNS inverso con confirmación directa (FCrDNS), TLS, un dominio From que no sea de un proveedor de correo gratuito y que no falle DMARC, una política DMARC publicada, al menos un método de autenticación alineado, cancelación de suscripción con un clic y un enlace visible para darse de baja. Cada fila dice sí o no. Una fila en rojo es una causa probable de peor colocación en la bandeja de entrada de los grandes proveedores, y la puntuación completa es la base para el correo masivo.

Algunas filas solo cuentan cuando se aplican. Las dos filas de cancelación de suscripción cuentan cuando el mensaje lleva una cabecera de envío masivo: List-Unsubscribe, List-Unsubscribe-Post, List-Id o Precedence con el valor bulk, list o junk. En un mensaje personal sin ninguna de ellas, esas filas no cuentan. La alineación SPF queda fuera de la puntuación cuando el remitente del sobre se reescribió con SRS y DMARC pasa con DKIM alineado. Tras una reescritura SRS, SPF comprueba el dominio del servidor que reescribió la dirección en lugar del dominio From. Los servicios de reenvío usan SRS por diseño, y algunos servidores de envío aplican SRS a todo el correo saliente, con lo que pierden la alineación SPF. La puntuación muestra cuántas de las filas contadas se cumplen.

¿Cómo se muestra el mensaje?

La vista renderizada muestra la parte HTML dentro de un marco aislado (sandbox). El navegador hace el renderizado, así que el resultado se parece a un navegador de escritorio y no a un cliente de correo o dispositivo concreto. Los scripts, formularios y enlaces están desactivados en la vista previa. Otras vistas muestran el mensaje con las imágenes bloqueadas y con el texto alternativo en lugar de cada imagen, que es como muchos lectores ven un mensaje por primera vez.

¿Qué muestra la sección MIME?

MIME es la estructura interna de un mensaje: las partes, sus tipos de contenido, juegos de caracteres, codificaciones de transferencia y los delimitadores que las separan. Un boletín típico tiene un contenedor multipart/alternative con una parte text/plain y una parte text/html. Una parte de texto que falta, un delimitador de cierre que falta o un anidamiento poco habitual se ven en el árbol.

¿Qué muestra la sección Mensaje en bruto?

La sección Mensaje en bruto muestra el mensaje tal como llegó, con estadísticas: tamaño total, número de líneas, la línea más larga, caracteres fuera de ASCII y saltos de línea sin CR. La RFC 5322 limita una línea a 998 caracteres, y algunos servidores cortan o rechazan las líneas más largas. Los saltos de línea sin retorno de carro (CR) son una causa frecuente de fallos DKIM, porque los servidores del camino los reescriben.

La vista del mensaje en bruto empieza con las cabeceras de traza que mx.echo.email registra en la entrega: Return-Path, Authentication-Results, Received-SPF y Received. Debajo está el mensaje exactamente como llegó, y el enlace de descarga ofrece el archivo .eml sin cambios.

¿Qué listas de bloqueo revisa el informe?

Los receptores consultan la dirección IP de envío y los dominios del remitente en listas de bloqueo DNS, y aparecer en una lista muy usada lleva a que el correo se rechace o se filtre. El informe revisa las mismas listas que scan.mx: Spamhaus ZEN y AuthBL para la dirección IP, Spamhaus DBL y ZRD para el dominio From y el del sobre, además de SpamCop, GBUdb Truncate y PSBL para direcciones IPv4. Cada fila dice listado o no listado, con un enlace a la página del operador de la lista para solicitar la exclusión.

Un listado por política en Spamhaus PBL marca un rango de direcciones que no debe enviar correo directamente, como una conexión doméstica. El correo de una dirección así debe salir por el servidor de correo del proveedor. Los resultados se guardan en caché durante dos horas, así que una corrección se ve en una prueba nueva como mucho dos horas después.

¿Qué significa la puntuación de SpamAssassin?

SpamAssassin es un filtro antispam de código abierto que muchos servidores receptores utilizan. El servidor de correo puntúa cada mensaje de prueba con SpamAssassin y sus reglas estándar, que se actualizan a diario. El informe muestra el total, el umbral de spam de 5 y cada regla que coincidió, empezando por las de más puntos. Los puntos negativos cuentan a favor del mensaje, por ejemplo por una firma DKIM válida.

Las pruebas de red consultan la dirección IP de envío y los dominios de los enlaces en Spamhaus (a través de DQS), URIBL, SURBL y las demás listas de las reglas estándar. El aprendizaje bayesiano y las redes de hashes compartidos Razor, Pyzor y DCC están desactivados, así que la puntuación depende solo del mensaje y nada del mensaje sale del servidor para aprendizaje.

La puntuación es orientativa y no cuenta para la puntuación de buenas prácticas. Cada receptor usa su propio filtro con sus propias reglas y umbrales, y Gmail y Outlook no usan SpamAssassin. Una puntuación por encima de cero es normal. Las reglas con más puntos muestran dónde un cambio ayuda más. Los mensajes de más de 500 KB no se puntúan.

¿Por qué los dominios del remitente necesitan servidores de correo?

Las respuestas van al dominio From, y los rebotes van al dominio del remitente del sobre. Los dos necesitan un registro MX, o al menos un registro de dirección, que los servidores de correo usan como alternativa. Un null MX, un único MX que apunta a un punto (RFC 7505), declara que un dominio no acepta ningún correo, y algunos receptores rechazan los mensajes de un dominio así.

¿Qué elementos HTML se consideran de riesgo?

Los scripts, formularios, iframes, objects y embeds casi nunca tienen sitio en un correo. La mayoría de los clientes de correo los eliminan, y los filtros antispam los puntúan como señal de phishing. Los enlaces e imágenes normales hacen el mismo trabajo sin esa penalización. La sección de contenido también muestra el tamaño del HTML y cuánto texto visible contiene, porque un mensaje hecho casi solo de marcado o imágenes resulta sospechoso para los filtros.

¿Por qué se marcan los acortadores de enlaces?

Los acortadores públicos como bit.ly ocultan el destino real. Las campañas de phishing los usan mucho, así que los filtros desconfían de los enlaces que pasan por ellos. Los enlaces que apuntan directamente al dominio del remitente, en cambio, construyen reputación.

¿Qué muestra la sección DNS?

Cada consulta DNS hecha para el informe aparece en la sección DNS, agrupada por finalidad: DNS inverso, SPF, DKIM, DMARC, BIMI, servidores de correo y la comprobación de IPv6. Las consultas a listas de bloqueo no aparecen, porque sus nombres de consulta llevan una clave de acceso. Cada entrada muestra el nombre, el tipo de registro, el código de respuesta, las respuestas con su TTL y los registros de autoridad, si los hay. La lista muestra qué registros produjeron cada resultado, lo que ayuda cuando un cambio reciente de DNS aún no ha llegado a todos los resolvers.

Más herramientas gratuitas

scan.mx
Comprueba la configuración de correo de un dominio: MX, SPF, DKIM, DMARC, BIMI.
portscan.com
Comprueba qué puertos TCP están abiertos en una dirección IP, incluido el puerto 25.