委託先メールをDMARCで安全に運用する設計

この記事でわかること

結論：外部委託先（SaaS・ESP・代理送信）から送られるメールは、事前の同意と技術的調整（SPF/DKIM/DMARCの設計）でDMARC準拠にでき、委託先の負担を最小化できます。

理由：DMARCは"送信ドメインの整合性"を確認する仕組みで、SPFかDKIMのいずれか（または両方）が送信ドメインと整合していれば許容されます。これを利用して、DNS側の設定（SPF include、DKIM署名権限付与、サブドメイン運用など）と委託先の署名方針を組み合わせることで実現します。

以下で、設計方針、具体手順、よくあるトラブルと対処法、他技術との関係をわかりやすく説明します。

外部委託先をDMARCで保護しつつ負担を減らす基本方針（結論）

最優先は「送信ドメインの所有者（ドメイン管理者）が認可すること」。技術的には次のいずれか、または組合せで対応します。

• SPF：委託先の送信IPを自ドメインのSPFに含める（include推奨）
• DKIM：委託先に自ドメインで署名してもらう、または委託先のSelectorを自ドメインのDNSに配置
• サブドメイン分離：委託送信用に専用サブドメインを割り当て、DMARCを適切に設定する

ユーザー（委託先）負担を減らすポイント：

• 署名キー（DKIM）発行をドメイン所有側で管理する（可能な場合）
• テンプレートやワークフローを標準化し、実装手順をドキュメント化する
• 段階的にDMARCポリシーを強化する（p=none → quarantine → reject）

仕組み（初心者向け解説）

SPF・DKIM・DMARCの役割を簡単に

• SPF：送信を許可するIPリストをDNSで宣言する。例えると"誰がその会社のユニフォームでメールを投函できるか"の名簿。
• DKIM：メールに電子署名を付ける。例えると"差出人が封筒に自署したサイン"。
• DMARC：SPFとDKIMの結果と"Fromヘッダに一致しているか"を見て動作を決める"監査と指示書"。

どこでつまずくか（委託先特有の問題）

• 送信IPが複数あるSaaSだとSPFレコードが長くなりやすい
• 委託先が自社ドメインでしかDKIMを署名できない場合、Fromと整合しない
• 転送や一部の受信環境で整合性が崩れるケース（中継によるヘッダ改変）

具体例：よくある3つの設計パターン（結論→理由→例→手順）

パターンA：自ドメインに委託先の送信IPを追加（SPF include中心）

結論：委託先がIPベースで送信する場合は最も簡単。SPFにincludeを追加してDMARCのSPF整合を得る。

理由：SPFはIP照合なので、正しいIP範囲を含めれば受信側で合格になりやすい。

例：ニュースレター配信を外注し、外注が独自の送信IPプールを使う場合。

手順：

1. 委託先から公式のSPF include文字列を受け取る（例: "include:mail.example-esp.com"）。
2. 自ドメインのDNSのSPFレコードを編集して include を追加する（既存のTXTレコードを編集）。

v=spf1 include:mail.example-esp.com include:_spf.google.com -all

注意点：SPFの文字数制限とDNSクエリ数（10ルックアップ制限）に注意。

パターンB：自ドメインでDKIM署名を行う（委託先の協力が必要）

結論：DKIMで自ドメインを署名できれば、SPFに頼らずDMARC合格を得られるため安定度が高い。

理由：DKIMは署名が残るため、転送や中継でSPFが壊れても有効な場合が多い。

例：SaaSが外部のDKIM鍵登録をサポートし、管理側のDNSに公開鍵を置けるケース。

手順：

1. 委託先に自ドメイン名（例: selector._domainkey.example.com）で公開鍵をDNSに掲載する手順を依頼する。
2. 委託先で署名に使用するselector名と公開鍵を合意する。
3. DNSに公開鍵を追加する。

selector1._domainkey.example.com IN TXT "v=DKIM1; k=rsa; p=MIIBIj..."

注意点：キー管理やローテーションの責任分担を明確にすること。

パターンC：サブドメイン分離（例: mail.example.com に委託）

結論：委託先専用サブドメインを用意し、DNSとDMARCを分けて管理することでリスクと負担を分離できます。

理由：メインドメインのDMARCポリシーに影響を与えずに運用でき、委託先にはサブドメインの管理範囲だけを依頼できる。

例：プロモーションメールは promo.example.com で全て送信する。

手順：

1. サブドメインのDNSを用意し、SPF/DKIM/DMARCをサブドメイン専用で設定。
2. 委託先にFromヘッダをサブドメインに合わせてもらう。

promo.example.com. TXT "v=spf1 include:mail.example-esp.com -all"
promo._domainkey.promo.example.com. TXT "v=DKIM1; k=rsa; p=..."
_dmarc.promo.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@example.com"

注意点：ブランディング（Fromアドレスの見え方）と顧客信頼の調整が必要。

実践手順：合意フローと技術チェックリスト

結論：同意と技術設定はワークフロー化すると失敗が少ない。以下は推奨プロセスです。

同意・契約フェーズ（事前）

1. 送信ドメインとFromポリシーの決定（メインドメイン or サブドメイン）
2. 責任分担表の作成（DNS編集権限、鍵管理、ログ共有）
3. SPF/DKIM/DMARC の要件を契約に記載

技術実装フェーズ

1. 委託先から必要情報を取得：SPF include、DKIM selector/公開鍵、送信IPレンジ
2. DNSの変更をステージングで検証（DNS TTL短めに）
3. メールを実送してSPF/DKIM/DMARC検証ツールで確認（第三者ツールやGoogle/Microsoftのレポート）
4. 問題がなければDMARCポリシーを段階的に強化

監視・運用フェーズ

• DMARCのrua（Aggregate report）で送信状況を定期確認
• 異常が出たらすぐにロールバックや一時的にp=noneに戻す運用ルールを用意

よくあるトラブルと対処法

トラブル1：SPFが10ルックアップを超える

対処法：SPF flatteningを使わずに、委託先と協力してincludeを整理する。必要であればサブドメイン運用へ移行。

トラブル2：受信でDKIMが破られる（署名不一致）

対処法：送信経路でヘッダを書き換える中継がないか確認し、委託先に署名タイミング（最終送信直前に署名）を確認する。可能ならARCの導入を検討する。

トラブル3：DMARCレポートが大量で解析が追いつかない

対処法：集約ツールを導入して視覚化する。重要なのは"差出人ドメインに無関係な第三者送信"を見つけること。

他の技術との関係（ARC・BIMIなど）

ARC：中継によって破られた認証を補助するための仕組み。全ての受信系がARCを評価するわけではないが、転送が多い場合は有効。

BIMI：ブランドアイコン表示の仕組みで、DMARCの強いポリシー（p=quarantine/reject）と連動して効果を発揮します。

まとめ（結論の再掲と推奨）

結論：委託先の負担を減らす最短ルートは次の順序で検討すること：1) SPF include（簡便）、2) DKIMで自ドメイン署名（安定）、3) サブドメイン分離（リスク分離）。

推奨アクション：

1. まず現状を可視化（どの委託先がどの方法で送信しているか）
2. 優先度の高い送信から上記パターンで対応
3. DMARCレポートを見ながら段階的にp=quarantine/rejectに移行

最後に、技術実装だけでなく契約と責任分担を明確にすることが成功の鍵です。