Skip to main content
New SPF lookups must resolve in milliseconds — why a DMARC tool's add-on isn't enough Learn Why → →

DMARC とは？

DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、RFC 7489 で定義され、SPF と DKIM の上に構築されるメール認証プロトコルです。ドメイン所有者がポリシーを公開し、SPF と DKIM の認証チェックに失敗したメッセージを受信メールサーバーがどう扱うか——監視（p=none）、隔離（p=quarantine）、または拒否（p=reject）——を伝えることができます。DMARC はまた、SPF または DKIM が認証したドメインが見える From ヘッダーのドメインと一致することを要求する、アラインメントの概念を導入します。さらに DMARC は集約レポートとフォレンジックレポートを可能にし、ドメイン所有者に、誰が自分に代わってメールを送信しているかへの可視性を与えます。

このガイドは、DMARC の完全ガイドの一部です。関連：DMARC レコード と DMARC ポリシー。

DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、SPF と DKIM を統合されたメール認証フレームワークへと結び付けるプロトコルです。DMARC がなければ、SPF と DKIM はそれぞれ独立して動作し、認証に失敗したときに受信サーバーが何をすべきかを伝える標準化された方法も、インターネット全体の認証結果に関するレポートを受け取る方法もありません。

RFC 7489 は DMARC を、メールを送信する組織がメッセージの検証・処理・レポートに関するドメインレベルのポリシーと設定を表明できる、スケーラブルな仕組みとして定義しています。受信メールサーバーはこれらのポリシーを利用して、メール処理の判断を改善できます。

DMARC は、SPF と DKIM だけでは解決できない 3 つの問題を解決します。

  1. ポリシーの強制 - 認証に失敗したメッセージを拒否・隔離・受理のいずれにするかを受信サーバーに伝えます
  2. アラインメント - SPF または DKIM が認証したドメインが、見える From ヘッダーのドメインと一致することを要求し、SPF や DKIM が受信者の見るドメインとは別のドメインで合格してしまう隙間を塞ぎます
  3. レポート - 標準化されたレポートの仕組みを提供し、ドメイン所有者が自分のドメインを使って誰がメールを送信しているか、そしてそれらのメッセージが認証に合格しているか失敗しているかを正確に把握できるようにします

DMARC の仕組み

DMARC の評価は、SPF と DKIM がすでにチェックされた後に行われます。その流れは次のとおりです。

  1. 受信サーバーが SPF をチェックする（送信元 IP はそのドメインの SPF レコードで認可されているか？）
  2. 受信サーバーが DKIM をチェックする（メッセージは有効な DKIM 署名を持っているか？）
  3. 受信サーバーが DMARC アラインメントをチェックする（SPF または DKIM が認証したドメインは From ヘッダーのドメインと一致するか？）
  4. SPF も DKIM もアラインメント付きで合格しない場合、受信サーバーは DMARC ポリシーを適用する

重要なポイントは、DMARC 自体は独自の認証チェックを行わないということです。DMARC は SPF と DKIM の結果を評価し、その上にアラインメントの検証とポリシーの強制を追加します。

DMARC の DNS レコード

DMARC レコードは、_dmarc.yourdomain.com に公開される DNS TXT レコードです。典型的な例を次に示します。

_dmarc.example.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; adkim=r; aspf=r; pct=100"
タグ意味値
v=DMARC1バージョン（必須）常に DMARC1
p=ポリシー（必須）none、quarantine、reject
rua=集約レポートの受信者mailto: URI
ruf=フォレンジックレポートの受信者mailto: URI
adkim=DKIM アラインメントモードr（relaxed）または s（strict）
aspf=SPF アラインメントモードr（relaxed）または s（strict）
pct=ポリシーを適用するメッセージの割合1〜100（デフォルト 100）
sp=サブドメインポリシーnone、quarantine、reject
fo=フォレンジックレポートのオプション0、1、d、s

任意のドメインの DMARC レコードは、DMARC チェッカー を使って確認できます。

DMARC ポリシー：none、quarantine、reject

p= タグは DMARC レコードで最も重要な要素です。SPF と DKIM のアラインメントの両方に失敗したメッセージを受信サーバーがどう扱うかを指示します。

p=none（監視のみ）

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

これは DMARC 導入の出発点です。失敗したメッセージに対して何もしない——通常どおり配信する——よう受信サーバーに指示します。p=none の目的は集約レポートを収集し、次のことを把握できるようにすることです。

  • どのサービスがあなたに代わってメールを送信しているか
  • それらのサービスは SPF と DKIM に合格しているか
  • アラインメントが正しく設定されているか
  • 認可されていない送信者があなたのドメインを使っていないか

より厳格なポリシーに移行する前に、少なくとも 2〜4 週間は p=none を使いましょう。 これにより、適切に認証されていない正当な送信元を特定して修正する時間が得られます。

p=quarantine

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=25

quarantine は、失敗したメッセージを疑わしいものとして扱うよう受信サーバーに指示します。実際には、これは通常それらを迷惑メールフォルダーに振り分けることを意味します。pct= タグを使うと、失敗したメッセージの一定の割合にのみ quarantine ポリシーを適用でき、段階的な展開が可能になります。

一般的な展開戦略は次のとおりです。

  1. p=quarantine; pct=10 から始める - 失敗したメッセージの 10% に quarantine を適用する
  2. 誤検知についてレポートを監視する
  3. pct=25、次に pct=50、そして pct=100 へと引き上げる
  4. 確信が持てたら p=reject に移行する

p=reject

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

reject は、SPF と DKIM のアラインメントの両方に失敗したメッセージを完全にブロックするよう受信サーバーに指示します。メッセージはまったく配信されず、送信者にはバウンスメッセージが返されます。

p=reject はドメインのなりすましに対して最も強力な保護を提供しますが、慎重に展開しなければなりません。いずれかの正当な送信元が適切に認証されていない場合、そのメッセージは拒否されます。AI フィッシングの脅威 がますます高度化する中で、強力な強制はいっそう重要になっています。

詳細ガイド： 監視から強制へ：スケーラブルな DMARC 戦略の構築

DMARC アラインメント：欠けていたピース

アラインメントは、SPF と DKIM を独立して実行することとは根本的に DMARC を異なるものにする要素です。アラインメントがなければ、攻撃者は自分自身のドメインに対して SPF と DKIM を設定し、そのドメインを Return-Path や DKIM 署名で使いながら、見える From ヘッダーではあなたのドメインになりすますことができてしまいます。受信者にはあなたのドメインが見えますが、認証は実際には攻撃者のドメインをチェックしていることになります。

DMARC は、次のうち少なくとも 1 つが真であることを要求することでこの隙間を塞ぎます。

  • SPF アラインメント - Return-Path（エンベロープ送信者）のドメインが From ヘッダーのドメインと一致する
  • DKIM アラインメント - DKIM 署名のドメイン（d= の値）が From ヘッダーのドメインと一致する

relaxed と strict のアラインメント

DMARC は各プロトコルについて 2 つのアラインメントモードをサポートします。

relaxed アラインメント（デフォルト）： 組織ドメインが一致していなければなりませんが、サブドメインは許容されます。

  • From: user@example.com で Return-Path: bounce@mail.example.com - relaxed SPF アラインメントに合格
  • From: user@example.com で d=mail.example.com - relaxed DKIM アラインメントに合格

strict アラインメント： ドメインが完全に一致しなければなりません。

  • From: user@example.com で Return-Path: bounce@mail.example.com - strict SPF アラインメントに失敗
  • From: user@example.com で d=example.com - strict DKIM アラインメントに合格

ほとんどの組織は relaxed アラインメントから始めるべきです。strict アラインメントは、サブドメインの管理が重要となる高セキュリティ環境に適しています。

詳細ガイド：

DMARC レポート：メールエコシステムの可視性

DMARC の最も価値ある機能の 1 つは、そのレポートの仕組みです。DMARC レポートは、あなたのドメインを使って送信されたすべてのメールについて——認可したかどうかにかかわらず——可視性を与えてくれます。

集約レポート（rua）

集約レポートは、受信メールサーバーが（通常は日次で）送ってくる XML 文書で、あなたのドメインの認証結果を要約したものです。次の内容が含まれます。

  • あなたのドメインを使ってメールを送信した送信元 IP アドレス
  • 各送信元からのメッセージ数
  • 各送信元の SPF と DKIM の合格/失敗の結果
  • DMARC アラインメントの結果
  • 失敗したメッセージに適用された DMARC ポリシー

集約レポートは、次のことのための主要なツールです。

  • あなたのドメインを使っている認可されていない送信者を発見する
  • 適切に認証されていない正当なサービスを特定する
  • 時間の経過とともに DMARC ポリシーの有効性を監視する
  • ポリシーのアップグレード（none から quarantine、そして reject へ）に備える

生の集約レポートは XML であり、手作業で読むのは困難です。DMARC Report のような専用の DMARC レポートツールは、これらのレポートを人間が読みやすいダッシュボードに解析し、どの送信元が認証に合格または失敗しているかを正確に示してくれます。DMARC Report は DuoCircle がまさにこの目的のために設計した補完的な製品で、集約レポートを取り込み、実用的なインサイト、傾向分析、アラートを提供します。

詳細ガイド： DMARC レポートを活用して SPF エラーを解決する方法

フォレンジックレポート（ruf）

フォレンジックレポート（失敗レポートとも呼ばれる）は、DMARC に失敗した個々のメッセージについてほぼリアルタイムで送られます。ヘッダーや、場合によっては部分的なメッセージ内容を含む、その特定のメッセージに関する詳細情報が含まれます。

フォレンジックレポートは次のことに役立ちます。

  • 特定のなりすまし事案を調査する
  • 個々のメッセージの認証失敗をデバッグする
  • 認証チェーンにおける失敗の正確な地点を特定する

プライバシーに関する注意： 多くの受信サーバーはプライバシー上の懸念からフォレンジックレポートを送信せず、送信するものについても個人情報を伏せる場合があります。フォレンジックレポートを DMARC データの唯一の情報源として頼らないでください。

fo= タグは、フォレンジックレポートがいつ生成されるかを制御します。

値意味
fo=0SPF と DKIM の両方が失敗した場合に報告（デフォルト）
fo=1SPF または DKIM のいずれかが失敗した場合に報告
fo=dDKIM が失敗した場合に報告
fo=sSPF が失敗した場合に報告

DMARC とスパム対策：別々の問題

よくある誤解に、DMARC はスパム対策ツールだというものがあります。そうではありません。DMARC はドメインの身元を認証します——送信者が名乗るとおりの人物かどうかを教えてくれます。メッセージの内容をスパムの特徴について評価するわけではありません。

メールは DMARC に合格しても依然としてスパムであることがあります（送信者は認証されていても、望まれない内容を送っている場合）。逆に、正当なメールが DMARC に失敗することもあります（認証が誤って設定されている場合）。DMARC とスパム対策フィルターは異なる層で機能し、互いを補完し合います。

詳細ガイド： DMARC とスパム対策は同じではない！

DMARC の導入：段階的な戦略

DMARC の導入は、正当なメール配信を妨げないよう、段階的なアプローチに従うべきです。

フェーズ 1：準備

  1. 送信元を監査する - あなたのドメインを使ってメールを送信するすべてのサービス、サーバー、プラットフォームを文書化する
  2. SPF を設定する - SPF レコード がすべての認可された送信者を含んでいることを確認する
  3. DKIM を設定する - すべての送信プラットフォームで DKIM 署名 を設定する
  4. アラインメントを検証する - SPF と DKIM のドメインが From ヘッダーのドメインと整合していることを確認する

フェーズ 2：監視（p=none）

  1. p=none と集約レポート用の rua= アドレスを設定した DMARC レコードを公開する
  2. 受信するレポートを解析する DMARC レポートプロセッサー（DMARC Report など）を設定する
  3. 2〜4 週間レポートを監視する
  4. 認証やアラインメントに失敗している正当な送信元を特定して修正する

フェーズ 3：quarantine

  1. p=quarantine; pct=10 に更新し、失敗したメッセージのごく一部を迷惑メールに振り分け始める
  2. 誤検知（正当なメールが隔離されること）についてレポートを監視する
  3. 確信が高まるにつれて pct= の値を徐々に引き上げる
  4. 誤検知なく pct=100 に達したら、フェーズ 4 へ移行する

フェーズ 4：reject

  1. p=reject に更新し、認証されていないメッセージを完全にブロックする
  2. 新しいサービスや設定ミスがないか、集約レポートを引き続き監視する
  3. サービスが時とともに変化するのに合わせて、SPF と DKIM の設定を維持する

詳細ガイド：

DMARC コンプライアンス要件

DMARC は単なるベストプラクティスではなく、ますます規制および業界の要件になりつつあります。同じことは、DMARC の強制を支える SPF コンプライアンス にも当てはまります。

Google と Yahoo の要件（2024 年以降）

2024 年 2 月以降、Google と Yahoo は一括送信者（Gmail または Yahoo のアドレスに 1 日あたり 5,000 通を超えるメッセージを送信する送信者）に対して DMARC 認証を要求しています。DMARC のないドメインは、配信性の低下を経験する可能性があります。

詳細ガイド： 主要なメールサービスプロバイダーが DMARC 導入を強調

PCI DSS 4.0

Payment Card Industry Data Security Standard（PCI DSS）バージョン 4.0 は、決済カードデータを処理する組織に対して DMARC を義務化しており、完全な強制は 2025 年に始まります。

詳細ガイド： DMARC は 2025 年までに PCI DSS コンプライアンスで必須になる

GDPR とデータ保護

DMARC の集約レポートは、組織が GDPR のデータ保護および侵害通知の要件を満たすのに役立つ、メールトラフィックへの可視性を提供します。

詳細ガイド： DMARC を実装して可視性を得て GDPR コンプライアンスを維持する

政府の要件

複数の政府が、政府ドメインに対して DMARC を義務化または強く推奨しています。これには英国（NCSC を通じて）、ニュージーランド、そして米国（BOD 18-01 を通じて）が含まれます。

詳細ガイド：

DORA（デジタル・オペレーショナル・レジリエンス法）

EU の DORA 規制は、金融機関に対する DMARC 要件と交差しています。

詳細ガイド： DORA と DMARC が交差する地点

よくある DMARC のエラーとトラブルシューティング

554 5.7.5 DMARC における恒久的エラー

このエラーは、受信サーバーが DMARC ポリシーに基づいてメッセージを拒否したことを示します。通常、SPF と DKIM の両方が From ヘッダーのドメインとの整合に失敗したことを意味します。

詳細ガイド： DMARC における 554 5.7.5 恒久的エラーとは何か、その修正方法は？

SPF は合格するのに DMARC が失敗する

これは、SPF がエンベロープ送信者ドメインを認証しても、そのドメインが From ヘッダーのドメインと一致しない（アラインメント失敗）ときに起こります。修正方法は、エンベロープ送信者があなたのドメインを使うように設定するか、一致する d= ドメインで DKIM を設定することです。

詳細ガイド：

転送されたメールが DMARC に失敗する

メール転送は SPF を壊します（転送サーバーの IP は元のドメインの SPF レコードに含まれていません）。DKIM が設定されていないか、転送サーバーがメッセージを変更する（DKIM 署名を壊す）と、DMARC は失敗します。解決策は DKIM が適切に設定されていることを確認することです。メッセージの内容が変更されなければ、DKIM 署名は転送を経ても維持されます。

DMARC と SPF の関係

DMARC は、SPF が正しく設定されていることに大きく依存しています。SPF レコードにエラーがある場合——10 の DNS ルックアップ制限を超えている、構文の誤りがある、認可された送信者が欠けているなど——DMARC の強制は、それらの認証失敗が隔離または拒否されたメールにつながる原因となります。DMARC を壊す前に、SPF の DNS ルックアップが多すぎる問題 の修正方法を学びましょう。SPF フラット化サービス で include を統合し、10 ルックアップ制限内に収めましょう。

DMARC を強制モードで展開する前に、SPF チェッカー で SPF レコードを検証し、SPF バリデーター を使って DNS ルックアップ数が制限内にあることを確認してください。

ルックアップ制限に近づく複雑な SPF レコードを持つドメインには、AutoSPF が動的な SPF フラット化を提供し、レコードを自動的に制限内に保ちます——これは信頼できる DMARC 強制のための重要な基盤です。

DMARC Report - DuoCircle の補完的な製品

DMARC Report は、DuoCircle 専用の DMARC レポートおよび分析プラットフォームです。AutoSPF と並んで機能し、完全なメール認証管理を提供するよう設計されています。

  • AutoSPF は SPF 側を担当します——動的なフラット化、DNS ルックアップの管理、SPF レコードの最適化。
  • DMARC Report は可視性の側を担当します——集約レポートの解析、認証失敗の特定、コンプライアンスの傾向の追跡、問題のアラート。

両者を組み合わせることで、メール認証の態勢を完全に制御できます。DMARC Report はあなたの rua= 集約レポートを取り込み、データを正規化し、どの送信者があなたのドメインの認証に合格または失敗しているかを正確に示す実用的なダッシュボードを提示します。

診断ツール

次のステップ

  1. 現在の DMARC ステータスを確認する - DMARC チェッカー を使って、DMARC レコードがあるか、どのポリシーを指定しているかを確認する
  2. p=none から始める - DMARC を導入していない場合は、監視モードから始めてデータを収集する
  3. レポート処理を設定する - 人間が読めるダッシュボードのために、rua= アドレスを DMARC Report に向ける
  4. 認証のギャップを修正する - 集約レポートを使って、SPF や DKIM に失敗するサービスを特定して修正する
  5. 強制へ進む - 認証のカバレッジが成熟するにつれて、quarantine から reject へと進める
  6. 継続的に維持する - メールインフラは絶えず変化します。レポートを監視し、必要に応じて SPF/DKIM の設定を更新する

SPF 管理ツールの完全な比較については、PowerDMARC の代替案、EasyDMARC の代替案、DMARCLY の代替案 をご覧ください。

Rated 5/5 on G2 · Trusted since 2018

Trusted by 50,000+ domains

"AutoSPF Flattens SPF Records Seamlessly & Keeps Changes Logged - I am quite pleased with the product"

It does what it promises to do, and does it very well. I appreciate that it keeps a log of changes made, which prevents many mistakes. A client's SPF record would have way too many lookups, but AutoSPF makes that problem go away. The length of the SPF record is typically not the issue; it's the amount of lookups in the record that are. AutoSPF "flattens" the record, automatically expanding the defined lookups to IP addresses or ranges. And it auto-updates the record when the un-flattened lookups change.
PJ

Peter J.

President · Small-Business (50 or fewer emp.)

"Helped us go beyond capacity"

AutoSPF did exactly as described, it helped us get past our 10 lookup limit. Afterwards, we hit another limit regarding overall capacity and when contacted, they quickly provided us with a new solution to eliminate capacity issues entirely going forward, so now we can add as many SPF records as needed. They also provided us with a personalized support video explaining their new method in its entirety using our instance as the example.
VU

Verified User

Financial Services · Mid-Market (51-1000 emp.)

"Great service and great support"

AutoSPF was easy to initially set up on our own and a great cost effective entry into spf flattening. Needed our first support assistance today and got great response including a video demonstrating the issue I was trying to solve, a quick fix, and more detailed followup.
GF

Greg F.

Mid-Market (51-1000 emp.)

Read our reviews on G2