Tomemos un solo mensaje. Una tienda inventada, Bright Parcel, acaba de recibir el registro de un visitante con la dirección quietfox42@veylax.com, y su sistema pulsa el equivalente de Enviar en un correo de confirmación. Poco después ese mensaje está en la pantalla del visitante, y un día más tarde ya no existe en ningún lugar del servicio de bandejas. Este artículo lo sigue durante todo el recorrido.
Entonces, ¿cómo funciona el correo temporal? Usa la maquinaria ordinaria del correo de internet con un giro: el lado receptor acepta correo para cualquier nombre de usuario de sus dominios y lo guarda solo un tiempo breve. El servidor del remitente consulta en el DNS el registro MX del dominio, se conecta al equipo indicado por SMTP en el puerto 25 y entrega el mensaje. El sistema de correo temporal lo analiza, lo muestra en una bandeja y lo elimina según un calendario. En VookMail, los registros MX de los dominios apuntan a un proveedor de entrega de correo, que recibe la sesión SMTP y reenvía cada mensaje a VookMail por HTTPS.
Etapa 1: Salir del remitente
La aplicación de Bright Parcel construye el mensaje. Un mensaje es texto estructurado, dispuesto según el Internet Message Format (RFC 5322): cabeceras como From, To y Subject, luego una línea en blanco y después el cuerpo. La aplicación no suele entregarlo directamente. Se lo pasa a un servicio de correo saliente, ya sea por una conexión SMTP autenticada en el puerto 587 (o 465 con TLS desde el principio) o a través de la API web de la empresa de envío.
El primer retraso puede producirse justo aquí. Muchas aplicaciones ponen el correo saliente en una cola de trabajos y lo procesan por lotes, sobre todo las plataformas de publicidad. Así que el momento en que un sitio web dice «revisa tu correo» puede estar bastante por delante del momento en que el correo sale. En nuestro ejemplo, supongamos que la cola tarda veinte segundos. Todavía no ha llegado nada al lado del destinatario, y ningún servicio de correo temporal puede verlo ni acelerarlo.
Etapa 2: Averiguar adónde lleva veylax.com su correo
El servidor saliente lee la parte posterior a la @, en este caso veylax.com, y pregunta al DNS por los registros MX de ese dominio. Un registro MX (mail exchanger) nombra un servidor que acepta el correo del dominio. En notación de archivo de zona, así podrían verse los registros de un dominio. Los nombres son inventados para ilustrar:
example-temp.com. 3600 IN MX 10 mx1.mail-provider.example.
example-temp.com. 3600 IN MX 20 mx2.mail-provider.example.
El 3600 es el TTL (time to live), el número de segundos que un resolvedor puede guardar en caché esta respuesta. El 10 y el 20 son preferencias: los remitentes prueban primero el número más bajo y recurren al más alto si no se puede alcanzar. El nombre del equipo debe tener su propio registro A (IPv4) o AAAA (IPv6). Un registro MX debería apuntar a un nombre de equipo, y no directamente a una dirección IP ni a un alias CNAME.
Puedes hacer esta consulta tú mismo para cualquier dominio:
| Sistema | Comando |
|---|---|
| Símbolo del sistema de Windows | nslookup -type=mx example.com |
| Windows PowerShell | Resolve-DnsName example.com -Type MX |
| macOS y Linux | dig MX example.com +short |
Los sistemas antiabuso usan esta misma consulta para detectar dominios que dirigen el correo a infraestructura desechable conocida. Esa es una de las razones por las que algunos sitios web reconocen los dominios de correo temporal incluso cuando el dominio en sí es nuevo.
Dos casos límite en el DNS
Un dominio sin registro MX no es automáticamente inalcanzable. La RFC 5321, el estándar de SMTP, define una alternativa: el remitente puede tratar el propio registro A o AAAA del dominio como un equipo de correo implícito. Un dominio que no quiere recibir correo puede decirlo con un null MX (RFC 7505), que es un registro MX con preferencia 0 y un único punto como equipo. Los dominios de correo temporal publican registros MX normales, por supuesto, ya que recibir es toda su finalidad.
La caché también puede estorbar cuando un servicio añade un dominio. Los resolvedores que recibieron hace poco una respuesta de «no existe tal registro» pueden conservarla hasta que se agote el tiempo de caché negativa, controlado por el registro SOA del dominio (RFC 2308). Por eso un dominio recién creado puede tardar un tiempo en recibir de forma fiable desde todos los remitentes.
Etapa 3: La conversación entre dos servidores
El servidor saliente de Bright Parcel abre ahora una conexión TCP con el equipo MX preferido en el puerto 25. SMTP es un protocolo de texto: el cliente envía comandos y el servidor responde con respuestas numeradas. Esta es una sesión simplificada para nuestro mensaje, en la que S: es el receptor y C: es el remitente. Los equipos y la cifra de tamaño pertenecen a este ejemplo inventado.
S: 220 mx1.mail-provider.example ESMTP ready
C: EHLO out.brightparcel.example
S: 250-mx1.mail-provider.example
S: 250-STARTTLS
S: 250 SIZE 26214400
C: STARTTLS
S: 220 Ready to start TLS
(TLS handshake, then EHLO again)
C: MAIL FROM:<bounce@brightparcel.example>
S: 250 OK
C: RCPT TO:<quietfox42@veylax.com>
S: 250 OK
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: (headers, blank line, body, then a line with a single dot)
S: 250 Queued as 8F2A1C
C: QUIT
S: 221 Bye
| Comando | Finalidad | Qué significa para el correo temporal |
|---|---|---|
EHLO | Identifica al remitente y pregunta qué admite el servidor | La respuesta enumera extensiones como STARTTLS y el SIZE máximo |
STARTTLS | Eleva la conexión a TLS (RFC 3207) | Protege este salto concreto. No es cifrado de extremo a extremo |
MAIL FROM | Fija el remitente del sobre, adonde van los rebotes | A menudo difiere de la línea From visible, sobre todo en los remitentes de envíos masivos |
RCPT TO | Nombra a un destinatario | Un receptor catch-all responde 250 para cualquier nombre de usuario de sus dominios |
DATA | Inicia el contenido del mensaje | Termina con un único punto en una línea propia |
QUIT | Cierra la sesión | La entrega ya quedó decidida con el 250 posterior a DATA |
El momento en que cambia la responsabilidad
Ese último 250 es la línea más importante de la sesión. Hasta entonces, el mensaje pertenece al servidor de Bright Parcel, y si se corta la conexión lo vuelve a intentar. Después, el receptor ha aceptado la responsabilidad. El panel del remitente dirá ahora normalmente «entregado», lo que solo significa que este salto tuvo éxito. No significa que una persona haya visto nada.
Los códigos de respuesta explican buena parte del comportamiento que ve la gente:
- 2xx es éxito, y
250significa aceptado. - 3xx es un paso intermedio, y
354le dice al remitente que transmita el mensaje. - 4xx es un fallo temporal, por ejemplo
421o451. El remitente mantiene el mensaje en su cola y reintenta. - 5xx es un fallo permanente, por ejemplo
550(buzón no disponible o rechazado) o552(demasiado grande). El remitente se rinde y normalmente genera un mensaje de rebote.
La diferencia entre 4xx y 5xx explica la mayor parte del correo «lento». Si el receptor hubiera respondido 451 en este punto, quizá por greylisting (RFC 6647), nuestro mensaje estaría en la cola de Bright Parcel, ni perdido ni entregado. La RFC 5321 aconseja un intervalo de reintento de, en general, al menos 30 minutos y un tiempo de abandono de al menos cuatro o cinco días, aunque los sistemas reales fijan sus propios calendarios, y muchos reintentan antes. Por eso una confirmación puede aparecer a los pocos segundos y la siguiente a los veinte minutos, sin que nada falle en ninguno de los dos casos.
Dos conjuntos de direcciones
SMTP tiene dos capas de direccionamiento. El sobre, MAIL FROM y RCPT TO, es lo que usan los servidores para encaminar. Las cabeceras, From:, To: y Subject:, forman parte del contenido del mensaje y son lo que ves en pantalla. Pueden diferir. Un boletín puede mostrar To: subscribers aunque el destinatario del sobre fuera tu dirección temporal. Por eso un sistema receptor archiva los mensajes según el destinatario del sobre, el valor fiable. También explica por qué la cabecera Return-Path, añadida en la entrega final, registra el remitente del sobre y no la dirección From visible.
Etapa 4: Por qué quietfox42 no tenía que existir
En RCPT TO, un servidor de correo normal comprueba si el buzón existe y responde 550 si no. Un dominio de correo temporal funciona al revés. Opera como receptor catch-all, o comodín: se acepta cada parte local (lo que va antes de la @).
Esa única decisión es lo que hace posibles las direcciones instantáneas. Cuando VookMail te muestra una dirección aleatoria, no hizo falta crear nada en ningún servidor de correo. Cuando pulsas Nuevo, escribes tu propio nombre de usuario, eliges un dominio y pulsas la flecha, ese nombre ya «existe», porque el dominio acepta todos los nombres. La aplicación solo tiene que mostrarte los mensajes cuyo destinatario coincide con la dirección que tienes en pantalla.
A esos nombres se aplican dos reglas pequeñas. El estándar dice que una parte local puede distinguir mayúsculas y minúsculas, pero casi todos los sistemas reales tratan Test@ y test@ como un mismo buzón, así que un sistema de correo temporal normaliza con sensatez las mayúsculas para evitar que la capitalización del remitente parta una bandeja en dos. Y la RFC 5321 limita la parte local a 64 octetos, con un límite práctico de 254 caracteres para una dirección completa, así que los nombres generados deben quedarse muy por debajo.
Etapa 5: Del protocolo de correo a la petición web
Nuestro mensaje ya ha sido aceptado por una máquina que habla SMTP. El sitio web que muestra la bandeja es una aplicación web. Algo tiene que conectar ambas cosas.
Gestionar un servidor de correo expuesto a todo internet es trabajo de verdad: TLS, avalanchas de conexiones, colas, software malicioso y mantener una buena reputación. Por eso muchas aplicaciones modernas dejan la parte SMTP a un proveedor de entrada especializado y reciben los mensajes como peticiones web, un patrón que suele llamarse inbound parse webhook. VookMail usa este modelo. Funciona así:
- Los equipos MX del proveedor aceptan el mensaje del servidor del remitente, como en la sesión de arriba.
- El proveedor lo empaqueta, bien como código fuente MIME sin procesar o bien como campos ya analizados, como remitente, destinatarios, asunto, texto, HTML y archivos adjuntos.
- Envía ese paquete en un POST HTTPS a un punto de conexión gestionado por la aplicación de correo temporal, lo que cifra el contenido entre esos dos puntos.
- La aplicación responde con un estado de éxito. Si no está disponible o devuelve un error, un proveedor que se comporte bien reintenta según su propia política.
- La aplicación valida la petición, asocia el destinatario con una dirección y almacena el mensaje temporalmente.
| Aspecto | Receptor SMTP propio | Proveedor de entrada más HTTPS |
|---|---|---|
| Exposición | Puerto 25 abierto a todos los equipos de internet | El proveedor recibe el tráfico SMTP, y la aplicación solo ve peticiones HTTPS |
| Picos de tráfico | El operador debe dimensionar la capacidad | La infraestructura del proveedor absorbe las ráfagas |
| Análisis MIME | El operador escribe o mantiene un analizador | A menudo lo hace el proveedor, aunque aún se puede usar el código fuente sin procesar |
| Encaje con una aplicación web | Necesita un puente entre la cola de correo y la aplicación | El mensaje llega como cualquier petición a una API |
| Dependencia | Menos terceros | Depende de la disponibilidad y la configuración del proveedor |
La última fila es un coste real. Si un proveedor de entrada sufre una caída o un problema de configuración, la entrega a todos los dominios que hay detrás puede detenerse hasta que se resuelva, aunque el sitio web de correo temporal funcione con normalidad. Los mensajes rechazados con un error temporal durante ese tiempo aún pueden llegar cuando los remitentes originales reintenten, según cuánto tiempo los conserven sus colas.
Proteger el punto de conexión
Un punto de conexión webhook es una URL pública, así que cualquiera podría intentar enviarle un mensaje falsificado. Las implementaciones cuidadosas suelen combinar varias defensas:
- Verificación de firma, en la que el proveedor firma cada petición y la aplicación rechaza las que no coinciden.
- Una ruta secreta o un token que solo conocen el proveedor y la aplicación.
- Restringir las peticiones a los rangos de direcciones publicados por el proveedor, cuando existen.
- Límites de tamaño, que rechazan pronto las cargas desmesuradas para proteger la memoria y el almacenamiento.
- Idempotencia. Los proveedores reintentan, así que el mismo mensaje puede llegar dos veces, y un Message-ID o un ID de evento del proveedor evita los duplicados.
Etapa 6: Desmontar el mensaje
Lo que llega todavía no es algo que una persona pueda leer cómodamente. MIME (Multipurpose Internet Mail Extensions, RFC 2045 y siguientes) permite que un mensaje lleve varias partes en distintos formatos. Nuestro correo de confirmación podría estar organizado así, con una factura añadida como ejemplo:
| Parte | Qué contiene |
|---|---|
multipart/mixed | El contenedor exterior cuando hay archivos adjuntos |
multipart/alternative | El mismo contenido dos veces, como text/plain y text/html. El lector muestra la forma más rica que admite |
multipart/related | HTML agrupado con imágenes insertadas, referenciadas por identificadores cid: |
| Parte de archivo adjunto | Una cabecera Content-Disposition: attachment y un nombre de archivo, y luego los datos codificados del archivo |
Encima de esas partes están las cabeceras, incluidas Message-ID, Date y las líneas de rastreo Received, que registran cada servidor por el que pasó el mensaje. Si alguna vez quieres saber dónde se produjo un retraso, las marcas de tiempo de las líneas Received son el lugar donde mirar.
Un analizador también tiene que revertir varias codificaciones. Base64 transporta los archivos adjuntos binarios y los infla en aproximadamente un tercio, así que un archivo de 10 MB se convierte en un mensaje de entre 13 y 14 MB. Quoted-printable se encarga del texto mayormente ASCII escribiendo los caracteres especiales como =XX. El valor charset= indica cómo está codificado el texto, normalmente UTF-8, lo cual importa mucho para un servicio que se usa en muchos idiomas. Y las líneas de asunto con caracteres no ASCII usan la sintaxis =?UTF-8?B?...?= o =?UTF-8?Q?...?= de la RFC 2047.
Hacer seguro el HTML para mostrarlo
El HTML del correo lo escriben desconocidos, así que un visor no debe permitir que ejecute código en el contexto del sitio web. Las implementaciones cuidadosas suelen eliminar los scripts, los atributos de manejadores de eventos y los esquemas de URL peligrosos, y mostrar el mensaje en un marco aislado para que sus estilos y su contenido no puedan afectar a la página que lo rodea.
Las imágenes remotas también requieren reflexión. Cargar una le dice a su remitente que el mensaje se abrió, que es como funcionan los píxeles de seguimiento. VookMail elimina los píxeles de seguimiento ocultos y mantiene las imágenes desactivadas hasta que las permites.
Un visor también puede hacer algo útil con el texto analizado. Para nuestro mensaje de confirmación, VookMail muestra el código de verificación o el enlace de confirmación por encima del mensaje, para que nadie tenga que desplazarse por una plantilla larga para encontrarlo.
Archivos adjuntos
Los archivos adjuntos se decodifican y se almacenan temporalmente para poder descargarlos. En VookMail, los archivos de programa habituales como .exe, .bat y .apk se rechazan, los archivos comprimidos como .zip muestran una advertencia, y se aplican tamaños máximos. Los archivos adjuntos se eliminan junto con los mensajes. Recuerda que la seguridad de un archivo no tiene nada que ver con dónde se almacenó: un documento con macros habilitadas es igual de peligroso si se descarga de una bandeja temporal.
Etapa 7: Llegar a la pantalla
Nuestro mensaje ya está almacenado, pero el navegador que muestra quietfox42@veylax.com todavía no lo sabe. Las aplicaciones web tienen varias formas de enterarse:
| Técnica | Cómo funciona | Ventajas e inconvenientes |
|---|---|---|
| Short polling | La página pregunta al servidor cada pocos segundos | Sencillo y fiable, pero genera peticiones repetidas |
| Long polling | Una petición queda abierta hasta que hay novedades o se agota el tiempo | Menos respuestas vacías, más conexiones abiertas |
| Server-Sent Events | Un flujo de larga duración del servidor al navegador | Eficiente en un sentido, se reconecta solo |
| WebSockets | Una conexión persistente en los dos sentidos | Totalmente interactiva, necesita infraestructura dedicada |
La bandeja de VookMail busca correo cada pocos segundos, y el botón Actualizar lo comprueba a mano, por ejemplo después de que tu dispositivo haya estado suspendido o se haya caído tu red. Esos pocos segundos suelen ser el tramo más corto del viaje. Si el correo parece lento, el tiempo casi siempre se ha perdido antes, en la cola del remitente o en un reintento.
Crear una dirección también pasa por una pequeña protección contra bots: un cálculo breve en el navegador del visitante, conocido como proof of work. A un visitante normal le cuesta casi nada, y encarece la creación de direcciones en masa.
La dirección también se puede abrir en otro sitio. Como la propia dirección identifica la bandeja, pasarla a otro dispositivo solo requiere pasar la dirección. El botón QR de VookMail la muestra como un código que un teléfono puede escanear, así que la misma bandeja se puede abrir allí, y las apps para Android y Huawei muestran el correo de la misma manera. Es cómodo, y también muestra por qué estas bandejas tienen poca privacidad: cualquiera que conozca o adivine una dirección puede abrir esa bandeja. Una dirección aleatoria es la opción más segura, porque es mucho más difícil de adivinar que un nombre corto.
Etapa 8: Eliminación
Un día aproximadamente después de que llegara nuestra confirmación, desaparece. La conservación en un sistema de correo temporal se suele implementar con una marca de tiempo en cada mensaje almacenado y una tarea programada que elimina todo lo que supera el límite. Los archivos adjuntos guardados como archivos aparte se van al mismo tiempo. Otros diseños usan caducidad a nivel de almacenamiento, donde la propia base de datos elimina los registros antiguos mediante un ajuste de time-to-live. Las tareas por lotes son una de las razones por las que los servicios suelen describir la caducidad como «aproximadamente» un día, ya que el momento exacto depende de cuándo se ejecute la tarea. En VookMail, los mensajes, los archivos adjuntos y las direcciones se eliminan en unas 24 horas, y el botón Eliminar te permite quitar cosas antes.
Una conservación corta cumple dos fines a la vez. Protege la privacidad, y además es una necesidad de capacidad: las bandejas desechables reciben mucho correo publicitario, y guardarlo durante mucho tiempo no serviría a nadie. Nuestra política de privacidad y la página de metodología tratan el manejo de los datos con más detalle.
Fíjate en lo que la eliminación no toca. Bright Parcel sigue teniendo la dirección en su tabla de clientes, y sus registros siguen mostrando que se «entregó». Lo único que se ha ido es la copia del lado de la bandeja.
Todo el recorrido en una tabla
| Etapa | Componente | Protocolo o mecanismo | Puerto o formato habitual |
|---|---|---|---|
| Redacción | Aplicación o cliente de correo | Mensaje RFC 5322, MIME | Texto con cabeceras y partes |
| Envío | Servicio de correo del remitente | SMTP submission o API de envío | 587 o 465 |
| Consulta de encaminamiento | Resolvedor DNS | Consultas MX, y luego A o AAAA | DNS, puerto 53 |
| Retransmisión | Del servidor del remitente al MX del destinatario | SMTP con STARTTLS oportunista | 25 |
| Recepción de entrada | Proveedor de entrega de correo | Aceptación catch-all para los dominios | Respuestas 250, 4xx, 5xx |
| Reenvío | Del proveedor a VookMail | Petición HTTPS | 443 |
| Procesamiento | Aplicación de correo temporal | Análisis MIME, saneamiento, almacenamiento | Base de datos y almacenamiento de archivos |
| Visualización | Navegador o app móvil | Comprobación cada pocos segundos, más Actualizar manual | HTTPS |
| Caducidad | Limpieza programada | Regla de conservación | Aproximadamente un día en VookMail |
Dónde entran SPF, DKIM y DMARC
Estos tres se mencionan en casi todas las conversaciones sobre correo, así que conviene ser preciso sobre dónde se sitúan en este recorrido. Todos tienen que ver con demostrar quién envió un mensaje. Ninguno decide si una dirección temporal puede recibirlo.
SPF (RFC 7208) es un registro DNS TXT que enumera los servidores autorizados a enviar usando un dominio en el remitente del sobre, y los receptores comparan con él la IP que se conecta. DKIM (RFC 6376) es una firma criptográfica que el dominio remitente añade a ciertas cabeceras y al cuerpo, verificada con una clave pública en el DNS. DMARC (RFC 7489) es una política que indica a los receptores qué hacer cuando un mensaje no supera la alineación de SPF y DKIM con el dominio From visible, y adónde enviar los informes.
Para nuestro mensaje, estas comprobaciones ocurren hacia la Etapa 3. El servidor de Bright Parcel se comprobó contra su registro SPF, y su firma DKIM se puede verificar con su clave publicada. El proveedor receptor puede usar esos resultados para señalar la suplantación. El reenvío complica un poco las cosas: una firma DKIM sobrevive mientras el mensaje no se modifique, mientras que un resultado SPF solo se refiere al último servidor que se conectó. Cuando el correo se retransmite, ARC (Authenticated Received Chain, RFC 8617) puede registrar los resultados anteriores. Al final, sin embargo, lo que hace llegar el mensaje es el registro MX y la aceptación del receptor.
Cuando un mensaje nunca aparece
Cada etapa anterior es un lugar donde un mensaje puede detenerse. Trabajar desde el extremo del remitente suele encontrar el problema más rápido.
| Etapa | Qué falló | Qué ves o qué haces |
|---|---|---|
| Antes de enviar | Una errata en la dirección | El correo fue a otro sitio o rebotó. Usa el botón Copiar |
| Salida del remitente | El mensaje está en cola, o los lotes son lentos | Uno o dos minutos es normal en algunos servicios. Espera |
| Salida del remitente | El sitio omite en silencio los dominios desechables | No llega nada. Respétalo y usa ahí una dirección permanente o un alias |
| SMTP | Una respuesta 4xx y un reintento posterior | El mensaje llega tras un retraso que puede ser de minutos o más |
| SMTP | El mensaje supera el límite de tamaño | Un rechazo 552 y un rebote al remitente |
| Proveedor de entrada | Una caída o un problema de DNS | La entrega a todos los dominios puede pausarse hasta que se resuelva |
| Bandeja | Ha pasado el plazo, o la dirección se eliminó | El mensaje llega demasiado tarde para verse |
Leer un fallo cuando eres dueño del lado emisor
Si estás probando tu propia aplicación, puedes ver mucho más que un usuario, y nuestra guía sobre el correo temporal para desarrolladores profundiza en el diseño de pruebas. Un orden sensato de comprobaciones:
- Abre los registros de correo de tu aplicación o el panel de tu proveedor de envío. ¿Se aceptó el mensaje y qué estado final muestra?
- Busca rebotes o eventos de webhook que informen de un 5xx desde el lado del destinatario. El texto posterior al código suele nombrar el motivo.
- Resuelve los registros MX del dominio del destinatario desde la red de tu servidor, con los comandos de arriba. Un problema del resolvedor ahí puede no aparecer en ningún otro sitio.
- Confirma que tu dominio de envío tiene SPF, DKIM y DMARC configurados, porque algunos receptores tratan con sospecha el correo sin autenticar.
- Envía un mensaje pequeño en texto plano para descartar un filtrado por tamaño o por contenido.
- Usa un nombre de usuario distinto en cada prueba para saber qué ejecución produjo cada mensaje.
Si un mensaje llega tarde a la bandeja, lee sus cabeceras Received de abajo arriba. Un hueco largo entre dos marcas de tiempo muestra qué salto lo retuvo, teniendo en cuenta cualquier diferencia entre los relojes de esos servidores.
¿Por qué tener muchos dominios?
VookMail te permite elegir entre más de 30 dominios. Hay motivos prácticos para eso. Quienes prueban software pueden separar proyectos o conjuntos de pruebas por dominio. Si un dominio tiene un problema de DNS o de entrega, los demás pueden seguir funcionando. Y se depende menos de un solo nombre, lo que ayuda cuando los sistemas de envío juzgan los dominios de los destinatarios además de los remitentes.
Los dominios múltiples no son una herramienta para saltarse los sitios web que rechazan deliberadamente las direcciones desechables. Si un servicio rechaza un dominio de correo temporal, está señalando que quiere un contacto permanente, y la elección correcta es tu dirección real o un alias permanente para ese servicio. El rechazo puede producirse en el formulario, mediante una lista de dominios o una consulta MX como la de la Etapa 2, o más tarde, cuando el remitente se niega a enviar.
Lo que el recorrido te dice sobre la seguridad
Tras seguir el mensaje, puedes ver exactamente hasta dónde llega cada protección.
El cifrado se aplica salto a salto. STARTTLS protege cada tramo de servidor a servidor cuando ambas partes lo admiten, y a menudo es oportunista, de modo que una conexión puede volver al texto plano salvo que una política como MTA-STS (RFC 8461) exija otra cosa. HTTPS protege los tramos de reenvío y de visualización. Nada de esto es cifrado de extremo a extremo: todos los sistemas que manejan el mensaje pueden leerlo.
El acceso es la otra mitad. Sin contraseña, conocer la dirección es lo que da entrada, así que nunca dejes que se envíe ahí nada confidencial. Una conservación corta limita el daño de cualquier exposición, pero también significa que la bandeja no sirve como registro. Y como el contenido no es de fiar, el phishing y el software malicioso pueden llegar a esta bandeja como a cualquier otra. Una bandeja temporal protege tu dirección real, y hace poco por tu dispositivo si abres un archivo malo. Los usos adecuados son la privacidad, el control del spam y las pruebas, como establecen nuestros términos y condiciones, y las cuentas importantes van en otro lado.
Cómo se ve esto en VookMail
Toda la maquinaria anterior está en su sitio antes de que llegues. Cuando abres VookMail, hay una dirección lista. Puedes pulsar Nuevo para escribir un nombre de usuario y elegir un dominio, o usar el botón amarillo «Aleatorio» descrito en nuestra guía para usar VookMail. No hay nada que registrar, porque el dominio ya acepta todos los nombres. Cuando un remitente entrega correo, el proveedor que está detrás de los registros MX lo recibe por SMTP y lo reenvía por HTTPS, y aparece en tu bandeja con sus archivos adjuntos la próxima vez que la página compruebe. Un día más tarde aproximadamente, desaparece.
El servicio también está disponible como app en Google Play y en Huawei AppGallery.
Algunas preguntas técnicas más
¿Qué puerto usa el correo entrante?
La entrega entre servidores de correo usa SMTP en el puerto TCP 25. Los puertos 587 y 465 sirven para enviar correo saliente a tu propio proveedor, así que aparecen en la Etapa 1 y no en la Etapa 3. Por eso mismo una conexión doméstica que bloquea el puerto 25 normalmente puede seguir enviando a través de su proveedor.
¿Puede un servicio de correo temporal ver mis mensajes?
Técnicamente, sí. El mensaje llega al servicio en forma legible, porque así es como puede mostrártelo, y lo mismo vale para el proveedor de entrega que lo maneja por el camino. Esto también es cierto del correo alojado corriente, a menos que el contenido esté cifrado de extremo a extremo. Es otra razón para mantener todo lo sensible fuera de una bandeja temporal.
¿Por qué el remitente puede pensar que un mensaje se entregó cuando yo no veo nada?
Porque «entregado» en el panel de un remitente se refiere a la respuesta 250 del servidor receptor. Los sucesos posteriores a ese punto, como el paso de reenvío o una llegada tardía después de que se limpiara la bandeja, son invisibles para el remitente.
¿Podría un remitente saber que mi dirección es catch-all?
A menudo. Una herramienta de verificación puede probar un nombre de usuario inventado en el dominio, y si el servidor lo acepta, el dominio probablemente es catch-all. Eso por sí solo no demuestra que el dominio sea desechable, ya que muchos dominios corrientes de empresas están configurados igual, así que estas herramientas suelen combinarlo con otras señales.
¿Funcionan las respuestas al mensaje?
Las respuestas desde tu lado no son el objetivo del diseño, ya que la bandeja sobre todo recibe. Si necesitas un intercambio en los dos sentidos, un buzón normal o un servicio de alias que admita respuestas encaja mejor.
Para saber más sobre el producto en sí, consulta nuestras preguntas frecuentes. VookMail forma parte de la red de herramientas gratuitas de PAYATE.