OCI Email Delivery

解決する課題

自前でメールサーバー（MTA）を立てて IP の評判管理や認証設定を運用せずに、アプリケーションからのメールを確実に届けられます。

• パスワードリセット・登録確認・領収書などのトランザクションメールを確実に届けたい
• 大量送信時の**到達率（デリバラビリティ）**を保ち、迷惑メール判定を避けたい
• SPF・DKIM・DMARC といった認証設定を正しく行いたいが運用負荷を下げたい
• バウンスや苦情を把握して**送信者評判（レピュテーション）**を維持したい

主要概念と用語

• 承認済み送信者（Approved Sender）: 送信元として使う From アドレス。事前に登録した送信者からのみ送信できる
• 送信ドメイン（Email Domain）: DKIM 署名や認証の単位となるドメイン。ドメインを登録して認証レコードを設定する
• SMTP 認証情報（SMTP Credentials）: SMTP 経由で送信する際のユーザー名・パスワード。IAM ユーザーに紐づけて発行する
• DKIM: 送信ドメインの秘密鍵でメールに署名し、受信側が公開鍵（DNS の TXT/CNAME）で検証する仕組み。なりすまし対策と到達率向上に効く
• SPF: 送信元 IP がそのドメインの正規送信元かを DNS で宣言する仕組み
• バウンス / 苦情（Bounce / Complaint）: 宛先不達や受信者の迷惑メール報告。放置すると評判が下がる
• サプレッションリスト（Suppression List）: バウンスや苦情が出た宛先を自動で登録し、以後の送信を抑止する一覧

仕様・制限・クォータ

• 送信専用サービス。メールの受信（受信箱）機能は持たない。受信が要るなら別の手段を使う
• 送信は SMTP または 送信用 API から行う。アプリの言語を問わず連携できる
• 送信元は承認済み送信者として事前登録したアドレスに限られる
• 新規テナンシには送信レート/日次送信量の初期上限があり、評判や利用実績に応じて引き上げ申請できる
• バウンス・苦情が出た宛先はサプレッションリストで自動的に送信抑止される
• リージョナルサービス。エンドポイントはリージョン単位で、送信は作成したリージョンの設定に従う
• 添付や本文サイズには上限があり、超過分は送信できない（具体値は公式を参照）

内部の仕組み

アプリケーションは SMTP エンドポイント（SMTP 認証情報で認証）または送信用 API にメッセージを渡します。サービスは承認済み送信者かを検証し、送信ドメインの DKIM 鍵で署名したうえで、評判が管理された送信 IP プールから受信側 MTA へ配送します。受信側は DNS 上の SPF・DKIM レコードで認証を検証し、正規の送信元と判断したメールを受信箱へ通します。

宛先が不達（ハードバウンス）だったり受信者が迷惑メール報告（苦情）をすると、その宛先はサプレッションリストへ自動登録され、以後の送信が抑止されます。これにより無効な宛先への再送を防ぎ、送信 IP の評判低下を抑えます。

設計パターン / ベストプラクティス

• トランザクションメールの送信基盤: アプリの確認・通知メールを SMTP/API で送る最も一般的な用途
• 通知サービスとの併用: 監視アラートは Notifications（Email 宛先）で簡易に飛ばし、ユーザー向けの整形メールは Email Delivery で送る、と役割を分ける
• ドメインの分離: マーケティング系と重要なトランザクション系で送信ドメイン/サブドメインを分け、片方の評判低下が他方に波及しないようにする
• バウンス処理の自動化: バウンス・苦情の通知を受け取り、自社の宛先リストからも除外して再送を止める
• 段階的なウォームアップ: 新しい送信ドメインは少量から送信量を徐々に増やし、IP/ドメインの評判を育てる

運用・監視

• 送信メトリクス（送信数・配信・バウンス・苦情など）を監視し、バウンス率・苦情率の急増を早期に検知する
• サプレッションリストを定期的に確認し、抑止された宛先の傾向（無効アドレスの混入など）を把握する
• DKIM/SPF レコードの有効状態を監視し、DNS 変更で認証が壊れていないか確認する
• 送信ドメインや承認済み送信者の追加・変更は **OCI Audit（監査ログ）**に記録され、誰がいつ変更したか追跡できる
• バウンス率・苦情率が上限に近づくと送信が制限されうるため、しきい値をAlarmで通知して未然に対処する

コスト

セキュリティ

• IAM ポリシーで送信ドメイン・承認済み送信者・SMTP 認証情報の管理操作を最小権限に制御する
• SMTP 認証情報は IAM ユーザーに紐づくシークレット。漏洩すると不正送信に使われるため、専用ユーザーに発行し、不要になったら失効させる
• 送信は TLS で暗号化し、平文 SMTP を避ける
• DKIM 署名でなりすましを防ぎ、DMARC ポリシーを併用して自ドメインを騙るメールを受信側に拒否させる
• 機微情報を本文に直接載せず、必要なら認証付きのリンク先で表示する

関連サービス・比較（AWS との対応）

ハンズオン / CLI例

# 送信ドメイン（Email Domain）を作成
oci email email-domain create \
  --compartment-id "$COMPARTMENT_OCID" \
  --name "mail.example.com"

# 承認済み送信者（From アドレス）を登録
oci email sender create \
  --compartment-id "$COMPARTMENT_OCID" \
  --email-address "noreply@mail.example.com"

# 登録済みの承認済み送信者を一覧
oci email sender list --compartment-id "$COMPARTMENT_OCID" \
  --query "data[].{Email:\"email-address\", State:\"lifecycle-state\"}" --output table

# SMTP 認証情報を発行（IAM ユーザーに紐づく。出力のパスワードは一度しか表示されない）
oci iam smtp-credential create \
  --user-id "$USER_OCID" \
  --description "email-delivery-app"

# 以降は払い出された SMTP ホスト/ポート/認証情報を使い、
# アプリの SMTP クライアントから承認済み送信者を From にしてメールを送信する