完全なDMARC実装ガイド
複数のドメインやサブドメインの管理から、SPF、DKIMの調整、ポリシーの安全な実施まで、DNSにDMARCを完全に実装する方法を学びます。
基本的なDMARCレコードを公開したら、実際の作業が始まります:すべてのドメインとシステムにわたって正しく実装することです。
DMARC(Domain-based Message Authentication, Reporting & Conformance)は、組織内のすべてのメールソースが認証され、整合され、監視されている場合に、最も効果的に機能します。
このガイドでは、DNSでのDMARCの設定、マルチドメイン環境の管理、テストから完全な実施への安全な移行について、基本的なことを説明します。
DMARCの基本とポリシーの発行方法については、DMARCの概要と初期導入のための5ステップガイドをご覧ください。
ステップ1: 一元化されたDMARC戦略から始める
組織が複数のドメインやサブドメインを管理している場合、DMARCを単発のDNSレコードではなく、長期的なポリシーの枠組みとして扱います。特定することから始めましょう:
- すべての送信元(CRM、マーケティングツール、発券システム、人事プラットフォームなど)
- メール送信に使用するすべてのドメインとサブドメイン
- 社内で管理しているシステムと、サードパーティーベンダーが管理しているシステム。
各部門や事業部門がそれぞれ独自の送信設定を持っていることはよくあることです。しかし、連携したDMARC戦略がないと、レポートが断片的になり、実施も危険になります。
送信者のインベントリを作成し、それぞれがどのドメインから送信するかを決定します。これが完全なコンプライアンスの基礎となります。
ステップ2:すべての送信システムでSPFとDKIMを確認する
DMARCはメッセージの認証にSPFとDKIMを利用しています。どちらかが失敗したり、整合していない場合、DMARCも失敗します。
SPFチェック
各ドメインは、すべての認可された送信者をリストした単一のSPFレコードを持つべきである:
v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org -allベストプラクティス
- 10回以上のDNSルックアップの連鎖を避ける(SPFにはハードリミットがある)。
- 複数のSPFレコードを作成せず、1つにまとめる。
- 不正な送信者を拒否するために、常に
-allで終わらせる。
DKIMチェック
各メール送信システム(HubSpotやOffice 365など)は、DNSに追加するDKIMセレクタを提供しています:
セレクタ1._domainkey.yourdomain.comv=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9...
確認してください:
- すべてのサービスは、独自のDKIMキーでメッセージに署名します。
- d="フィールドは、あなたのドメインと一致します(位置合わせのため)。
- セキュリティ向上のため、キーは定期的にローテーションされる。
すべてのDKIMセレクタを文書化し、既知の送信元と関連付ける。こうすることで、後のトラブルシューティングが容易になります。
ステップ3:適切なDMARCレコードを発行する
DMARCレコードは、DNSに_dmarc.yourdomain.comの下に追加されるTXTエントリです。
実装の確実な出発点は次のようになります:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; aspf=r; adkim=rこれを分解してみよう:
- v=DMARC1 - 必要なプロトコルのバージョン。
- p=none - 監視モード(レポート収集、実施なし)。
- rua=mailto: - 集計レポートの送信先。
- aspf=r / adkim=r - アライメントの緩和(マルチドメイン・セットアップでより安全)。
複数のドメインを管理している場合は、一意のレポート・アドレスを使って区別する:
rua=mailto:dmarc@corp.yourdomain.com,mailto:dmarc@reports.partner.comサブドメインの場合は、 別のレコードを発行するか(例:_dmarc.mail.yourdomain.com)、組織ドメインからポリシーを継承します。
ステップ4:DMARCレポートの分析と整合性の検証
本番稼動後、メールボックス・プロバイダはDMARC集計(RUA)レポートを毎日送信し、どのIPがあなたのドメインにメールを送信し、それらがどのように実行されたかをまとめます。
探す
- 不明なIPがメールを送信している(スプーフィングの可能性)。
- SPFまたはDKIMに失敗している既知のシステム。
- 認証結果の不一致
各レポート行には以下が含まれます:
- SPFの結果:合格または不合格。
- DKIMの結果:合格または不合格。
- アライメント:各結果があなたのドメインと一致するかどうか。
正当な送信者がアライメントに失敗した場合は、実施に移る前に修正する。
より詳しい説明については、「DMARC集計レポートの読み方」のガイドを参照してください。
ステップ5:サードパーティの送信者への対応
DMARCの問題の多くは、マーケティングツール、CRM、または決済プロセッサのような、貴社に代わってメールを送信するサードパーティのプラットフォームに起因しています。
これらのメッセージがDMARCを通過するようにするには
- 送信者のIPを追加するか、SPFレコードにメカニズムを含める。
- 提供されたDKIMキーを公開する。
- From」ヘッダーに、一般的な共有ドメインではなく、貴社のドメインを使用していることを確認する。
ベンダーがDKIMアライメントをサポートしていない場合、拒絶を避けるためにSPFアライメントは完璧でなければならない。
ヒント:承認されたすべてのサードパーティの送信者とそのDNS設定のリストを社内で共有しておく。
ステップ6:監視から実施へ
すべての正当な送信者が正しく認証されていることが報告されたら、DMARCの施行を開始します。
徐々に移行する:
- p=none → p=quarantine(失敗したメッセージをスパムに送信)。
- p=quarantine → p=reject(失敗メッセージを完全にブロック)。
pctタグを使って部分的な強制をテストすることもできます:
v=DMARC1; p=reject; pct=50; rua=mailto:dmarc-reports@yourdomain.comv=DMARC1;p=reject;pct=50;。
エンフォースメントを強化するにつれて、毎日レポートを確認し続けてください。
ステップ7:サブドメインポリシーの設定
サブドメインはメインポリシーを継承するか、独自のポリシーを持つことができます。例えば
v=DMARC1; p=none; sp=reject; rua=mailto:dmarc-reports@yourdomain.comここで
- p=noneはメインドメインに適用されます。
- sp=rejectはすべてのサブドメインにDMARCを適用します。
メインドメインでテストしているが、billing.yourdomain.comのようなトランザクション用のサブドメインでより厳格に実施したい場合に使用する。
ステップ8:よくある実装ミスを避ける
よく準備されたチームでさえ、次のようなミスを犯します:
- 1つのドメインに複数のSPFレコードがある
ruaタグがない(レポートがない)。- いつまでも監視のみのポリシーを使用する
(p=none)。 - プラットフォーム変更後のDKIMキーの更新忘れ。
- 整列されていないサブドメインを無視する。
DMARCはアクティブに監視され、実施される場合にのみ保護されます。いつまでもp=noneのままにしておくと、なりすましからの保護にはなりません。
ステップ9:長期的な維持と監視
DMARCポリシーが完全に実施された後は、継続的な監視によってすべてが健全な状態に保たれます。
定期的に確認しましょう:
- レポートに表示される新しいIP(潜在的な新しい送信者)。
- 認証通過率の変化
- サードパーティの統合が正しく認証されているかどうか。
DMARCは「設定したら終わり」のシステムではありません。DMARCは、お客様のドメインのセキュリティ態勢を進化させるものです。
DMARCeyeが実装管理を支援する方法
DMARCの設定は一つの問題です。複数のドメインやプラットフォームでDMARCを維持することは、また別の問題です。DMARCeyeは、AIを活用したDMARC監視・管理プラットフォームです:
- DMARCレポートの収集と解釈
- すべての送信元を視覚的にマッピングします。
- 整合性のない送信者や未承認の送信者にフラグを立てます。
- ポリシー強化の進捗を追跡します。
実装がうまくいっているかどうか、調整が必要なシステムはどれか、完全なコンプライアンスにどれだけ近づいているかを簡単に確認できます。
今すぐDMARCeyeの無料トライアルをダウンロードして、メールドメインの保護を開始しましょう。