A resposta curta, e a metade que surpreende as pessoas
5 dias. Essa é toda a resposta que a maioria das pessoas veio buscar, e vale ser exato sobre a que pergunta ela responde: uma mensagem é legível por 5 dias. O endereço em que ela caiu não expira nunca, porque não há nada ali para expirar.
São duas coisas diferentes, e misturá-las produz as duas mensagens que recebemos sobre isso — “meu endereço parou de funcionar”, o que não aconteceu, e “dá para manter essa por mais tempo”, para o que não existe alavanca nenhuma para puxar.
- Uma mensagem
- Legível por 5 dias a partir do próprio timestamp, depois some. Corpo, cabeçalhos, prévia e quaisquer anexos, tudo no mesmo instante.
- Um endereço
- Sem expiração, porque nenhum registro dele é mantido. É uma string. Funciona na primeira vez que você usa e funciona um ano depois.
- Uma caixa de entrada
- O registro que contabiliza um endereço é criado pela primeira mensagem que chega nele e removido quando a última vai embora. Você nunca cria nem destrói esse registro sozinho.
Uma janela só, igual para todo mundo: grátis ou pago, um domínio público ou o seu próprio. Não é um recurso de plano, e não existe configuração em lugar nenhum que mude isso.
Quando o relógio realmente começa
O prazo é calculado uma única vez, no momento em que a mensagem é entregue, e gravado no registro ao lado dela. Nada recalcula isso depois — nenhuma política é consultada quando você lê, nenhum plano é verificado, nenhum relógio reinicia porque você abriu alguma coisa.
A partir de onde ele é contado é a parte que vale a pena saber. Uma mensagem carrega seu próprio cabeçalho Date, escrito por quem quer que a tenha enviado, e é esse o início dos 5 dias — mas só enquanto ele for crível.
- O cabeçalho está a menos de um dia de agora. Ele é aceito como está. Quase toda mensagem se encaixa nesse caso, e para elas a janela corre 5 dias a partir do momento em que quem enviou apertou enviar.
- O cabeçalho está mais distante do que isso, para qualquer um dos lados. Ele é ignorado, e o horário de chegada é usado no lugar. Quem envia pode escrever a data que quiser, inclusive uma do século que vem, e uma mensagem que nunca expirasse seria uma mensagem que nunca teria saído.
- Não há cabeçalho nenhum utilizável. O mesmo vale: horário de chegada.
Isso só pode custar horas, e só pode ir para um lado — uma mensagem pode chegar com um pouco menos de 5 dias restantes, nunca mais. Algo que ficou parado numa fila em algum lugar por vinte horas antes de chegar até nós aparece com cerca de quatro dias e quatro horas pela frente.
O que vai junto, e o que fica
Quando uma mensagem chega ao prazo, tudo o que pertence a ela vai embora de uma vez. Nada fica retido em outra tabela, e nada sobrevive numa forma reduzida — não há vestígio, não há linha de assunto guardada para registro, não há miniatura de arquivo.
| O quê | O que acontece com isso | Quando |
|---|---|---|
| A mensagem | Texto, HTML, cabeçalhos e prévia, removidos juntos. | No prazo dela |
| Os anexos dela | Excluídos do disco e também do banco de dados. Um arquivo só é alcançável através da mensagem que o carregou, então ele não pode sobreviver a ela. | Junto com a mensagem |
| A marcação de lida | É uma coluna na mensagem, não algo com existência própria. Vai embora quando o registro vai. | Junto com a mensagem |
| O registro da caixa de entrada | O registro que conta o que há em um endereço é removido assim que a última mensagem nele se vai. Ele existe porque um e-mail chegou; ele não sobrevive ao e-mail. | Junto com a última mensagem |
| O endereço | Nada para remover. Nunca foi armazenado como algo que pode existir ou deixar de existir. | Nunca |
| Um alias que carregou e-mail | Mantido. É o fio que diz qual serviço recebeu qual endereço, e isso vale mais do que o registro custa. | Nunca |
| Um alias que não carregou nenhum | Descartado depois de 5 dias parado — e recalculado, de forma idêntica, na próxima vez que o endereço for usado. Um alias é derivado do endereço, não atribuído a ele, então descartar um que não foi usado não perde nada. | Depois de 5 dias parado |
| O registro MX do seu próprio domínio | Seu, no seu DNS, intocado por qualquer coisa disso. Retenção é sobre o e-mail, não sobre o roteamento. | Nunca |
Os arquivos dos anexos são desvinculados antes dos registros deles, e a ordem é proposital: uma falha no meio disso deixa registros cujos arquivos já se foram, e a próxima varredura organiza isso. A outra ordem deixaria arquivos para os quais nada aponta, e nada jamais voltaria para buscá-los.
Ilegível primeiro, excluída depois
São dois eventos, e não são o mesmo evento. Só o primeiro está numa programação em que dá para confiar, e é o único que dá para observar.
Toda leitura aqui é filtrada pelo prazo. Listar uma caixa de entrada, abrir uma mensagem, baixar um anexo — as três carregam a mesma condição, e uma mensagem que passou da janela não corresponde a nenhuma delas. Não existe um intervalo em que o e-mail está “tecnicamente ainda ali”: no segundo em que expira, ele some da página da caixa de entrada, da API e do servidor MCP ao mesmo tempo.
O que acontece depois é faxina. Uma varredura passa e libera o registro e os arquivos, em lotes limitados, num ritmo escolhido para que limpar um acúmulo nunca deixe entregas ativas na fila atrás dele. A rapidez com que ela chega a uma mensagem específica não muda nada que alguém consiga ver.
- O prazo
- Uma condição em toda consulta que poderia retornar uma mensagem. Exata, e idêntica na caixa de entrada, na API e no servidor MCP, porque as três fazem a mesma pergunta.
- A varredura
- Trabalho limitado que libera o que já está inalcançável. Nunca algo que um leitor espera, e nunca a coisa que decide se você consegue ler algo.
É por isso que a resposta para “ele foi excluído ou só ficou escondido?” é “as duas coisas, nessa ordem” — e por que não faz diferença qual das duas já aconteceu no momento em que você pergunta.
Lendo o prazo direto na mensagem
Você nunca precisa calcular a data sozinho. Toda mensagem que a API devolve carrega o prazo que recebeu na entrega, como um timestamp ISO 8601 em UTC.
$ curl -sG https://grabmail.io/api/v1/mailbox \
--data-urlencode "address=you@grabmail.io"Cada mensagem na resposta carrega as duas pontas da própria janela:
{
"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 é de onde o relógio partiu, e expires_at é onde ele para. Subtraia um do outro e você chega a 5 dias, sempre — que é o jeito mais rápido de se convencer de que nada do que você fez no meio do caminho mudou alguma coisa.
expires_at- O momento em que ela deixa de ser legível. Absoluto, em UTC, com o deslocamento escrito por extenso, em vez de um Z no final.
date- O próprio timestamp da mensagem — aceito quando está a menos de um dia da chegada, silenciosamente substituído pelo horário de chegada quando não está.
Peça uma mensagem que já passou do prazo e você recebe exatamente a mesma resposta que receberia para uma que nunca existiu:
{"error":"not_found","message":"no such message in that mailbox, or it has expired"}A API não vai dizer qual das duas foi, e isso não é um descuido. Diferenciar as duas transformaria um 404 numa forma de confirmar que algum id específico já foi real algum dia, e essa é uma pergunta que ninguém de fora da caixa de entrada deveria conseguir fazer.
Guardando a coisa que você realmente veio buscar
Quase nada do que chega em um endereço descartável precisa sobreviver a ele. O punhado de exceções vale a pena resolver de propósito, em vez de descobrir isso no sexto dia.
- Um código, um link ou uma senha temporária. Use agora. Essas são as coisas que duram menos tempo na mensagem, de qualquer forma — a maioria dos links de confirmação para de funcionar bem antes de os 5 dias acabarem, e o e-mail sobreviver ao link é o caso comum, não o contrário.
- Um arquivo. Baixe enquanto a mensagem ainda está lá. Uma mensagem inteira tem um teto de 5 MB, então isso nunca é uma operação grande, e o arquivo vai embora no mesmo instante que a mensagem.
- Um recibo ou uma nota fiscal. O único caso em que um endereço descartável é simplesmente a ferramenta errada. Guarde em algum lugar onde você guarda as coisas, ou use um endereço que você mantém.
- Qualquer coisa que uma suíte de testes produziu. Faça o assert dentro da própria execução que produziu isso. Um job que lê uma caixa de entrada da execução de ontem é um job que fica instável na primeira segunda-feira de um feriado prolongado.
- Prova do que um serviço te enviou. Tire isso da caixa de entrada no dia em que chegar. Não existe exportação aqui, e nada fica escrito duas vezes.
Excluindo antes da hora, e por que um script deveria fazer isso
Esperar não é a única forma de uma mensagem ir embora. Uma chamada remove uma mensagem, e o efeito é imediato, em vez de esperar por alguma varredura futura.
$ curl -sX DELETE -G https://grabmail.io/api/v1/message/01k4h2v9r7m3d8f0b6n5c1qtzx \
--data-urlencode "mailbox=you@grabmail.io"Para uma pessoa, isso é organização. Para um script, é mais parecido com contabilidade: uma caixa de entrada esvaziada é a afirmação mais simples possível de que tudo o que estava ali já foi tratado, e não custa nada manter isso verdadeiro. A alternativa — uma lista de ids já processados — é uma lista que precisa morar em algum lugar, ser escrita em algum lugar e ser limpa em algum lugar.
Isso não muda nada na janela de mais nada, e nem precisa: o que você deixar para trás vai embora sozinho.
Excluir a última mensagem de uma caixa de entrada remove o registro dela junto, exatamente como a expiração faria. Não há diferença no estado final entre excluir uma mensagem e esperar por ela — só no quando.
Por que 5 dias e não trinta
O motivo honesto não é armazenamento. É que, num domínio público, o endereço é o segredo — quem souber o endereço consegue ler a caixa de entrada, e é exatamente essa característica que permite usar uma sem conta, sem senha e sem um e-mail seu para confirmar. A retenção, portanto, não é um botão de generosidade. É o tamanho do raio de explosão.
- 5 dias é tempo suficiente para tudo aquilo para o que este serviço realmente serve: um código de confirmação, um link de download, uma execução de teste, um recibo que você está prestes a mover para outro lugar.
- É curto o bastante para que um endereço que você digitou num formulário em março não esteja mais segurando nada em abril, não importa quem mais tenha recebido esse endereço desde então.
- É igual para todo mundo, então não há configuração para errar, nem plano em que seu e-mail sobreviva silenciosamente além do que você esperava dele.
Se você também quer que o endereço continue em segredo, é para isso que serve um alias: distribua o alias, leia pelo endereço. Quem tentar usar o alias encontra uma caixa de entrada vazia, sempre, e o guia para se cadastrar sem o seu endereço de verdade explica o truque por completo.
E se o que você quer é uma janela mais longa num e-mail que você controla, a resposta é uma caixa de entrada que você controla, não uma configuração mais longa aqui. Apontar um domínio seu para este serviço também não muda a janela — muda quem é dono dos endereços, o que é uma coisa diferente e melhor de resolver.
Quando já se foi
Não há nada para tentar. Vale dizer isso claramente, porque todo outro serviço de e-mail que você já usou tem uma lixeira em algum lugar, e o reflexo é sair procurando a deste aqui.
- Nenhum arquivo morto
- Nada é copiado para lugar nenhum na saída.
- Nenhuma lixeira
- Não existe um estado entre legível e sumida, e nada que segure uma mensagem por um tempo.
- Nenhum chamado
- Não existe ação de operador nenhuma que devolva uma mensagem expirada. Todo caminho que poderia ler uma carrega o mesmo prazo, incluindo os que nós mesmos usaríamos.
A coisa que realmente vale a pena fazer é a óbvia: pedir de novo para quem enviou. Um e-mail de verificação, um link de download e um recibo são todos coisas que um serviço reemite quando você pede, geralmente pela mesma página em que você já estava. Abra um endereço novo primeiro, se o antigo tiver circulado por aí.
E se aquilo que você estava esperando nunca chegou, para começo de conversa, esta é a página errada — o guia sobre e-mails que nunca chegam percorre as causas na ordem que vale a pena checar, começando pela que leva dez segundos.
Na prática
Tudo isso, como hábito de trabalho:
- Abra um endereço e use-o. Não há nada para ativar, e nada que comece a contar regressivamente.
- Faça aquilo para o qual você o abriu — o código, o link, o arquivo — enquanto ainda está lá.
- Tire da caixa de entrada qualquer coisa que você pretenda guardar, no dia em que ela chegar.
- Se um script está lendo, decida com base em
expires_at, não numa contagem de tentativas. - Exclua o que você já terminou de usar, nem que seja só para que a caixa de entrada mostre o que ainda falta fazer.
- Volte para o mesmo endereço quando quiser. Ele vai estar lá, e vai estar vazio.
Essa última linha é a que vale guardar. O endereço é permanente e o e-mail não é, o que é o inverso de toda caixa de entrada que você já tem — e é exatamente por isso que essa aqui não custa nada e não pede nada.
Perguntas
Dá para recuperar uma mensagem depois de 5 dias?
Não. Não há arquivo morto, não há lixeira, e não há ação de operador que devolva uma — todo caminho que poderia ler uma mensagem carrega o mesmo prazo, então não existe lugar de onde ela possa voltar.
Abrir ou ler uma mensagem reinicia o relógio?
Não. O prazo é gravado uma única vez, na entrega, e nada o recalcula. Ler, marcar como lida, atualizar a página e listar a caixa de entrada de novo — nada disso muda onde ele estava.
O endereço expira se eu parar de usá-lo?
Não, porque ele não é armazenado como algo que poderia expirar. Um endereço só vira um registro enquanto há e-mail nele, e esse registro vai embora quando o e-mail vai. Digite o mesmo endereço de novo daqui a seis meses e ele funciona — vazio, e seu para usar.
Dá para pagar por mais tempo de retenção?
Não. Existe uma única janela, e ela é igual em todo endereço, todo domínio e todo plano. Não é uma configuração em lugar nenhum, e não é algo que o suporte consiga liberar para uma conta específica.
Os anexos duram o mesmo tanto que a mensagem?
Exatamente o mesmo tanto, nem mais um segundo. Um arquivo só é alcançável através da mensagem que o carregou, e os dois vão embora no mesmo instante. O guia sobre anexos cobre o teto de tamanho e como tirar um arquivo de lá enquanto ele ainda está disponível.
E se a data de quem enviou estiver errada?
Um cabeçalho Date a mais de um dia de distância do momento em que a mensagem chegou é ignorado, e o horário de chegada é usado no lugar. Então, na pior das hipóteses, uma data errada pode custar a uma mensagem algumas horas da janela dela; nunca pode estendê-la.
Meu e-mail é excluído, ou só fica escondido depois do prazo?
As duas coisas, nessa ordem. Ele deixa de ser legível no prazo, que é uma condição em toda consulta, e os bytes são liberados depois por uma varredura que ninguém espera terminar. Nenhum dos dois estados é um de onde dá para ler alguma coisa.
Excluir uma mensagem libera o endereço na hora?
A mensagem vai embora na hora, e o registro da caixa de entrada vai junto com a última mensagem que havia nela. Mas o endereço nunca esteve retido, para começo de conversa, então não há nada para liberar — ele esteve disponível para você o tempo todo, e para qualquer outra pessoa que o tivesse adivinhado.
Como mantenho uma caixa de entrada viva para um teste de longa duração?
Você não precisa: o endereço não precisa de nada para se manter vivo, só o e-mail expira. O que uma suíte longa realmente quer é um endereço novo a cada execução, que é o que o guia para testar fluxos de verificação constrói — uma caixa de entrada compartilhada entre dias é uma caixa de entrada em que a mensagem de ontem ainda está batendo com o assert de hoje.
