課題 (Situation/Task)

なりすましメール対策として、メールの送信元認証（SPF、DKIM、DMARC）の要件が年々厳格化しています。

SaaSやECプラットフォームなどのマルチテナントシステムにおいて、ユーザーが自身の独自ドメイン（例：example.com）を使用してトランザクションメールを送信するケースは一般的です。しかし、認証の種類や複雑さが増すにつれ、ドメインを利用するユーザー側に要求されるインフラリテラシーが増大しています。

特に、専任のインフラ担当者が不在の小規模な組織では、「自身でドメインを取得したものの、DKIMやDMARCのDNSレコード設定方法がわからない」というケースが多発し、結果として重要なトランザクションメールが不達になる課題を抱える現場が増えています。

本記事では、ユーザーがDNS設定（DKIMやDMARC）に対応できない状況下において、確実にメールを届けるためのシステム的な送信アーキテクチャの選択肢を比較・検討します。

解決策 (Action)

DNS設定の変更が困難なユーザーに対するアーキテクチャの代替手段として、以下の3つのアプローチを検討しました。

アプローチ1：システム共通ドメインからの送信 ＋ Reply-To（返信先）指定

ユーザーにDNSを操作させず、プラットフォーム側で確実なメール配送を担保する仕組みです。

(図1：アプローチ1のメール送信と返信の仕組み)

仕組み:

• メール生成 (Step 2): SaaSプラットフォームが、送信元（From）を自身の認証済みシステムドメインに強制し、返信先（Reply-To）をユーザーの希望アドレスに設定します。
• メール配送 (Step 4): システムドメインとして送信されるため、プラットフォーム側のメールサーバーでSPF/DKIM署名が完全に機能し、高い到達率が担保されます。
• エンドユーザーの返信 (Step 6-7): エンドユーザーがメーラーの「返信」ボタンを押すと、メーラーはReply-Toヘッダーを参照するため、返信メールはユーザー（店舗）のアドレス宛に送信されます。

メリット: ユーザー側のインフラ作業が一切不要です。プラットフォーム側でSPFおよびDKIMが完全に担保されているため、高い到達率を維持できます。

デメリット: 送信元のドメインと、ユーザーのサイトドメイン（例：shop.example.com）が異なるため、エンドユーザーに「偽サイトではないか」という不信感を与えるリスクがあります。

緩和策:

• メーラー上で目立つ「送信者名（表示名）」をユーザーのサービス名に工夫する（例："XXXX オンラインストア" <noreply@システムドメイン>）。
• 自動送信メールの冒頭やヘッダーに、システム経由で自動送信されている旨を明記して安心感を持たせる。

アプローチ2：外部SMTPサーバー連携

ユーザーが契約・管理している外部メールサーバーの「SMTP認証情報（ホスト、ポート、ID、パスワード）」をシステムに入力してもらい、そのサーバーを間借りして送信する仕組みです。

(図2：アプローチ2のメール送信と課題)

仕組み:

• メール生成 (Step 2): SaaSプラットフォームが、ユーザー独自ドメインの「From」を維持したメールを生成します。その際、ユーザーが設定した外部SMTPの認証情報（ホスト、ポート、ID、パスワード）を参照します。
• SMTP送信要求 (Step 3): プラットフォームから外部SMTPサーバーへ接続し、認証と送信要求を行います。この図では、同期処理によってプラットフォーム側の画面がフリーズ（数秒〜10秒）する可能性を明示しています。
• メール配送 (Step 4): 外部SMTPサーバーによってSPF/DKIM署名が付与され、配送されます。

メリット: エンドユーザーへの不信感を解消しつつ、DNSが編集できない問題もクリアできます。

デメリット:

• 原因切り分けの困難さ: メール不達時に、原因がシステム側にあるのか、外部SMTP側にあるのかの特定が非常に困難になります。
• プロバイダの仕様変更や認証エラー: 各メールプロバイダ（特にGoogle Workspaceなど）のセキュリティポリシー変更に振り回され、サポートコストが増大します。また、パスワード変更による突然の送信エラーも発生しやすくなります。
• パフォーマンスとトランザクションへの影響: 同期処理で外部SMTP通信を行うと、遅延（数秒〜10秒以上）が発生し、決済プロセス中の画面フリーズや、タイムアウトによる二重決済などの重大なトラブルを誘発する恐れがあります（非同期処理化でパフォーマンスへの影響は緩和可能ですが、送信の確実性は外部依存となります）。
• レートリミットによる凍結リスク: 外部サービスにはスパム対策として厳格な送信上限があり、注文集中時などにアカウント自体が凍結されるリスクがあります。

アプローチ3：DNS設定の「管理代行」（ネームサーバー移譲）

プラットフォーム側のWAF/CDN基盤（Cloudflare等）へネームサーバーごと移譲してもらい、DNSレコードの管理をプラットフォーム側で巻き取る運用です。

(図3：アプローチ3のメール送信と運用の仕組み)

仕組み:

• 初期設定: ユーザー（店舗様）が、自身の「ドメインレジストラ（管理パネル）」で、ネームサーバーをプラットフォーム管理のサーバー情報に変更します。この1度きりの作業によって、DNSの管理権限がプラットフォーム側へ移譲されます。
• メール送信要求: SaaSプラットフォームは、ユーザー独自ドメインの「From」を維持したまま送信要求を行います。
• DNSレコードの参照 (Step 3-4): プラットフォーム側のメールサーバーは、自社で管理するネームサーバーに対して、SPF/DKIM/DMARCレコードを参照します。
• メール配送 (Step 5): プラットフォーム管理下のネームサーバー情報に基づいてSPF/DKIM署名が付与され、配送されます。アプローチ2で課題となっていた同期処理の遅延や、外部サーバー側のレートリミットによる凍結リスクが解消されています。
• エンドユーザーの返信 (Step 7-8): Reply-ToではなくFromアドレスへの返信となるため、エンドユーザーにとっても不信感がなく、自然なコミュニケーションが可能です。

メリット: エンドユーザーの不信感を解消し、インフラ担当者不在の問題をクリアしつつ、アプローチ1と同様にシステム側でSPF/DKIMを担保できるため、高い到達率を実現できます。

デメリット: ドメイン管理画面でネームサーバーを変更するという、初期設定の作業が1度だけ発生します。

緩和策: ユーザーが使用している主要なドメイン管理サービスごとに、「管理画面にログインし、この文字列をそのままペーストしてください」という専用の手順書を作成して提供する。

結論 (Result)

3つのアプローチを比較検討した結果、トランザクションの確実性とシステム運用負荷の観点から、「アプローチ2（外部SMTP連携）」はシステムに対する不確実性が高すぎる（レートリミットや仕様変更のコントロールが不可能）ため、SaaSプラットフォームのアーキテクチャの選択肢としては推奨しがたい、というのが私の意見です。

到達率と信頼性を両立できる　「アプローチ3（DNS管理代行）」を基本方針　としつつ、ネームサーバーの移譲すら対応が難しいケースに対するフォールバックとして　「アプローチ1（システムドメイン＋Reply-To）」の機能を拡充　する設計がよいかもしれません。

また、メール送信元認証の厳格化は今後も進むと予想されるため、メール自体に依存しない通知手段（システム内のメッセージボードや通知機能など）の拡充も並行して進めることで、より堅牢な顧客コミュニケーション基盤の構築が可能になるのではないでしょうか。