使い捨てメールボックスの保存期間｜メッセージと一緒に消えるもの

短い答えと、みんなが意外に思う半分

5日。たいていの人が求めてここにたどり着く答えは、これで全部です。ただ、これが何に対する答えなのかは正確にしておく価値があります。読めるのは、メッセージが5日間だということです。そのメッセージが届いたアドレスのほうは、そもそも期限切れになるものがないので、まったく期限が切れません。

この二つはまったく別のものであり、両者を混同することから、私たちのところに届く二種類の声が生まれます — 「アドレスが使えなくなった」（実際にはなっていません）と、「これをもっと長く残しておけないか」（それを動かすレバーはどこにもありません）というものです。

メッセージ

自分自身のタイムスタンプから5日間読めて、その後は消えます。本文、ヘッダー、プレビュー、添付ファイル、そのすべてが同じ瞬間に消えます。

アドレス

記録そのものが存在しないので、期限切れになりません。ただの文字列であり、初めて使うときも、1年後に使うときも、同じように機能します。

メールボックス

ひとつのアドレスの中身を数える行は、そこに最初のメッセージが届いたときに作られ、最後のメッセージが消えたときに取り除かれます。自分で作ったり壊したりすることは一切ありません。

期間はひとつだけで、誰にとっても同じです。無料でも有料でも、公開ドメインでも自分のドメインでも変わりません。プランの機能ではなく、それを動かす設定もどこにもありません。

時計が実際に動き出すのはいつか

期限はメッセージが配信された時点で一度だけ計算され、その行に一緒に書き込まれます。その後、何かがそれを再計算することはありません — 読むときにポリシーが参照されることも、プランが確認されることも、何かを開いたことで時計がリセットされることもありません。

知っておく価値があるのは、それがどこから数えられているかです。メッセージは、それを送った側が書き込んだ独自のDateヘッダーを持っており、それが5日間の起点になります — ただし、それが信じられる範囲でのことです。

1. ヘッダーが現在時刻の1日以内に収まっている。その場合は、書かれているとおりに採用されます。ほとんどすべてのメッセージがこのケースにあたり、その場合の期間は、送信者が送信ボタンを押した瞬間から5日間です。
2. ヘッダーがそれより先にも後にもずれている。その場合は無視され、代わりに到着時刻が使われます。送信者は次の世紀の日付でも何でも自由に書けてしまうので、もし期限が切れないメッセージがあるとすれば、それは一度も届かなかったメッセージだけです。
3. そもそも使えるヘッダーがない。この場合も同じで、到着時刻が使われます。

これによって失われるのはせいぜい数時間であり、しかも方向はひとつしかありません — メッセージが届いた時点で残りが5日よりわずかに少なくなることはあっても、多くなることは決してありません。どこかのキューで20時間過ごしてから届いたメッセージは、残り約4日と4時間の状態で現れることになります。

何が一緒に消え、何が残るのか

メッセージが期限に達すると、それに属するものはすべて一度に消えます。別のテーブルに何かが取り置かれることもなければ、縮小された形で何かが生き残ることもありません — スタブも、記録用に残された件名も、ファイルのサムネイルも存在しません。

添付ファイルは、その行が消える前にリンクが外されます。この順序は意図的なものです — その途中でクラッシュが起きても、残るのはファイルがすでに消えた行だけであり、それは次の回できれいに片付けられます。逆の順序にすると、どこからも指されていないファイルが残ってしまい、それを回収しに戻ってくるものは二度と現れません。

先に読めなくなり、後から削除される

これは二つの出来事であり、同じ出来事ではありません。頼りにできるスケジュールの上にあるのは最初の方だけであり、あなたが観測できるのもそれだけです。

ここでのすべての読み出しは、期限によってフィルタされます。メールボックスの一覧表示、メッセージを1通開くこと、添付ファイルを1つダウンロードすること — この三つはすべて同じ条件を持っており、期間を過ぎたメッセージはそのどれにも一致しません。「技術的にはまだそこにある」という状態の期間は存在しません。期限が切れた瞬間、受信箱のページからも、APIからも、MCPサーバーからも同時に消えます。

その後に起きるのは、ただの後片付けです。掃除処理が通りかかり、行とファイルを区切られたバッチ単位で回収します。そのペースは、溜まった分を片付ける作業が現在進行中の配信を待たせることのないように選ばれています。特定のメッセージにいつ順番が回ってくるかによって、誰かの目に見える何かが変わることはありません。

期限

メッセージを返しうるすべての問い合わせにかかる条件です。正確で、受信箱、API、MCPサーバーのどれでも同一です。三つとも、同じ問いを尋ねているからです。

掃除処理

すでに手が届かなくなったものを回収する、範囲の限られた作業です。読み手がそれを待つことは決してなく、何かを読めるかどうかを決めているのもこれではありません。

だからこそ、「削除されたのか、それとも隠されているだけなのか?」という問いへの答えは「両方、その順番で」になります — そして、あなたが尋ねる時点でそのどちらが起きているかによって、何も変わらない理由もそこにあります。

期限をメッセージから直接読み取る

日付を自分で計算する必要は一切ありません。APIが返すすべてのメッセージには、配信時に与えられた期限が、UTCのISO 8601形式のタイムスタンプとして含まれています。

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

レスポンスに含まれる各メッセージには、その期間の両端が含まれています。

{
  "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が時計の起点で、expires_atがその終点です。片方からもう片方を引けば、毎回必ず5日間になります — これが、その間に自分が何をしても何も動かなかったことを確かめる、一番手っ取り早い方法です。

expires_at

読めなくなる瞬間です。絶対時刻で、UTCで表され、末尾のZではなくオフセットがそのまま書き出されます。

date

メッセージ自身のタイムスタンプです — 到着から1日以内であればそのまま信用され、そうでなければ静かに到着時刻に置き換えられます。

期限を過ぎたメッセージを求めると、一度も存在しなかったメッセージを求めたときとまったく同じ答えが返ってきます。

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

APIは、そのどちらだったのかを教えてくれませんが、これは考慮漏れではありません。両者を区別してしまうと、404が「その特定のidがかつて実在した」ことを確認する手段になってしまいます。それは、メールボックスの外にいる誰にも尋ねられるべきではない問いです。

本当に必要なものを、手元に残しておく

使い捨てアドレスに届くもののほとんどは、それより長生きする必要がありません。数少ない例外については、6日目になって気づくのではなく、あらかじめ意識して扱っておく価値があります。

1. コード、リンク、一時的なパスワード。今すぐ使ってください。そもそもメッセージの中で一番寿命が短いのはこれらです — たいていの確認リンクは5日が経つよりずっと前に使えなくなるので、リンクよりメールの方が長持ちするのがふつうであり、その逆ではありません。
2. ファイル。メッセージがあるうちにダウンロードしてください。メッセージ全体は5 MBが上限なので、これは決して大掛かりな作業にはなりません。そして、ファイルはメッセージとまったく同じ瞬間に消えます。
3. 領収書や請求書。使い捨てアドレスが単純に不向きな、唯一のケースです。ものを保管しておく場所に置くか、自分が保持し続けるアドレスを使ってください。
4. テストスイートが生成したもの全般。それを生成した実行の中でアサーションしてください。前日の実行のメールボックスを読みに行くジョブは、連休明けの最初の月曜日に不安定になるジョブです。
5. あるサービスが自分に何を送ってきたかの証拠。届いたその日のうちに受信箱から取り出してください。ここにはエクスポート機能がなく、何かが二重に記録されることもありません。

早めに削除すること、そしてスクリプトがそうすべき理由

メッセージが消える方法は、待つことだけではありません。1回の呼び出しで1通のメッセージが削除され、それは後の掃除処理を待たず、その場で反映されます。

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

人間にとって、それは片付けです。スクリプトにとっては、むしろ帳簿付けに近いものです。空になったメールボックスは、そこにあったものすべてが処理済みであることを示す、最も単純な表明であり、それを保ち続けるコストはゼロです。代わりの方法 — 処理済みidのリストを持つこと — は、そのリストをどこかに置き、どこかに書き込み、どこかで掃除しなければならなくなります。

これによって、他の何かの期間が変わることはありませんし、変わる必要もありません — 残しておいたものは、放っておいても勝手に消えていきます。

メールボックスの最後のメッセージを削除すると、期限切れの場合とまったく同じように、メールボックスの記録も一緒に取り除かれます。メッセージを削除するのと、期限切れを待つのとで、最終的な状態に違いはありません — 違うのはタイミングだけです。

なぜ30日ではなく5日なのか

正直に言えば、理由はストレージではありません。公開ドメインでは、アドレスそのものが秘密であり、それを知っている人なら誰でもメールボックスを読めるという、その性質のおかげで、アカウントもパスワードも確認用の自分のメールアドレスも無しで使えるのです。だから保持期間は、気前の良さを調整するつまみではありません。被害が及ぶ範囲の広さなのです。

• 5日あれば、このサービスが実際に想定している用途 — 確認コード、ダウンロードリンク、テストの実行、これから別の場所に移す予定の領収書 — にはすべて十分です。
• 同時に、3月にフォームへ入力したアドレスが4月になってもまだ何かを抱えている、ということがない程度には短くもあります。その間に他の誰にそのアドレスが渡っていたとしても、です。
• 誰にとっても同じなので、間違えようのある設定は存在せず、自分が思っていたより静かにメールが長生きしてしまうようなプランもありません。

アドレスの方も秘密にしておきたいなら、そのためにあるのがエイリアスです。エイリアスを渡し、アドレスの方で読む。エイリアスを試した誰かが見つけるのは、常に空のメールボックスだけです。その仕組みの全体は本物のアドレスを使わずに登録するガイドで詳しく説明しています。

そして、自分が管理するメールについてもっと長い期間が欲しいのであれば、答えはここの設定を長くすることではなく、自分が管理するメールボックスを持つことです。自分のドメインをこのサービスに向けても、期間そのものは変わりません — 変わるのはアドレスを誰が所有しているかであり、それこそが直すべき、より良い部分です。

すでに消えてしまったとき

試せることは何もありません。これははっきり言っておく価値があります。これまで使ってきた他のメールサービスには、たいていどこかにゴミ箱があり、ここにもそれを探しに行きたくなるのが自然な反応だからです。

アーカイブなし

消えていく途中で、どこにも何もコピーされません。

ゴミ箱なし

「読める」と「消えた」の間に状態は存在せず、メッセージをしばらくとどめておくものもありません。

チケットなし

期限切れのメッセージを取り戻す、運営側の操作というものはありません。それを読み出せる可能性のある経路はすべて同じ期限を持っており、私たちが使うことになる経路も例外ではありません。

実際にやる価値があるのは、ごくふつうのことです。送信元にもう一度頼むことです。確認メール、ダウンロードリンク、領収書は、どれも頼めばサービス側が再発行してくれるものであり、たいていは元々いたページから頼めます。古いアドレスがあちこちに出回ってしまっている場合は、まず新しいアドレスを開いてください。

そして、そもそも待っていたものが最初から届いていなかったのなら、このページは見当違いです — メールが届かないことについてのガイドで、確認する価値のある順番に原因をたどれます。まずは10秒で確認できるものからです。

実際には

これまでの話をまとめると、実践するための習慣はこうなります。

1. アドレスを開いて、使う。有効化すべきものは何もなく、カウントダウンが始まるものも何もない。
2. それを開いた目的のこと — コード、リンク、ファイル — を、まだそこにいるうちに済ませる。
3. 残しておきたいものは、届いたその日のうちに受信箱の外へ持ち出す。
4. スクリプトが読み取るなら、リトライ回数ではなくexpires_atで分岐させる。
5. 終わったものは削除する。せめて、メールボックスを見ればまだやるべきことが分かる状態にしておくために。
6. 同じアドレスには、好きなときに戻ってくればいい。ちゃんとそこにあり、空になっている。

最後の一行こそが、覚えておく価値のあるものです。アドレスは永続的で、メールはそうではありません。これは、あなたがすでに持っているどの受信箱とも逆の関係であり、そしてそれこそが、このサービスが何も課金せず、何も求めない理由のすべてです。

質問