ドメインのセットアップ

ドメインのセットアップは、NTT CPaaSで本格的なメールメッセージを送信するための準備の最初のステップです。ドメインをセットアップすることにより、受信者との信頼関係を構築し、配信到達性を向上させ、高度なメール機能を利用できるようになります。

ドメイン戦略

強力なドメイン戦略は、メールの配信到達性を高いレベルで維持するのに役立ちます。送信者のレピュテーションはドメインとIPアドレスの両方に依存するため、慎重な計画が重要です。

メールトラフィックの種類ごとに個別のサブドメインを使用するようにします。メインドメイン (company.comなど) は、社内または企業のコミュニケーション用にk確保しておきます。サブドメインは、様々な種類のメール活動を分離し、メインドメインのレピュテーションの低下を防ぐのに役立ちます。

例えば：

マーケティング： mkt.company.com
トランザクション： trk.company.com
サポート： help.company.com

専用サブドメインを使用すると、配信到達性が向上し、レピュテーション管理が強化され、スパムフィルターによるDNSルックアップ処理が効率化されます。また、そうすることにより、特定のメール活動に関連するレピュテーションの低下や迷惑メールとして扱われてしまう問題が生じる原因を突き止め、それを解決しやすくなります。

アウトバウンドドメインの構成

アウトバウンドドメインはメールメッセージの送信に使用されますが、インバウンド (opens in a new tab)とアウトバウンドドメインは別々に管理されます。

NTT CPaaSでメールを送信するには、ドメインの登録が必要です。

ドメインを登録するメリット

配信到達性の向上：メッセージが迷惑メールフォルダーではなく受信トレイに届く可能性が高まります。
エンゲージメントの追跡：開封とクリックの追跡を有効にして、受信者がメッセージとどのようにやり取りするかを測定します。
登録解除の管理：ビルトインツールを使用して登録解除リクエストを処理し、コンプライアンスを維持します。
レピュテーションの管理：一貫したメール配信が維持できるように、ドメインのレピュテーションを保護して管理します。
インバウンド処理の有効化：ドメインへの返信またはインバウンドメッセージを直接受信して処理します。

推奨プラクティスUse a dedicated subdomain (for example, email.yourcompany.com) instead of your primary domain to isolate email activity. This protects your root domain’s reputation and simplifies deliverability troubleshooting.

アウトバウンドドメインの追加

Channels and Numbers (チャネルと番号) → Channels (チャネル) → Email (メール) → Outbound Email (アウトバウンドメール) に移動します。
Domains (ドメイン) タブで、Add new domain (新しいドメインの追加) を選択します。
必要な情報を入力します：
- Domain (ドメイン)：ドメイン名をプレフィックスなしで入力します。
- Targeted daily traffic (目標とする毎日のトラフィック)：予想される毎日のトラフィック量を指定します。この値は、ドメインのウォームアップをトリガーするのに役立ちます。制限に達すると、ウォームアッププロセスが開始されます。ウォームアップ中は、一度に送信できるキャンペーンは 1 つだけです。これは、Webインターフェイス送信者にのみ適用されます。
- DKIM key length (DKIMキー長)： 1024 または 2048 bits (ビット) を選択します。DomainKeys Identified Mailの略であるDKIMは、送信者の信頼性を検証します。キーが長いほど、より強力な保護が提供されます。この設定は永続的であり、後で変更することはできません。
Set up domain (ドメインのセットアップ) を選択してフォームを送信します。お使いのドメインプロバイダーに追加するためのDNSレコード (opens in a new tab)を受け取ります。

備考These records must be added to your domain provider’s DNS settings to complete verification. For details, see DNS records.

アウトバウンドドメインの検証

ドメインを登録したら、メールメッセージを送信する前に、そのドメインを Verify (検証) する必要があります。検証により、ドメインを所有していることが確認され、SPFやDKIM認証、追跡、インバウンド返信処理 (opens in a new tab) などの機能が有効になります。

ドメインを送信すると、NTT CPaaSが生成するDNSレコード (opens in a new tab) をドメインのDNS設定に追加する必要があります。これらのレコードは、ドメインの所有権を確認し、メール機能を有効にします。

DNSプロバイダーによっては、DNSの変更が反映されるまでに 最大48時間 かかる場合があります。各レコードのステータスは、ドメイン構成パネルで監視できます。必要なレコードがすべて確認されると、ドメインのステータスが Active (アクティブ) に変わります。

アウトバウンドドメインの管理

ドメインの検証が済んだら、メールのユースケースに合わせて設定を管理できます。ドメインの横にある 3ドットメニュー を選択して、以下のいずれかのオプションにアクセスします：

Manage (管理) - ドメイン構成ページを開きます。
Delete (削除) - ドメインを削除します。

ドメインを構成するには：

検証済みのドメインの横にある3ドットメニューを選択し、**Manage (管理)**を選択します。
以下のオプションを確認して更新します：
- DNS records (DNSレコード)：ドメイン検証に必要なDNSレコードを表示します。ドメインがまだ検証されていない場合は、これらのレコードをコピーしてDNSホストに追加します。レコードが伝播すると、ドメインはメールメッセージを送信する準備が整います。
- Domain pools (ドメインプール)：このドメインに関連付けられた送信プールを管理します。プールは優先度順に上から下へ並べられており、トラフィック配信時には最上位のプールが最初に使用されます。最上位プールが利用不可になった場合、システムは優先度リストの次のプールに自動的に切り替わります。ここでは、**+ Add (+ 追加)**ボタンを選択してドメインプールを追加できます。
  - ドメインプールを追加するには、+ Add (+ 追加) を選択し、割り当てるプールを個別に選択するか、**Select all (すべて選択)**をクリックします。Assign to domain (ドメインに割り当て) ボタンを選択して確認します。
  - プールを追加した後、必要に応じて優先度を調整したり、削除したりできます。変更を適用するには、**Save (保存)**を選択する必要があることをお忘れのないようにしてください。
- Tracking (追跡)：受信者のインタラクションを追跡する方法を構成します。
  - Open tracking (オープントラッキング)：受信者がいつメールを開いたかを監視します。
  - Click tracking (クリックトラッキング)：受信者がメッセージ内のリンクをクリックしたタイミングを追跡します。
  - Unsubscribe tracking (登録解除の追跡)：配信停止リストを使ってオプトアウトを管理します。
- Blocklist (ブロックリスト)：登録解除の処理方法を次の中から選択します：
  - From sender address (送信者アドレスから)：特定のメールアドレス(例：info@infobip.com) からのメッセージをブロックします。この場合、ユーザーは、その後も同じドメイン内の他のアドレスからメールを受信することがあります。
  - From this domain (このドメインから)：このアカウント (例： %infobip.com) が使用しているドメイン全体からのメッセージをブロックします。

ドメインに関する設定をコミュニケーションのニーズに合わせて調整したり、配信到達性や機能アクセス関連の問題のトラブルシューティングを行ったりする必要が生じた時は、ドメイン構成パネルを使用します。

DNSレコード

メールを適切に配信するには、次のDNSレコードを構成する必要があります。

レコードタイプ	レコード値	レコードの目的
TXT	このレコードの値は、Expected Value (期待値)列のDomain details (ドメインの詳細)で確認できます。	DKIM – なりすましからドメインを保護し、配信到達性を全体的に向上させます。
CNAME	`emailtracking.email-messaging.com`	メールに、デフォルトのNTT CPaaS追跡ドメインではなく、追跡リンク内の送信ドメインを含めることができるようにします。
CNAME	このレコードの値は、Expected Value (期待値)列のDomain details (ドメインの詳細)で確認できます。DMARCレコードは`_dmarc`で始まります。	DMARC – From アドレスのドメインを認証し、信頼性を高め、構成やなりすましの問題に関するレポートを提供します。
CNAME	クライアントのエンベロープドメインに基づいて動的に生成されます。	メール配信を成功させるために必要な SPF、MX および A レコードを伝播します。

TXTレコードを編集するための一般的なプロバイダー

DNSレコードを追加するプロセスは、ホスティングプロバイダーによって異なります。NTT CPaaSでは、以下のプロバイダーが採用している手順を段階的に説明する記事をそれぞれ用意しています：

DNSレコードが更新され、ドメインが検証されると、そのことを伝える通知メールがNTT CPaaSから届きます。また、ダッシュボードのドメインの横に Verified (検証済み) ラベルが表示されるようにもなります。

ドメインの検証には、NTT CPaaSとサービスプロバイダー間のDNS伝播に応じて、最大48時間 かかる場合があります。

検証後、各ドメインを追跡するかどうかを定義するトラッキング構成を個別に定めることができます。追跡機能はデフォルトで有効になっていますが、必要に応じて無効にすることができます。

インバウンドドメインの構成

インバウンドメールドメインとアウトバウンドメールドメインは、別々に管理されます。メールを送信するには、アウトバウンドドメインを作成 (opens in a new tab) する必要があります。インバウンドメールを受信する場合は、独自の MXレコード 構成を使用して別のインバウンドドメインを作成します。このようにセットアップすると、インバウンドメッセージを処理するドメインと、返信のルーティング方法を制御できるようになります。

Channels and Numbers (チャネルと番号) → Channels (チャネル) → Email (メール) → Inbound Email (インバウンドメール) に移動します。

Inbound Email (インバウンドメール) ページには、登録されているすべてのインバウンドドメインが一覧表示されます。検索バーを使って特定のドメインを見つけるか、新しいドメインを追加 (opens in a new tab) します。

各ドメインエントリーには、次の情報が表示されます：

Domain name (ドメイン名)：登録済みのインバウンドドメイン
Status (ステータス)：現在のドメインステータス (例： アクティブ、セットアップが未完了、アクションが必要)

ドメインを管理するには、その横にある3ドットメニューを選択し、以下のいずれかを選択します：

Manage (管理)：ドメイン構成ページを開きます
Delete (削除)：インバウンドドメインを削除します

インバウンドドメインの追加

新しいインバウンドドメインを登録するには：

Channels and Numbers (チャネルと番号) → Channels (チャネル) → Email (メール) → Inbound Email (インバウンドメール) に移動します。
Add inbound domain (インバウンドドメインの追加) ボタンを選択します。
ポップアップで、インバウンドメールの受信に使用するドメインを入力します。プレフィックスなしでドメイン名を入力します (例：https://example.com)。
Add domain (ドメインの追加) を選択します。

ドメインテーブルにドメインが表示されます。表示されたら、ドメインを管理 (opens in a new tab) して、 MXレコードやウェブフック転送を構成できるようになります。

インバウンドドメインの管理

インバウンドドメインを構成するには、ドメイン横にある 3ドットメニュー を選択し、**Manage (管理)**を選択します。

これにより、ドメイン構成ページが開き、セットアップを完了できます。

MXレコードの検証

このページに表示されている MX record (MXレコード) をDNS構成に追加します。
DNS changes (DNSの変更) が反映されるのを待ちます。
Verify (検証) を選択して、レコードが正しく構成されていることを確認します。

MXレコードの詳細には、次のものが含まれます：

Type (タイプ) - DNSレコードの種類
Name (名前) - DNS構成に追加するレコード名
Expected value (期待値) - MXレコードが解決すべき値
Current value (現在の値) - DNSで現在構成されている値
Status (ステータス) - レコードの検証ステータス

ウェブフックの構成

インバウンドメールの処理方法を選択します：
1. ウェブフック (HTTPプッシュ通知) - インバウンドメールを解析し、構造化されたコンテンツをウェブフックURLにリアルタイムで転送します (インバウンドメッセージごとに課金されます)。
2. MX record only (MXレコードのみ) - 転送せずに MXレコード経由でメールを受信します (追加費用なし)
インバウンド解析アクションを選択します：
1. Disable inbound parsing (インバウンド解析の無効化) - インバウンドメールの処理を停止します
2. HTTPプッシュ通知 - ウェブフックへの解析と転送を有効にします。
ウェブフックURL を入力して、インバウンドメールのデータ送信先を指定します。
Save (保存) を選択します。

インバウンドドメインの検証

インバウンドドメインを完全にアクティブ化するには、MXレコード と ウェブフック の両方を構成して検証する必要があります。

インバウンドドメインが完全に 構成済み かつ アクティブ であると見なされるのは、以下の場合のみです：

MXレコードが検証済み で、
ウェブフックが構成済み

構成状態

セットアップ内容に応じて、ドメインは次のいずれかの状態になります：

ウェブフックは構成済みだが、MXレコードは検証されていない
- 請求が有効
- ドメインが完全に構成されてない
- インバウンドメールが正しく機能しない
MXレコードは検証済みだが、ウェブフックは構成されていない
- 請求は有効でない
- ドメインが完全に構成されてない
- インバウンドメール処理が不完全
MXレコードの検証もウェブフックの構成も両方済んでいる
- 請求が有効
- ドメインは完全に構成済み
- インバウンドメールは期待どおりに機能

Reply-Toの構成

返信は、アウトバウンドメールのReply-Toヘッダーに基づいてルーティングされます。インバウンドドメインが送信 (アウトバウンド) ドメインと異なる場合は、Reply-Toヘッダーを設定して、返信が正しいアドレスに送信されるようにします。

Reply-To は、以下の方法で設定できます：

HTTP API：送信リクエストにreplyToフィールドを含めます。
SMTP API： SMTPリクエストにReply-Toヘッダーを追加します。
Webインターフェイス：メール設定内でReply-Toを構成します。

次の表で、一般的な返信ルーティングのシナリオと推奨されるセットアップについて概説します：

シナリオ	対処法
`infobip.com`から送信し、同じドメインで返信を受け取りたい。	インバウンドドメインとして`infobip.com`を作成します。そうするだけで返信をこのドメインで受け取るようになります。
`infobip.com`から送信し、`replies.infobip.com`で返信を受け取りたい。	インバウンドドメインとして`replies.infobip.com`を作成します。APIまたは Webインターフェイスを通じて、`Reply-To`ヘッダーをご希望のアドレス (例：`support@replies.infobip.com`) に設定します。
`infobip.com`から送信し、インバウンドは不要。	アクションを起こす必要はありません。インバウンドドメインも作成する必要はありません。

備考

インバウンドとアウトバウンドのドメインが同じ場合、Reply-To の設定は不要です。返信は、デフォルトで送信アドレスにルーティングされます。

解析されたインバウンドトラフィックの受信

ウェブフック転送を構成すると、登録済みのインバウンドドメインに送信されたインバウンドメールが自動的に処理されます。NTT CPaaSは、メッセージコンテンツを抽出し、構造化された形式 (解析されたペイロード) に変換し、指定したウェブフックURLに転送してリアルタイムに処理します。

解析されたペイロード構造の例については、APIドキュメントに記載されている解析されたメールの受信 (opens in a new tab)エンドポイントをご参照ください。

エンベロープドメインシステム

メインドメインを使用してメールを送信する場合、そのメールのレピュテーションを下げないようにしなくてはなりません。NTT CPaaSは、新しい送信者ドメインを登録するたびに、一意のエンベロープドメイン を自動的に作成します。このエンベロープドメインは、メインの送信ドメインを公開したり危険にさらしたりすることなく、バウンスと配信エラー を管理します。

エンベロープドメインは、メール配信中にバックグラウンドで機能します。バウンスメッセージを転送し、DKIM (DomainKeys Identified Mail) などの認証メカニズムをサポートします。受信者には通常表示されませんが、メールヘッダー全体を表示するとReturn-Pathフィールドに表示されます。

その仕組み

NTT CPaaSは、エンベロープドメインとして機能するサブドメイン (例えば、ib38450.example.com) を生成します。この分離により、バウンス処理をプライマリードメインから分離しながら、配信到達性、モニタリング、トラブルシューティングを向上させることができるようになります。

アウトバウンドメールは、表示されている From アドレスにお使いの rootドメイン を使用しますが、実際には envelope-from サブドメインを使用して送信されます。

DMARCアライメント

DMARCアライメントは、メールメッセージが受信者に見える送信元アドレス (VBFR) に示されているのと同じドメインを使って認証されるかどうかを決定します。

DMARC認証に合格するには、少なくとも1つの方法で認証とアラインメント (VBFRドメインと一致するかどうか) の両方に合格する必要があります：

DKIM 認証とアライメント、または
SPF 認証とアライメント

DMARCレコードには、集計レポートやフォレンジックレポートなど、認証結果を可視化するタグを含めることもできます。これらのレポートは、アライメントを監視し、構成または配信の問題を特定するのに役立ちます。

DMARCタグ

DMARCレコードは、ドメインからのメッセージの処理とレポート設定の定義の方法を受信メールサーバーに指示するタグと値のペアで構成されています。DMARCアライメントの動作は、DNSレコードのDMARCタグを使って構成されます。

各タグには特定の目的があります。例えば、レコードがp=none; sp=quarantine; pct=100となっている場合、それはDMARC認証に失敗したプライマリードメインからのメッセージは監視されるが強制されないのに対し、DMARC認証に失敗したサブドメインからのメッセージはすべて隔離されることを意味します。

これらの設定に基づいて SPFとDKIMのどちらの認証とアラインメントも合格しない場合、DMARCポリシーが受信メールサーバーによって適用されます。

以下の表は、主なDMARCタグとそれぞれの機能をまとめたものです。

タグ	必須	説明
`v`	はい	DMARCプロトコルのバージョンを指定します。有効な値は`DMARC1`のみです。
`p`	はい	DMARC認証に失敗したプライマリードメインからのメッセージに適用されるポリシーを定義します。サポートされている値は、`none`、`quarantine` と`reject` です。
`sp`	いいえ	サブドメインがプライマリードメインのポリシーと異なる場合に適用されるポリシーを定義します。
`pct`	いいえ	DMARC ポリシーが適用されるメッセージの割合を指定します。
`aspf`	いいえ	SPF アライメントモードを定義します。サポートされている値は、`r` (緩和) と `s` (厳密) です。
`adkim`	いいえ	DKIMアライメントモードを定義します。サポートされている値は、`r` (緩和) と `s` (厳密) です。
`rua`	いいえ	認証統計情報を含む集計DMARCレポートを受信するメールアドレスを指定します。
`ruf`	いいえ	認証失敗に関するメッセージレベルのフォレンジックレポートを受信するメールアドレスを指定します。
`fo`	いいえ	フォレンジックレポートを生成するタイミングを制御します (例えば、SPFの失敗、DKIMの失敗、またはその両方)。
`rf`	いいえ	フォレンジックレポートに使用する形式を指定します。
`ri`	いいえ	集計レポートが送信される間隔を秒単位で定義します。

DKIMアライメント

DKIMアライメント は、DKIM署名 (d=タグ)で使用されるドメイン が VBFRドメイン と一致しているかどうかを評価します。

備考NTT CPaaS Email uses strict DKIM alignment by default.

厳格なDKIMアライメント

厳格なアライメントでは、DKIM署名ドメインはVBFRドメインと完全に一致する必要があります。

DKIMタグドメイン：example.com
VBFR：info@example.com

緩和されたDKIMアライメント

緩和されたアライメントでは、DKIM署名ドメインはVBFRドメインと同じ組織のドメインに属している必要があります。サブドメインは許可されます。

DKIMタグドメイン：ib.321.example.com
VBFR：info@example.com

DKIMアライメントがDMARCに与える影響

DKIMアライメントだけでは、いかなるアクションも強制されません。この場合、メッセージがDMARC認証に合格したかどうかは、DMARCとSPFアライメントを合わせた 評価で決まります。

SPFアライメント

SPFアライメント は、SPFによって認証されたドメインが受信者に見える送信元アドレス (VBFR) と一致するかどうかを照合します。SPF認証は、エンベロープ送信者ドメイン (MAIL FROMまたはReturn-Pathドメインとも呼ばれる) に基づいており、送信IPアドレスと照合されます。

SPFアライメントはDMARCによって評価され、それ自体では何のアクションをも強制しません。

SPFアライメントモード

SPFアライメントの動作は、緩和されたアライメントと厳格なアライメントの両方をサポートするDMARCの aspfタグによって制御されます。

厳格なSPFアライメント

厳格なアライメントでは、エンベロープ送信者ドメインはVBFRドメインと完全に一致する必要があります。

エンベロープ送信者ドメイン：example.com
VBFR：info@example.com

緩和されたSPFアライメント

緩和されたアライメントでは、エンベロープ送信者ドメインはVBFRドメインと同じ組織ドメイン**に属している必要があります。サブドメインは許可されます。

エンベロープ送信者ドメイン：mail.example.com
VBFR：info@example.com

SPFアライメントとDMARC

DMARC認証に合格するには、SPFがaspf設定に基づいて認証に合格し、VBFRドメインと一致する必要があります。SPFは認証に合格してもアライメントに合格しない場合は、DMARCの要件を満たしません。ただその場合でも、DKIMアライメントによって、メッセージがDMARC認証に合格することもあります。

遅延バウンスとレポート

遅延バウンスはレポートには反映されず、プロバイダーが配信を確認すると、メッセージのステータスはdelivered (配信済み)のままです。遅延バウンス情報がその後に届いた場合、メッセージのステータスは更新されません。

遅延バウンスイベントを受信するには、遅延バウンスウェブフックにサブスクライブします。

詳細については、遅延バウンスについて詳述しているドキュメントをご参照ください。

初めてのメールメッセージを送信する IP と IP プールを管理する