アドレスと用途
- 使い捨てメールアドレス
- 限られた期間だけメールを受信できるアドレスで、登録テストや認証コードの受信によく使われます。「使い捨て」は利用できる期間を指し、すべてのサービスで受け付けられることや、機密情報を受信してよいことを意味しません。
- 転送エイリアス
- 受信メールを指定したメールアドレスに転送する専用アドレスです。送信元ごとに作成したり、一時停止したりできます。ただし、一時停止しても転送先に届いたメールのコピーは取り消せません。また、長期利用する受信用メールアドレスの代わりにはなりません。
- メールサンドボックス
- 開発環境で、本来送信されるメールを受け取り、テンプレートや変数を確認するためのテストサービスです。アプリからサンドボックスにメールを渡せたとしても、同じメールがインターネット経由で実際のユーザーに届くとは限りません。
- MXレコード
- メールを受信するサーバーを示すDNSレコードです。MXの設定が正しいことは配送経路の一要素にすぎません。受信アドレスの実在、サーバーによる受信、受信トレイでの表示を単独で証明するものではありません。
配信とステータス
- SMTP
- メールサーバー間や、アプリと送信サーバー間で広く使われる転送プロトコルです。SMTPで成功応答が返っても、通常はその時点の接続先がメールを受け付けたことを示すだけで、受信まで完了したことを意味しません。
- キュー待ち / Queued
- メールの処理がキューに入り、順番を待っている状態です。受信サーバーへの接続がまだ始まっていない場合もあります。長時間変化がないときは、受信トレイを更新するだけでなく、キューの滞留状況、再試行の予定、サービスの稼働状況を確認しましょう。
- 受け付け済み / Accepted
- サービスがリクエストやメールを受け取った状態です。誰が受け付けたのかを確認する必要があります。アプリによるリクエストの受付、送信サービスによる処理依頼の受付、受信サーバーによるメールの受付は、それぞれ異なる証拠です。
- バウンス / Bounce
- 配信に失敗した際に返される通知やステータスです。アドレスが存在しない、ポリシーで拒否されたなど、さまざまな原因があります。エラーコードと説明を確認し、恒久的な失敗か一時的な失敗かを見極めてから再送を判断しましょう。
- 一時拒否 / Deferral
- リソース不足や送信制限などにより、サーバーが一時的にメールを受け付けない状態です。SMTP 4xxはこの種の状況でよく見られます。送信サービスが自動で再試行する場合もありますが、間隔や回数は受信トレイ側では決まりません。
- Message-IDとサービス側のメッセージID
- メールとログを関連付けるための識別子です。メールヘッダーのMessage-IDと送信APIが返すタスクIDは、必ずしも同じではありません。問い合わせの際は、それぞれの値と取得元を記録し、「送信成功」とだけ記載しないようにしましょう。
送信者認証
- SPF
- SPFはDNSを使って、エンベロープ送信者のドメインからメールを送信できるサーバーを指定します。SPFに合格しても、画面に表示されるFromアドレスが信頼できる送信者だとは限らず、メールが受信トレイに届く保証にもなりません。
- DKIM
- DKIMはメールの一部にドメインの電子署名を付け、受信側が公開鍵で検証する仕組みです。署名に合格すれば署名対象の部分が検証条件を満たしていると分かりますが、メールの内容が安全であることや、送信者の約束が真実であることまでは証明できません。
- DMARC
- DMARCはSPFまたはDKIMの認証結果と、表示されるFromドメインとの整合性を確認し、メールの処理方針を指定します。拒否ポリシーを設定しても配信成功が保証されるわけではありません。転送や第三者による送信では、適切な設定が必要です。
- FromとReturn-Path
- Fromは通常、ユーザーに送信者として表示されるアドレスです。Return-Pathはバウンスの返送先に関係します。両者が異なっていても、それだけで偽メールとは限りませんが、送信者の確認やバウンスの調査では分けて確認しましょう。
内容と検証
- OTP / ワンタイムパスワード
- 特定のリクエストに対して、限られた時間だけ本人確認に使うコードです。OTPを受信できたことから分かるのはメールが届いたことだけです。コードが使えるかどうかは、リクエストとの紐付け、有効期限、使用済みかどうかによって異なります。有効なコードを問い合わせチケットに貼り付けないでください。
- HTMLメールとテキストメール
- 一通のメールに、書式付きのHTML版と書式なしのテキスト版が含まれることがあります。どちらも確認しましょう。重要なリンク、認証コード、サービス情報は両方で一致している必要があり、画像の中だけに記載すべきではありません。
- CID埋め込み画像
- メール本文内のコンテンツIDを使って参照される画像で、添付ファイルと一緒に送られることがよくあります。使い捨てメールサービスがこの種の画像を保持しない場合、表示が不完全になることがあります。送信側が本文を送っていないとは限らないため、元のメール構造も確認してください。
- 認証コードの期限とメールアドレスの期限
- 認証コードの有効期限は送信元サイトが決め、メールアドレスの残り時間は受信サービスが決めます。アドレスの期限を延ばしても認証コードの有効期限は延びません。また、アドレスを変更しても登録済みサイトのアカウント情報は自動更新されません。
用語を見かけたら、まず確認すること
「合格」したのは何?
送信者認証、送信タスク、サービス上の認証コードが通ることは、それぞれ別の結果です。ログの取得元と、何を検証したのかをあわせて記録しましょう。
「成功」したのはどの段階?
アプリからの送信、サーバーによる受け付け、ユーザーによるメールの確認は、同じではありません。次の段階に進んだ証拠を探し、経路全体を判断しましょう。
「期限切れ」なのはどのタイマー?
まず、アドレス・認証コード・セッションを区別しましょう。本当に期限切れになったものだけに対処し、必要なくアドレスを何度も変更したり、新しいコードを何度も送信したりしないでください。
それぞれの期限は別々に管理されます
| 対象 | 期限を決めるもの | 注意点 |
|---|---|---|
| 使い捨てメールアドレス | 受信サービスが設定するアドレスの有効期限 | アドレスの期限を延ばしても、サイトの認証コードの期限は延びません |
| OTP | コードを送信したサイト | メールを受信しても、コードがまだ有効とは限りません |
| 転送履歴 | 当サイトの30日間の記録保存期間 | 転送先に届いたメールのコピーには影響しません |