クラウドサービス

OCI Email Delivery

アプリからの大量メールを高い到達率で送れるマネージドの送信基盤。SMTP/API で組み込め、SPF・DKIM で認証する。AWS の Amazon SES に相当する。

基礎信頼性運用上の優秀性セキュリティコスト最適化
最終更新: 2026-07-29公式ドキュメント
3つの要点
TL;DR
  1. SMTPまたはHTTPS APIでアプリのメールを送信する。
  2. SPFとDKIM、サプレッションで送信評判を守る。
  3. 業務IDで二重送信を防ぎMessage-IDは追跡に使う。

解決する課題

自前でメールサーバー(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 から行う。アプリの言語を問わず連携できる
  • 送信元は承認済み送信者として事前登録したアドレスに限られる
  • エンタープライズアカウントの既定上限は 1日 50,000 通・毎分 18,000 通、承認済み送信者は 10,000件、SMTP資格情報は IAM ユーザーあたり 2件。無料トライアルは1日200通・毎分10通・承認済み送信者2,000件で、必要ならサービス制限の引き上げを申請する
  • バウンス・苦情が出た宛先はサプレッションリストで自動的に送信抑止される
  • リージョナルサービス。エンドポイントはリージョン単位で、送信は作成したリージョンの設定に従う
  • メッセージは既定 2 MB。SPF と DKIM を設定したうえで最大 60 MBまで引き上げを申請できるが、大きな添付は Object Storage の期限付きURLへ逃がす

内部の仕組み

横にスクロール

アプリがSMTPまたはHTTPS APIでメールを送信し、送信者検証とDKIM署名を経て受信側へ配送される経路を示す図
受付、配送、サプレッションはOCIが担う。同意、宛先品質、再試行時の二重送信防止は利用者が担う

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

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

DKIM と SPF は必ず設定する

DKIM 署名と SPF レコードを正しく設定しないと、受信側で認証に失敗して迷惑メール扱い・拒否されやすくなります。送信ドメインを登録したら、表示される DNS レコードを反映し、認証が有効になってから本番送信に進みます。

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

  • トランザクションメールの送信基盤: アプリの確認・通知メールを SMTP/API で送る最も一般的な用途
  • 通知サービスとの併用: 監視アラートは Notifications(Email 宛先)で簡易に飛ばし、ユーザー向けの整形メールは Email Delivery で送る、と役割を分ける
  • ドメインの分離: マーケティング系と重要なトランザクション系で送信ドメイン/サブドメインを分け、片方の評判低下が他方に波及しないようにする
  • バウンス処理の自動化: バウンス・苦情の通知を受け取り、自社の宛先リストからも除外して再送を止める
  • 段階的なウォームアップ: 新しい送信ドメインは少量から送信量を徐々に増やし、IP/ドメインの評判を育てる
  • 二重送信の防止: 業務IDごとの送信受付結果をアプリ側に保存し、再試行前に確認する。Message-ID はサービスログとの相関に使えるが、同じIDでの再送を拒否する冪等性キーではない

運用・監視

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

コスト

毎月最初の 3,000通は無料で、超過分は 1,000通あたり 0.085 USDです。配信失敗を無制限に再試行すると料金だけでなく送信評判も悪化するため、恒久エラーと一時エラーを分けます。

項目課金の考え方備考
送信メール数月3,000通まで無料、以後1,000通0.085 USD恒久エラーへの再送を止める
送信ドメイン/承認済み送信者登録自体に料金はかからない課金は基本「送信した数」で発生
データ転送通常の送信に伴う転送は送信料金に含まれる大量配信ではボリュームディスカウントの対象になりうる

セキュリティ

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

SMTP 認証情報をアプリのソースコードや共有アカウントに埋め込むのは NG。漏洩するとスパム送信に悪用され、送信ドメインの評判が一気に毀損します。認証情報は専用 IAM ユーザーに発行し、シークレット管理(OCI Vault など)から安全に渡し、ローテーションします。

関連サービス・比較(AWS との対応)

観点OCI Email DeliveryAmazon SES
位置づけOCI のマネージド送信メール基盤AWS のマネージド送受信メール基盤
主な用途トランザクション/大量送信トランザクション/大量送信
送信方式SMTP / 送信用 APISMTP / SES API
認証承認済み送信者 + DKIM / SPF検証済み ID + DKIM / SPF
受信機能なし(送信専用)あり(受信ルールで受信可能)
評判管理サプレッションリスト / バウンス苦情監視サプレッションリスト / 評判ダッシュボード
スコープリージョナルリージョナル

ハンズオン / 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 にしてメールを送信する

# HTTPS Submission API 用の複合パラメータ雛形を生成
oci email-data-plane email-submitted-response submit-email \
  --generate-param-json-input sender > sender.json
oci email-data-plane email-submitted-response submit-email \
  --generate-param-json-input recipients > recipients.json

# sender.json / recipients.json を編集後、書式済みメールを送信
oci email-data-plane email-submitted-response submit-email \
  --sender file://sender.json \
  --recipients file://recipients.json \
  --subject "処理完了のお知らせ" \
  --body-text "処理が完了しました" \
  --message-id "job-12345@mail.example.com"

OCI Service

OCI Email Deliveryを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

アプリ統合

比較で見る軸

クラウド: OCI / カテゴリ: アプリ統合 / 難易度: basic

導入後に効く点

SPFとDKIM、サプレッションで送信評判を守る。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
OCI
カテゴリ
アプリ統合
難易度
basic
関連資格
設計柱
reliability / operational / security / cost

判断チェックリスト

  • 自社の用途が「アプリ統合 / reliability」に近いか確認する。
  • 強みである「SMTPまたはHTTPS APIでアプリのメールを送信する。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

アプリ統合reliabilityoperationalsecuritycost