Cuánto dura un buzón desechable y qué caduca con él

La respuesta corta, y la mitad que sorprende a la gente

5 días. Esa es toda la respuesta que busca la mayoría, y merece la pena ser exacto sobre a qué responde: un mensaje es legible durante 5 días. La dirección en la que cayó no caduca en absoluto, porque ahí no hay nada que caduque.

Son dos cosas distintas, y confundirlas produce los dos mensajes que más recibimos sobre esto — "mi dirección dejó de funcionar", que no es el caso, y "¿puedes conservar este un poco más?", para lo cual no hay ninguna palanca que mover.

Un mensaje

Legible durante 5 días desde su propia marca de tiempo, y luego desaparece. Cuerpo, encabezados, vista previa y cualquier adjunto, todo en el mismo momento.

Una dirección

Sin caducidad, porque no se guarda ningún registro de ella. Es una cadena de texto. Funciona la primera vez que la usas y funciona un año después.

Un buzón

El registro que contabiliza una dirección se crea con el primer mensaje que cae en ella y se elimina cuando se va el último. Tú nunca lo creas ni lo destruyes.

Una sola ventana, igual para todos: gratis o de pago, un dominio público o uno propio. No es una función de ningún plan, y no hay ningún ajuste en ningún sitio que la mueva.

Cuándo empieza realmente el reloj

El plazo se calcula una sola vez, cuando se entrega el mensaje, y se escribe en el registro junto a él. Nada lo vuelve a calcular después — no se consulta ninguna política cuando lees, no se mira ningún plan, ningún reloj se reinicia por haber abierto algo.

Lo que vale la pena saber es desde dónde se cuenta. Un mensaje lleva su propia cabecera Date, escrita por lo que sea que lo envió, y ahí empiezan los 5 días — pero solo mientras resulte creíble.

1. La cabecera está a menos de un día de ahora. Se toma tal cual. Casi todos los mensajes están en este caso, y para ellos la ventana corre 5 días desde el momento en que el remitente pulsó enviar.
2. La cabecera se aleja más que eso, en cualquiera de los dos sentidos. Se ignora y se usa en su lugar la hora de llegada. Un remitente puede escribir la fecha que quiera, incluida una del siglo que viene, y un mensaje que nunca caducara sería un mensaje que nunca salió.
3. No hay ninguna cabecera utilizable. Lo mismo: la hora de llegada.

Esto, como mucho, te puede costar horas, y solo puede ir en un sentido — un mensaje puede llegar con algo menos de 5 días por delante, nunca con más. Algo que se quedó veinte horas en alguna cola antes de llegar hasta aquí aparece con unos cuatro días y cuatro horas por delante.

Qué desaparece con él, y qué se queda

Cuando un mensaje llega a su plazo, todo lo que le pertenece desaparece a la vez. Nada se guarda aparte en otra tabla, y nada sobrevive en una forma reducida — no queda ningún resto, ningún asunto guardado como constancia, ninguna miniatura de un archivo.

Los archivos de los adjuntos se desvinculan antes que sus registros, y el orden es deliberado: un fallo justo en medio deja registros cuyos archivos ya han desaparecido, algo que la siguiente pasada ordena. El orden contrario dejaría archivos a los que nada apunta, y nadie volvería nunca a por ellos.

Primero ilegible, después eliminado

Son dos sucesos, y no son el mismo suceso. Solo el primero sigue un calendario en el que puedes confiar, y es el único que puedes observar.

Aquí, cada lectura pasa por el filtro del plazo. Listar un buzón, abrir un mensaje, descargar un adjunto — las tres llevan la misma condición, y un mensaje que ya pasó su ventana no coincide con ninguna de ellas. No hay ningún intervalo en el que el correo esté "técnicamente todavía ahí": en el segundo en que caduca desaparece de la página del buzón, de la API y del servidor MCP a la vez.

Lo que ocurre después es limpieza. Un barrido pasa y libera el registro y los archivos, en lotes acotados, a un ritmo elegido para que vaciar una acumulación nunca deje esperando detrás a entregas en curso. Lo rápido que llegue a un mensaje concreto no cambia nada que nadie pueda ver.

El plazo

Una condición en cada consulta que podría devolver un mensaje. Exacta, e idéntica en el buzón, la API y el servidor MCP, porque los tres hacen la misma pregunta.

El barrido

Trabajo acotado que libera lo que ya es inalcanzable. Nunca algo que un lector espera, y nunca lo que decide si puedes leer algo.

Por eso la respuesta a "¿está eliminado o solo oculto?" es "las dos cosas, en ese orden" — y por eso no importa cuál de las dos haya ocurrido ya en el momento en que preguntas.

Leer el plazo directamente del mensaje

Nunca tienes que calcular tú la fecha. Cada mensaje que devuelve la API lleva el plazo que se le asignó al entregarse, como marca de tiempo ISO 8601 en UTC.

$ curl -sG https://grabmail.io/api/v1/mailbox \
  --data-urlencode "address=you@grabmail.io"

Cada mensaje de la respuesta lleva los dos extremos de su propia ventana:

{
  "id": "01k4h2v9r7m3d8f0b6n5c1qtzx",
  "from": "no-reply@example.com",
  "subject": "Confirm your email address",
  "date": "2026-09-01T09:00:00+00:00",
  "seen": false,
  "attachments": 0,
  "expires_at": "2026-09-06T09:00:00+00:00"
}

date es desde donde arrancó el reloj y expires_at es donde se detiene. Resta uno del otro y obtienes 5 días, siempre — la forma más rápida de comprobar que nada de lo que hiciste mientras tanto movió nada.

expires_at

El momento en que deja de ser legible. Absoluto, en UTC, con el desfase escrito completo en lugar de como una Z final.

date

La propia marca de tiempo del mensaje — se acepta cuando está a menos de un día de la llegada, y se sustituye discretamente por la hora de llegada cuando no lo está.

Pide un mensaje que ya ha pasado su plazo y obtienes exactamente la misma respuesta que obtendrías por uno que nunca existió:

{"error":"not_found","message":"no such message in that mailbox, or it has expired"}

La API no dirá cuál de las dos cosas fue, y eso no es un descuido. Distinguirlas convertiría un 404 en una forma de confirmar que un id concreto llegó a existir, una pregunta que nadie fuera del buzón debería poder hacer.

Quedarte con lo que en realidad viniste a buscar

Casi nada de lo que llega a una dirección desechable necesita sobrevivirla. El puñado de excepciones merece la pena resolverlas a propósito, en lugar de descubrirlas el día seis.

1. Un código, un enlace o una contraseña temporal. Úsalo ahora. Son, de todas formas, lo más efímero que hay en el mensaje — la mayoría de los enlaces de confirmación dejan de funcionar mucho antes de que pasen los 5 días, y que el correo sobreviva al enlace es el caso normal, no al revés.
2. Un archivo. Descárgalo mientras el mensaje esté ahí. Un mensaje completo tiene un tope de 5 MB, así que nunca es una operación grande, y el archivo desaparece en el mismo instante que el mensaje.
3. Un recibo o una factura. El único caso en el que una dirección desechable es sencillamente la herramienta equivocada. Guárdalo en algún sitio donde guardes cosas, o usa una dirección que conserves.
4. Cualquier cosa que produzca una batería de pruebas. Compruébalo dentro de la misma ejecución que lo produjo. Un trabajo que lee un buzón de la ejecución de ayer es un trabajo que se vuelve inestable el primer lunes de un puente.
5. La prueba de lo que te envió un servicio. Sácala del buzón el mismo día que llegue. Aquí no hay exportación, y nada se guarda por duplicado.

Eliminar antes de tiempo, y por qué debería hacerlo un script

Esperar no es la única forma en que un mensaje se va. Una llamada elimina un mensaje, y surte efecto al instante, no en algún barrido posterior.

$ curl -sX DELETE -G https://grabmail.io/api/v1/message/01k4h2v9r7m3d8f0b6n5c1qtzx \
  --data-urlencode "mailbox=you@grabmail.io"

Para una persona, eso es orden. Para un script, se parece más a la contabilidad: un buzón vacío es la afirmación más simple posible de que todo lo que había allí ya se ha tratado, y no cuesta nada mantenerla cierta. La alternativa — una lista de ids ya procesados — es una lista que tiene que vivir en algún sitio, escribirse en algún sitio y limpiarse en algún sitio.

No cambia nada sobre la ventana de lo demás, y no necesita hacerlo: lo que dejes atrás desaparece por su cuenta.

Eliminar el último mensaje de un buzón elimina con él el registro del buzón, igual que habría hecho la caducidad. No hay ninguna diferencia en el estado final entre eliminar un mensaje y esperar a que caduque — solo en cuándo.

Por qué 5 días y no treinta

La razón honesta no es el almacenamiento. Es que, en un dominio público, la dirección es el secreto — cualquiera que la conozca puede leer el buzón, que es exactamente la propiedad que te permite usar uno sin cuenta, sin contraseña y sin un correo propio con el que confirmar nada. La retención no es, por tanto, un dial de generosidad. Es el tamaño del radio de la explosión.

• 5 días son suficientes para todo aquello para lo que sirve en realidad este servicio: un código de confirmación, un enlace de descarga, una ejecución de pruebas, un recibo que estás a punto de mover a otro sitio.
• Es lo bastante corto para que una dirección que escribiste en un formulario en marzo no siga conservando nada en abril, sea quien sea a quien se la hayan dado desde entonces.
• Es igual para todos, así que no hay ninguna configuración que puedas equivocar ni ningún plan en el que tu correo sobreviva en silencio a lo que esperabas de él.

Si además quieres que la dirección se mantenga en secreto, para eso está el alias: entrega el alias, lee la dirección. Cualquiera que pruebe el alias encuentra un buzón vacío, siempre, y la guía sobre cómo registrarte sin tu dirección real expone el truco por completo.

Y si lo que quieres es una ventana más larga en correo que controlas tú, la respuesta es un buzón que controles tú, no un ajuste más largo aquí. Apuntar un dominio propio a este servicio tampoco cambia la ventana — cambia quién es el dueño de las direcciones, que es un problema distinto y mejor de resolver.

Cuando ya ha desaparecido

No hay nada que intentar. Merece la pena decirlo sin rodeos, porque todos los demás servicios de correo que has usado tienen una papelera en alguna parte, y el acto reflejo es ponerte a buscar la de este.

Ninguna copia

Nada se copia a ningún sitio al salir.

Ninguna papelera

No hay ningún estado entre legible y desaparecido, ni nada que retenga un mensaje durante un tiempo.

Ningún ticket

No existe ninguna acción de un operador que devuelva un mensaje caducado. Todos los caminos que podrían leer uno llevan el mismo plazo, incluidos los que usaríamos nosotros.

Lo único que de verdad merece la pena hacer es lo normal: pedírselo de nuevo al remitente. Un correo de verificación, un enlace de descarga y un recibo son cosas que un servicio volverá a emitir si se lo pides, normalmente desde la misma página en la que ya estabas. Abre antes una dirección nueva si la antigua ha ido pasando de mano en mano.

Y si lo que esperabas nunca llegó a aparecer, esta no es la página que buscas — la guía sobre el correo que nunca llega repasa las causas en el orden en que merece la pena revisarlas, empezando por la que toma diez segundos.

En la práctica

Todo esto, como hábito de trabajo:

1. Abre una dirección y úsala. No hay nada que activar ni nada que empiece a contar hacia atrás.
2. Haz aquello para lo que la abriste — el código, el enlace, el archivo — mientras sigas ahí.
3. Saca del buzón, el mismo día que llegue, todo lo que pienses conservar.
4. Si un script lo está leyendo, decide según expires_at en lugar de un contador de reintentos.
5. Elimina aquello con lo que ya hayas terminado, aunque solo sea para que el buzón diga qué queda por hacer.
6. Vuelve a la misma dirección cuando quieras. Ahí estará, y estará vacía.

Esa última línea es la que hay que recordar. La dirección es permanente y el correo no lo es, que es justo lo contrario de cualquier buzón que ya tengas — y es la razón entera por la que este no cuesta nada y no pide nada.

Preguntas